On 11/04/13 08:54, Nikolay Denev wrote:
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?


Yes I'm still seeing this.

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"

Reply via email to