UDP Multicast on Windows 10

[paulc]

Hi, I have an application which discovers UPNP devices on a network. The application has worked on Windows XP and Windows 7. When testing this application on Windows 10 it appeared to stop working after a reboot.

I have checked the inbound and outbound rules on the firewall and allowed TCP and UDP on all ports for the application. I have even disabled the firewall, group policy and anti-vrus. The UAC level are switched off. I have had the IT manager log on as a "super-user" and the same situation occurs.

The application will work however after I run the Labview shipped examples:

• UDP Multicast Receiver.vi
• UDP Multcast Sender.vi

After a reboot it will stop working again until I run the examples. No issues with this on Win XP or Win 7.  When running wireshark I can see that outbound discovery message is missing, I can see traffic on the recive ports so I assume it's the outbound message which is being blocked.

I have attached a similar example (LV 7.1) of our application - which detects UPNP traffic.

Has anyone seen something like this?

I should add I have tried this vi in Labview 2015 (built from 2015 vi's) and have had the same result.

(as a work-a-round I can run the examples prior to the application and all works fine)

[Eirikur]

If I run the VI as is, with default values for 'Send to Port' and 'local port' it does not work. However, if I set the two controls to contain the same portnumber it works on my Win10 - also after reboot and with out having run UDB Multicast example before.

Is it intentional that these port numbers are different in 'local port' and 'Send to port'?

[Eirikur]

Any update on this from your end?

[paulc]

Hi, yes this is intentional. If you use the same port it acts as a "loopback". 

The UPNP port for common traffic is 1900 - with the device responding to the local port.

Paul.

[paulc]

Update:The below "fix" no longer works.

The application will work however after I run the Labview shipped examples: 

• UDP Multicast Receiver.vi
• UDP Multcast Sender.vi

I have rebuilt the tests using examples from Labview 2015 (UDP read and UDP write) with the same result. It still seems that something is preventing the UDP message from leaving the PC on the send port (confirmed by Wireshark). I am at a loss just now as to why - downgrading the OS in the same PC from Win10 to Win7 fixes the issue completely.

It looks like a Labview/Win10 issue as other programs on the same PC can send UDP traffic out on that port OK (again confirmed by wireshark). Again, tried with firewall off/on and creating inbound and outbound rules within the firewall when activated.

The UDP message example is as follows:

M-SEARCH * HTTP/1.1
ST: upnp:rootdevice
MAN: "ssdp:discover"
MX: 5
HOST: 239.255.255.250:1900
Content-Length: 0

The message is sent via a port, that port then grabs the incoming data from the devices which reply. If I compare the outgoing message with another (generated from another program) it is identical. In wireshark the outgoing message shows as SSDP traffic. Example trace attached.

If anyone else is using UDP with external hardware comms I would be interested to discuss?

Paul.

[rolfk]

I'm not sure this is relevant, but the later messages after the one you show seem to be IPv6 IP addresses. The LabVIEW TCP/IP stack interface definitely doesn't support IPv6 frames. Maybe there was an IPv6 to IPv4 translation in the earlier Windows stack that made sure those messages arrived as IPv4 frames in LabVIEW anyways?