Hi @Nierd 

Thanks for posting in our business forum.

Nierd wrote

ER605 still not changing next server address with option 66 as of this release - I know this was fixed on the E7206 earlier this year - do we know if this is on the 'list' to fix for the 605 at some point?

How do you verify and make this comment? Can you share your Wireshark results?

Put up the proof with some concrete results so I can better submit this issue to the dev.

Hi @SingletrackMind 

Thanks for posting in our business forum.

SingletrackMind wrote

  @Clive_A 

 

It seems this firmware has introduced a bug in DHCP reservations, at least for new clients.  I've had several reservations set for some time now and as far as I can tell, those are still being respected.  However, I've replaced one of my devices (an AppleTV) with a new model.  I deleted the previous reservation for that IP address and old MAC then created a new reservation for that IP with the new MAC.  The new device refuses to take it.  I also just tried creating a bogus reservation (fake MAC) to reserve the IP this new AppleTV keeps taking.  I can see an event on the controller where the device was rejected from getting that wrong IP, now that it's reserved for a fake MAC, but that device still didn't take on the reservation for the IP address I want it to take, it just picked another one.  I've triple checked that I have the correct MAC address on the reservation and it is enabled.

 

I have also completely deleted and recreated the reservation again, and another bogus reservation for the 2nd IP address it picked up after the first attempt, and it still refuses to take the IP address I want it to.  It seems as though the reservation is working in the sense of blocking a client from taking it if the MAC address doesn't match but it's refusing to hand out the reserved IP address as per the reservation.

 

And yes, the IP address I've set for the reservation for this device is withing the DHCP scope range, in fact it's the first address in the range and isn't currently in use by any other client.  Lastly, I've tried setting the reservation to an IP address that's NOT the first in the scope range and it didn't take that one either.

 

Controller is Linux version 5.12.7 (beta)

Delete the reservation in the DHCP reservation for this new AppleTV. Then make sure the router is connected during and after the reservation.

Then create the new DHCP reservation, after the creation, reboot your AppleTV instantly.

It should gain the new IP address from the DHCP server.

Here's the thing, if a device received a DHCP IP prior to your reservation, it would not take the IP until its lease time is over. Then new DHCP request and the device gets the new IP.

Try the steps I gave above and see if the AppleTV can get the new and correct IP address after the reboot.

Hi @Nierd 

Thanks for posting in our business forum.

Nierd wrote

  @Clive_A 

No problem

 

Attched the DHCP packet log so you can view the raw data - of note:

 

Next server IP address: 192.168.1.1

no option 66 sent - 67 is sent correctly

I'm not deep enough into the tech knowhow of the DHCP protocol to understand but I'll copy the TP link tech support answer here:

 

"

An update from TPLINK Support

 

The issue may be caused by that the PXE boot clients does not support DHCP option 66, and get host address of the TFTP server from the next server IP field. However, currently ER7206 does not support modifying next server IP field, and it is DHCP server IP as default, so the TFTP request from the client is sent to the DHCP server and fail to get the boot file.

"

 

 

As mentioned in the following forum thread where this is discussed for the 7206 and fixed by a firmware earlier this year - same situation and behavior.

https://community.tp-link.com/en/business/forum/topic/599398?sortDir=ASC&page=2

 

Seems that you have contacted the support by email. So, I had a conversation with the senior engineer yesterday about this matter.

We noticed an increase in the PXE boot issue recently. It seems to be the next-server is not supported and it is the root cause for the issue that your PXE cannot boot up with the DHCP options 66 and 67 having been correctly set.

After the conversation, I was informed that there will be a new firmware to address the missing of next-server on the router.

When that is added, your problem should be fixed.

ER7206 does not experience this issue.

Hi @SingletrackMind 

Thanks for posting in our business forum.

SingletrackMind wrote

  @Clive_A 

 

I've done exactly that, at least 4 times now, and it's not working.  I even manually set the desired IP on the AppleTV, hoping that after setting it back to DHCP, it would pull that very IP as reserved.   It did not, it pulled yet another random IP from the scope.

Turn off AppleTV and write down your AppleTV MAC. Clear the binding and reboot the router and controller and let the router reboot its services. After the boot of the controller and router, fill in the MAC address and desired IP. Boot up the AppleTV.

BTW, how did your AppleTV connect? Wireless or wired? Does it support virtual MAC addresses? I don't know if tvOS supports virtual MAC to protect your "privacy" that Apple calls.

Hi @SingletrackMind 

Thanks for posting in our business forum.

SingletrackMind wrote

Clive_A wrote

Hi @SingletrackMind 

Thanks for posting in our business forum.

SingletrackMind wrote

  @Clive_A 

 

I've done exactly that, at least 4 times now, and it's not working.  I even manually set the desired IP on the AppleTV, hoping that after setting it back to DHCP, it would pull that very IP as reserved.   It did not, it pulled yet another random IP from the scope.

Turn off AppleTV and write down your AppleTV MAC. Clear the binding and reboot the router and controller and let the router reboot its services. After the boot of the controller and router, fill in the MAC address and desired IP. Boot up the AppleTV.

 

BTW, how did your AppleTV connect? Wireless or wired? Does it support virtual MAC addresses? I don't know if tvOS supports virtual MAC to protect your "privacy" that Apple calls.

  @Clive_A 

 

That actually worked!  I'm certainly pleased to get this issue solved, however, I'm disturbed by the completely unacceptable measures required on what is supposed to be a business class system to get there.  What steps will be taken to resolve whatever code bug is causing this?  I did run a download of the router's "device info" from the controller earlier today as I was expecting that to be requested at some point.  If you feel this downloaded ZIP file would be of use for finding and resolving the code bug, please provide a method for me to update the file in a secure manner.

It might be a single case. I'd like to wait for a while and see how other feedback on this. My concerns about this problem were that

1. AppleTV was constantly requiring THAT IP address. So this issue persists when you try anything on the router.

2. The system did not sync the information correctly. I mean the controller and the router. They need to sync the information. It is rare to see unsynced problems.

3. The router is based on the Linux system. There might be a problem with the ARP table or DHCP reservation rules. When you delete it, it does not successfully sync from the controller or stick there and glitch out. So rebooting would fix it.

Most of the time, it would be the DHCP client issue as the phase of DHCP request and offer may encounter an issue. This is not included in the Device Info. Usually, need you to Wireshark and find out how they interact.

Glad to know that the steps resolved this. This solution is kinda universal to any DHCP problems. It just clears the cache left on the router and the client so they can start a brand-new connection. Request and offer the correct IP address.