Has anyone approached the DHCP problem with anything other than the “reboot every 24 hours” approach?
Do you mean the Dhcp lease renewal?
sorry, yes, the fact that the lease expires and not be renewed.
I suggest that you try to have a timer that renew the lease for example every 12 hours.
I think what Brett is asking “how to renew it?”
Actually, Gus is somewhat right, but perhaps I should explain more. I am about to embark on my first real network connected Panda and wondered if anyone had put in place a workaround to deal with the “known issue” as documented in the SDK readme. My preference isn’t to force restart the device because it will have some active sensor measurements that require effort to maintain sync with the physical environment, although the chances of that being an issue at say midnight are very small. That periodic forced restart seems to be the approach others have taken so far. I wondered if anyone else had taken a different tack?
Here’s the API reference for W5100 renew:
http://www.ghielectronics.com/downloads/NETMF/WIZnet%20Library%20Documentation/html/83433ed7-4b25-e25c-9674-7a395d196f79.htm
I am assuming, but don’t know for sure, that this call currently doesn’t work and is the “known issue”? Or is it simply that unless you explicitly call this and get a (re)new(ed) lease, the lease will expire and the IP address becomes invalid?
One of the other issues is that to implement a real DHCP solution at a software layer, you need to know how long the lease is granted for, to implement a “half-life” renewal like DHCP is meant to have - we currently don’t have a way of exposing that in the API. A quick look in the main netmf DHCP related calls, that info isn’t available there either, so it’s obviously a shared problem for both the core networking stack and W5100 - although how lease expiry/renewal is handled in the core networking must be behind the scenes?
Failing knowing the lease duration, I guess one should be periodically checking and detecting that the IP address on the interface hasn’t changed - assuming that the address is actually dropped from the interface when the lease is up. Is there any way to attach an event to that, short of having a polling thread look every 10 secs or something?
Brett,
RenewDhcpLease() method should work fine and it what is does is it simply request for a new Dhcp lease. This is the method I suggest that a time to call it every certain time. Maybe you can give the user the option to set this time.
I agree with you that currently there is no way to know the lease duration in both the wiznet library and the original netmf libraries. But I don’t think if the lease was expired the device will lose connectivity. I think there would be very little chance that the DHCP server (if the DHCP is a poor) will give that IP to another device. I am saying “poor server”, because usually DHCP server checks if an IP address is available and not used before giving it away to another device.
I always thought DHCP put the emphasis for collision checking back on the client rather than the server - but I know many “dumb” servers ie home ADSL routers probably check in some way. But it’s still a risk, right - your lease expires, there’s no other free addresses in the range, and it gets allocated to a new device; Bam.
I also wonder what an acceptable time is to renew the lease. My DHCP server says 12h “default” and 24h “maximum”, so for me 10h seems sensible, but to avoid issues I might initially set every 2 hours (4 packets in 2 hours doesn’t seem too onerous does it ? 
)
Agreed that to be more robust we need to know the DHCP Lease conditions which is probably a good suggestion to have in the netmf.
Hi,
Just to let you know, my library “NetConfig” ( http://code.tinyclr.com/project/308/netconfig-wiz5100-http-configuration-framework/ ) addresses the problem, with a configurable dhcp release timer.
It also addresses another problem, that you may not have noticed : you you should always renew the dhcp lease after an ethernet cable is disconnected, reconnected (is this in the same network ?). For that, the same library “NetConfig” monitors the link status led (add a wire) and does the job.
I have been using now the Netconfig class for months, with boards running it without rebooting for months, and never crashing (and not recovering) or leaking a single byte of memory.
This may not be the prettiest network class for the usbuzi, however it was made to be stable for professional applications. I have seen also http://code.tinyclr.com/project/426/fez-connect-web-server/ from jasdev, it looks gorgeous and much more powerful, however I had no time to test it for stability, dhcp renew problem and cable disconnect / reconnect monitor, I don’t know if it handles it !
Have Fun 
Brett,
Nicolas is right. He has a lot of good stuff in his code to handle network disconnections. I purposely left that out of my code because I didn’t need it in the project I was working on, but if you want your network connections to be more reliable you should follow Nicolas’s example.
Thank you Nicolas 8)
I can second that. I’ve using a modified version of this for some home automation since it was released. It’s very robust.
thanks for the fine words guys, Nicolas, Jasdev in particular for your projects and shared code.
I am only just starting out on this project (and really, on anything more than proof of network connectivity app). A couple of days ago I grabbed Jasdev’s app and loaded it up to see if it was a starting point I could use, and certainly it seems so - in fact, theres so many positives about that code I can’t say them all. And in the past I had your code on my watch list to Nicolas, and given their similarity and history I think there will certainly be things I will use from both. (as an aside, both of your code bases have taught me a lot about C# programming styles too!) I would like to deal with DHCP and network disconnects reliably, and since I am using WIZ812MJ modules on perfboard, I already catered for the link LED being connected to a pin, so I’ll be taking a deeper look in at Nicolas’ handling of that. The reason I started the thread was I thought, obviously incorrectly, that your code essentially used a regular reboot to renew the lease (and my app is a little sensitive to that) but that must have come from an early discussion and not from the latest code.
Joe, out of interest and if you know off the top of your head, how does the core netmf networking handle lease expiry, if at all? Are these hurdles ones that need dealing with there as well?
[quote]Joe, out of interest and if you know off the top of your head, how does the core netmf networking handle lease expiry, if at all? Are these hurdles ones that need dealing with there as well?
[/quote]
I am going to be honest with you. I don’t know. ;D. We use the closed source RTIP stack with NETMF 4.1.
@ Joe,
-
Are you sure you are running the RTIP stack on the Wiznet5100 chip, because as far as I understood, the TCP/IP stack was built in within the wiznet chip ?
-
Would it be possible, in a future sdk update to be able to read a property of the lease duration as received from the DHCP OFFER packet, so we can trigger a timer in our classes for the DHCP renew operation with accuracy ?
Thank You !
@ Joe, thanks. Yep, know it’s RTIP in the core netmf. @ Nicolas, Joe’s answer was to my “core” netmf question not for Wiz5100.
The reason I asked that was that the Wiz5100 implementation is obviously a “parity” situation with the core netmf. I would like to see the DHCP info you request made available in the core netmf IP stack(s) and then we can get updated wiz5100 support and have parity again, and give the best of both worlds.
i have to say I like the fact that both the core feature set that @ nicolas and @ jasdev have added allows a device to come up on DHCP and someone to change it to fixed IP address, which in my view is a great “plug and play” device capability; you get network connectivity and then you can tweak it for permanent emplacement in the network (if you like hard coding IP addresses). That does mean you can somewhat avoid the DHCP lease issue but its still something worth explicitly handling in my view.
[quote] Would it be possible, in a future sdk update to be able to read a property of the lease duration as received from the DHCP OFFER packet, so we can trigger a timer in our classes for the DHCP renew operation with accuracy ?
[/quote]
We will look into it