EMX DHCP and 4.2

NETMF & Gadgeteer
1

Hi,

OK just picked this project up again after a 12 month gap :-((.

Upgraded to MS NetMF 4.3 GHI 4.2 etc. - as of yesterday (May 15 2013).

Cannot make DHCP work. Static IP sort of works - depending on how I set it - ie works from code but not from config tool :-((.

  1. The config tool network setup seems to change depending on what the code last did - is this for REAL ??? - surely a ‘config’ ought to be fixed ???.

  2. I am trying to use the EthernetBuiltIn code but the doc is very sparse - is there a real example of using this for an EMX board ???. Most refer to a J11 file etc. ???

  3. Is Dhcp tied to Dynamic DNS - ie do they BOTH have to be enabled ???.

  4. This is driving me nuts - as I did have this sort of working a year ago but now DHCP doesn’t even try to establish as far as I can see - so chances are that I am simply using the code wrongly - as I cannot find a suitable doc :-((.

Any help much appreciated please - for an EMX board not one the many others please…

NB I can post code which works (Static IP) and doesn’t (DHCP) - if it helps…

Best Regards

Graham

2

Andre,

Well - you make it sound easy - but it simply does not work.

Sorry for the confusion with the J11 stuff - I wasn’t aware that it was simply a physical module. My own board has the ethernet socket as part of the layout ;-)).

There is still some confusion as ‘ethernet’ does not have an ‘Interface’. (I am creating ethernet as follows) :

    private static EthernetBuiltIn ethernet = new EthernetBuiltIn();

Declared at class level.

The cited example may be based on OLD code I assume ???.

Then my code does :


                ethernet.NetworkAddressChanged += ethernet_NetworkAddressChanged;
                ethernet.CableConnectivityChanged += ethernet_CableConnectivityChanged;

                ethernet.Open();
                NetworkInterfaceExtension.AssignNetworkingStackTo(ethernet);

                iface = ethernet.NetworkInterface;

                //ethernet.NetworkInterface.EnableDhcp();
                //ethernet.NetworkInterface.EnableDynamicDns();

                ethernet.NetworkInterface.EnableStaticIP("192.168.1.111", "255.255.255.0", "192.168.1.1");

                while (iface.IPAddress == "0.0.0.0")
                {
                    Utils.ToDebug("Waiting for DHCP:");
                    Thread.Sleep(2000);
                }
etc.......

This works and gives me a static IP as expected.

If I then comment the static line out and enabledhcp line in - it doesn’t work, and simply sits in the loop waiting for an IP address.

NB Once this has run, if I check my Network Config from the GHI setup tool, it has wiped the original static IP and gateway IP :-O.

Thanks again…

Best Regards

Graham

3

@ GrahamS - try enabling DHCP before assigning the interface to the stack

4

Mike,

Thanks - just tried that and no difference.

I had just typed a LONG reply and the forum had logged me off so it trashed it for me. Here goes again :-((.

I can see from my router that an IP IS being allocated :-)).

If I REVOKE for this MAC address - it goes away and even gets regenerated again after a few seconds.

SO - it looks to me like its an issue with the EMX failing to see the DHCP response packet correctly :-((.

Looks like I’ll have to go packet-sniffing again :-((.

Incidentally the old problem (which I reported over a year ago) is still there in that the EMX board name is not being populated against the MAC address in the router :-O. I had rather hoped that GHI might have fixed this after so long :-((.

I suspect that its more of a DHCP recognition issue now - and I am sure that I saw this early in 2012 - better go hunting for my old posts :-O.

Thanks again all - we WILL fix this problem ;-).

best Regards

Graham

5

Guys,

Did some trawling for my own messages (GrahamS)…

I did indeed report this problem WAY back and was sent a fixed library.

Chances are that I continued to use this fixed library until dropping the project last year.

Now that I come back to the project (on a new dev machine !!) - of course I am using the latest release libraries and maybe the fix was never rolled into it ???.

Sounds pretty much the same old same old problem to me :-((.

Please someone in GHI (GUS or JOE ???) take a trawl through my old messages and confirm if this fix has been lost :-O.

Many Thanks

Best Regards

Graham

6

Andre,

Router (running the DHCP server) is a DLink DIR655 - pretty old and the same as was used last year.

I found my old posts (includes the one you refer to ;-)).

Not sure why this is a NetMF as opposed to GHI issue - as I have little knowledge of who provides what parts of the NETMF deployment :-O.

I will try to take another look at the protocol again, and confirm this as being the problem :-(.

GHI issued a fixed library previously.

Just used the new GHI config tool and it says 4.2.10.1 build May 1st.

Hope this helps…

Thanks

Graham

7

I believe that with 4.2 a new open source stack was introduced. That is why there has been so many IP related issues with 4.2. I think GHI can now fix stack issues, where they were not able to do so with the prior closed stack.

8

While we can change it all, we should keep compatibility with other devices. We can fix multicast for example but shouldn’t make changes on the functionality.

9

Guys,

OK - telling me its my router is not very helpful !!. This router has been working very well for MANY years now and in the past couple of years given me DHCP problems only TWICE - Both times with EMX boards !!. Of course thats not to say that the router is indeed NOT at fault but I consider that unlikely -or that the EMX DHCP protocol may be overly critical…

So - I sniffed the LAN segment and can now see that this is a completely different problem.

The DHCP server gets a DHCP DISCOVER request from the EMX, finds the next free IP, performs an ARP to verify that its not in use, then sends it back as a DHCP OFFER.

The EMX then DECLINES that offer :-O.

Seems like it now thinks there is something wrong with the OFFER :-O.

Now - my router ‘should’ at this point mark the address as ‘unallocated’ and offer a different one the next time round - which it appears not to do !! - so yes this ‘could’ be a router problem, but everything else seems to have no issue with this :open_mouth: - I have PC’s, AppleTV, iPad, iPhones, Android phones, Android tablets, a multitude of other hardware development modules - many with Ethernet) as well as a range of network printers over the years all connecting to this router :-O. SO I suspect that the EMX is primarily to blame here :-O.

I need access to the source code for the DHCP module I suspect - to see WHY the EMX is 'DECLINE’ing the legitimate OFFER being made.

Maybe it is simply hearing the ARP request being sent by the DHCP server and thus ‘assuming’ it to be a live IP address :-O.

I have NEVER had so much (ANY!!) trouble with DHCP until plugging EMX modules into my network :-((.

Guess I’m just going to have to turn off the DHCP server in this router and find another to test with :-O. Maybe a simple PC-based one will at least prove the point…

Frustrated…

Best Regards

Graham

10

The source code is at https://netmf.codeplex.com/ if you want to peek.

11

All,

Tried to find the code, logged in and can see the source code but cannot find any suitable ‘network’ or ‘dhcp’ files :-((.

Anyway - I went to the associated forum and see that there are a number of complaints about DHCP being flakey over the years…

So - I re-captured my DHCP from a power-down reboot.

Although I reported the DHCP DECLINE coming from the client - this is only after the initial failure.

The first DISCOVER results in an OFFER from my server.

This is followed by a REQUEST from the client, then a NAK from my server. I think I now know why !!!

My server is possibly implementing part of the DHCP protocol which may be being ignored by others :-O.

the RFC (2131 - although I have not yet checked any subsequent updates!) specifically states :

The DHCPREQUEST message contains the same xid as the DHCPOFFER
message.

Well in the case of the EMX board this is NOT the case. It is bumping the transaction ID between the OFFER and the REQUEST (see the following from an MS Network Monitor V3.4 capure) :

102 10:34:52 17/05/2013 10.1929378 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0xABCD0002 {DHCP:29, UDP:68, IPv4:67}

110 10:34:53 17/05/2013 11.1933372 192.168.1.1 255.255.255.255 DHCP DHCP:Reply, MsgType = OFFER, TransactionID = 0xABCD0002 {DHCP:29, UDP:68, IPv4:67}

111 10:34:53 17/05/2013 11.1946106 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = REQUEST, TransactionID = 0xABCD0003 {DHCP:30, UDP:68, IPv4:67}

112 10:34:53 17/05/2013 11.1950930 192.168.1.1 255.255.255.255 DHCP DHCP:Reply, MsgType = NAK, TransactionID = 0xABCD0003 {DHCP:30, UDP:68, IPv4:67}

NB I skipped frames 103 - 109 as not being part of this conversation.

Clearly the request is coming with a new transaction ID - so the router is strictly correct in Nacking it !!

NB I did a similar trial using an Olimex Pic32 board (using the Microcgip stack) and it worked perfectly - the transaction ID’s all remained the same though…

So - not quite sure how to get this fixed, but as I will need to deploy my EMX box(es) into the field - clearly I will have little control over the routers they will be connecting with :-((. So - I need a version of the code which works with all (well as many as it can) routers :-)). Any code ‘released into the wild’ MUST be able to cope with numerous DHCP servers - or it becomes a liability and will generate numerous support issues upon deployment :-((. DHCP is fundamental to establishing an IP Address :-O.

Summary: strictly speaking this is an issue with the NetMF implementation of DHCP (IMHO), but one which admittedly many routers seem able to ignore - as they probably simply rely on the client MAC address. There are questions about WHY DHCP uses Transaction ID’s as well as client MAC address - but they are WAY beyond the scope of this forum :-)).

Hope this feedback helps, and that someone knows who/how to get this fixed please ???. NB I saw the same issues in the NetDuino forum and will probably find them elsewhere if I were to look ;-)) - some also did specifically mention the DLink DIR-655 :-O.

Many Thanks

Best Regards

Graham

1 Like
12

Andre,

Hopefully my reply above will answer your question. There are grey areas in DHCP - specifically with client identification - I have seen questions asked as to WHY there is even a transaction ID field - when the client can be identified from its unique MAC address anyway.

Maybe many servers out there simply ignore the Transaction ID field and just rely on the MAC Address - who knows…

Ours is not to reason why - ours is but to do or die…

Of course I could be talking a load of bull**** here, and the Transaction ID might not even be the problem ;-)). I think its a pretty good bet though…

Best Regards

Graham

13

I’ve same problem using a Cerbuino + ENC28 + Fortigate as DHCP server

Previously I worked with Panda II + same Fortigate and all was ok.

14

Hi,

It seems that we have the same issue with differents G120HDR and ENC28 modules.

With a CISCO 857 router we allways got the same sequence on DHCP request.

DHCP DISCOVER
DHCP DECLINE

As stated in a previous post, every other client is working properly

We are using version 4.2.11.1 ,older versions give the same behaviour.

Any idea ?

regards
Loïc