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?
Related
Similar to How to set source address when sending using and UDP socket, but not identical:
I'm writing an experimental UDP packet relay.
The code works so far, but the problem is that the relayed packets have the address and port of the relay (instead of the original sender) as sending address in the outgoing packets, so any responses would also go to the relay, and not to the original sender.
Is there a standard way (without manipulating the packets directly) to do this?
Currently it has to work for IPv4 only.
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?
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.
(edit: solved -- see below)
This is my situation:
TL-MR3020 -----ethernet----- mbed
OpenWRT C/C++ custom networking stack
192.168.2.1 192.168.2.16
TL-MR3020 is a Linux embedded router
mbed is an ARM microcontroller.
On the network I just want them to exchange messages using UDP packets on port 2225. In particular, TL-MR3020 has to periodically send packets every second to 192.168.2.16:2225, while mbed has to periodically send packets every 50ms to 192.168.2.1:2225.
Everything was good untill I removed the network stack library from mbed (lwIP, not so lightweight for me) and written a new minimal stack.
My new stacks sends 5 gratuitous ARP reply just after the ethernet link gets up, then starts sending and receiving udp packets.
Now TL-MR3020 doesn't receive any UDP packet. In particular, with ifconfig I can see packets coming, but my application can't get them.
Also, if I connect my laptop instead of the TL-MR3020, I can see the UDP packets coming, using Wireshark. There's nothing wrong, except done for my application.
I have a node.js script that has to receive the packets, but it doesn't receive nothing, but if I send UDP packets from local to local, the script receives them.
I think that my application is OK also because neither SOCAT can receive the UDP packets using socat - UDP-LISTEN:2225.
I've already checked on TL-MR3020:
arp table has the correct ip-mac assiciation
destination MAC address matches the incoming interface
destination IP address matches the incoming interface
IP checksum: wireshark says good=false, bad=false
UDP checksum: wireshark says good=false, bad=false
So, I'm asking... what are the minimum requirements for a custom networking stack to send UDP packets?
SOLVED:
You need a good checksum in the IP header.
UDP checksum, my case, can be set to zero.
tcpdump is very helpful (thanks to AndrewMcDonnell)
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.