I am writing a program to capture packets from a network via an Ethernet
card. The program uses a raw socket and recvfrom() to gather the
packets. The program works fine most of the time. However, occasionally
recvfrom() returns incorrect byte counts.
To test I send a ping to a device on the Ethernet and trace with my
program and a network analyser. The network analyser trace starts with an
ARP exchange; the ARP request being 60 bytes long and the response 42
bytes. recvfrom() returns 42 bytes for the first packet and 60 bytes for
the second ie. the wrong way around. The following ICMP Echo packets are
74 bytes long and are correctly reported by recvfrom().
My first thought was that I had done something wrong and so I repeated the
test with tcpdump. tcpdump has the same problem.
I'm running RedHat 6.0 on a Toshiba 480CDT with 32 MB of memory and a 3Com
3C575 PCMCIA Ethernet card.
We have carried out more testing and can add the following observations.
* We are able to recreate the problem under Red Hat 6.1.
* We are not able to recreate the problem on a desktop machine with an 3Com
* The problem only seems to occur on ARP packets. recvfrom() seems to return
the correct length for other packets of 60 bytes or less.
I guess this points towards a problem with the 3C575 driver.
I don't think raw network sockets guarantee order...
I don't think I've explained this clearly. It's not that the packets are
arriving in the wrong order. The problem is that recvfrom is returning a value
of 42 for a packet that is actually 60 bytes long.
I couldn't reproduce this on Redhat 6.2 systems, using a couple of different
I take it this is either a driver issue (belonging to 'kernel'; I'd suggest
trying it with the latest network driver), and/or has been resolved already.