Problems with multicast UDP not putting NIC in promiscuous mode

[hobbss]

Using the UDP multicast read example, I have a significant problem.

The UDP tool in Labview does not configure the NIC to listen for multicast packets properly.  I.e., the read example does not work if it runs alone.  If I simultaneously run a packet sniffing program in promiscuous mode (i.e., Wireshark), the example works perfectly.  I have looked at the diagnostics of my NIC and verified that it is discarding all multicast packets when the VI is running -- unless Wireshark is also performing a live capture (which somehow tells the NIC to keep the multicast messages).

Am I missing something and/or is there a way around this problem?

[JD_war_eagle]

Hey hobbss,

It sounds like this could be caused by Labview being unable to properly control the NIC driver to place the card in promiscuous mode.  Are you trying to receive multicast packets from the multicast sender example?  What version of Labview are you using?  What NIC do you have and what driver?

[hobbss]

Justin,

Thanks for the response.  I believe that that is the problem exactly (that Labview is not properly controling the NIC driver).  I am using Labview 2010.  My NIC is a Broadcom NetXtreme 57xx Gigabit Controller.  The driver is b57nd60a.sys.

I am trying to read packets transmitted to a multicast address from another [non-Labview] source (different physical computer).  Again, it sees the packets perfectly if Wireshark is running, but not at all if Wireshark isn't.

[JD_war_eagle]

I am actually using the same NIC in my computer currently and I am not having an issue with it.  My driver version is 12.2.0.3, and I am running Windows 7.  Possibly upgrading to the newest driver from http://www.broadcom.com/support/ethernet_nic/downloaddrivers.php may help.  Also installing the newest Labview device drivers from http://joule.ni.com/nidu/cds/view/p/id/2602/lang/en may help.  I know the LV drivers are a big download so make sure you try to upgrade your NIC driver first before you resort to the LV drivers.

[hobbss]

Justin,

Thanks again for your help.  I believe that I have solved the problem.

According to IEEE Std 802.3-2002, Section 1, the only requirement for a destination MAC address for multicast is that the least significant bit of the most significant byte of the address be a '1':

Quote:

The first bit (LSB) shall be used in the Destination Address field as an address type designation bit to
identify the Destination Address either as an individual or as a group address. If this bit is 0, it shall
indicate that the address field contains an individual address. If this bit is 1, it shall indicate that the
address field contains a group address that identifies none, one or more, or all of the stations connected
to the LAN. In the Source Address field, the first bit is reserved and set to 0.

To meet this requirement, I was using a destination mac address with a MSByte of 0x47.

However, according to wikipedia, the range of acceptable multicast addresses is: 01:00:5E:00:00:00 to 01:00:5E:7F:FF:FF. When I changed the destination address to something in this range in my multicast tx program, the Labview script started working (without requiring Wireshark to be running).

I believe Wireshark is configuring the NIC differently than Labview is (perhaps in a more robust/thorough manner?). However, both of them work if I put the destination mac address in the above range.

Note -- I have seen a few threads similar to this one (i.e., "my Labview Multicast read only works when Wireshark/Ethereal is running") posted over the last couple of years.  None of them were resolved.  It is possible that some/all of them may be solved by using a mac address in the above range.

[rolfk]

You are right that multicast is only meant to work for a specific range of addresses, but the address you mention looks more like a MAC address than an IP address. IPv6 would use up to eight groups of 4 character hex numbers.

The correct IPv4 address range for multicast group addresses is 224.0.0.0 to 239.255.255.255 or FF00::/8 for IPv6. The LabVIEW multicast VIs adhere strictly to that range as far as I could find (but LabVIEW doesn't support IPv6).

I find the requirement to manipulate the MAC address to make an interface multicast capable a very strange thing. The MAC address is meant to stay fixed (although there exist tools for most NIC manufactureres to change their MAC address).

As to what Wireshark does with a NIC, not much really! 🙂

It's the underlaying PCAP driver that Wireshark uses that does all kinds of complicated things to the NIC in order to set it into promiscious mode. That may as well have a side effect on the TCP/IP stack in how to treat multicast packets.

[hobbss]

I am referring to the MAC address -- the destination MAC address.  I started finding the solution here:

http://en.wikipedia.org/wiki/IP_multicast --> scroll down to the section titled: Layer 2 Delivery

and finished finding the solution here:

http://technet.microsoft.com/en-us/library/cc957928.aspx

In my application, I am building the [multicast] udp packets by hand.  I knew the IPv4 destination IP address had to be in a specific range, but did not realize that the destination MAC address also had restrictions -- I had picked a destination mac address (in the eth header) randomly.  When I fixed the destination address as described in the first link, my receiving labview script started working.  I then fixed it as described in the second link to be completely compliant with the standard.

[rambefrank]

Hi sir,

If its possible can you please share the simple UDP chatting application to me.

In my code UDP transmitter sending properly but in the UDP receiver err coming as 54, 56 and 60.

Just know i started learning the labview so i facing this problem.

[rolfk]

Have you looked at the examples that come with LabVIEW? Start the Example Finder from the LabVIEW Help menu and search for UDP and it will show you what examples LabVIEW comes with.

If those examples don't work (after possibly adjusting the IP addresses to your network configuration) you have some problems in the network setup somehow and need to get that working first.

[altenbach]

---

rambefrank wrote:

In my code UDP transmitter sending properly but in the UDP receiver err coming as 54, 56 and 60.

---

You have the following problems, and none are LabVIEW problems. How familiar are you with TCP/IP networking in general? (IP addresses, ports, protocols, etc.)

It looks like your inputs are malformed, your timeout are too short, or you are trying to listen on a port that is already in use:

• 54 LabVIEW:  The network address is ill-formed. Make sure the address is in a valid format. For TCP/IP, the address can be either a machine name or an IP address in the form xxx.xxx.xxx.xxx. If this error occurs when specifying a machine name, make sure the machine name is valid. Try to ping the machine name. Check that you have a DNS server properly configured. If you are using the TCP Open Connection function, ensure that the value of the remote port or service name is not 0.
• 56 LabVIEW:  The network operation exceeded the user-specified or system time limit.
• 60 LabVIEW:  The specified port or network address is currently in use. Select an available port or network address.