DHCP issue on FEZ Cobra (I) with newest GHI SDK

Hi,
I have been struggled all the way down the last 3 days to “something so strange” : I cannot get an IP-Address via DHCP with FEZ Cobra I (EMX based) and its on-board ethernet-adapter (cable connected to my LAN-Router) with the latest GHI SDK v4.2 (Version 1.0.4 from 30.04.2013) - using the VS 2010 “branch” with the Micorosft .NET MF SDK 4.2 QFE2.

I also tried the VS 2012 “branch” with Microsoft .Net MF SDK 4.3 RTM without success.

But the exact same code works on another development machine which has the same MS SDK installed (.Net MF SDK 4.2 QFE2), but an older GHI SDK v4.2 (Version 0.0.5 - from 23.08.2012).

So originally the code-base came from that “old machine” and I knew it worked … I took it over to the new machine and built something of top of it - which failed in the end … and took me 3 days “off road” (crazy bug hunting). Okay that’s the story … now the truth in code :wink:

private static void InitializeNetworkViaDHCP()
{
int lintSeconds = 0;
NetworkInterface[] larNetworkInterface;

//* get all built-in / accessable network-interfaces of the .NET MF device
larNetworkInterface = NetworkInterface.GetAllNetworkInterfaces();

if (larNetworkInterface != null && larNetworkInterface.Length > 0)
{

  // * we use the first of all available network-interfaces
  cNetworkInterfacePrimary = larNetworkInterface[0];


  Debug.Print("DHCP will be activated - wait for IP-Lease ...");

  // * activate DHCP 
  cNetworkInterfacePrimary.EnableDhcp();

  // * wait for the IP-Lease - IP-Adress assignment
  while (cNetworkInterfacePrimary.IPAddress == IPAddress.Any.ToString())
  {
     Debug.Print("waiting the <" + (++lintSeconds).ToString() + ">'th second for IP-Lease.");

     //* wait another second
     Thread.Sleep(1000);
  }


  Debug.Print(" IP Address = <" + cNetworkInterfacePrimary.IPAddress + ">");

}
else
{
throw new NotSupportedException(“no network-interface (e.g. ethernet hardware) existant !”);
}
}

This method is called in Main inside a try-catch block and the system-date is set just before the call.

With GHI SDK 4.2 Version 1.0.4 the while Loop is never left … it waits until the end of time to get an IP-Adress assigned.

So please give me back the ligth of eyes - the last 3 days made me blind : is the cause a bug or an API change (in the GHI world - in the sense that things have to been set up different since Version 0.0.5) I am not aware of ?

Thanks for your effort in advance
geba

There was an improvement on DHCP since the beta but I do not see how that would cause problems! Have you tried to look at wire shark?

Also, please always wrap your code with “code tags”, see the proper icon when you post.

Welcome to the community.

Thanks GUS for the fastest answer I ever get !

No I did not look at wire shark … that kind of tools are beyond my scope of knowledge - and I am no expert in the DHCP protocol as well, so I could not interpret the bytes that I would see.

Do you have another idea how I could get you more details/deeper info so that you can get an idea about the cause of the problem ?

Thanks
geba

wire share is very simple. You will see the frames labeled DHCP labeled and will eb able to determine what is going on back and forth.

As for speed, we want to be in guinness record for the fastest forum! :slight_smile:

@ abdre.m : thanks for trying to help me … but what do you mean with “open the nif” ?

There is no more code reagrding the NetworkInterface class I use - and as I wrote the strange thing is that this code works on the GHI SDK 4.2 Version 0.0.5. And all the samples I found in this community and tutorials and looked into do not more with that NetworkInterface class.

Geba

@ Gus : if you need a witness for the council of the guinness book of records - I am with you.

And regarding “wire shark” : I just took a quick look at their website and thought about this way of troubleshooting … and you convinced me!

Just a short question to the wire-shark expert : I have a Windows 7 64-bit Development machine, does the 32-bit portable Version also work. As this tool works in the deeper space of the OS this might work only with the 64-bit Version on a 64-bit machine, or ?

thanks geba

@ andre.m : I just gave your code a try, but it ended up in an exception (NotSupportedException). EDIT : on the call to Open !

You should remember that I have a FEZ Cobra I and this is NOT a Gadgeteer device where this kind of “open network-Interface” and assigning might be needed.

I saw a blog post from someone who used a Gadgeteer Ethernet Module J11D … but I think this kind of code is not need in the “plain old world” of FEZ Cobra (as it is a “native” EMX based .Net MF device) … or am I wrong ?

thank
geba

I just edit you lines of code at the top of the method … so it Looks like :

		private static void InitializeNetworkViaDHCP()
		{
			int lintSeconds = 0;
			NetworkInterface[] larNetworkInterface;

			EthernetBuiltIn eth0 = new EthernetBuiltIn();

			eth0.Open();

			GHI.Premium.Net.NetworkInterfaceExtension.AssignNetworkingStackTo(eth0);


			//	*	get all built-in / accessable network-interfaces of the .NET MF device
			larNetworkInterface = NetworkInterface.GetAllNetworkInterfaces();

and on the line “eth0.Open();” it throws that exception.

… and about your “strengthen pointing” to EthernetBuiltIn … maybe ist a good idea to dig in that documentation, lean back & think a while … because things & API have changed since the examples (I read) have been published (and been working), I think :wink:
thanks geba

in first shot it does not work - if I try :

GHI.Premium.Net.NetworkInterfaceExtension.AssignNetworkingStackTo(cNetworkInterfacePrimary);

the comipiler does not like it :wink: … because NetworkInterface is different from NetworkInterfaceExtension … and currently I cannot read the Documentation about the class hierarchies & realtionships because with Internet-Explorer (Version 10) and my current Setting I cannot read the GHI online-docs

… seems to be a road of crazy things in row

@ andre.m : after a break with some food and now with fresh coffee back at the machines … I think your hint to the new “GHI Premium Networking Library” is a greate one.
As I found the offline Doc’s of the GHI Premium Libraries and threw a “quick view” over the classes in GHI.Premium.Net I see the goodness of EthernetBuiltIn Class … and I found a great but simple example on codeshare from Gus showing the use of that class (https://www.ghielectronics.com/community/codeshare/entry/588).

+@ Gus : … and now the interessting thing - this does NOT work with my FEZ Cobra (I - powered by EMX) !

I also get an exception on the EthernetBuiltIn.Open call and I attach a screenshot of it … and this class should be useable with FEZ Cobra I, because the doc’s say : “Built-in Ethernet driver (supported on SOM with Internal Ethernet PHY like EMX)”.

If my own downstripped code WOULD NOT work with “GHI SDK v4.2 - Version 0.0.5” I would like to guess there is something wrong with the hardware … but it does work.

Has someone an idea, if there might be a configuration problem - something I can fix by using MF-Deploy oder FEZ-Config ?

thanks for help
geba

@ andre.m : I will try your new way also …

@ andre.m : Yes I run it on the FEZ Cobra (I) and not on the emulator … and to be on safe side I went into the bathroom and took a look into mirror in order to be sure that I am still a human and did mutated into a squirrel … I am lucky : I don’t have to look for a place in a tree for sleep tonight ;-).

Don’t misunderstand me - your question was right … these are the weird kind of things that happen if you hunt a bug for hours and hours… and you just forget to plug in the cable !

I just try to free my mind by working with fun & laughing about that weird things that happen, so that I get clear in my mind and free myself from the “angry thinking” that puts oneself in the wrong direction.

Okay … and back to my tryout regarding the “static IP-address” assignment … and that was the reason I went into the bathroom … I got another strange exception (see the attachment) which happend on the call to

cNetworkInterfacePrimary.EnableStaticIP(lstrIPAddress, lstrSubnetMask, lstrGatewayAddress);

… and I think its time to flush the device from ground up again : burn TinyBooter and TinyCLR again on that crazy device.

After that I try that static IP-address assignment again and post my experience ;-).

geba

@ andre.m : yipiii … I see the light again ;-).

First & not really successful try : after burning the device with TinyBooter & TinyCLR I tried my code with the static IP-Address assignemtn (IP-Address & DNS) with the result that NO exception occured, but I could not ping the device from other machines (Windows 7 & 8).

Second & successful try : I build the SimpleHttpServer from Gus again, deployed and debugged it on the device … and taraaaa !!! … it works : no exception, device can be ping’ed and I can see the “Hello World!” webpage when I type in the “http://X.X.X.X” in the Web-Browser (which is IE10).

Oh men (& women) what can happen to this devices … what makes what corrupt in the Flash so that buring TinyBooter & TinyCLR is the (only) solution ? I come back to that question, but first a will further try on and use EthernetBuiltIn for DHCP … because GUS example uses also static IP … and for my Project I Need a dynamic IP.

… I will be back on DHCP success I hope …
geba

@ andre.m : as I guess’ed, your pointing towards EthernetBuiltIn guides me out of the darkness :wink: Thank you very much !!!

@ andre.m : I really got it now … with your help ! Many, many thanks … this will be great night and maybe this night I dream of a squirrel and a kangaroo enjoying their life in an oasis somewhere in the desert and talking & giggle about the crazy humans who spent (or do they call it waste :wink: their time on trying to teach dumb, deaf & blind electronics the way that the humans world work … I guess they would laugh if they would understand how humans make their life (sometimes ?:wink: complicated, in order to make their life easier with that devices, or ?

Okay … let’s finish the success story : even the DHCP now works with the EthernetBuiltIn Class - thanks to the great & easy example made by Gus (SimpleHttpServer). I just exchanged the EnableStaticIP call with EnableDhcp and put it below the if-block with the “cable connected” code.

This all works fine, even if the device (FEZ Cobra I) is powered up with no cable plugged in - and plugging that ethernet cable into the jack some time later … I am so glad and happy after this 3 days of “pain in the brain” !!!

Again many thanks for your time & brain-storms andre.m !
geba

P.S.: My first guess regarding all that exception problems (remember that SimpleHttpServer worked only after burning TinyBooter & TinyCLR again) is that MF-Deploy (or FEZ Config) might be the cause : as I looked up the Network configuration some more times … and maybe they did not disconnect properly from the FEZ Cobra or left the network-configuration in some “bad state”, which cannot be seen the UI? Maybe I got “better guesses” after some time of distance from the problem - remembering some unsual actions I have done and that might be the cause.