Implementation of DHCP lease handling

[kmpm]

Requires a periodic call to the new method Ethernet.maintain()
http://code.google.com/p/arduino/issues/detail?id=716

[JerrySievert]

any possibility of this getting merged in? even when setting a static ip, my host is going offline as soon as a lease expires.

[JerrySievert]

any possibility of this getting merged in? even when setting a static ip, my host is going offline as soon as a lease expires.

[kmpm]

Can you please try it out an get back with your results. With more tests it will be easier to get it in.

[kmpm]

Can you please try it out an get back with your results. With more tests it will be easier to get it in.

[JerrySievert]

i had to back down to pre-1.0 for my production hardware, will try to set up another arduino/shield over the weekend with this patch.

[JerrySievert]

i had to back down to pre-1.0 for my production hardware, will try to set up another arduino/shield over the weekend with this patch.

[amcewen]

Thanks for implementing this. It doesn't seem to have broken anything - I'll report back whether it works in a few days after the lease has expired on the test Arduino I've just set up :-)

I'll also read through the code properly then too, but in the meantime, a few thoughts or items for further discussion that come to mind after a quick look at it...

1. I think it would be useful if Ethernet::maintain() returned a value to let the user know if the IP address had been renewed. Most of the time people would ignore it, but it's possible that a sketch would have read the IP address and so letting them know that it should be re-read is useful to have.

2. Do we need to keep the DhcpClass object around in the Ethernet object all the time? I can see why you've done that, as it keeps the DHCP logic all nicely self-contained, but it also means that any sketch using DHCP will lose around 50 bytes of RAM, which seems a lot when the ideal solution would just store a timeout value. I don't have an obvious solution, but thought I'd start the discussion and then revisit it when I'm doing a more detailed code review.

[amcewen]

Thanks for implementing this. It doesn't seem to have broken anything - I'll report back whether it works in a few days after the lease has expired on the test Arduino I've just set up :-)

I'll also read through the code properly then too, but in the meantime, a few thoughts or items for further discussion that come to mind after a quick look at it...

1. I think it would be useful if Ethernet::maintain() returned a value to let the user know if the IP address had been renewed. Most of the time people would ignore it, but it's possible that a sketch would have read the IP address and so letting them know that it should be re-read is useful to have.

2. Do we need to keep the DhcpClass object around in the Ethernet object all the time? I can see why you've done that, as it keeps the DHCP logic all nicely self-contained, but it also means that any sketch using DHCP will lose around 50 bytes of RAM, which seems a lot when the ideal solution would just store a timeout value. I don't have an obvious solution, but thought I'd start the discussion and then revisit it when I'm doing a more detailed code review.

[JerrySievert]

i am seeing much better behavior with this changeset.

[JerrySievert]

i am seeing much better behavior with this changeset.

[kmpm]

Nice to see that it worked.

1. I agree to 100%. Something for next week... Should it differentiate between a renewal and rebind ( new ip ) or just one return value regardless?

2. I was also annoyed with having the Dhcp object around but I couldn't find a clean and nice way of implementing it differently. C/C++ is not my native language so I might miss something obvious. If someone do have a way of fix it then please do it or describe how to do it.

[kmpm]

Nice to see that it worked.

1. I agree to 100%. Something for next week... Should it differentiate between a renewal and rebind ( new ip ) or just one return value regardless?

2. I was also annoyed with having the Dhcp object around but I couldn't find a clean and nice way of implementing it differently. C/C++ is not my native language so I might miss something obvious. If someone do have a way of fix it then please do it or describe how to do it.

[amcewen]

Still haven't had chance to dig into the code, but thought I'd at least report back on my testing so far - haven't actually seen it renew a lease :-/ Obviously that's not a very useful bug report, more of a comment on my investigatons. When I get time to look through the code properly I'll also

1. I don't mind particularly about differentiating between the two, but if it's easy to do then we might as well. If 0 is the "didn't do anything" return then in the trivial case where you don't care which it was out of renewal or rebind, you can just do "if (Ethernet.maintain())"

2. Again, will see if I can come up with something when I run through the code.

[amcewen]

Still haven't had chance to dig into the code, but thought I'd at least report back on my testing so far - haven't actually seen it renew a lease :-/ Obviously that's not a very useful bug report, more of a comment on my investigatons. When I get time to look through the code properly I'll also

1. I don't mind particularly about differentiating between the two, but if it's easy to do then we might as well. If 0 is the "didn't do anything" return then in the trivial case where you don't care which it was out of renewal or rebind, you can just do "if (Ethernet.maintain())"

2. Again, will see if I can come up with something when I run through the code.

[kmpm]

I'm closing this pull request and refer to the issue at http://code.google.com/p/arduino/issues/detail?id=716
The work is till in progress, just not in this pull request.

[kmpm]

I'm closing this pull request and refer to the issue at http://code.google.com/p/arduino/issues/detail?id=716
The work is till in progress, just not in this pull request.