On 10.04.2013, at 15:32, Michal Dubiel <m...@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-unsubscr...@freebsd.org"

Do you still see this if you increase tcpdump's snaplen by adding the
"-s0" option for example?
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to