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.
12

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.
DHCP Option 66 picks up the wrong value.
2023-02-16 20:13:42 - last edited 2023-02-22 05:33:15
Tags: #DHCP Service #DHCP Options
Model: ER7206 (TL-ER7206)  
Hardware Version: V1
Firmware Version: 1.2.3

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?

  1      
  1      
#1
Options
1 Accepted Solution
Re:DHCP Option 66 picks up the wrong value.-Solution
2023-02-21 14:54:57 - last edited 2023-02-22 05:33:15

  @KimcheeGUN 

 

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.

Recommended Solution
  3  
  3  
#5
Options
19 Reply
Re:DHCP Option 66 picks up the wrong value.
2023-02-17 17:41:12 - last edited 2023-02-17 17:42:40

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.

  1  
  1  
#2
Options
Re:DHCP Option 66 picks up the wrong value.
2023-02-19 14:46:44

  @greenaar 

 

I think @Fae  should take a look at this

I can not teach anyone anything - I can only make them think - Socrates
  0  
  0  
#3
Options
Re:DHCP Option 66 picks up the wrong value.
2023-02-21 13:32:49

  @greenaar 

 

Did you forward this to TP Link Support?

 

I'm about to enable PXE boot on my 7206 and curious on what they found?

 

 

I can not teach anyone anything - I can only make them think - Socrates
  0  
  0  
#4
Options
Re:DHCP Option 66 picks up the wrong value.-Solution
2023-02-21 14:54:57 - last edited 2023-02-22 05:33:15

  @KimcheeGUN 

 

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.

Recommended Solution
  3  
  3  
#5
Options
Re:DHCP Option 66 picks up the wrong value.
2023-02-28 14:36:06

  @greenaar 

 

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.  

I can not teach anyone anything - I can only make them think - Socrates
  0  
  0  
#6
Options
Re:DHCP Option 66 picks up the wrong value.
2023-02-28 14:51:32

  @KimcheeGUN 

 

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.

  1  
  1  
#7
Options
Re:DHCP Option 66 picks up the wrong value.
2023-02-28 15:21:47

  @greenaar 

 

Thanks dude!  Appreciate the info!

 

I can not teach anyone anything - I can only make them think - Socrates
  0  
  0  
#8
Options
Re:DHCP Option 66 picks up the wrong value.
2023-03-03 13:18:55

  @greenaar 

 

Quick Question, are you trying this in standlone mode and controller mode too?  Both fail?

 

Thanks,

KG!

I can not teach anyone anything - I can only make them think - Socrates
  0  
  0  
#9
Options
Re:DHCP Option 66 picks up the wrong value.
2023-03-03 14:54:30

  @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.

  0  
  0  
#10
Options
Re:DHCP Option 66 picks up the wrong value.
2023-03-03 15:06:26 - last edited 2023-03-03 15:06:43

My reply to them:

 

This is not a business network. It's a home network.  It contains work related and personal secrets which are not completely secured against internal access.
 
Your side confirmed *very early on* that they were able to replicate this issue in their lab.  Unsurprising, since it's 100% repeatable here too.  I even identified which two values (option 12 and option 66) were getting incorrectly set while running in standalone mode.
 
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.
 
If you need some additional piece of information, you'll have to tell me WHAT exactly you are looking for that you don't already have, and why you're unable to capture this information in your own lab.  Give me that, and *I* will gather that specific piece of information from my network and send it.
 
Otherwise I can only assume this tech support request has died, and that no support for this issue is forthcoming.
 
Can you bump this up another support tier? Get me closer to the people actually working on the issue? Let them explain directly what they're looking for?
 
I am not pleased.  Having no access to your router's source code, I have no idea what level of complexity awaits when swapping the contents of option 12 and option 66, but I'm really disheartened that additional requests for network access keep coming, when (as mentioned above) you've already confirmed the problem in your own lab.
  1  
  1  
#11
Options