Re: print_llc code question

[Guy Harris <guy () alum mit edu>]

On Sep 1, 2009, at 6:55 AM, Jean-Louis CHARTON wrote:

> Maybe the following question is pretty obvious but since I'm not an
> 802.2/LLC expert, I can't find a response for it.
> I was reading print_llc.c code and in llc_print() function, I found
> something that I don't really understand.
>
> At lines 247 to 251, one has :
>
>    if (ssap == LLCSAP_IP && dsap == LLCSAP_IP &&
>        control == LLC_UI) {
>        ip_print(gndo, p+4, length-4);
>        return (1);
>    }
>
> Why is ip_print() called with p+4 and length-4 when just a few lines
> above for the LLCSAP_8021D case or a few lines below for the  
> LLCSAP_IPX
> case, we have stp_print(p+3, length-3) and ipx_print(p+3, length-3)
> respectively?
>
> The control field is 1 byte long in this case, isn't it? The LLC  
> header
> should be only 3 bytes long, so I don't understand why it's not
> ip_print(gndo, p+3, length-3). What's the reason for the extra byte?

I don't know.

Hannes Gredler added that code in 2002:

        revision 1.51
	date: 2002-11-13 08:08:39 -0800;  author: hannes;  state: Exp;   
lines: +6 -1;
        added processing of LLC_SAPIP

RFC 948, "Two methods for the transmission of IP datagrams over IEEE  
802.3 networks", describes, well, two methods for the transmission of  
IP datagrams over IEEE 802.3 networks.  The first of them is "transmit  
them the standard Ethernet way, because for all type fields with  
values > 1500, you can tell the difference between an "Ethernet II"  
packet and an "802.3" packet by looking at the value of the type/ 
length field.  The second of them is "use 802.2 and a DSAP and SSAP  
for IP"; it says:

	IP datagrams are transmitted in standard 802.2/802.3 LLC Type 1  
Unnumbered Information format with the DSAP and SSAP fields of the  
802.2 header set to 96, the IEEE assigned global SAP value for IP  
[8].  The data field contains the IP header followed immediately by  
the IP data.

and later seems to indicate that the old Ethernet way will go away in  
favor of the 802.2 way.  In reality, of course, that didn't exactly  
happen....

As for non-Ethernet networks using 802.2, RFC 1042, "Standard for the  
transmission of IP datagrams over IEEE 802 networks" replaced that  
scheme with a scheme using SNAP headers with the standard Ethertype  
for IP.

So I don't know who actually *used* an 802.2 header without a SNAP  
header when sending IP datagrams.

In any case, that seems to indicate that you'd have a standard 3-octet  
802.2 LLC Type 1 UI header, followed *immediately* by the IP packet.   
Hannes?  Was somebody adding an extra byte in there?  Perhaps they  
were the *only* people using an 802.2 header without a SNAP header to  
transmit IP datagrams, so, even if they weren't doing it the way RFC  
948 implied they should, they're the only implementation that actually  
matters.  (This might be the first time anybody noticed the extra  
byte; perhaps that's another indication that next to nobody ever sent  
IP datagrams out with an 802.2 header and no SNAP header.)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.