We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a question about what to do if the ethernet link goes down (eg someone pulled the cable out) while TCPnet is running.
It mostly seems to be fine in that the ethernet traffic resumes if the same cable is replaced. However, my understanding is that if DHCP has been used to obtain an IP address, then the DHCP should be used to renew the lease when the link comes back up, which TCPnet does not do.
TCPnet seems to assume the old IP address is still OK. It *probably* will be if it is reconnected to the same network, but almost certainly won't be if it is connected to a different network.
I can't find a way of forcing the correct behaviour through the API.
Comments?
Christopher Hicks ==
"TCPnet seems to assume the old IP address is still OK."
That would be correct - The IP address has been given to the device by the DHCP server for the duration of the lease.
If the device were disconnected when the lease expired, then it would have to acquire a new lease on re-connection.
But, in fact, the cable would have to be disconnected for more than half of the trailing time of the lease, because the device should attempt to re-new at 50% of the lease time.
"That would be correct - The IP address has been given to the device by the DHCP server for the duration of the lease."
That's a fair point, and is valid as long as the reconnection occurs to the same network. However, it doesn't apply if the device is reconnected to a different network. My laptop gets a new lease by DHCP every time the link comes up, and not just when the old lease has expired. Thus I can move it between networks without rebooting. I would like TCPnet to behave the same, but I begin to think it cannot do this.
Christopher Hicks
"However, it doesn't apply if the device is reconnected to a different network."
To do that, you'd first have to detect that the link was down. Probably easiest to check the appropriate PHY register. Then you'd have to give the DHCP client a kick. Unfortunately I think you're right - I cannot see any such facility in TCPnet.
Now if Keil had a sensible pricing structure to gain access to the TCPnet source ...