DHCP Option 66 picks up the wrong value.
DHCP Option 66 picks up the wrong value.
![](/avatar/default.png)
On the latest non-beta firmware on an ER7206 in standalone mode.
Option 66 is set to x.x.x.46
Option 67 is set to the correct .kpxe file (whose name i can't post due to the forum software thinking it's an external link)
Default gateway is set to x.x.x..1
On attempting a PXE boot, 'next server' reports back as x.x.x.1. The boot file is attempted from that ip, instead of x.x.x.46 as expected. The filename is correct however, so option 67 is working.
Setting Option 150 (with or without option 66) has no effect, so it looks like option 66 is getting ignored or incorrectly substituted.
Has anyone run into this and resolved it?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
I got a wild hair up on my rear end... Just to confirm this issue and help test this issue.
I had 1 remote site (Corporate IT) that has a Windows Server 2016 WDS/MDT for PC imaging.
I went ahead and swapped out and ER-X (EdgeRouter X, that PXE Boot is working and operational, with Omada Switches, and APs) for the ER7206.
Brand new out of the box... updated to the newest Beta Version: 1.2.3 Build 20230224 Rel.60828
Entered into the Controller, 599 version:
Entered in LAN (VLAN 1) configs, Option 66 <IP Address of MDT Server>, Option 67 <wdsnbp dot com>, Option 138 (L3 adoption to Main Omada Controller 599 version). Site 2 Site VPN is configured too.
Plugged it up, swapped out, Adopted, fired up a test laptop to be imaged... and it grabbed!
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
I am using the Omada Controller 599 on the newest beta version. I have a self hosted controller that I L3 adopt remote sites too.
- Copy Link
- Report Inappropriate Content
@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.
- Copy Link
- Report Inappropriate Content
An update from TPLINK Support
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
![](/avatar/default.png)
Information
Helpful: 1
Views: 2210
Replies: 19
Voters 1
![voter's avatar](https://static-community.tp-link.com/icon/c188b9abc4a544f59a7962a438df2174.jpeg)