Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Apr 2013 16:14:58 +0800
From:      Jean <Jean@femrice.com>
To:        freebsd-net <freebsd-net@freebsd.org>
Subject:   SFP/SFP+ , PCI Express Gigabit Ethernet NIC Card supplier, 10G NIC, Server Adapter Intel chipsets
Message-ID:  <2013041116145510946350@femrice.com>

next in thread | raw e-mail | index | archive | help
SGVsbG8sDQoNCg0KSSBhbSBqZWFuIGFuZCB2ZXJ5IGdsYWQgdG8ga25vdyB5b3UgZnJvbSBHb29n
bGUgd2Vic2l0ZSAuQ2hlY2tlZCB5b3VyIHdlYnNpdGUgYW5kIG1heWJlIHlvdXIgY3VzdG9tZXIg
bmVlZCBvdXIgDQoNCnByb2R1Y3RzIHNvIFdyaXRlIHRvIHlvdSBhbmQgdGFsayBhYm91dCB3aGV0
aGVyIHdlIGNvdWxkIGNvb3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXIgaW4gdGhlIGZ1cnRoZXIgLg0K
DQoNCndlIGFyZSB0aGUgbWFudWZhY3R1cmVyIG9mIFBDSSBFeHByZXNzIDFHICYxMEcgRXRoZXJu
ZXQgTklDIENhcmQoU2VydmVyIEFkYXB0ZXIgTklDIENhcmRzKSxJbnRlbCBjaGlwc2V0cywgT3Vy
IA0KDQpGZW1yaWNlIGJyYW5kIC5DRSxGQyxST0hTLCBTdG9jaywgbGlmZXRpbWUgd2FycmFudHku
VmVyeSBnb29kIHByaWNlIGluIHRoZSBtYXJrZXQuIA0KDQoNCndlIGFsc28gc3VwcGx5IFNGUCAs
U0ZQKyxYRlAgYW5kIG90aGVyIHNwZWNpYWwgbW9kdWxlcyAuDQoNCg0KVGhlIEZvbGxvd2luZyBv
bmUgaXMgb3VyIG1haW5seSBOSUMgQ2FyZHM6DQoNCg0KRmliZXIgY2FyZHMgOg0KDQoNCjEuIFBD
SSBFeHByZXNzKHg0LykgRHVhbCBQb3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVy
IE5JQyBDYXJkICwgU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcxRUIgQ2hpcHNldCBjb250cm9sbGVy
ICwgVHlwZSBOdW1iZXIgOiAxMDAwMlBGDQoNCg0KMi4gUENJIEV4cHJlc3MgKHg0KSBEdWFsIFBv
cnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxM
QywgSW50ZWw4MjU3NkVCIENoaXBzZXQgY29udHJvbGxlciAsICAgVHlwZSBOdW1iZXIgOiAxMDAw
MkVGDQoNCg0KMy5QQ0kgRXhwcmVzcyh4NCkgICBEdWFsIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBO
SUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU4MERCQ2hpcHNl
dCBjb250cm9sbGVyICwgIFR5cGUgTnVtYmVyIDogMUcyREI1ODAtU0ZQDQoNCg0KNC4gUENJIEV4
cHJlc3MgKHg0KSBTaW5nbGUgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBGaWJlciBO
SUMgQ2FyZCAsU0ZQIFNsb3QgLExDLCBJbnRlbDgyNTcyRUkgQ2hpcHNldCBjb250cm9sbGVyICwg
ICBUeXBlIE51bWJlciA6IDEwMDAxUEYNCg0KDQo1LiBQQ0kgRXhwcmVzcyAoeDEpIFNpbmdsZSBQ
b3J0IEdpZ2FiaXQgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJkICxTRlAgU2xvdCAs
TEMsIEludGVsODI1ODMgQ2hpcHNldCBjb250cm9sbGVyICwgICBUeXBlIE51bWJlciA6IDFHUEY1
ODMtU0ZQDQoNCg0KNi4gUENJIEV4cHJlc3MgKHg0KSBRdWFkIFBvcnQgR2lnYWJpdCBFdGhlcm5l
dCBOSUMgQ2FyZCwgRmliZXIgTklDIENhcmQgLFNGUCBTbG90ICxMQywgSW50ZWw4MjU4MEVCIENo
aXBzZXQgY29udHJvbGxlciAsICAgVHlwZSBOdW1iZXIgOiAxMDAwNFBGDQoNCg0KNy5QQ0kgRXhw
cmVzcyAoeDgpIER1YWwgUG9ydCAxMEcgRXRoZXJuZXQgTklDIENhcmQsIEZpYmVyIE5JQyBDYXJk
ICxTRlAgU2xvdCAsTEMsIEludGVsODI1OTlFUyBDaGlwc2V0IGNvbnRyb2xsZXIgLCAgIFR5cGUg
TnVtYmVyIDogMTBHMkJGLVNGUCsNCg0KDQo4LiAgUENJIEV4cHJlc3MoeDQvKSBEdWFsIFBvcnQv
U2luZ2xlIFBvcnQgR2lnYWJpdCBFdGhlcm5ldCBOSUMgQ2FyZCwgRmliZXIgLCBTRlAgU2xvdCAs
TEMsIEludGVsODI1NzFFQiBDaGlwc2V0IGNvbnRyb2xsZXIgLCBqdXN0ICBUcmFuc21pc3NpdmUg
IG5vDQogDQpyZWNlaXZlciBmdW5jdGlvbnMgVHlwZSBOdW1iZXIgOiAxRzJCRjU3MS1UWCAoTWFp
bmx5IHVzZWQgaW4gVW5pLWRpcmVjdGlvbmFsIEdBUCApDQoNCg0KOS5QQ0kgRXhwcmVzcyh4NC8p
IER1YWwgUG9ydC9TaW5nbGUgUG9ydCBHaWdhYml0IEV0aGVybmV0IE5JQyBDYXJkLCBGaWJlciAs
IFNGUCBTbG90ICxMQywgSW50ZWw4MjU3MUVCIENoaXBzZXQgY29udHJvbGxlciAsICBqdXN0IFJl
Y2VpdmVyIG5vDQogDQp0cmFuc21pc3Npb24gZnVuY3Rpb25zIFR5cGUgTnVtYmVyIDogMUcyQkY1
NzEtUlggKE1haW5seSB1c2VkIGluIFVuaS1kaXJlY3Rpb25hbCBHQVAgKQ0KDQoNClBseiByZXBs
eSB0byBtZSBpZiB5b3UgYXJlIGludGVyZXN0ZWQgaW4gb3VyIFByb2R1Y3RzIC4NCg0KSG9wZSB3
ZSBoYXZlIGNoYW5jZSB0byBjb29wZXJhdGUgd2l0aCBlYWNoIG90aGVyIGluIHRoZSBmdXJ0aGVy
IC4NCg0KDQpJZiB5b3UgaGF2ZSBTa3lwZSBvciBNU04gSUQgaXMgbW9yZSBiZXR0ZXIgLE15IHNr
eXBlIDogRHJlYW0tZmx5OTkNCg0KDQpCZXN0IFJlZ2FyZHMNCg0KDQpKZWFuIGhlbmcNCg0KDQpG
ZW1yaWNlIChDaGluYSkgVGVjaG5vbG9neSBDby4sIEx0ZC4NCg0KDQpUZWw6MDA4Ni0xMC01MTI2
NjgwNy04MTMgDQoNCg0KTW9iaWxlOjAwODYtMTMwMDEwMjM2MTUNCg0KDQpGYXg6IDAwODYtMTAt
NjI5NzkzNDMNCg0KDQpFbWFpbDogSmVhbkBmZW1yaWNlLmNvbSANCg0KDQpXZWJzaXRlczogaHR0
cDovL3d3dy5ldGhlcm5ldHNlcnZlcmFkYXB0ZXIuY29tLw0KICAgICAgICAgIHd3dy5mZW1yaWNl
LmNvbSANCg0KDQpTa3lwZTogRHJlYW0tZmx5OTkNCg0KDQpNU046IERyZWFtLWZseTk5QEhvdG1h
aWwuY29t
From owner-freebsd-net@FreeBSD.ORG  Thu Apr 11 08:21:53 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 B2BDFDB4
 for <freebsd-net@freebsd.org>; Thu, 11 Apr 2013 08:21:53 +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 42BD79E9
 for <freebsd-net@freebsd.org>; Thu, 11 Apr 2013 08:21:52 +0000 (UTC)
Received: from localhost (unknown [213.17.239.109])
 by smtp.semihalf.com (Postfix) with ESMTP id 639D9EBDCE;
 Thu, 11 Apr 2013 10:21:51 +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 1iGVmwyAsbKs; Thu, 11 Apr 2013 10:21:50 +0200 (CEST)
Received: from [10.0.2.210] (cardhu.semihalf.com [213.17.239.108])
 by smtp.semihalf.com (Postfix) with ESMTPSA id 5B129EBD4F;
 Thu, 11 Apr 2013 10:21:50 +0200 (CEST)
Message-ID: <516672C6.5010906@semihalf.com>
Date: Thu, 11 Apr 2013 10:22:30 +0200
From: Michal Dubiel <md@semihalf.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Nikolay Denev <ndenev@gmail.com>
Subject: Re: Corrupted octets seen by tcpdump
References: <51657801.1080700@semihalf.com> <-2382443979031863675@unknownmsgid>
In-Reply-To: <-2382443979031863675@unknownmsgid>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>;
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 08:21:53 -0000

On 11/04/13 08:54, Nikolay Denev wrote:
> On 10.04.2013, at 15:32, Michal Dubiel <md@semihalf.com> wrote:
>
>> 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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>         options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
>>         ether 00:02:00:58:31:30
>>         media: Ethernet autoselect (1000baseT <full-duplex>)
>>         status: active
>> mge1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>         options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
>>         ether 00:02:01:58:31:30
>>         media: Ethernet autoselect (1000baseT <full-duplex,master>)
>>         status: active
>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>>         options=3<RXCSUM,TXCSUM>
>>         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
>>         inet6 ::1 prefixlen 128
>>         inet 127.0.0.1 netmask 0xff000000
>>         nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>                 ifmaxaddr 0 port 3 priority 128 path cost 20000
>>         member: mge0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>                 ifmaxaddr 0 port 2 priority 128 path cost 20000
>> vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex>)
>>         status: active
>>         vlan: 100 parent interface: mge0
>> vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>         ether 00:02:01:58:31:30
>>         media: Ethernet autoselect (1000baseT <full-duplex,master>)
>>         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
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
> Do you still see this if you increase tcpdump's snaplen by adding the
> "-s0" option for example?
>

Yes I'm still seeing this.

Best regards,
Michal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2013041116145510946350>