DHCP working! (code now attached)

Roy Eltham · 2010-11-14 05:16

DHCP code for the Spinneret Web Server

I've updated this to be more of a module you call from your code instead of being stand alone. Although, I did leave in a commented out section at the top that you can put back in to run it stand alone and test.

Usage info:
1. Call Start
2. Immediately call SetMAC_Address() passing in the address of an array of 6 bytes containing your MAC address from the sticker on the bottom of your Spinneret.
3. Now call DoDHCP(). The first parameter is the socket(0-3), and second is an ID which can be anything you want.
4. If DoDHCP() returns SUCCESS, then you can call the various GetXXX() functions to get the IP, Gateway, SubnetMask, etc.
5. Call Stop

Applied fixes for bugs reported by jstjohnz.

I've removed the file from this message, the latest version is available in the google repository here: http://code.google.com/p/spinneret-web-server/source/browse/trunk/DHCP.spin

Q*bert · 2010-11-14 06:42

Great! Can't wait to try it!

Oldbitcollector (Jeff) · 2010-11-14 10:53

Awesome Roy! This will help with those configuring.

OBC

Roy Eltham · 2010-11-15 09:21

I've attached the code to the first message. Let me know if this does or doesn't work for you.

If you get Error 2, that is a timeout waiting for the server. The demo code in main just tries once, but normally you would call DoDHCP() a few times if the result is a timeout. I plan to implement the proper timeout/retry protocol from the DHCP spec, but until then what's there will get you going in most cases.

Also, it's up to you to redo the DHCP just before the Lease runs out. I'll be adding a proper Renew function soon, but I plan to leave it up to you to call it at the appropriate time.

$WMc% · 2010-11-15 11:28

Roy Eltham wrote: »

I just got my Spinneret to communicate with my Router's DHCP server to get it's configuration (IP, Gateway, and Subnet Mask).

It's all pretty ugly code right now. I'll clean it up after I get some sleep. Then I'll post it here for you guys (hopefully Sunday Evening/Night 11/14/2010).

Just wanted to share!

Here's the cleaned up code. It's not final yet, but I figured I'd share it with folks so they could try it out.

Be sure to edit in your MAC Address in the CON section near the top. You should have your MAC address on a sticker on the bottom of your Spinneret Web Server.

'
Hello Mr.Eltham
'
Thanks for posting the code DHCP.spin
'
I can't seem to find the Object "Brilldea_W5100_Indirect_Driver_Ver006.spin".
'
All I can find is Brilldea_W5100_UDP_Echo_Demo_indirect_Ver005.spin
'
I don't feel too stupid since google can't seem to find it either.
'
Could You post the Driver or a link to it?
'
I look forward to trying out Your code.
'
Thanks again.

Roy Eltham · 2010-11-15 11:52

Sorry, I forgot to mention that it uses the Wiznet 5100 driver written by Timothy Swieter. It's on the obex here.

$WMc% · 2010-11-15 13:09

Roy Eltham wrote: »

Sorry, I forgot to mention that it uses the Wiznet 5100 driver written by Timothy Swieter. It's on the obex here.

'
Thanks Mr.Eltham
'
They changed the name in the OBEX pointer to "Wiznet W5100 Indirect/Parallel Driver". This is why I couldn't find the file.
'
http://obex.parallax.com/objects/615/
'
Thanks again

$WMc% · 2010-11-15 14:19

Mr Eltham:
'
Your code works great!
'
My router See's the Spinneret with no problems.
'
Here is a screen shot of the PST and the cmd window that I "ping"ed the Spinneret with.
'
You are the Man
'
Many Thanks

Roy Eltham · 2010-11-15 14:34

Excellent, glad it works on another setup besides my own!

Brian Carpenter · 2010-11-15 21:52

can you post your pst object please?

Roy Eltham · 2010-11-15 21:56

Brian, it comes with the Prop Tool.

$WMc% · 2010-11-16 10:15

Brian Carpenter wrote: »

can you post your pst object please?

'
PST object
http://obex.parallax.com/objects/457/

obrienm · 2010-11-17 09:23

Roy,
Your code works out of the box with Timothy Swieter's driver.
Thank you for providing a starting place with which to start developing for the higher OSI layers.
I would like to concentrate above the application layer on top of HTTP(GET and maybe POST) and URL mapping with the eventual goal of implementing some part of a dynamic application server stack supporting (JSP/Servlet or ASP - both use <% %> html ignored tags) - after I scope out what not to implement.
Any work at the future application server level will build upon all the layers below like your DHCP code, as well as community submitted standard HTTP, TCP/UDP, IP implementations.

thank you
/michael

Roy Eltham · 2010-11-17 09:32

obrienm,
I noticed in your screenshot image that your MAC is still set to 00:00:00:00:00:00. You should edit the MAC_ADDRESS_# constants at the top of the DHCP.spin file to match your MAC address from the sticker on the bottom your Spinneret.

Also, I plan to keep extending this "lower level" stuff to include better DHCP handling, DNS, basic HTTP support, code to get date and time from time servers to set the RTC, and so on. I need all of these things for my project.

obrienm · 2010-11-17 11:27

Roy,
Good one, I was wondering why my MAC was not auto-detecting in SPIN. I should actually read your code.
My MAC address shows now, I guess I can simulate any other mac as well. I'll need to store this in EEPROM or SD.

00:08:dc:16:ef:06 192.168.0.189 SpinServer0 23 Hours 59 Minutes Revoke Reserve

thank you
/michael

Roy Eltham · 2010-11-17 12:10

I'll be changing the code soon to take the MAC address at startup, and also to allow you to set the hostname as well. Instead of using constants.

Beau Schwabe · 2010-11-17 14:06

Roy Eltham,

Excellent!! Great job!!

Oldbitcollector (Jeff) · 2010-11-17 17:42

I'm up and running...

It works perfectly here as well.

OBC

sstandfast · 2010-11-19 20:12

For the past two weeks I have been working on coding an interface driver for the W5100. I had all the low level assembly written and was about to start on the socket API. Then yesterday I scan the OBEX and discover that one has already been written by Timothy Swieter. So after I kicked myself for not checking the exchange first, I started work on a DHCP driver. I had the DHCPDiscover routine written but was having trouble with reliable reading of the DHCPOffer response. 3 out of 5 DHCPOffer responses would be missing bytes from the OPTIONS field, usually around the Subnet Mask. So today I got on the forum to look and see if anyone had posted results with the W5100 driver and if there was an issue with dropping bytes during a read from the W5100. That's when I found that you have beat me to the punch and have developed working DHCP routines. So I kicked myself again.

So after modifying the pin definitions in your code to match my board, I tried your program. Unfortunately, I still have the same results. About 40% of the time I get correct responses. The rest of the time either the Subnet Mask,Gateway IP, or DNS Server or a combination of all three will be wrong. The IP address is always correct and I have yet to see any issues with any bytes prior to the Magic Cookie. I am beginning to suspect that my W5100 has problems with flaky RAM but I just wanted to see if anybody else has had similar issues. As part of a troubleshooting exercise I might try starting the RAM at a higher location and see if that works.

Regards,

Shawn

*Just for grins, here is a dump from the serial terminal. I did tweak your code to allow the DHCP process to be restarted via serial commands so I could retry if I got bogus results. Here is an example of what I'm seeing. The most common erroneous result is to have the subnet mask read 255.255.0.3 or 255.255.3.4. Incidentally, this response was taken after switching to Socket 1 instead of Socket 0. (Which BTW, to make your code work with any socket, in your DoDHCP procedure you need to change the line that reads the socket status register to:
' get the status of the socket
W5100.readIND((W5100#_S0_SR + (socket * $0100)), @status, 1)
)

Here is the Serial Port Dump from my Prop/WIZ811MJ combo.

DHCP Demo. Press 1 to start DHCP

IP : 192.168.0.104
Subnet Mask: 0.0.66.66
Gateway IP : 192.168.0.1
DNS Server : 0.0.84.4
DHCP Server: 192.168.0.1
Domain Name: KRWSMS
DHCP Demo. Press 1 to start DHCP

IP : 192.168.0.104
Subnet Mask: 255.255.3.4
Gateway IP : 192.168.0.1
DNS Server : 0.0.84.4
DHCP Server: 192.168.0.1
Domain Name: KRWSMS
DHCP Demo. Press 1 to start DHCP

IP : 192.168.0.104
Subnet Mask: 255.255.255.0
Gateway IP : 192.168.0.1
DNS Server : 192.168.0.1
DHCP Server: 192.168.0.1
Domain Name: KRWSMS
DHCP Demo. Press 1 to start DHCP

Roy Eltham · 2010-11-19 21:09

sstandfast,
I have not had any issues with DHCP packets being messed up like you describe. It's could be your W5100 chip, but it could also be your router being flaky? My DHCP code doesn't do any validation of the packet and doesn't retry either, but most things will, so you might not notice DHCP issues with other devices.

Anyway, I will be uploading a new version soon, and it'll have more stuff configurable, like the socket to use. I moved the status reading to a function also.

ElectricAye · 2010-11-19 22:12

Roy (and others),

would you mind posting a link to your code in the Sticky that now resides at the very top of the Spinneret Forum? I'm encouraging everyone to help keep that list up to date.

thanks,
Mark

sstandfast · 2010-11-19 22:40

Hi Roy,

It's not the router. I have verified the packets being sent to the W5100 from the router are correct via Wireshark. I have tried all four sockets with the same sporadic results. I have started reading both your's and Tim's code trying to understand what is going on and I can't see any obvious issues. I really don't know where to look at this point. I've used Tim's UDP Echo Demo with the UDP Test Tool by Simple Com Tools and have not yet seen a problem. I've even modified the code so that it dumps the entire contents of the received array to the serial port and everything looks ok with it. I'll keep poking around and let you know what I find.

Thanks for the help,

Shawn

brian.lloyd · 2010-11-20 20:31

Roy Eltham wrote: »

sstandfast,
I have not had any issues with DHCP packets being messed up like you describe. It's could be your W5100 chip, but it could also be your router being flaky? My DHCP code doesn't do any validation of the packet and doesn't retry either, but most things will, so you might not notice DHCP issues with other devices.

Noob here. Please forgive me if I am stating the obvious.

The ethernet controller should verify the CRC as it is being received. If you have a good CRC after completely receiving the frame, you *should* have what the DHCP server sent. I haven't seen the code for the Spinneret yet so I can't look to comment.

Of course, that begs the question: is there any working code that implements a reasonable IP stack up through at least UDP? I am not so worried about DHCP (services should live at static addresses) but would like to get a Spinneret to play with knowing that there is something that works to try out initially.

Brian

Roy Eltham · 2010-11-20 20:53

The Wiznet W5100 chip does the stack. It's got an internal buffer, and when you open a socket you pick rawip, udp, or tcp, and then it does much of the work. The driver that's available interfaces to the chip and allows you to set registers, read/write the buffer, and issue commands. So, the code we are implementing is the stuff that sits on top of the stack.

obrienm · 2010-11-20 21:03

Brian,
Welcome, I myself use reserved static IP's so I am able to use Timothy's TCP Server demo with a couple minor modifications (only the TCP port and IP are required at this point - the MAC address is not required at this layer). There are now ~?10+ developers here with working and more advanced demos involving evolving modules for DHCP, SD I/O, GET URI path/program/querystring_parameter parsing for the upper OSI layers.

As for the TCP layer transport (ports) driver - as an upper layer developer I would expect that the hardware would provide this. However checksum should be checked by one or all of the transport layers above IP - (TCP, UDP and ICMP-(ping) in sequence) - this would be good to verify. This would be either an enhancement request or bug report for this project.

Check the sticky posts for collaborative works in progress.
http://forums.parallax.com/showthread.php?p=955671#post955671

thank you
/michael

brian.lloyd · 2010-11-21 08:32

Thank you Roy, Michael. I was thinking that the 5100 was just an ethernet controller. Huh, IP in silicon. As a router and protocol designer it goes against my grain but I imagine it makes things quite compact. I was going to hack together PPP for the IP stack but if the IP stack is inaccessible then that won't work. Oh well.

Still, this will work for my project -- a ham-radio station controller for stations using software-defined radios. I need a peripheral to control various functions, e.g. antenna switching relays, rotator, amplifier control, external device bandswitching, analog in/out, and BCD in/out.

Been using the BS2 and Propeller in my classes at school (http://www.gbmontessori.com). We have been extremely well supported by Parallax (Andy and Stephanie are wonderful!) and by Hanno Sander (12blocks). Love the chip. The only thing I miss is analog I/O on the chip.

Hmm, I think I feel a GPS-disciplined reference oscillator and NTP server coming on (even NTP broadcast would be great).

Oh! Does the 5100 do IPv6?

Brian

sstandfast · 2010-12-01 08:59

Hi Roy,

I definitely think it is a hardware problem either with my layout (I am using point-to-point wiring between a WIZ811MJ and the Propeller Proto USB board) or with the W5100 itself because I modified your DHCP driver to use the SPI interface and it now works flawlessly. I'm still not exactly sure what the problem is because I only have issues with reading all three 0xFF's of the subnet mask. I only get two out of the three which throws off the rest packet since there is one byte missing. It could be a problem with a noise spike coupling to the Read line during one of the transitions that tricks the W5100 into thinking a Read has occurred which then causes the read pointer to Auto-Increment. Since I don't have the equipment to diagnose this effectively (I only have a 10MHz single channel O'Scope), I think I am just going to switch to SPI mode until I get to the point where I am confident enough to have a prototype board spun-up.

Shawn

jstjohnz · 2010-12-26 22:55

Hello Roy,
Nice piece of software, and will come in very handy. One issue I was seeing was that sometimes the routine would return with an error timeout well before 10 seconds had elapsed. I think the problem is that in your timeout test code you use ">=" when comparing currentcount and timeoutcount. That is an assignment operator. I think you need to use "=>". At least, it seemed to work for me.

jstjohnz · 2010-12-29 14:16

I found another minor bug. In your parsedhcpreply routine you have:

  ' verify XID match
  repeat index from 0 to 3
    if XID.byte[index] <> byte[packetBuffer][DHCP_XID+index]
      return 0 ' does not match, so not for us

The byte comparison is backwards. Either change [index] to [3-index] or change [DHCP XID+index] to [DHCP XID+3-index].
As written it will only work if the xid is 4 identical bytes..

Roy Eltham · 2010-12-29 23:09

I have updated the first post with a new version of DHCP.spin that includes the bug fixes jstjohnz mentions in the above two posts.

Ray0665 · 2010-12-30 08:06

At the risk of being slightly off topic: The DHCP server in most routers will allow you to configure a hostname and fixed address to return in response to a request .
I am using the Verizon advantec router and under the advanced tab you have IP distribution (the DHCP server) where I can tell it what hostname and IP to assign to what MAC address.
By having a fixed IP you can then find the web server more easily and map it through the router for outside access.

@obrienm
by setting up the network dhcp server to return the fixed address you have better control over the network addresses and once you configure the MAC address in the spinneret you don't need to configure the IP/gateway/netmask/hostname in the hardware so moving to another network is then trivial.

DHCP working! (code now attached)

Comments