I'm having a similar problem to Linux Kernel not passing through multicast UDP packets only broadcast rather than multicast, and nothing I've tried has helped.

I've got a device at spewing out broadcast UDP packets, connected directly to eth1 ( eth0 is my real network. ifconfig tells me the broadcast address, as expected, is

$ sudo ifconfig
eth0  Link encap:Ethernet  HWaddr 54:04:a6:64:b5:a6  
      inet addr:  Bcast:  Mask:
      inet6 addr: fe80::5604:a6ff:fe64:b5a6/64 Scope:Link
      RX packets:1526809 errors:0 dropped:0 overruns:0 frame:0
      TX packets:986480 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:807179430 (807.1 MB)  TX bytes:747692150 (747.6 MB)

eth1  Link encap:Ethernet  HWaddr 00:50:b6:15:6e:9a  
      inet addr:  Bcast:  Mask:
      inet6 addr: fe80::250:b6ff:fe15:6e9a/64 Scope:Link
      RX packets:544315 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:572619380 (572.6 MB)  TX bytes:77544 (77.5 KB)

tcpdump confirms I've got data hitting the port.

$ sudo tcpdump -c 4 -l -n -i eth1 'udp and port 61440'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
09:24:51.101619 IP > UDP, length 1024
09:24:51.103980 IP > UDP, length 1024
09:24:51.106205 IP > UDP, length 1024
09:24:51.108584 IP > UDP, length 1024
4 packets captured
114 packets received by filter
0 packets dropped by kernel

But from anything I've tried to actually pick those packets up, I've got radio silence, whether I run them as user or root.

$ nc -lu 61440
$ socat UDP4-RECV:61440,reuseaddr,bind= STDOUT,nonblock=1

Also tried writing my own C and my own Python. Nada. Something in all this is stealing my packets. Any ideas on what? Ubuntu 14.04.

Edit to add: No firewall running. ufw reports inactive, and iptables reports all 3 tables as a bare ACCEPT.

I also tried having netcat and socat bind the overall broadcast address of, or the eth1 local address No packets received on any attempt.

Routing tables show nothing out of the ordinary:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 eth0     U     1      0        0 eth0     U     0      0        0 eth1

I know that the network interface is working correctly. If I disconnect this device and attach a different type (which is trying to DHCP) it successfully connects with the dnsmasq instance and gets assigned a lease properly.

Interestingly, asking socat to give me raw IP packets turns them up just fine:

$ sudo socat IP4-RECVFROM:17 STDOUT | hexdump 
0000000 0000 00f0 0804 4bb1 6463 6665 6867 6a69
0000010 6c6b 6e6d 606f 6261 6463 6665 6867 6a69


Going in and looking more deeply at the packets, it looks like they've got bad checksums. I think they're not getting passed along through the UDP stack because of that. I've also run out of time for elegant solutions to this problem, and have decided to brute force it by opening a socket on raw IP packets and filtering them myself. Thanks, everyone, for your help.

  • Shouldn't the application be sending to rather than Also, you cannot bind to a broadcast address - you need the receiving application to bind to a local unicast address for the interface which will be receiving the broadcast packets; they will then be directed to the listening socket (of your application) via the system network stack as normal.
    – parkamark
    Jun 1 '16 at 16:51
  • Why the device broadcast ? Update the firmware of it ?
    – yagmoth555
    Jun 1 '16 at 16:54
  • No go on changing the device; it is what it is. but broadcasting to is entirely legal; it's how a DHCP DISCOVER goes out.
    – Rgaddi
    Jun 1 '16 at 18:01
  • @parkamark I tried binding to the unicast address, i.e. the eth1 local address. No luck. And any other addresses, for instance, give me Cannot assign requested address.
    – Rgaddi
    Jun 1 '16 at 18:04
  • I know that, but the answer is a broadcast too. Why no answer in your broadcast packet log ? Your dhcp server dont follow the RFC ?
    – yagmoth555
    Jun 1 '16 at 18:08

Here is a python script for testing UDP connections that I have used in the past:

import socket
#---socket creation
connexion = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

    connexion.bind(('', 10015))
except socket.error:
    print "connexion failed"

while 1:
    data, addr = connexion.recvfrom(1024)
    print "messages : ",addr , data

The following can be entered into shell prompt to test sending a message

echo -n "TEST MESSAGE" >/dev/udp/

Testing it from localhost to localhost would be the first troubleshooting step, and then from another computer to the computer in question.


I have had similar problems when I set up a secondary network interface by hand, and didn't set up routing properly for that interface.

Try running: route -n and see what what the routing configuration is for eth1.

  • Nothing unexpected. 172.16.*.* and the gateway on eth0. 192.168.*.* on eth1.
    – Rgaddi
    Jun 3 '16 at 16:13
  • Sorry that didn't help. In that case, I recommend trying the answer by @CaffeineAddiction.
    – Epictitus
    Jun 6 '16 at 18:27
  • Oh, I just noticed your edit where you said that your device is generating packets with bad checksums, and you're switching to a brute-force approach reading raw packets. Good luck!
    – Epictitus
    Jun 6 '16 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.