@KimcheeGUN 

That's correct.  They want remote access to a host on my network.

That's a non-starter.  There's no reason given which would explain why access to one of my systems would give them more than they already have, since they have said they can reproduce the issue locally.

I have enough of a mix of business and private data that I'm not comfortable letting an unknown external entity have free access to poke around, nor do I think they've given any reason why they'd need it.  They haven't asked me for more information since their last overreach (give us your full router config, including port forwards, mac address details, etc) which they admitted wasn't required.

It sounds a lot like either:

a) There's a script of things you COULD ask for, and they're going down the list regardless of whether or not it applies (get me everything)

b) They are reluctant/unwilling/unable to do this work, and they're looking to me to say 'oh forget it' by asking for increasingly private details and extended access. (Say no by saying 'yes but do this first').

I'll admit I'm getting rather salty about these requests.

2 DHCP options.  12 and 66.  The values are reversed.  Option 12 should contain the details currently in option 66, and option 66 should contain the details in option 12.

I'm sure there's one file in their source code that maps dhcp options from provided values.  It's obvious someone goofed at some point.  It's not obvious why it's so hard to address, or more disturbingly why they need more and more information for a problem they can see on their side. If they think they've fixed it, GREAT. Send me a firmware, I'll test it.  I can prove/disprove a fix with wireshark in about 12 seconds.

  @KimcheeGUN 

Please confirm for me, it sounds like you're using the Omada SDN controller, and not running this in standalone?

If you are and it's working, let me know, and I'll just go that route - I feel like the config should work properly in standalone mode, but I'm also at the point where if I can make it work at all, I'll take works over perfect.

  @KimcheeGUN Hmm. Ok.

I have an OC200 I can use, but with firmware 5.7.6 it lacks option 67 (PXE filename) and only has option 66. - so that's also a nonstarter.  At best I'd get the right server with no filename.

I think I'm stuck until either

a) a new firmware comes out for the OC200 with the right setting(s)

b) a new firmware comes out for the ER7206 with the fix for option 12/66.

Thanks for letting me know there is a combination that works, it's a shame it's not one I can use at this time.

An update from TPLINK Support

Update:

TP-Link support sent me a beta 1.3.0 firmware this morning, which DOES support PXE properly.  Tested it, everything is perfect.

I've let them know, and hopefully they'll release it soon, we should be almost due for the 1.3.0 beta for the ER7206 in their release thread.