I have a Fedora 20 machine which is receiving UDP broadcast packets at regular intervals on a strange high port. No program is presently listening for these packets. If I run, "tcpdump -i eth0 port 29531", I see each of the packets arriving just as I expect. Note, the packets are not empty and contain mostly ASCII characters.
But if I then run, "nc -lu 29531", I don't see anything! Why not? What obvious thing am I missing?
This same operation works better (but still not as I expect) on Fedora 14. NC shows one packet arriving but then doesn't show any more.
Running NC under strace on both machines, I see F14 NC seems to use poll(2). It outputs one packet then hangs on poll. F20 NC seems to use select(2). It hangs on the first call.
SELinux and the firewall are disabled on both machines.
On 06/26/2014 09:53 AM, CLOSE Dave issued this missive:
I have a Fedora 20 machine which is receiving UDP broadcast packets at regular intervals on a strange high port. No program is presently listening for these packets. If I run, "tcpdump -i eth0 port 29531", I see each of the packets arriving just as I expect. Note, the packets are not empty and contain mostly ASCII characters.
But if I then run, "nc -lu 29531", I don't see anything! Why not? What obvious thing am I missing?
This same operation works better (but still not as I expect) on Fedora 14. NC shows one packet arriving but then doesn't show any more.
Running NC under strace on both machines, I see F14 NC seems to use poll(2). It outputs one packet then hangs on poll. F20 NC seems to use select(2). It hangs on the first call.
SELinux and the firewall are disabled on both machines.
You may need to use "nc -lu --recv-only 29531" so the system doesn't try to reply to the packet. Perhaps it's better to use wireshark or tcpdump to copy the data to a file and examine it. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - NEWS FLASH! Intelligence of mankind decreasing! Details at... - - uh, when, uh, the little hand is, uh, on the... Aw, NUTS! - ----------------------------------------------------------------------
I wrote:
I have a Fedora 20 machine which is receiving UDP broadcast packets at regular intervals on a strange high port. No program is presently listening for these packets. If I run, "tcpdump -i eth0 port 29531", I see each of the packets arriving just as I expect. Note, the packets are not empty and contain mostly ASCII characters.
But if I then run, "nc -lu 29531", I don't see anything! Why not? What obvious thing am I missing?
This same operation works better (but still not as I expect) on Fedora 14. NC shows one packet arriving but then doesn't show any more.
Running NC under strace on both machines, I see F14 NC seems to use poll(2). It outputs one packet then hangs on poll. F20 NC seems to use select(2). It hangs on the first call.
SELinux and the firewall are disabled on both machines.
Rick Stevens answered:
You may need to use "nc -lu --recv-only 29531" so the system doesn't try to reply to the packet. Perhaps it's better to use wireshark or tcpdump to copy the data to a file and examine it.
Thanks. But that doesn't make any obvious difference. Still no output.
If examining the packets were my only concern, tcpdump would do just fine. But I actually have a program which would like to receive those packets and doesn't. Using NC is part of the investigation to discover why not. But NC doesn't seem to get the packets, either.
On 06/26/2014 11:21 AM, CLOSE Dave issued this missive:
I wrote:
I have a Fedora 20 machine which is receiving UDP broadcast packets at regular intervals on a strange high port. No program is presently listening for these packets. If I run, "tcpdump -i eth0 port 29531", I see each of the packets arriving just as I expect. Note, the packets are not empty and contain mostly ASCII characters.
But if I then run, "nc -lu 29531", I don't see anything! Why not? What obvious thing am I missing?
This same operation works better (but still not as I expect) on Fedora 14. NC shows one packet arriving but then doesn't show any more.
Running NC under strace on both machines, I see F14 NC seems to use poll(2). It outputs one packet then hangs on poll. F20 NC seems to use select(2). It hangs on the first call.
SELinux and the firewall are disabled on both machines.
Rick Stevens answered:
You may need to use "nc -lu --recv-only 29531" so the system doesn't try to reply to the packet. Perhaps it's better to use wireshark or tcpdump to copy the data to a file and examine it.
Thanks. But that doesn't make any obvious difference. Still no output.
If examining the packets were my only concern, tcpdump would do just fine. But I actually have a program which would like to receive those packets and doesn't. Using NC is part of the investigation to discover why not. But NC doesn't seem to get the packets, either.
Quite odd. Seems to work on my machine. In one window, I did a
nc -lu 29531
and in another:
echo 'Hello there!' | nc -u localhost 29531
and the first window saw the message. Try the same and see if it works. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Make it idiot proof and someone will make a better idiot. - ----------------------------------------------------------------------
Rick Stevens wrote:
Quite odd. Seems to work on my machine. In one window, I did a
nc -lu 29531
and in another:
echo 'Hello there!' | nc -u localhost 29531
and the first window saw the message. Try the same and see if it works.
Yes, that works for me. Further, this works when run from a different machine on the same network:
echo "UDP broadcast" \ | socat - UDP4-DATAGRAM:255.255.255.255:29531,so-broadcast
Examining the packets as they are captured by tcpdump, both the ones NC sees and the ones it doesn't, I don't find anything unusual. No checksum or length errors, for example. And comparing them to the one generated by socat doesn't reveal any obvious significant difference, either.
On 06/26/2014 12:36 PM, CLOSE Dave issued this missive:
Rick Stevens wrote:
Quite odd. Seems to work on my machine. In one window, I did a
nc -lu 29531
and in another:
echo 'Hello there!' | nc -u localhost 29531
and the first window saw the message. Try the same and see if it works.
Yes, that works for me. Further, this works when run from a different machine on the same network:
echo "UDP broadcast" \ | socat - UDP4-DATAGRAM:255.255.255.255:29531,so-broadcast
Examining the packets as they are captured by tcpdump, both the ones NC sees and the ones it doesn't, I don't find anything unusual. No checksum or length errors, for example. And comparing them to the one generated by socat doesn't reveal any obvious significant difference, either.
Uhm, gee. Since another host on the same network gets through, the one sending packets that NC doesn't get must have something set in the TCP stack that nc doesn't like. I'd check the flags on the packets that nc doesn't see. It might be really subtle. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Try to look unimportant. The bad guys may be low on ammo. - ----------------------------------------------------------------------
-
CLOSE Dave -
Rick Stevens