I'm working with a cluster of about 40 nodes running Debian 4. Each node runs a daemon which sits and listens on a multicast IP.
I wrote some client software to send out a multicast over the LAN with a client computer on the same switch as the cluster, so that each node in the cluster would receive the packet and respond.
It works great, except when I run the client software on a computer that has both LAN and WAN interfaces. If there is a WAN interface, the multicast doesn't work. So obviously, I figure the multicast is incorrectly going over the WAN interface (eth0), rather than the LAN (eth1.) So, I use the SO_BINDTODEVICE socket option to force the multicast socket to use eth1, and all is well.
But I thought that the kernel's routing table should determine that the LAN (eth1) is obviously a lower cost destination for the multicast. Is there some reason I have to explicitly force the socket to use eth1? And, is there some way (perhaps an ioctl call) that I can have the application automatically determine if a particular interface is a LAN or WAN?
If you don't explicitly bind to an
interface, I believe Linux uses the
interface for the default unicast
route for multicast sending.
Linux needs a multicast route, if none exists you will get a EHOSTUNREACH or ENETUNREACH error. The LCM project documents this possible problem. The routing will be overridden if you use the socket option IP_MULTICAST_IF or IPV6_MULTICAST_IF. You are supposed be able to specify the interface via scope-id field in IPv6 addresses but not all platforms properly support it. As dameiss points out, Stevens' Unix Network Programming book covers these details, you can browse most of the chapter on multicast via Google Books for free.
If you don't explicitly bind to an interface, I believe Linux uses the interface for the default unicast route for multicast sending. So my guess is that your default route is via the WAN interface.
Richard Stevens' "Unix Network Programming, Vol. 1", chapter 17 (at least in the 3rd edition), has some good information and examples of how to enumerate the network interfaces.
Related
I am a beginner in OPC UA, exploring the discovery mechanisms mentioned in part 12 of the specification. I have a couple of queries.
In the Multicast extension discovery, the server registers to its Local discovery server(LDS ME), and when client does the registration to its LDS-ME, the client side LDS-ME issues a multicast probe for which the server side LDS-ME responds with an announcement, thus allowing the client to know the list of servers in the network.
My question here is, why is the process referred as Multicast probe and multicast announcement. Because as per the mDNS specification, probe and announcement are used initially to secure unique ownership of a resource record. Anybody could tell me why is it referred as probe and announce?
In the open62541 stack, with the discovery examples, running the server_lds.c, i get a log message saying "Multicast DNS: outbound interface 0.0.0.0, it means that the first OS interface is used (you can explicitly set the interface by using 'discovery.mdnsInterfaceIP' config parameter)".
Now theory says multicast dns IP should be 224.0.0.251: 5353
Why is it being set to 0.0.0.0? Could anyone please let me know?
Regards,
Rakshan
There is no relation to the words "probe" and "announce" used in the mDNS Spec. It just says probe, means look-up or query, and announce like "there are the follwing results related to your probe request".
0.0.0.0 means here every Ipv4 interface is used (bound). So every capable interface in your system will be configured for mDNS. Should be the way you mentioned.
"0.0.0.0" => have a look here https://en.wikipedia.org/wiki/0.0.0.0
Hints about working with VLAN? I have to write a client-server program, where the client will send a packet through eth0 and the server will receive the packet on VLAN, and to send it to a concerned VLAN client should parse on which command line VLAN will receive it?
Usually there is nothing to do in the application to work with a VLAN. The VLAN is realized using a virtual network interface with its own IP address. From the perspective of the application this is not different from a real network interface with own IP address. The OS will take care about routing and encapsulation of packets and there is nothing to do from the application itself.
I am recently writing some tool for testing some network processes that run across different hosts.
I am tempted to the idea that when testing, instead of running the client and server in different hosts, I can run them within one host.
Since the client and server are using TCP to communicate, so I think this should be fine, except one point below:
Is the TCP socket behavior the same when communicating data within the same host as the case of across hosts?
Will the data be physically present to the NIC interface and then routed to the target socket? Or the kernel will bypass the NIC interface under such scenarios? (Let's limit the OS as only Linux here for discussion)
There seems little specification regarding to such case.
==== EDIT ====
I actually notice some difference between intra-host and inter-host communications.
When doing inter-host communications, my program can successfully get hardware timestamp. But with the exact same code to run within the same host, the hardware timestamp disappears. When supported and enabled, hardware timestamp of TCP packet is available, and is returned as the ancillary data of recvmsg along with the received TCP data. Linux kernel timestamp doc has all the related info.
I checked the source code, the only difference is that whether the sender is within the same host of the receiver, no other difference.
So I am wondering whether Linux kernel will bypass the NIC and present the data directly to the receiver when doing intra-host communication, thus cause the issue.
Will the data be physically present to the NIC interface and then routed to the target socket?
No. There is typically no device that provides this capability, nor is there any need for one.
Or the kernel will bypass the NIC interface under such scenarios?
The kernel will not use the NIC unless it needs to send or receive a packet on a network. Typically, NICs can only return local packets if put in a test or loopback mode, which would require them to stop listening to the network.
When programming in linux sockets, we are invoking the standard libraries socket(), connect(), send() and so on, but if we have two network adapters connected to the same LAN, can we choose one manually or it depends on the route table configured by the administrator that we can't change or something else?
Well, you can specify interface with bind(), since every interface has its unique IP address.
I would like to learn that once and for all. What is the procedure to connect a multicast socket? I know you have to bind to a local interface (do you need IP and port for that?) then I know you have to join a group (do you need IP:PORT for the address you want to join and the network interface again!!!??) and then finally you can leave the group.
Can someone with experience clarify what is the whole of those many addresses? I will list below:
BindAddress (IP:PORT)
NetworkAddress (IP:PORT)
MulticastAddress (IP:PORT)
Where and what is the multicast group here?
A multicast group is a special IP address. You join it via setsockopt() using the socket option IP_ADDMEMBERSHIP, or e.g. in Java via MulticastSocket.joinGroup(). No port number here. If you want to join via a specific local address, use the overload that specifies a local address, or call setNetworkInterface() first.
Binding to a local address is a separate operation, which primarily determines which local addresses the socket can send and receive data on: one, or all of them: either one local address, which determines which of your available subnets you are listening to and can send via, or a port, or both. Normally it is best to use INADDR_ANY as the bind-address, unless your application magically knows about the network topology.
This is muddied by the fact that you can bind to a multicast address in Linux, but this appears to be a misunderstanding that will now always be with us.
You send to a multicast group by sending to the multicast address.
Yes, you must define both the address and the port for sending/receiving multicast messages. These are UDP packets, so they require both address and port for the networking stack to be able to properly deliver the messages to participating processes. So to listen for a particular set of multicast messages, your application needs to bind to a particular multicast ip address and port combination (and obviously for a set or all interfaces on the machine). The group is defined by the address/port combination.
Good quick explanation
Some sample source code in C and other languages