From owner-freebsd-net@FreeBSD.ORG Wed Apr 10 14:32:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09FB2D1D for ; Wed, 10 Apr 2013 14:32:03 +0000 (UTC) (envelope-from md@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 7511C1D1 for ; Wed, 10 Apr 2013 14:32:02 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 297AAEBD4F for ; Wed, 10 Apr 2013 16:31:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id EvWTgsHlA9Ym for ; Wed, 10 Apr 2013 16:31:54 +0200 (CEST) Received: from [10.0.2.210] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 391BBEBD4D for ; Wed, 10 Apr 2013 16:31:54 +0200 (CEST) Message-ID: <51657801.1080700@semihalf.com> Date: Wed, 10 Apr 2013 16:32:33 +0200 From: Michal Dubiel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120910 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Corrupted octets seen by tcpdump Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 14:32:03 -0000 Hi, I would like to ask you for some hints about where to look next and how could I debug the following issue: I have a FreeBSD host with two Ethernet interfaces and a Linux host with one interface, which connected each other as in the picture below: eth0.100 --- eth0 --------------- mge0 --- vlan0 \ \ bridge0 / / mge1 --- vlan1 On FreeBSD host: # ifconfig mge0: flags=8943 metric 0 mtu 1500 options=8000b ether 00:02:00:58:31:30 media: Ethernet autoselect (1000baseT ) status: active mge1: flags=8943 metric 0 mtu 1500 options=8000b ether 00:02:01:58:31:30 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 bridge0: flags=8843 metric 0 mtu 1500 ether 02:89:b3:33:d2:00 inet 192.168.126.6 netmask 0xffffff80 broadcast 192.168.126.127 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: mge1 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 20000 member: mge0 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 20000 vlan0: flags=8843 metric 0 mtu 1500 ether 00:11:22:33:44:55 inet 172.18.0.254 netmask 0xffff0000 broadcast 172.18.255.255 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge0 vlan1: flags=8843 metric 0 mtu 1500 ether 00:02:01:58:31:30 media: Ethernet autoselect (1000baseT ) status: active vlan: 100 parent interface: mge1 The test is to ping from the remote Linux host the vlan0 interface (172.18.0.254). I intentionally changed the vlan0 MAC address to be different than it's parent: the mge0 device. I know it is not good configuration, but this allows me to reproduce the issue I'm asking here. The problem is that if I start sniffing packets (using tcpdump) on mge0 I observe correct ping requests, but on bridge0 interface I'm getting corruptions: # tcpdump -eni bridge0 15:34:15.624125 00:01:6c:ea:a1:70 > 00:11:22:33:44:55, ethertype 802.1Q (0x8100), length 104: vlan 100, p 0, ethertype IPv4, IP13 bad-hlen 8 I'm always seeing the same corruption (0xdb octed in the place where the first octet of IP header should be, plus one additional random octed right after it). This corrupts the IP version and header length fields. The interesting think is also that after those two bogus octets, the rest of the packet in the correct form appears. However, I instrumented the code of bridge interface (sys/net/if_bridge.c) and when I do printf() directly from the mbuf of the beginning bytes of the received packet I don't see any corruption there. I suspect there may be some problem with tcpdump or its integration with the stack. Have anyone had a similar problems/observations and does anybody have any hints on what can be causing this corruption and how to debug it further? I'm using FreeBSD 8.3 on ARM architecture. Thanks in advance for your response. Best regards, Michal