Bug 9134

Summary: link-level headers screwed up in tcpdump-3.4-16
Product: [Retired] Red Hat Linux Reporter: Hao Li <hli>
Component: tcpdumpAssignee: Harald Hoyer <harald>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: hli
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-11-02 12:51:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hao Li 2000-02-05 00:41:50 UTC 
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 21:43:42 UTC 
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 19:49:08 UTC 
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 20:23:20 UTC 
*** Bug 17800 has been marked as a duplicate of this bug. ***
Comment 4 Jeff Johnson 2001-01-08 19:47:22 UTC 
This problem appears to be resolved. Please reopen if I'm wrong.