Bug 8764 - recvfrom sometimes returns incorrect byte count
Summary: recvfrom sometimes returns incorrect byte count
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tcpdump
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-01-23 10:47 UTC by paul.offord
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-03 20:21:20 UTC

Attachments (Terms of Use)

Description paul.offord 2000-01-23 10:47:55 UTC
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

Comment 1 paul.offord 2000-01-25 16:01:59 UTC
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.

Comment 2 Elliot Lee 2000-02-03 19:41:59 UTC
I don't think raw network sockets guarantee order...

Comment 3 paul.offord 2000-02-03 20:21:59 UTC
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.

Comment 4 Pekka Savola 2000-07-13 19:56:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.