Ncat anomaly

[CLOSE Dave <Dave.Close () us thalesgroup com>]

I have a Fedora 20 machine which is receiving UDP broadcast packets at 
regular intervals on a high port. I have a program which is trying to 
receive these packets and failing to do so. As part of the bug 
investigation, I checked to see of Ncat would receive them. It doesn't.

My program is not running and no other 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. I don't 
care of that old version of NC works or not but I include this datum in 
case it helps diagnose the problem.

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.

Manually generated broadcast packets using both NC and SOCAT are 
received and shown by NC. However, those arrive on a different 
interface. The packets NC doesn't see arrive on an interface to a closed 
proprietary network. None of the machines on that network offer the 
opportunity to generate ad hoc packets with SOCAT. One does offer NC but 
a packet generated using it (echo 'Hello there!' | nc -u 255.255.255.255 
29531) is not received by either tcpdump or NC.

SELinux and the firewall are disabled on both the F20 and F14 machines.

Details:

# uname -a
Linux pses16d 3.14.6-200.fc20.x86_64 #1 SMP Sun Jun 8 01:21:56 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
# rpm -q nmap-ncat
nmap-ncat-6.45-1.fc20.x86_64

# uname -a
Linux pses00b 3.3.4-5.thales1.fc14.x86_64 #1 SMP Wed May 23 20:01:27 PDT 
2012 x86_64 x86_64 x86_64 GNU/Linux
# rpm -q nc
nc-1.100-2.fc14.x86_64

Attached is a short pcap file containing a few of the packets NC does 
not see and one of those generated using SOCAT that NC does see.
-- 
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close () us thalesgroup com

"If a cluttered desk is a sign of a cluttered mind,
of what then is an empty desk?" --Albert Einstein

Attachment: bc.cap
Description: bc.cap

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/