DHCP Option 66 picks up the wrong value.
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.DHCP Option 66 picks up the wrong value.
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
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
I did forward it to them. I then also sent them a (requested) wireshark dump of dhcp requests showing the issue, as well as my LAN configuration.
They were able to confirm that yes, it's a real problem, and yes, they were able to duplicate it on their side.
It's been escalated and pushed to their R&D team, hopefully to result in a speedy fix.
- Copy Link
- Report Inappropriate Content
An update.
It looks like Option 12 (server name) is getting set in place of option 66 (next server).
Wiresharked results sent to TP support, sadly it'd definitely trigger the 'illegal link in content' alert that seems to be part of this forum software, so i'll mask the filename, but it's correct.
Dynamic Host Configuration Protocol (ACK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x5c00dcb9
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 172.16.2.161
Next server IP address: 172.16.2.1
Relay agent IP address: 0.0.0.0
Client MAC address: WistronI_5a:ab:ef (48:2a:e3:5a:ab:ef)
Client hardware address padding: 00000000000000000000
Server host name: 172.16.2.46
Boot file name: netboot<FILENAME IS CORRECT HERE>
Magic cookie: DHCP
Option: (53) DHCP Message Type (ACK)
Option: (54) DHCP Server Identifier (172.16.2.1)
Option: (51) IP Address Lease Time
Option: (58) Renewal Time Value
Option: (59) Rebinding Time Value
Option: (1) Subnet Mask (255.255.255.0)
Option: (28) Broadcast Address (172.16.2.255)
Option: (81) Client Fully Qualified Domain Name
Option: (15) Domain Name
Option: (6) Domain Name Server
Option: (3) Router
Option: (255) End
As you can see, the wrong data is getting pulled. Option 66 is definitely set for 172.16.2.46, and there's no Option 12 available to set, so I'm not sure how they're getting mixed up.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Did you forward this to TP Link Support?
I'm about to enable PXE boot on my 7206 and curious on what they found?
- Copy Link
- Report Inappropriate Content
I did forward it to them. I then also sent them a (requested) wireshark dump of dhcp requests showing the issue, as well as my LAN configuration.
They were able to confirm that yes, it's a real problem, and yes, they were able to duplicate it on their side.
It's been escalated and pushed to their R&D team, hopefully to result in a speedy fix.
- Copy Link
- Report Inappropriate Content
A new beta release has come out... Are you able to run it and see if that fixes PXE boot?
Did say something about option 67. Being "supported" IDK if that means "fixed"?
The reason I'm asking is due to the fact that I'm on the edge of installing the same router and I NEED PXE boot working.
By chance, I found your post and super curious.
- Copy Link
- Report Inappropriate Content
I can confirm this latest beta firmware (20230224) does NOT fix the issue.
Option 66 remains incorrectly set to the gateway ip, and option 12 is instead set to the PXE server.
I've sent a request for an update to the in-progress support ticket, I'll post here if I hear back.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Quick Question, are you trying this in standlone mode and controller mode too? Both fail?
Thanks,
KG!
- Copy Link
- Report Inappropriate Content
@KimcheeGUN I've only tried this in standalone mode, and I can confirm failure there - I've been reluctant to change any more variables until this one is solved.. which at this rate I'm less confident:
"Can we arrange a remote session through TeamViewer? Our R&D team need a remote session to address the issue."
They have my Lan config, they have a wireshark dump of the dhcp request and response, and they confirmed early on they were able to replicate this in their lab. I can't think of ANYTHING they could need that hasn't already been provided.
In the past I've seen people say no by saying 'Yes, but i need you do do this additional thing' over and over until the requester gives up. This really feels like that.
I'm now considering whether or not I'll have to just turn off DHCP entirely on the router, and use a server based alternative. I'm not pleased.
- Copy Link
- Report Inappropriate Content
My reply to them:
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 2532
Replies: 19
Voters 1
