I have a server on pc with address 192.168.1.3, and a client socket bound with address in different subnet 92.1.1.1. client and server are connected via a switch.
from wireshark, I could see the interface 192.168.1.3 receives the packets from 92.1.1.1, but at udp server level, there are no packets received.
Are the packets get dropped because they are from different subnet? But at which layer are they dropped? How do I check what happened?
Related
I tried to receive broadcast packets on an interface that has no IPv4 address set.
The packets are visible via tcpdump. But the network stack seems to drop the packets before they can be received via a socket.
Is this possible without libpcap?
I am using this code to experiment with multicast.
I have wireshark running on another PC in the LAN and I am trying to see the packets sent over the network.
If packets are sent to the IP address 224.0.0.1 they are correctly received, if I send them to the address 239.255.255.250 they are not.
I have this entry in my routing table
224.0.0.0/4 dev eth0.100 src 192.0.0.1
I know 192.0.0.1 looks weird, but it is the correct interface address
Do you know why packets are not being sent?
The PC that you are attempting to capture the multicast traffic most likely has multicast filtering enabled and has not enabled reception of the 239.255.255.250 group.
Any host device that communicates multicast joins the 224.0.0.1 (All Hosts group) so packets sent to that group pass the filter, but not packets sent to 239.255.255.250.
Multicast filtering is usually implemented in the network interface and received frames that don't pass the filter will be dropped in hardware instead of being passed up to the Kernel driver. If the frames are not passed to the Kernel, then Wireshark can not capture them.
You can verify the active multicast groups per interface with netstat. I'm assuming you're on a Linux system since you tagged the question with "Linux"
netstat -g
Multicast groups are joined when a socket enables the IP_ADD_MEMBERSHIP socket option. In order to join the group on your capturing device, you'll need a program that creates a socket and joins the multicast group using the IP_ADD_MEMBERSHIP socket option
To add to Joel Cunningham's answer in the case of switched LAN:
There's nothing listening for multicast on 239.255.255.250, thus no IGMP joins are sent out. thus the switch does not propagate these multicast frames to the port where you have the wireshark(1)-running PC.
Again, 226.0.0.1 is well known and is always joined to by all hosts.
My server listens on a UDP port and also receives broadcast messages. Can I detect somehow if the received message was sent to my ip directly or to a broadcast address? rinfo just gives me the sender information
It is currently not possible.
See this Github bug link
Workaround:
have different internal ports for the broadcast and the normal traffic.
Use iptables to redirect broadcast traffic to one of the internal port and the other traffic to the other port.
I implemented a network discovery process which makes use of multicast messages. It allows to discover specific devices with any ip-address connected to the same segment.
Client A sends a multicast messages, asking for other Clients. The other clients response with a multicast message "I'am here...". Basically this works fine.
But there is one case which causes me troubles.
Client A Client B
192.168.2.5 192.168.2.5
| |
\__________ /
>>>
UDP Multicast Message:
Source: 192.168.2.5 | Destination: 224.0.0.150
The coincident could arise, that Client A which sends the multicast message and Client B both listen to the same ip-address. In this case the source address of the UDP packet is the same as the ip-address of the destination client. Thus the application on Client B does not receive any multicast message.
I guess that the multicast message with the same messages gets blocked and dropped in the ip-stack. Is there a way (socket settings) to receive it anyway.
Yes, you can have a host read its own multicast packets(which is often just a filter on the source IP address), this is controlled by the IP_MULTICAST_LOOP socket option.
int loop = 1;
setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
To receive a multicast on my not default NIC (dvb) I do the following:
open a socket (AF_INET, SOCK_DGRAM)
join the multicast address with IP_ADD_MEMBERSHIP on the dvb interface
bind the multicast address (note that a common error is to bind "0.0.0.0" and then receive on that socket even multicast you are not interested in) and the port
at this point the only way to receive the needed multicast packets is to add in the routing table a rule to reach the network where the sender is (another network) trough the dvb, as if the dvb needs to reply to the multicast sender; let say a sort of source sender multicast mode. Anyone knows what is going on? The problem is annoying to me because in principle I don't know the ip of sender.
You appear to be being stung by rp_filter reverse-path filtering. This drops packets if they arrive on an interface that doesn't have a route for the source address.
You can disable it on a per-interface basis with the sysctl /proc/sys/net/ipv4/conf/<if>/rp_filter.
bind the multicast address
That is definitely wrong. You must bind to an actual IP address of a real adapter, or 0.0.0.0.
note that a common error is to bind
"0.0.0.0"
That's not an error. THat is correct procedure unless you only want to listen to one IP address.
and then receive on that
socket even multicast you are not
interested in
I don't know what this means.
in principle I don't know the ip of sender
The IP address of the sender of any UDP datagram is available via the sockets API.