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. Best regards...Paul
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 Etherlink XL. * 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 NIC's. 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.