RE: hard_start_xmit and Linux bridging

RE: hard_start_xmit and Linux bridging

[Lewis Adam-CAL022]

Hi Ben,

> -----Original Message-----
> From: Ben Greear [mailto:greearb@candelatech.com] 
> Sent: Thursday, September 09, 2004 6:30 PM
> To: Lewis Adam-CAL022
> Cc: netdev@oss.sgi.com
> Subject: Re: hard_start_xmit and Linux bridging
> 
> I added some ioctls to allow one to turn on the ability to 
> receive the CRC, but I don't know of any drivers that include 
> it by default.

Right, this is what I would have expected since no other driver account for it.

> 
> What driver/hardware is your eth0 device?

It is a custom board but a Xilinx PCORE and using a Montavista driver.  Based on what you said above, it seems that I might want to pursue this with them.

> 
> How are you determining the size, by the skb->len ?

Exactly.  And not only does it include the FCS/CRC, but in the case of an ARP, there are an extra 14 trailing 0's.  I thought this was a bridging issue, now I'm thinking it's a xilinx/mvista issue.

> 
> Does tcpdump/ethereal show the extra 4 bytes if you sniff 
> eth0 w/out bridging?

Yeah.  And in the case of ARP it is even weirder, and extra 18 bytes, mostly zeros.  So case in point, it sounds like this is not proper operation?  I want to confirm before I bring it up with Xilinx and Montavista.

Thanks!
Adam

Re: hard_start_xmit and Linux bridging

[Ben Greear]

Lewis Adam-CAL022 wrote:
> Hi Ben,
> 
> 
>>-----Original Message-----
>>From: Ben Greear [mailto:greearb@candelatech.com] 
>>Sent: Thursday, September 09, 2004 6:30 PM
>>To: Lewis Adam-CAL022
>>Cc: netdev@oss.sgi.com
>>Subject: Re: hard_start_xmit and Linux bridging
>>
>>I added some ioctls to allow one to turn on the ability to 
>>receive the CRC, but I don't know of any drivers that include 
>>it by default.
> 
> 
> Right, this is what I would have expected since no other driver account for it.
> 
> 
>>What driver/hardware is your eth0 device?
> 
> 
> It is a custom board but a Xilinx PCORE and using a Montavista driver.  Based on what you said above, it seems that I might want to pursue this with them.
> 
> 
>>How are you determining the size, by the skb->len ?
> 
> 
> Exactly.  And not only does it include the FCS/CRC, but in the case of an ARP, there are an extra 14 trailing 0's.  I thought this was a bridging issue, now I'm thinking it's a xilinx/mvista issue.
> 
> 
>>Does tcpdump/ethereal show the extra 4 bytes if you sniff 
>>eth0 w/out bridging?
> 
> 
> Yeah.  And in the case of ARP it is even weirder, and extra 18 bytes, mostly zeros.  So case in point, it sounds like this is not proper operation?  I want to confirm before I bring it up with Xilinx and Montavista.

Sounds to me like they are not zeroing out the padded bytes, and that
they are also counting the padded bytes (and CRC) as valid data in
the driver.

My vote is definately an ethernet driver bug (or bugs).

Ben

> 
> Thanks!
> Adam
> 


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

hard_start_xmit and Linux bridging

[Lewis Adam-CAL022]

Hi all,

I tried going to the bridge@lists.osdl.org for this question but got no response, I'm hoping somebody here has had a similar experience as me.

Basically, I put my wlan0 driver in a bridge with eth0.  When my hard_start_xmit() function is called (as a result of a packet received on eth0 and bridged to my driver), the skb that I am passed contains an extra four bytes (e.g. the Ethernet FCS).  

In my mind, this should be stripped off.  But I have looked at all the open source net drivers I could find and nobody seems to care.  Is there a way to know if the skb has been forwarded by a bridged interface?  If I forward on the extra bytes, then a 1500 byte packet becomes 1504 and fails the MTU check on the other side of the wireless interface (when it is passed back to eth0).

TIA,
Adam

Re: hard_start_xmit and Linux bridging

[Ben Greear]

Lewis Adam-CAL022 wrote:
> Hi all,
> 
> I tried going to the bridge@lists.osdl.org for this question but got no response, I'm hoping somebody here has had a similar experience as me.
> 
> Basically, I put my wlan0 driver in a bridge with eth0.  When my hard_start_xmit() function is called (as a result of a packet received on eth0 and bridged to my driver), the skb that I am passed contains an extra four bytes (e.g. the Ethernet FCS).  
> 
> In my mind, this should be stripped off.  But I have looked at all the open source net drivers I could find and nobody seems to care.  Is there a way to know if the skb has been forwarded by a bridged interface?  If I forward on the extra bytes, then a 1500 byte packet becomes 1504 and fails the MTU check on the other side of the wireless interface (when it is passed back to eth0).
> 
> TIA,
> Adam

I added some ioctls to allow one to turn on the ability to receive the CRC, but I
don't know of any drivers that include it by default.

What driver/hardware is your eth0 device?

How are you determining the size, by the skb->len ?

Does tcpdump/ethereal show the extra 4 bytes if you sniff eth0 w/out bridging?

Ben

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