G400D DHCP test

DHCP SERVER is performed by Windows Small Business Server 2003.

I repeated the test 12 times on a Spider/4.3/ethernetBuildin and this device received an IP address 12 times. So is seems that the problem is related to G400

Here is the discover message

The offer message:
As you can see in the log it start endless loop (if the code test if different than 0.0.0.0 during ten second if still 0.0.0.0 it enable static IP and reloop on enable DHCP, renew DHCP lease and test if different than 0.0.0.0 and so on)

Arghā€¦ :-[ I canā€™t launch PCB production if this is not solved. I canā€™t even test with ENC28 because I donā€™t have one.

If the debugger is not attached the platform work well. Therefore I assume it is not a problem of DHCP server or code. It is a problem of G400, its SDK combined with the debugger.

This makes the platform most of the time unable to debug if eth built in is recquired by the application.

When this happens, the cableconnected property is false while there is cable and led link is ON.

It happens also with static IP, running the code with visual studio, I canā€™t ping sometime. while if i reset the board alls seems ok.

Please GHi have a look on that. I am using VSExpress 2012 and sdk 4.3.6.0.

This is a bit surprising. Iā€™m working with G400 and BuiltIn at the very moment, and though it [em]is [/em]tricky sometimes, itā€™s really not that bad. But I am using 4.3.5 (2014 R4), maybe that is the difference?..

Itā€™s a pitty that GHI doesnā€™t provide a reference hardware with BuiltIn ethernet. So it is impossible to try it before making decisionsā€¦

@ GHI team, what are your plans about this issue? It seems that I am not the only one who observe the problem. I canā€™t design our new G400 based product unless it 100% solved.

@ leforban - We are still looking into the issue. We will let you know once we find out more.

Does this mean you confirm the issue?

@ leforban - Not yet, no. We are still looking into reproducing it.

Not sure it is directly related with the problem leforban has, but since Iā€™ve been working on improving ethernet reliability for the pas few days, I think Iā€™ll share some of my observations.

Iā€™m using G400 with BuiltIn ethernet.

The main thing: G400 has serious problems aquiring IP address if it starts without LAN cable connected, or the cable is reconnected while working. ā€œSerious problemsā€ in this context is that IP address is sometimes aquired, sometimes not, but mostly not. For example:

G400 starts without LAN cable connected -> I connect the cable -> Cable connection triggers DHCP procedure -> DHCP fails;

Or:

G400 starts with cable connected -> DHCP ok -> Cable disconnected ->cable reconnected -> Cable connection triggers DHCP procedure ->DHCP fails.

But, as always, I found a workaround :slight_smile: If I [em]manually set static IP address[/em] before calling EnableDhcp() method, DHCP always succeeds. So, my procedures now look like this:

G400 starts without LAN cable connected -> I detect that and set static IP address-> I connect the cable -> Cable connection triggers DHCP procedure -> DHCP succeeds;

or

G400 starts with cable connected -> DHCP ok -> Cable disconnected -> I detect that and set static IP address-> cable reconnected -> Cable connection triggers DHCP procedure ->DHCP succeeds.

if (((EthernetBuiltIn)_ethernetType).CableConnected) {
                    RunEthernetConnectionProcedure();
                } else {
                    _ethernetType.NetworkInterface.EnableStaticIP(StaticIp, StaticMask, "0.0.0.0");
                }

                NetworkChange.NetworkAvailabilityChanged += (sender, e) => {
                    if (((EthernetBuiltIn)_ethernetType).CableConnected == true) {
                       RunEthernetConnectionProcedure();
                     } else {
                         _ethernetType.NetworkInterface.EnableStaticIP(StaticIp, StaticMask, "0.0.0.0");
                     }
                };

 private void RunEthernetConnectionProcedure() {
           if (_ethernetType.NetworkInterface.IsDhcpEnabled == false) {
                   _ethernetType.NetworkInterface.EnableDhcp();
                } else {
                   _ethernetType.NetworkInterface.RenewDhcpLease();
                }

                for (int i = 0; i < 15; i++) {
                  if (_ethernetType.NetworkInterface.IPAddress == "0.0.0.0") {
                        Thread.Sleep(1000);
                    } else {
                       break;
                    }
                    if (i == 14) {
                        _ethernetType.NetworkInterface.EnableStaticIP(StaticIp, StaticMask, "0.0.0.0");
                    }
                }
            }
        }

Hope it helpsā€¦

Hello Simon

I am not sure this is direclty related to the problem I observe. If you have a look on my previous code, the test was setting static Ip and then enabling dhcp in a infinite loop but this was not working and more weird: the cableconnected property was false.

For now I am testing the SDK and the application on EMX to see if it is a G400 issue or something related with the SDK

I just have a look on wireshark. May you have a look on the screenshot. You will observe two requests instantiated by the G400.

Thereā€™s one followed by an NAK and the second by an ACK.
The strange thing is that even if DHCP Offers 192.168.1.34, G400 request 0.0.0.0.
G400 request the good IP after BUT I canā€™t still PING the board.

Even with a static IP I canā€™t sometimes ping the G400! I used to have some troubles with EMX, but on G400 it is more than 90%.

If the program is launched by visual studio (I am using for now VS2013 community with the beta .netmf SDK and the GHI SDK version 2014 R5) the CableConnect property is false while if I rerun the code after pressing the reset button (and therefore without VS) and observe with FEZ config, the code may works (still rarely but sometimes it happensā€¦)

I spend the all working day to debug ethernet and to resume:

1:Thereā€™s a knd of conflict between VS deployment and the ethernet stack. I can provide the code that shows this issue.
2:As soon as PC25 is used the ethernet becomes unresponsive (have a look on the code below)

Please GHI update this post soon and gives clear elements on what you are doing or not and delay of solving (if solving that is possible). Professionnal customers and companies can then design their products with this in mind.


using System.Threading;
using GHI.Networking;
using GHI.Pins;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

namespace TestDHCP
{
    public class Program
    {
        public static void Main()
        {
            var eth = new EthernetBuiltIn();
            int it = 0;

            if (eth.Opened)
            {
                Debug.Print("closing interface");
                eth.Close();
            }
            eth.Open();

            if (!eth.IsDhcpEnabled)
                eth.NetworkInterface.EnableDhcp();
            else eth.NetworkInterface.RenewDhcpLease();
            int i = 0;
            while (eth.IPAddress == "0.0.0.0" && i < 10)
            {
                Debug.Print("Waiting for DHCP");
                Thread.Sleep(1000);
                i++;
            }
            Debug.Print("IP DHCP" + eth.IPAddress.ToString());
            //            OutputPort p = new OutputPort(G400.PC25, false);
            while (true)
            { Thread.Sleep(250); }
        }
    }
}


@ leforban - We are still looking into the issue. When you create the OutputPort on PC25, what exactly happens?

Before creating output port on PC25, you can ping the device and cableproperty is true, after creating the port , ping fails and cableproperty returns false.

Simon can you test also that?

Completely agree, ran into it, too. Iā€™ve raised this question a few times, but GHI guys wasnā€™t particularly interested. Have you tried my ā€œquick resetā€ trick? For me, it helps a lot.