Bug 9134 - link-level headers screwed up in tcpdump-3.4-16
link-level headers screwed up in tcpdump-3.4-16
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: tcpdump (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
: 17800 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-04 19:41 EST by Hao Li
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-02 07:51:50 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 Hao Li 2000-02-04 19:41:50 EST
tcpdump-3.4-16 in RH61 mis-interprets link-level headers (src MAC and dest
MAC). tcpdump-3.4-18 in Rawhide has the same problem while tcpdump-3.4-10
in RH60 doesn't.

For outgoing packets, it always put "0:0:0:0:0:0" as src MAC and real src
MAC as dest MAC. For incoming packets, src MAC is correct while dest MAC is
always "0:0:0:0:0:1". For example:

lotus:		00:10:5A:E4:C4:E9	Running tcpdump-3.4-10
ferrari:	00:90:27:10:2A:42	Running tcpdump-3.4-16

lotus% telnet ferrari

lotus# /usr/sbin/tcpdump -e 'tcp[13] & 2 != 0'
tcpdump: listening on eth0
16:37:54.429667 0:10:5a:e4:c4:e9 0:90:27:10:2a:42 ip 74:
lotus.home.prv.1137 > ferrari.home.prv.telnet: S 3726526579:3726526579(0)
win 32120 <mss 1460,sackOK,timestamp 281889[|tcp]> (DF)
16:37:54.429822 0:90:27:10:2a:42 0:10:5a:e4:c4:e9 ip 74:
ferrari.home.prv.telnet > lotus.home.prv.1137: S 3740727335:3740727335(0)
ack 3726526580 win 32120 <mss 1460,sackOK,timestamp 264736553[|tcp]> (DF)

ferrari# /usr/sbin/tcpdump -e 'tcp[13] & 2 != 0'
User level filter, protocol ALL, datagram packet socket
tcpdump: listening on all devices
16:37:54.428326 eth0 < 0:10:5a:e4:c4:e9 0:0:0:0:0:1 ip 74:
lotus.home.prv.1137 > ferrari.home.prv.telnet: S 3726526579:3726526579(0)
win 32120 <mss 1460,sackOK,timestamp 281889 0,nop,wscale 0> (DF)
16:37:54.428398 eth0 > 0:0:0:0:0:0 0:90:27:10:2a:42 ip 74:
ferrari.home.prv.telnet > lotus.home.prv.1137: S 3740727335:3740727335(0)
ack 3726526580 win 32120 <mss 1460,sackOK,timestamp 264736553
281889,nop,wscale 0> (DF)
Comment 1 Pekka Savola 2000-07-12 17:43:42 EDT
This seems to be caused by ANK patches.  I didn't manage to trace this outright,
but the workaround is to use raw sockets with -R switch; that seems to be te
only way in the new tcpdump 3.5 (www.tcpdump.org) anyway.
Comment 2 Pekka Savola 2000-07-13 15:49:08 EDT
This seems to be a "feature" of packet dumping code.  This is in libpcap's
pcap-linux.c, in pcap_read():

-----
        /* Emulate Ethernet-like MAC header */
        if (p->md.use_bpf == 2) {
                if (from.sll_pkttype != PACKET_OUTGOING) {
                        memset(bp-14, 0, 6);
                        if (from.sll_pkttype == PACKET_BROADCAST)
                                memset(bp-14, 0xFF, 6);
                        else if (from.sll_pkttype == PACKET_MULTICAST) {
                                *(bp-14) = 1;
                        } else {
                                *(bp-14+5) = 1;
                        }
                        memcpy(bp-14+6, from.sll_addr, 6);
                } else {
                        memcpy(bp-14, from.sll_addr, 6);
                        memset(bp-14+6, 0, 6);
                }
                *(unsigned short*)(bp-2) = from.sll_protocol;
        }
-----
from struct (sockaddr_ll) doesn't contain destination MAC address, only the
source.  Therefore, printing it is going to pose a serious problem..  The code
even specifically sets the addresses to zero with memset.

Anyway, tcpdump -R works so..

Comment 3 Pekka Savola 2000-09-30 16:23:20 EDT
*** Bug 17800 has been marked as a duplicate of this bug. ***
Comment 4 Jeff Johnson 2001-01-08 14:47:22 EST
This problem appears to be resolved. Please reopen if I'm wrong.

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