LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UDP Multicast on Windows 10

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)

0 Kudos
Message 1 of 9
(18,263 Views)

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'?

Regards,
Eirikur Runarsson
0 Kudos
Message 2 of 9
(18,168 Views)

Any update on this from your end?

Regards,
Eirikur Runarsson
0 Kudos
Message 3 of 9
(18,120 Views)

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.

0 Kudos
Message 4 of 9
(16,876 Views)

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.

0 Kudos
Message 5 of 9
(16,773 Views)

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? 

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 9
(16,762 Views)

Thanks for the reply, you may be onto something here. If I uncheck the IPV6 options on Win10 control panel (disable/enable the adapter) it starts to work as expected - result!!!!!

 

Although, trying the same trick on another PC did not work (Further investigation on this part required)

 

Many thanks, Paul.

0 Kudos
Message 7 of 9
(16,501 Views)

Update.

 

It appears that the act of disabling and re-enabling the ethernet adapter will cause the software to work - even without touching any other setting. Looks more like a Win10 security feature is doing something here unfortunately.

 

Paul.

0 Kudos
Message 8 of 9
(16,132 Views)

Hello paulc,

 

I had a detailed look at your question, the Universal Plug and Play Device Architecture 1.1 (which I used as reference), and Microsoft's Knowledge Base on how Windows 10 regulated UPnP traffic. I developed a new VI (in LabVIEW 2017) to find UPnP devices, which looks a bit different than your approach. It works on several Windows 10 PCs here, however I have not tested which part of your solution exactly is the one preventing the discovery.

 

Most likely, it is that UPnP devices respond to a M-SEARCH multicast message with a unicast datagram. Your example VI had a multicast receiver, I implemented a unicast receiver. 

 

To anyone executing the example: 

- Change the "Local address" to your computer's IP before executing. (I needed this as my computer has several IPs and I needed to define which interface my VI shall send the Multicast from.)

- I define a client wait time of two seconds ("MX:2") in the Multicast message. According to the UPnP standard the answering devices should answer within two seconds (plus network delay). However, I had device here that sometimes needed up to 4 seconds to respond. Therefore I programmed my VI to wait five seconds. Please be aware of this when re-using my code and change the value accordingly.


Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
Message 9 of 9
(11,971 Views)