lkml.org 
[lkml]   [2011]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: BUG: Bisected Gianfar in bridge not forwarding packets (was: 3.0-rc1 Bridge not forwarding unicast packages)
    From
    On Wed, Aug 10, 2011 at 11:59 AM, Michael Guntsche <mguntsche@gmail.com> wrote:
    <snip>
    >>>Offload parameters for lan_wire:
    >>>rx-checksumming: off
    >>>tx-checksumming: off
    >>>scatter-gather: off
    >>>tcp-segmentation-offload: off
    >>>udp-fragmentation-offload: off
    >>>generic-segmentation-offload: off
    >>>generic-receive-offload: on
    >>>large-receive-offload: off
    >>>rx-vlan-offload: off
    >>>tx-vlan-offload: off
    >>>ntuple-filters: off
    >>>receive-hashing: off
    >>>
    >>>The Bridge device on the other hand....
    >>>
    >>>Offload parameters for lan:
    >>>rx-checksumming: on
    >>>tx-checksumming: on
    >>>scatter-gather: off
    >>>tcp-segmentation-offload: off
    >>>udp-fragmentation-offload: off
    >>>generic-segmentation-offload: off
    >>>generic-receive-offload: on
    >>>large-receive-offload: off
    >>>rx-vlan-offload: off
    >>>tx-vlan-offload: on
    >>  ^^^^^^^^^^^^^^^^^^^ is this gfar?
    > No the "Lan" nic is the bridge itself. The gfar in question is lan_wire.
    >
    > /Michael
    >

    Ok I would have saved hours of bisecting if I had just used the -e
    switch with tcpdump from the beginning.
    Jiri first of all the patch makes the connection work again. I can
    ping the client on the wlan from the server and vice-versa. Taking a
    look at the tcpdump (WITH -e) makes it obvious why it fails with the
    non patched version...

    This is a capture from the gfar lan port on the bridge with no patch applied
    12:13:24.011492 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
    (oui Unknown), ethertype 802.1Q (0x8100), length 102: vlan 19, p 0,
    ethertype IPv4, gibson.comsick.at > 192.168.42.55: ICMP echo request,
    id 23567, seq 74, length 64

    As you can see we get a VLAN package????

    With the patched version:
    12:16:33.756966 00:13:d4:4f:a2:dc (oui Unknown) > b4:07:f9:70:b7:c1
    (oui Unknown), ethertype IPv4 (0x0800), length 98: gibson.comsick.at >
    192.168.42.55: ICMP echo request, id 23669, seq 2, length 64
    12:16:33.843289 b4:07:f9:70:b7:c1 (oui Unknown) > 00:13:d4:4f:a2:dc
    (oui Unknown), ethertype IPv4 (0x0800), length 98: 192.168.42.55 >
    gibson.comsick.at: ICMP echo reply, id 23669, seq 2, length 64

    No VLAN and I get my replies.
    All that is left to do now is to find out why the current driver
    thinks that it is on a VLAN when it isn't.

    Any ideas Jiri?

    Kind regards,
    Michael
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-08-10 12:33    [W:0.029 / U:89.908 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site