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.
