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)
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.
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..
*** Bug 17800 has been marked as a duplicate of this bug. ***
This problem appears to be resolved. Please reopen if I'm wrong.