David Greenman <dg@root.com> writes:

> >So, last night in another forum chopps reported seeing obviously
> >trashed packets coming in his fxp interface when he ran tcpdump.
> >
> >I no longer have the log lying around, but the bogus packets had their
> >tail overwritten by a sequence of 0x55's, and were shorter than the
> >minimum legal ethernet frame size.  My guess is that these were broken
> >"runt" packets which had been stepped on by collisions..
> >
> >Now, looking through the driver code, I note the following in fxp_init();
> >
> >	cbp->save_bf =		prm;	/* save bad frames */
> >	cbp->disc_short_rx =	!prm;	/* discard short packets */
> >
> >"prm" is 1 if the device is being put into promiscuous mode, 0
> >otherwise.  Is there any particularly good reason to do this sort of
> >thing by default? (i.e., does promiscuous mode lose valid frames on
> >the fxp unless you also tell the chip to receive broken frames and
> >runts?)  
> 
>    The idea is that promiscuous mode is often used to diagnose network
> problems, and thus should allow certain types of shouldn't-happen packets
> through (such as too small).
>    The 0x55 is the automatic padding byte that the interface adds to fill
> out a frame, so nothing mysterious there.

Yes, but tcpdump is also used for many things besides that and its
pretty annoying to have these bad frames interleaved between valid
ones.

Of the machines/arch's/drivers I tested only fxp did this bizarreness.

Why not use a link flag for this specific application?

Chris.