Gus, I did find that a previous issue I was having (UDP simply stopped sending in a Syslog sender I wrote) was fixed with the latest firmware/SDK.
The exception in this use case is getting thrown in one of the four socketopt calls and within the following code (looking at the 4.2 source tree). I am going to take this code and run by itself, and see what results I get–will report back shortly.
/// <summary>
/// Opens the stream for the UDP tansport binding
/// </summary>
/// <param name="stream">The stream for this binding.</param>
/// <param name="ctx">The context associated with the stream for this binding.</param>
/// <returns>The handling status for this operation.</returns>
protected override ChainResult OnOpen( ref Stream stream, BindingContext ctx )
{
m_udpReceiveClient = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
IPEndPoint localEP = new IPEndPoint(s_localIP, m_config.DiscoveryPort);
m_udpReceiveClient.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
m_udpReceiveClient.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReceiveBuffer, 0x5000);
// Join Multicast Group
byte[] discoveryAddr = m_config.DiscoveryAddress.GetAddressBytes();
byte[] ipAddr = s_localIP.GetAddressBytes();
byte[] multicastOpt = new byte[] { discoveryAddr[0], discoveryAddr[1], discoveryAddr[2], discoveryAddr[3], // WsDiscovery Multicast Address: 239.255.255.250
ipAddr [0], ipAddr [1], ipAddr [2], ipAddr [3] }; // Local IPAddress
m_udpReceiveClient.Bind(localEP);
m_udpReceiveClient.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.MulticastInterface, ipAddr );
m_udpReceiveClient.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.AddMembership, multicastOpt);
return ChainResult.Continue;
}
OK, here’s the repro code. I followed the stack call all the way through the NET MF 4.2 source and the only basic difference is the use of the WSDiscovery multicast address of 239.255.255.250, and I used IPAddrAny. I have chosen to use the accepted (private) administrative multicast address in the repro code. I get the same exception as in the WS code.
public static Gadgeteer.Modules.GHIElectronics.Ethernet_J11D eth0;
public static void Main()
{
Mainboard = new GHIElectronics.Gadgeteer.FEZSpider();
Program program = new Program();
eth0 = new Gadgeteer.Modules.GHIElectronics.Ethernet_J11D(7);
program.BugRepro();
}
public void BugRepro()
{
Program.eth0.UseThisNetworkInterface();
Program.eth0.UseStaticIP("192.168.0.80", "255.255.255.0", "192.168.0.1");
IPAddress anyIPAddr = IPAddress.Any;
IPEndPoint endPoint = new IPEndPoint(anyIPAddr, 9000);
System.Net.Sockets.Socket socket = new System.Net.Sockets.Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, 1);
socket.Bind(endPoint);
byte[] discoveryAddr = IPAddress.Parse("239.0.0.10").GetAddressBytes(); // administratively scoped IPv4 multicast address
byte[] ipAddr = IPAddress.Any.GetAddressBytes();
byte[] multicastOpt = new byte[] { discoveryAddr[0], discoveryAddr[1], discoveryAddr[2], discoveryAddr[3], // WsDiscovery Multicast Address: 239.255.255.250
ipAddr [0], ipAddr [1], ipAddr [2], ipAddr [3] }; // Local IPAddress
socket.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.AddMembership, multicastOpt);
}
Not sire if multicast was tested but the bug we had was related to the hardware driver not the TCP/IP stack. If we can locate a problem with the stack then we can try to track it down and probably involve Microsoft as this may effect all devices.
Gus, a little digging in the NETMF sockets layer and I found the following content buried in the socket options source:
/// <para>
/// IP multicast interface.
/// - Additional comments by mbolien:
/// multicast interface You provide it with an SOCKADDR_IN, and that tells the
/// system that it should receive multicast messages on that interface (if you
/// have more than one interface). Binding the socket is not sufficient, since
/// if the Ethernet hardware isnt set up to grab the multicast packets, it wont
/// do good to bind the socket. Kinda like raw sockets. Unless you
/// put the Ethernet card in promiscuous mode, youll only get stuff sent to and
/// from your machine.
/// </para>
Can you verify if the Ethernet driver for the J11D is supporting a promiscuous mode for multicast support? If not, honestly not sure how we get DPWS working if the underlying framework is requiring setting up a UDP multicast session first and if in fact, according to this comment, the Ethernet hardware must be able to support promiscuous?
Didn’t GHI enable multiple IP stacks in the 4.2 release? if so I am wondering if the issue is caused by the socket not being bound to a local IP address. I know that with 4.1 UDP multicast greeting messages work in the emulator but not on the spider due to the Send socket not being bound (http://www.tinyclr.com/forum/topic?id=2057&page=2).
My thinking is that with the single IP stack, not binding the receive socket may be ok but with multiple interfaces, the lack of binding could cause the 10049 error as described here: sending UDP packet from microcontroller, binding problems
Low memory devices e.g. mountaineer do not have the xmlreader class implemented; DPWS needs this class.so no.
For Mountaineer I built a version of DPWS server that uses my own leightweight xml reader and has no discovery service ; it works great. Once the udp issue is fixed I plan to add discovery, memory permitting
