Re: Variable length mac headers and gencode.c (and

[Darren Reed <darren.reed () oracle com>]

On 12/05/11 04:27 AM, Guy Harris wrote:
> On May 10, 2011, at 1:40 PM, Darren Reed wrote:
>
> > To pursue this a little further, experimenting has
> > determined that the best layout thus far would be
> > something similar to this:
> >
> > bits field
> > 00-07 version (1)
> > 08-15 pad (0)
> > 16-31 pre-mac payload length
> > 32-63 dlt (DLT_*)
> > 64-79 ethernet protocol number
> > 80-95 pad (0)
>
> What about packets for which there is no appropriate Ethernet protocol 
> number value, such as:
>
> various link control protocols for PPP;
>
> management and control frames for 802.11 (and similar frames for older 
> LAN technologies such as FDDI and Token Ring);
>
> LAN frames with 802.2 headers with DSAPs for which there's no Ethernet 
> protocol number;
>
> LAN frames with 802.2+SNAP headers with an OUI other than 0x000000;
>
> etc.?


An alternative would be like this:

bits  field values
----- ------------
00-07 version (1)
08-15 control field for bits 64-95
16-31 pre-mac payload length
32-63 dlt (DLT_*)
64-95 mac payload type

So, if bits 08-15 are 0, 64-79 are 0 and 80-95 are the ethernet protocol 
number.

And it is worked on from there....

I get the feeling that perhaps this should be an RFC rather than an informal
spec for tcpdump-workers. Thoughts?

The alternative is to just set bits 64-79 (in the original layout) to 0xffff
for any payload that does not have an ethernet protocol number.

The goal of this is quite specific: to allow packets on a network device
to have mixed link-layer headers present and be able to use tcpdump and
friends to push meaningful filters into the kernel. The general thrust
of that is towards IP, thus weird 802.2/PPP headers aren't really that
interesting from a problem perspective, however that doesn't mean they
get ignored. Adding the control field doesn't prevent that from occurring
but it does add another instruction to the filter code.

Darren

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.