EMX with 4.2.9.0 UDP Broadcast Issue

NETMF & Gadgeteer
#1

I am attempting to broadcast on my subnet broadcast address 100.100.255.255 rather than 255.255.255.255. Below is my test code. If I use 255.255.255.255 I see it just fine, but if I use 100.100.255.255 I get an ARP request “who has 100.100.255.255? Tell 100.100.1.5”. Am I doing something wrong in my code or is this an issue with the new 4.2 network stack?

Looks like my issue might be related to this
http://www.tinyclr.com/forum/topic?id=10532


public class Program
    {
        public static void Main()
        {
            //Uncomment just one
            //string broadcastIP = "255.255.255.255";
            string broadcastIP = "100.100.255.255";

            // Start Ethernet (EMX)
            EthernetBuiltIn Ethernet = new EthernetBuiltIn();
            Ethernet.Open();
            NetworkInterfaceExtension.AssignNetworkingStackTo(Ethernet);
            NetworkInterface[] networkInterfaces = NetworkInterface.GetAllNetworkInterfaces();
            networkInterfaces[0].PhysicalAddress = new byte[] { 0x00, 0x1A, 0xF1, 0x00, 0x42, 0x0D };
            networkInterfaces[0].EnableStaticIP("100.100.1.5", "255.255.0.0", "100.100.0.1");
             
            // Set up UDP endpoint
            EndPoint localEndPoint = new IPEndPoint(IPAddress.Parse("100.100.1.5"), 28598);
            EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Parse(broadcastIP), 28599);
            Socket serverSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
            serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
            serverSocket.SetSocketOption(SocketOptionLevel.Udp, SocketOptionName.Broadcast, true);
            serverSocket.Bind(localEndPoint);
            
            byte[] sendData = new byte[] { 0x1E, 0x10, 0xFF, 0xFF };

            for (; ; )
            {
                serverSocket.SendTo(sendData, remoteEndPoint);
                Thread.Sleep(1000);
            }
        }
    }
#2

@ andre.m - I just tried this (see below) and still getting an ARP request.


public static void Main()
        {
            //string broadcastIP = "255.255.255.255";
            string broadcastIP = "192.168.0.255";

            // Start Ethernet (EMX)
            EthernetBuiltIn Ethernet = new EthernetBuiltIn();
            Ethernet.Open();
            NetworkInterfaceExtension.AssignNetworkingStackTo(Ethernet);
            NetworkInterface[] networkInterfaces = NetworkInterface.GetAllNetworkInterfaces();
            networkInterfaces[0].PhysicalAddress = new byte[] { 0x00, 0x1A, 0xF1, 0x00, 0x42, 0x0D };
            networkInterfaces[0].EnableStaticIP("192.168.0.2", "255.255.255.0", "192.168.0.1");
             
            // Set up UDP endpoint
            EndPoint localEndPoint = new IPEndPoint(IPAddress.Parse("192.168.0.2"), 28598);
            EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Parse(broadcastIP), 28599);
            Socket serverSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
            serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
            serverSocket.SetSocketOption(SocketOptionLevel.Udp, SocketOptionName.Broadcast, true);
            serverSocket.Bind(localEndPoint);
            
            byte[] sendData = new byte[] { 0x1E, 0x10, 0xFF, 0xFF };

            for (; ; )
            {
                serverSocket.SendTo(sendData, remoteEndPoint);
                Thread.Sleep(1000);
            }
        }
#3

@ andre.m - Same thing. Still getting an ARP request :frowning:

#4

@ andre.m - Tried adding a few other lines (see below). Still nope. I was going to send out for this issue last week but I figured I would poke around the forums all weekend in search of an answer. Did not realize 4.2 has a new networking framework.

Thank you for your help andre. This answers my question but should I mark this as solved since it is a bug?
Dan


serverSocket.Bind(localEndPoint);
serverSocket.Connect(remoteEndPoint);

as well as changing send to sendto


//serverSocket.Send(sendData, 0, sendData.Length, SocketFlags.Broadcast);
serverSocket.SendTo(sendData, remoteEndPoint);
#5

@ andre.m - Just double checking. Thanks for the quick replies. Much appreciated.

#6

I see this workissue on codeplex. It’s been closed for awhile but perhaps it’s related?

http://netmf.codeplex.com/workitem/754

EDIT
I meant this link http://netmf.codeplex.com/workitem/1166

#7

@ andre.m - You must have read my mind. I just gave the emulator a try and it’s working fine in there :confused: Just had to remove some of the GHI specific lines and change the local endpoint. Below is what I ran in the emulator.


public class Program
    {
        public static void Main()
        {
            //string broadcastIP = "255.255.255.255";
            string broadcastIP = "100.100.255.255";
             
            // Set up UDP endpoint
            EndPoint localEndPoint = new IPEndPoint(IPAddress.Parse("100.100.100.254"), 28598);
            EndPoint remoteEndPoint = new IPEndPoint(IPAddress.Parse(broadcastIP), 28599);
            Socket serverSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
            serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
            serverSocket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.Broadcast, true);
            serverSocket.Bind(localEndPoint);
            
            byte[] sendData = new byte[] { 0x1E, 0x10, 0xFF, 0xFF };

            for (; ; )
            {
                serverSocket.SendTo(sendData, remoteEndPoint);
                Thread.Sleep(1000);
            }
        }
    }
#8

Using ostinato, I injected an ARP reply for 100.100.255.255 to resolve to FF:FF:FF:FF:FF:FF and it started working properly. Obviously once this ARP record expires or the device is rebooted, it will stop working.

-Dan Powers

#9

Not exactly in this case as the TCP/IP stack used in NETMF is not used by the emulator. We will run few test on multiple devices to see if it is related to a single device or it is on all devices. My guess it will be on all devices and will report to Microsoft if that is the case.

#10

@ Gus - Thanks Gus! I’ll just work around the issue for now by using 255.255.255.255. It should work for my application for the time being.

Thanks guys,
Dan Powers

#11

@ Gus - looks like the issue is resolved in 4.2.10.0. Marking it as answered.