Problem with igb and vlans in 2.6.38-rc4

Problem with igb and vlans in 2.6.38-rc4

[Ben Greear]

We have a user-space app that uses packet-sockets to grab and send
Ethernet frames (basically a user-space bridge).

This has stopped working for VLANs unless we set the physical
port MTU to be vlan-MTU + 4 (ie, 1504 for standard MTU size vlan frames).
I think this started post 2.6.34 kernel..but not exactly sure at this
time.

The test setup is essentially:

client -- vlan 5 -- [ eth4 {software-bridge} eth3 ] -- vlan 5 -- server

The software bridge machine has no VLANs enabled..it is supposed to just
read Ethernet frames from one port and xmit out the other.

The bridge machine sees rx-length errors, and if only one port is
set to 1504, the other shows xmit errors (since it doesn't like sending
a frame 4 bytes larger than MTU probably).

This used to work, and I'm hoping this change wasn't done on purpose.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Problem with igb and vlans in 2.6.38-rc4

[Ben Greear]

On 02/10/2011 09:57 AM, Ben Greear wrote:
>
> We have a user-space app that uses packet-sockets to grab and send
> Ethernet frames (basically a user-space bridge).

FYI:  I'll post some patches for comment soon..seems
I have it working now, just need to clean them up and
eat lunch :)

Thanks,
Ben

>
> This has stopped working for VLANs unless we set the physical
> port MTU to be vlan-MTU + 4 (ie, 1504 for standard MTU size vlan frames).
> I think this started post 2.6.34 kernel..but not exactly sure at this
> time.
>
> The test setup is essentially:
>
> client -- vlan 5 -- [ eth4 {software-bridge} eth3 ] -- vlan 5 -- server
>
> The software bridge machine has no VLANs enabled..it is supposed to just
> read Ethernet frames from one port and xmit out the other.
>
> The bridge machine sees rx-length errors, and if only one port is
> set to 1504, the other shows xmit errors (since it doesn't like sending
> a frame 4 bytes larger than MTU probably).
>
> This used to work, and I'm hoping this change wasn't done on purpose.
>
> Thanks,
> Ben
>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com