Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

DHCP - getting different IP address each time I restart


  • Please log in to reply
19 replies to this topic

#1 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 09:38 AM

Hi, I'm not sure if this is a problem on my DHCP server (AVM Fritz!Box), but everytime I restart my module i.e. when deploying my new code I get a new IP address. Other .NET MF boards are working correct, the Fritz!Box sends always the same IP address. Seems that there is a difference, but I don't know where to start. Any ideas? Regards, Michael

#2 Fred

Fred

    Advanced Member

  • Members
  • PipPipPip
  • 302 posts
  • LocationUK

Posted 06 November 2010 - 10:01 AM

Have you checked what MAC address has been assigned to your Netduino Plus? Mine resets itself if I reflash. I'd have thought the DHCP server would tend to reassign the same IP to the same MAC address, but if your MAC isn't valid it might not.

#3 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 10:45 AM

The MAC address reported in the DHCP server is identical with the one that is put on the board. :-( Michael

#4 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 11:00 AM

I tried following code:

foreach (NetworkInterface net in NetworkInterface.GetAllNetworkInterfaces())
            {
                Debug.Print(net.IPAddress.ToString());
                Debug.Print(ByteUtil.PrintBytes(net.PhysicalAddress));

                net.RenewDhcpLease();
            }

            foreach (NetworkInterface net in NetworkInterface.GetAllNetworkInterfaces())
            {
                Debug.Print(net.IPAddress.ToString());
                Debug.Print(ByteUtil.PrintBytes(net.PhysicalAddress));
            }


The output looks like this:

192.168.178.82
5C-86-4A-00-00-E5
0.0.0.0
5C-86-4A-00-00-E5


If I reboot the device I get 192.168.178.83.

Michael

#5 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 11:17 AM

Hi, maybe I found the problem. When switching on the Netduino Plus I get following DHCP request: 1) DISCOVER with YourIP 0.0.0.0 2) Reply from my DHCP server with OFFER and IP address 192.168.178.96 3) REQUEST with YourIP still 0.0.0.0 instead of the offered IP 192.168.178.96 4) Reply with ACK When comparing i.e. with Thaoe-II I have a difference with the step 3, the YourIP and ServerIP is filled correct instead of using 0.0.0.0. I have attached the capture of both requests. Michael

Attached Files



#6 Beijer

Beijer

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationSweden

Posted 06 November 2010 - 11:38 AM

Hi,

maybe I found the problem. When switching on the Netduino Plus I get following DHCP request:

1) DISCOVER with YourIP 0.0.0.0
2) Reply from my DHCP server with OFFER and IP address 192.168.178.96
3) REQUEST with YourIP still 0.0.0.0 instead of the offered IP 192.168.178.96
4) Reply with ACK

When comparing i.e. with Thaoe-II I have a difference with the step 3, the YourIP and ServerIP is filled correct instead of using 0.0.0.0.

I have attached the capture of both requests.

Michael


I don't really know how to tell this but I will give it a try.

The step 3 when it sends out a request should be 0.0.0.0 for a device that have never got an ip adress before. It will send it as a broadcast so that all the dhcp servers on the network will know about it.

The reason why the Thaoe will send it it's ip adress I don't know but as far as i know the whole DORA process is with Boradcast (Except when there is only a renew, and not a release renew)

I would really like to see the captures with wireshark though. :)

Sorry for the bad english..

#7 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 02:03 PM

Yes, you are right, but if the first response from the DHCP server (step 2) will send a real IP the server already knows the client's MAC address (already sent one in the past). This IP address should be used, I think. I will analyze other clients (PC, other network devices)... Michael

#8 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 02:26 PM

Seems that the clientID = 1 is missing in the REQUEST (step 3). I have monitored other DHCP requests and all are sending clientID = 1 which means that the DHCP server should take care of the MAC address (as far as I understand the DHCP protocol). Michael

#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 06 November 2010 - 07:40 PM

Hi Michael, We'll look into this. Do you see this issue with any other DHCP server? In theory, DHCP servers should give out a "lease length" on an address--and then always assign a specific IP address based on MAC addresses during the life of that lease. But I wouldn't be surprised if various DHCP servers behave in different ways. If there's a difference between the DHCP spec and lwIP's operation, perhaps we can fix it and look into checking the fix back into the lwIP codebase as well... Chris

#10 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 09:01 PM

Hi Chris,

yes, the same happens with other DHCP servers I have here.

I had a look on RFC 2132, 9.14:

This option is used by DHCP clients to specify their unique
identifier. DHCP servers use this value to index their database of
address bindings. This value is expected to be unique for all
clients in an administrative domain.

Identifiers SHOULD be treated as opaque objects by DHCP servers.

The client identifier MAY consist of type-value pairs similar to the
'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
of a hardware type and hardware address. In this case the type field
SHOULD be one of the ARP hardware types defined in STD2 [22]. A
hardware type of 0 (zero) should be used when the value field
contains an identifier other than a hardware address (e.g. a fully
qualified domain name).

For correct identification of clients, each client's client-
identifier MUST be unique among the client-identifiers used on the
subnet to which the client is attached. Vendors and system
administrators are responsible for choosing client-identifiers that
meet this requirement for uniqueness.


This is the part that DHCP servers use to identify the client's MAC address.

I think we need to add this. :unsure:

Michael

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 06 November 2010 - 09:09 PM

Michael, We'll dig into it and see what we and/or Microsoft can come up with. In the meantime, is it possible for you to assign a static IP using one of the DHCP addresses (or ask your DHCP server to assign a specific IP address to the MAC address of your Netduino Plus)? Chris

#12 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 06 November 2010 - 09:59 PM

Yes, we will see... I use a static IP, now, because my DHCP server cannot offer a IP address if this field is missing, this is used to identify the clients. So far I see the MAC address is two times in the DHCP request, the 2nd one is used to identify the same client again. So, no problem for me... but should be fixed somehow, all other .NET MF boards are using the clientID. Michael

#13 Beijer

Beijer

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationSweden

Posted 07 November 2010 - 08:35 AM

I have tried to forge custom packets for the whole DORA process using Wincap and a library called scarpcap to make it work in c# and I can tell you there are alot of things in the packets to make sure that they are not manipulated ;) Thats why I like Wireshark so much for packet capturing becouse it tells me if the packet is malformed and what is wrong.

#14 pascal06

pascal06

    Advanced Member

  • Members
  • PipPipPip
  • 95 posts
  • LocationFrance

Posted 07 November 2010 - 11:08 AM

Seems that the clientID = 1 is missing in the REQUEST (step 3). I have monitored other DHCP requests and all are sending clientID = 1 which means that the DHCP server should take care of the MAC address (as far as I understand the DHCP protocol).

Michael


Hi Michael,

You probably right concerning clientID, but it works fine with my Windows Server 2008 R2 DHCP server. And I use a reservation to fix my NetduinoPlus address.

Another strange behavior is that DHCP request take the configured static IP address to forge the IP packet. In case of this ip address use another subnet, it could be a issue. So, I have define 0.0.0.0 for static IP, subnet and gw.

If we definitly conclude that ClientID must be set, it probably not a big deal to fix it.

Pascal

#15 Michael Schwarz

Michael Schwarz

    Member

  • Members
  • PipPip
  • 21 posts

Posted 07 November 2010 - 01:49 PM

You probably right concerning clientID, but it works fine with my Windows Server 2008 R2 DHCP server. And I use a reservation to fix my NetduinoPlus address.


Hi Pascal,

yepp, seems that it is working with Microsoft DHCP server. I tried it with the AVM box as well as another Linux box and had no luck. Not sure who could give a try to add this option, should not be a big deal.

Can you do another test? What if you try to renew the lease in your application? Think of a module that you will plug to different networks while it is running. Is this working? I have configured the IP to 0.0.0.0, then I get an IP address from my DHCP... then I disconnect from network... connect again and renew the lease and get 0.0.0.0. :-(

Michael

#16 pascal06

pascal06

    Advanced Member

  • Members
  • PipPipPip
  • 95 posts
  • LocationFrance

Posted 07 November 2010 - 11:00 PM

Hi Pascal,

yepp, seems that it is working with Microsoft DHCP server. I tried it with the AVM box as well as another Linux box and had no luck. Not sure who could give a try to add this option, should not be a big deal.

Can you do another test? What if you try to renew the lease in your application? Think of a module that you will plug to different networks while it is running. Is this working? I have configured the IP to 0.0.0.0, then I get an IP address from my DHCP... then I disconnect from network... connect again and renew the lease and get 0.0.0.0. :-(

Michael


Hi Micheal,

Unfortunatly, I'm traveling this week. Without possibility to test. I will try next week-end if anybody have done it before.

Pascal

#17 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 07 November 2010 - 11:16 PM

Pascal, You're our resident networking expert/hero. :) Chris

#18 pascal06

pascal06

    Advanced Member

  • Members
  • PipPipPip
  • 95 posts
  • LocationFrance

Posted 14 November 2010 - 12:51 PM

Hello,

I have tested the last version with this code :

NetworkInterface[] networkInterfaces = NetworkInterface.GetAllNetworkInterfaces();
networkInterfaces[0].EnableDhcp();
networkInterfaces[0].RenewDhcpLease();

Netduino is already configured to use DHCP, the first request works fine. But, the renew doesn't works.
I'll wait for debugging capability to do more testing,

Also, I made some tests to evaluate the posibility to implement a little TCP/IP stack completly in managed code. It would be a good way to learn more by a easier way. The only bad effect would be the performance. Regarding FLASH/RAM use, it probably near the native code size. First implementation will be for the enc28j60 chip.

I'll let you know about it ...

Pascal

#19 pascal06

pascal06

    Advanced Member

  • Members
  • PipPipPip
  • 95 posts
  • LocationFrance

Posted 15 November 2010 - 07:22 PM

Hello, After some research, for me, your issue is more related to transactionID than ClientHardwareAddress. But it can be related to both in this case. ClientHardwareAddress is present in DISCOVER request. Usualy, a DHCP server remember each request by using the transactionID. But, it's seems that lwip change this option and use a different transactionID for DISCOVER and REQUEST. So, normaly, the DHCP server already have the ClientHardwareAddress because of DISCOVER request. But in this case, it can't because the transactionID was changed. For the server point of view, it's a new request. So, I think that it works with Microsoft DHCP server, because it use MAC Address at MAC level if the ClientHardwareAddress is not available. After some look at dhcp.c source, I also see that transactionID is change only after a multiple tries. So, I need to debug more to understand why multiple tries occurs in a normal situation. When I receive my JTAG interface, I will modify lwip to not change the transactionID between DISCOVER and REQUEST (if I found a way to do it). And I will send you a firmware to test. Pascal

#20 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 31 January 2011 - 06:30 AM

Quick update... We identified a DHCP server which didn't like the lwIP implementation in .NET MF...one of my "gaming routers" at home. DGL-4500 to be exact. Microsoft modified lwIP to send a client ID (0x01 + MAC address) in the DHCP DISCOVER packet--which made it work with the MS DHCP server. But some DHCP servers require the DHCP REQUEST packet to have the same client ID. We've added the option to the DHCP REQUEST packet, and it is now working here. This will be part of the v4.1.1a6 release and the v4.1.0.6b2 release. Coming soon... Hopefully it solves all DHCP issues. BTW, it is true that the REQUEST packet uses a different transaction ID than the DISCOVER packet, but that seems to be a structural issue within lwIP. It's easy to make them match--but then REQUEST-only transactions would use the transaction ID of the previous packet. If DHCP continues to have glitches, we can look at making bigger mods to lwIP. Chris




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.