USG110 - DHCP Discover failed on WAN1 Port

USG_User

Hi Peter and Stan,

I'm not so deeply digged in the DHCP standard, but for my understanding, when DHCP server has sent a NAK, the client has to completely initialize a new DISCOVER and must not still sending REQUESTs as broadcasts until the original lease finally runs out!

As example for understanding please refer to following diagram which is showing the right order of DHCP events: http://www.tcpipguide.com/free/diagrams/dhcpfsm.png

BTW: Our ISP is sending these NAK packets from time to time because they are presently extending their fiber network where IP ranges are changing. Whenever they have changed anything in their configuration, they let the DHCP server send a NAK to ALL clients to enforce them to make a DISCOVER for obtaining the new IP configuration by DHCP. And allthough our IP remains always the same, we are affected as well.

@Stan: Nevertheless we are saving all packets and will provide you with in the next minutes by PM

PeterUK

So the fix I said would work then but will zyxel go for it? Really why should the DHCP server when reset send out NAK in the first place? I guess its part of the protocol but why not just accept the request?

USG_User

Hi Peter,

In the meantime the conversation with Zyxel_Stan has been switched to private channel where I've provided him with the full set of captured DHCP packets. Further I've provided him with our IP renewal procedure after the IP config has been lost. In such case we do not interupt the physical connection, but only go to the USG dashboard > interface status summary > and click on the button RENEW which releases a DHCP DISCOVER. This RENEW button is only visible for DHCP configured ports, in our case WAN1.

Presently, for me, there is a bug in Zyxel's DHCP implementation. As per  different internet descriptions, as already said above ...

e.g. (source: http://www.tcpipguide.com/free/diagrams/dhcpfsm.png)

... whenever receiving a NAK, which means "Not ACK", the DHCP Client has to forget its IP configuration, irrespective whether the lease is not yet expired, and has to completely re-init with a DISCOVER packet as broadcast (that's why it is starting with own source address 0.0.0.0).

 But USG wrongly is still sending REQUESTs. The only difference is, that, after receiving the NAK, these REQUEST packets will not longer sent as unicast but as broadcasts, where the DHCP server doesn't react to.

But as per the image above, broadcast REQUESTs may only be sent in case T2 of the lease is already expired, but your IP configuration is still valid. But again, receiving a NAK let become your IP config immediately invalid and you have to start with a DISCOVER again.

USG_User

@Zyxel_Stanley:

Our ISP is helping us a little bit and has agreed to send NAKs (for implementing changed IP config to its clients) only at night, that our daily business is not regularly interrupted. Allthough in such case the USG is switching to our WAN2 line by "Fail-over Procedure", all VoIP and Video Sessions will be interrupted and have to be re-initialized. This is very annoying.

That's why it's a little bit urgent to investigate and solve this problem.

Thank you.

USG_User

Because we didn't receive a patched FW until now, we have put another Router (AVM Fritzbox) in between of the USG and the ISP's Cisco Fiber Switch. The Fritzbox has immediately made a DHCP DISCOVER like expected and like USG has made. So far so good. Now we are waiting for the next NAK packet to see how the Fritzbox DHCP client will handle this event.

USG_User

Today the added router (Fritzbox) in between of USG and ISP's Fiber Switch has received DHCP NAK packets two times. And both times it answered with a new DHCP DISCOVER as it should be as per standard. So for us USG is failing on react to DHCP NAK pakets on WAN port.

USG_User

Sorry for the delay, I was 2 weeks out of office.

Now we would like to install forums firmware WK28 as recommended by Zyxel_Stan since this FW should contain a DHCP improvement. But in the meantime also 4.65 AAPH.1 has been released. Does AAPH.1 also contains the DHCP improvement or should we still try WK28 first? (presently we are running v4.65 AAPH.0)

Zyxel_Stanley

Hi @USG_User
4.65 AAPH.1 not merge the fix yet. You can have a try forum release to confirm if it has any help. 

USG_User

Hi Stan,

Today we received a new DHCP_NAK packet from ISP DHCP server which let the USG fail again, also with WK28 firmware! After receiving the NAK packet the USG lost its IP and was permanently sending REQUEST packets instead of DISCOVER until we manually released a renewal of DHCP lease.

I've sent you more details including captured DHCP packets by PN

PeterUK

Guess it depends on who is right but unlikely ISP will put in a different DHCP server.

On the one hand it can be on a request when you have done a discover that receiving a NAK on a request that a request gets you a IP from the server without doing a discover.

On the other hand can be on a request when you have done a discover that receiving a NAK on a request that a request gets you no IP and you have to do a discover because the DHCP server has cleaned its table and will not accept requests as part of its working operation.

One thing I can think of if there is a risk of someone on the network sending a NAK other then the ISP...but then ISP should be blocking that...so yes zyxel will need to change the way the DHCP client runs on receiving a NAK.

I have yet to receive a NAK from my ISP to compare 

Testing here with XP running ICS as the DHCP server as its the only one that send NAK

DHCP client VPN300 on V5.02(ABFC.1)ITS-WK32-2021-08-09-210800242 with dhcp unicast on/off not that XP handle the unicast correctly but still worked.

dhcp unicast on

dhcp unicast off

From testing on the VPN300 it seems when XP sends a NAK a discover is sent after here just fine.

tested on zywall 110 with V4.65(AAAA.1) same thing so maybe the bug only happens to the USG 110?

edit however looking at your NAK vs my NAK the Client IP address and Your (client) IP address is 192.168.2.3 vs your 0.0.0.0 maybe thats the reason?