jordan.terrell
Just trying to make sense of things...

RFID Lock Prototype: DHCP Library v0.1

Sunday, 19 April 2009 22:11 by jordan.terrell

Update: This has been blogged about on the Makezine Blog – excellent!  Thanks to John Park for making this happen.

Well, I now have a version of the Arduino DHCP library that I feel moderately comfortable releasing to the wild. If you're interested in the background story, check out these posts.

       Download here: Arduino DHCP Library v0.1

I've tested it with an Arduino Duemilanove (ATMega168), but I'm positive that there will be bugs in the code and that for some (hopefully not many) people it will just plain not work.  If you do try to use it and find that it doesn't work, try using Wireshark to see what packets (if any) are flying across the wire.  Even if you can't figure it out, sending Wireshark capture logs to me will be helpful for me to debug.

In order to use the library, you need to drop the contents of the zip file into your "Arduino\hardware\libraries\Ethernet" folder.  There is a sample in the zip file called "WebClientWithDHCP" that is a modification of the standard Ethernet "WebClient" example.  There are the basic steps to get it working.

1) Add "#include "Dhcp.h" to the beginning of your Arduino sketch
2) Declare a variable of type Dhcp (e.g. "Dhcp dhcp;")
3) Call the beginWithDHCP() method, while providing it a MAC address

It has been a challenge writing this library, and I've just scratched the surface.  I don't have IP lease renewal, retry, cable detection, or even much error handling/reporting.  I'm just interested in getting feedback from the Arduino community to see if they find this useful and where to take the library next.

Enjoy!

Comments (8) -

April 20. 2009 11:39

raiderj

Sounds like an extremely worthwhile project! I'd be very interested to look more into your code to better see how DHCP works. Good luck!

raiderj

April 20. 2009 13:34

Ben Combee

Your code is clever -- it's not using a general UDP library, but instead just directly programming the Wiznet chip to send out the query and wait for a response.  I was originally wondering if you'd included the Client.cpp changes listed at www.arduino.cc/.../YaBB.pl?num=1238640832, but it looks like you're bypassing the Client class entirely.  That makes sense, as you can't really setup a client or server until you've got an IP address, and that's the main thing that you're using DHCP for.

Cool!

Ben Combee

April 20. 2009 13:49

Jordan

I don't know how clever it is, but I did want to keep it separate from the Client class because 1) it can be used in either client or server scenarios (server would be tricky, but doable) and 2) the current code base is ~3000 bytes and if you aren't going to use DHCP I didn't want to eat up that much program space unnecessarily.  In the future I will be looking for ways to lower the space used by the library - among other improvements.

Were you able to get the library working?

Jordan

April 20. 2009 23:19

J

I would be curious to see a tracefile(wireshark.org) of the DHCP as it is implemented here.

J

April 21. 2009 03:12

Zolty

Did the trick right out of the gate. Truly great work.

Zolty

April 21. 2009 06:26

Alastair Knox

Hi, great library. Your example webclientwithDHCP worked fine, it needed the 5sec delay uncommented prior to the dhcp.begin call.
I need to shrink my regular sketch a little to integrate the dhcp library, great work!
Alastair.

Alastair Knox

April 21. 2009 09:49

Jordan

Zolty/Alastair - I'm glad the library is working for you.

Alastair - I'm going to work on adding retry logic so that eventually you will not need to manually add a delay.  I also plan on finding some ways to shrink the size of the library.  I'm pretty sure some of the supporting code can be trimmed or eliminated.

Jordan

April 21. 2009 16:09

Ben Combee

One note -- Client is used by servers too -- you setup a server to wait for connections, but once one is made, you get a Client object representing the connection.  However, both Client and Server are pretty much tied to TCP, so they wouldn't be appropriate for UDP-type connections.

Ben Combee

Pingbacks and trackbacks (13)+

Comments are closed