Re: hard_start_xmit and Linux bridging

[Ben Greear <greearb@xxxxxxxxxxxxxxx>]

Lewis Adam-CAL022 wrote:
> Hi Ben,
>
>
> > -----Original Message-----
> > From: Ben Greear [mailto:greearb@xxxxxxxxxxxxxxx] 
> > Sent: Thursday, September 09, 2004 6:30 PM
> > To: Lewis Adam-CAL022
> > Cc: netdev@xxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com