XTCP DHCP Behaviour

[ChrisDodge]

We’re using the xTCP library V3.2.1 and have come across an issue with the DHCP behaviour. We get the occasional “port flap” where the Ethernet link goes down briefly, which can also be simulated by unplugging the network cable for a short time.

In this situation, the DHCP behaviour seems incorrect, so we’re wondering what the best behaviour is? At the moment, if the link goes down, the DHCP client is stopped. When the link comes up, DHCP is started and initialised, and so sends a DHCPDISCOVER packet to the router to start standard DHCP negotiation. Tracing the xTCP library code:

[tab=30]uip:linkdown()
[tab=30]dhcp:stop

[tab=30]uip:linkup()
[tab=30]dhcp:stop
[tab=30]dhcp:start
[tab=30]dhcp:init
[tab=30]dhcp:discover()

[tab=30]uip:echo
[tab=30]dhcp:discover()

When the router gets the DHCPDISCOVER, it is required to check whether the IP address that was in use by this device (i.e. associated with the MAC address) is still available, and it does this with an ICMP echo request to "ping" that IP. However, even though our DHCP client has been stopped, started and initialised, it behaves as if it has this IP address while DHCP negotiation is taking place, so responds to the ICMP echo. The router then thinks that the address is in use, logs an error and then gives our device a new IP address. The router’s log is:

[FVS336GV3] local7.info [DHCPD]: DHCPDISCOVER from 70:b3:d5:fd:10:0a via eth0.1
[FVS336GV3] local7.debug [DHCPD]: ICMP Echo reply while lease 192.168.1.198 valid.
[FVS336GV3] local7.err [DHCPD]: Abandoning IP address 192.168.1.198: pinged before offer
[FVS336GV3] local7.info [DHCPD]: DHCPDISCOVER from 70:b3:d5:fd:10:0a via eth0.1
[FVS336GV3] local7.info [DHCPD]: DHCPOFFER on 192.168.1.165 to 70:b3:d5:fd:10:0a via eth0.1
[FVS336GV3] local7.info [DHCPD]: DHCPREQUEST for 192.168.1.165 (192.168.1.1) from 70:b3:d5:fd:10:0a via eth0.1
…

The result is that the IP address of our device has changed from 192.168.1.198 to 192.168.1.165 caused by a simple cable unplug/plug, which doesn’t seem to be the correct behaviour. Two possible solutions would be:

1. The dhcp:init() function should really re-initialise the IP stack and so not allow the device to use that IP address (i.e. not respond to ICMP echos) until DHCP re-negotiation has completed.

2. The link going down does not stop DHCP, and so when the link comes up it can simply continue with the same IP address. This seemed to be the behaviour of the network module we used in the previous version of our product.

Does anyone have any thoughts or experience in this area, and in particular which approach is best? If we do number 1 above, what is the best way of re-init’ing the whole IP stack on a dhcp init (dhcp.c -> dhcpc_init())?

Thanks...

Chris

[louis]

Hi Chris,

Thanks for bringing this to our attention; it does indeed seem like incorrect behaviour! I will be looking in to this and hopefully issue a fix soon.

Cheers,
Louis

[louis]

Hi Chris,

I haven't been able to replicate the problem that you are having, although this likely to be because of differing DHCP servers. I am continuing to look in to this though and let you know the best fix.

Cheers,
Louis

[ChrisDodge]

Hi Louis,

Thanks for the replies and sorry about the delay in following up. Yes, I guess that a different DHCP server could behave differently and work out that the DHCPDISCOVER is from a device with a valid IP address.

If you unplug and re-plug the Ethernet cable, so you see the xTCP code send a DHCPDISCOVER request? We can create a small demo app for the slice-kit if that helps?

Our fix has been to not call the dhcp stop when the link goes down, and when it comes up again, we ignore the dhcp start/init etc if it has an IP address.

Best regards,

Chris