We got it working in principle. We swapped two wires.
But I am having some issues. While my code runs fine on my FEZ Cobra II and even on my G400HDR with the ENC28, it seems to work only every now and than with the G400 and EthernetBuiltIn.
The program hangs on NetworkInterfaceExtension.Open() and NetworkInterfaceExtension.Close() for some seconds. Furthermore I do only sporadically get an IP-Address assigned (NetworkInterfaceExtension.NetwirkAddressChanged).
I could not yet figure out when it works and when not.
Yes, I would say they are. We use 10cm of drilled wires that are soldered to the RJ45 connector. On the other side we plugged them into socket board. That also seems fixed.
The strange thing is: If it works once, it seems to be stable. I.e. once NetworkInterfaceExtension.NetwirkAddressChanged got fired I can use it as expected. The problem is, that it usually doesn’t get fired.
It also hangs at NetworkInterfaceExtension.Open() and NetworkInterfaceExtension.Close() no matter whether the RJ45 socket is connected or not.
ethernet = new EthernetBuiltIn();
ethernet.NetworkAddressChanged += EthOnNetworkAddressChanged;
if (!ethernet.NetworkInterface.IsDhcpEnabled)
{
Debug.Print("enabling DHCP.");
ethernet.NetworkInterface.EnableDhcp();
}
Debug.Print("closing ethernet");
ethernet.Close(); // close and open to force DHCP refresh in debug
Debug.Print("opening ethernet");
ethernet.Open();
This hangs at ethernet.Close() and ethernet.Open(). I also do not get an NetworkAddressChanged event.
I am not in the office today, but I will try your code on Monday. Maybe I got the j11d by then. I also ordered a new G400. I didn’t try it on that board yet.
I received the J11D and continued my investigations today. I condensed my test code to:
using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using GHI.Premium.Net;
using Microsoft.SPOT;
namespace EthernetG400
{
public class Program
{
private static EthernetBuiltIn ethernet;
public static void Main()
{
for (int i = 0; i < 20; i++)
{
Debug.Print("Waiting " + i);
Thread.Sleep(500);
}
ethernet = new EthernetBuiltIn();
ethernet.NetworkAddressChanged += EthOnNetworkAddressChanged;
if (!ethernet.NetworkInterface.IsDhcpEnabled)
{
Debug.Print("enabling DHCP.");
ethernet.NetworkInterface.EnableDhcp();
}
Debug.Print("closing ethernet");
ethernet.Close(); // close and open to force DHCP refresh in debug
Debug.Print("opening ethernet");
ethernet.Open();
Debug.Print("assigning ethernet to network stack");
NetworkInterfaceExtension.AssignNetworkingStackTo(ethernet);
Debug.Print("network initialized");
Thread.Sleep(Timeout.Infinite);
}
private static void EthOnNetworkAddressChanged(object sender, EventArgs e)
{
Debug.Print("Mac: " + FormatMacAddress(ethernet.NetworkInterface.PhysicalAddress));
Debug.Print("IP: " + ethernet.NetworkInterface.IPAddress);
Debug.Print("Subnet: " + ethernet.NetworkInterface.SubnetMask);
Debug.Print("Gateway: " + ethernet.NetworkInterface.GatewayAddress);
for (var i = 0; i < ethernet.NetworkInterface.DnsAddresses.Length; i++)
Debug.Print("DNS " + i + ": " + ethernet.NetworkInterface.DnsAddresses[i]);
if (ethernet.NetworkInterface.IPAddress != "0.0.0.0")
{
try
{
var address = "www.ghielectronics.com";
var ghiIp = Dns.GetHostEntry(address);
if (ghiIp != null)
{
Debug.Print("Testing access to Internet and DNS:");
Debug.Print(address + ": " + ghiIp.AddressList[0]);
}
else
{
Debug.Print("Could not resolve " + address);
}
}
catch (SocketException ex)
{
Debug.Print("Failed to Get the host entry of the FQN from DNS server!");
Debug.Print(ex.ToString());
}
}
}
private static string FormatMacAddress(byte[] mac)
{
if (mac.Length == 0) return string.Empty;
var macString = mac[0].ToString("X2");
for (var i = 1; i < mac.Length; i++)
macString += ":" + mac[i].ToString("X2");
return macString;
}
}
}
The code works with both the J11D and our WE socket, but only if the Visual Studio Debugger is not attached. If I start the G400 and connect with FEZ Config I see:
Connecting to G400_Gadgeteer connected. Waiting 6
Waiting 7
Waiting 8
Waiting 9
Waiting 10
Waiting 11
Waiting 12
Waiting 13
Waiting 14
Waiting 15
Waiting 16
Waiting 17
Waiting 18
Waiting 19
closing ethernet
opening ethernet
Warn ing: Ethernet PHY Link auton egotiation failu re.
Warning: Ethernet PHY Link autonegotiation failure.
Link detected 0x0
assigning ethernet to network stack
Mac: EE:27:44:09:78:84
IP: 10.30.1.146
Subnet: 255.255.255.0
Gateway: 10.30.1.1
DNS 0: 10.30.1.11
DNS 1: 10.30.2.10
Testing access to Internet and DNS:
www.ghielectronics.com: 207.58.176.212
If I just press F5 in Visual Studio the code hangs at
closing ethernet
I have to reset the hardware to be able to communicate again. Can you (or anyone else) reproduce the behavior?
Of course it would be great to use the G400 with both debugger and ethernet at the same time
BTW: If you think the code should work, you might want to post it in the G400 Document. Maybe that saves someone some time.
If I don’t call Close() I do not reliably get an IP address.
But I found today, that I can call
to get one.
@ Jeff:
I already tried that many times, but I have to admit: Today it works!
I have the feeling, that if I once got the G400 to hang at ethernet.Open() or ethernet.Close() it doesn't recover easily.
But it seems that it works now. Sorry to bother you and thanks for the help.
does not work reliably - at least not with debugger attached.
Sometimes it works as expected:
I get an IP address and when I disconnect and reconnect the cable, I get the address again (ethernet.NetworkAddressChanged is raised).
Sometimes it does not work:
I do not get an IP address and when I disconnect and reconnect the cable, ethernet.NetworkAddressChanged is not raised.
Is there anything I still do wrong? Can anyone reproduce that?
An example project that should definitely work with G400 and EthernetBuiltin would be great.
Not directly related, but… I was experiencing a very unstable behaviour, too, until I droped using global variables pointing to the ethernet interface (“ethernet” in your case). Now every time I want to do something with ethernet settings, I always get a fresh instance:
I did some further investigations on Peter’s issue.
I was able to reproduce the case in which the DHCP request was not completed successfully and recorded it with wireshark. (failed example.png)
The complete record is from message 99 (Discover) to 106 (2nd Ack). After that time, no more request happens.
The hardware address of the board is “3e:a0:c4:e2:b1:40” the DHCP server is “Microsoft_0c:64:00”.
As far as I know, the DHCP request should always be:
Discover -> Offer -> Request -> Ack
In the example in which the request was not successful the timing seems to be corrupted:
Discover -> Offer -> Request -> Discover -> Ack -> Offer -> Request -> Ack
I’ve also added a trace in which the request was successful. (working example.png)
Even though the request was successful the the Request -> Ack appears 3 times.
Do you have any ideas why the Discover (No 102) was sent immediately after the Request?