Bug 8764 - recvfrom sometimes returns incorrect byte count
recvfrom sometimes returns incorrect byte count
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: tcpdump (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-23 05:47 EST by paul.offord
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-03 15:21:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description paul.offord 2000-01-23 05:47:55 EST
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 11:01:59 EST
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 14:41:59 EST
I don't think raw network sockets guarantee order...
Comment 3 paul.offord 2000-02-03 15:21:59 EST
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 15:56:29 EDT
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.

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