Mailing List Archive

Eduardo Escudero Sánchez wrote:

> I have been using etehreal and i have received LLC frames.One of them
> was a TEST frame (its control field was 0xf3) But ethereal says that
> TEST comes with SNAP!!!!! isn't that impossible?.

So it was a test frame with SSAP=DSAP=0xAA?

> Only when you receive
> frames which have SSAP=DSAP=0xAA and the control byte = 0x03 (UI Frame
> then ) you can have a SNAP field of 5 bytes (3 for organization code and
> 2 for protocol identification).
> I'm wrong maybe? someone can explain me?

At least according to IEEE Std 802-2001, section "10.3.2 SNAP PDU format":

The LLC control field (CTL) is shown for PDU type UI, Unnumbered
Information, which is the most commonly used PDU type in this context;
however, other information-carrying LLC PDU types may also be used with
SNAP.

> The other question i have is about analizing llc frames. how can one
> knows whether the controll field of the frame is two bytes long or only
> one byte?.You can know it if you know it is an unnumbered frame (1
> control byte then) or a supervisory or information frame (2 control
> bytes in that case), but in order to discover the type of the frame you
> must see the value of the bits of the least significant byte of the
> control field

No.

If the low-order bit of the *first* byte is 0, it's an I frame.

Otherwise, if the bit above that is 0, it's an S frame.

Otherwise, it's a U frame.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

>No.

>If the low-order bit of the *first* byte is 0, it's an I frame.

>Otherwise, if the bit above that is 0, it's an S frame.

>Otherwise, it's a U frame.

But i dont understand. If you go to teh standard 802.2-1998 to the
5.4.2.1for example (Format of the I - PDU) you can see in the drawing
that the bits
are numbered from 1 to 16 and teh only indication it gives you is that the
bit numbered with 1 is the least significant byte so one can deduce from
here that the most significant bit of teh conrol field is teh bit numbered
with 16 so the first byte of the control field will be the byte whose eight
bits are the last eigth bits of the drawing. So you can not go to the last
bit of the first byte to see the type of frame because you will be seeing
the value of the P/F bit, dont you?
By the way Thanks for your attention


2006/6/25, Guy Harris <guy@alum.mit.edu>:
>
> Eduardo Escudero Sánchez wrote:
>
> > I have been using etehreal and i have received LLC frames.One of them
> > was a TEST frame (its control field was 0xf3) But ethereal says that
> > TEST comes with SNAP!!!!! isn't that impossible?.
>
> So it was a test frame with SSAP=DSAP=0xAA?
>
> > Only when you receive
> > frames which have SSAP=DSAP=0xAA and the control byte = 0x03 (UI Frame
> > then ) you can have a SNAP field of 5 bytes (3 for organization code and
> > 2 for protocol identification).
> > I'm wrong maybe? someone can explain me?
>
> At least according to IEEE Std 802-2001, section "10.3.2 SNAP PDU format":
>
> The LLC control field (CTL) is shown for PDU type UI, Unnumbered
> Information, which is the most commonly used PDU type in this context;
> however, other information-carrying LLC PDU types may also be used with
> SNAP.
>
> > The other question i have is about analizing llc frames. how can one
> > knows whether the controll field of the frame is two bytes long or only
> > one byte?.You can know it if you know it is an unnumbered frame (1
> > control byte then) or a supervisory or information frame (2 control
> > bytes in that case), but in order to discover the type of the frame you
> > must see the value of the bits of the least significant byte of the
> > control field
>
> No.
>
> If the low-order bit of the *first* byte is 0, it's an I frame.
>
> Otherwise, if the bit above that is 0, it's an S frame.
>
> Otherwise, it's a U frame.
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>

Eduardo Escudero Sánchez wrote:

> But i dont understand. If you go to teh standard 802.2-1998 to the
> 5.4.2.1 <http://5.4.2.1> for example (Format of the I - PDU) you can see
> in the drawing that the bits are numbered from 1 to 16 and teh only
> indication it gives you is that the bit numbered with 1 is the least
> significant byte so one can deduce from here that the most significant
> bit of teh conrol field is teh bit numbered with 16 so the first byte of
> the control field will be the byte whose eight bits are the last eigth
> bits of the drawing. So you can not go to the last bit of the first byte
> to see the type of frame because you will be seeing the value of the P/F
> bit, dont you?

If bits are transmitted in the order in which they're shown in 5.4.2.1;
the only way in which bit 1 would be the low-order bit of the *second*
octet of a 2-octet control field would be if the second octet were
transmitted first.

That seems unlikely to be the case.

Note that the control field is two octets, not a single 16-bit quantity;
see 3.3.2 "Control field":

The control field shall consist of one or two octets that shall be used
to designate command and response functions, and shall contain sequence
numbers when required.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

Hi . I have been searching in a lot of pages and in books to see if there
could be LLC frames other than those that have a 0x03 control field value
using SNAP (so they have 5 additional bytes after the LLC control field) and
i have found that many of them say that the control field must have the 0x03
value;
I dont know,for example you can see it in

http://www.javvin.com/protocolSNAP.html

where it says :

When SNAP is present the DSAP and SSAP fields within the LLC header contain
the value 170 (decimal) each and the Control field is set to 3 (unnumbered
information).
or for example in the book " Network protocol handbook" from Mathew Naugle
(McGraw-Hill Series on Computer Comunications) it says also that the control
field must have a value 0x03.
I come back to this issue because im in a trouble with the implementation of
LLc type2.
Suppose i have a connection component like the one described in the ISO 8802
for managing Type2 traffic in a local LSAP.Eacj connection component has an
identifier composed of DA,DSAP,SA,SSAP. So then i can have a connection
component with the identifier XX:XX:XX:XX:XX:XX,AA,YY:YY:YY:YY:YY:YY,AA to
identify a connection between those SAP's on those LSAPs.
There is a situation in the operation of that component on which when it
detects that the acknowledgement timer has expired it must send a disconnect
indication primitive to the upper layer through the connected LSAP. But the
LSAP is the AA LSAP and there could be a lot of network entities waiting for
a connection to be established. I must know which network entity is the one
whch i have to communicate the DISCONNECT situation. And i haven't any way
to know which entity is the one i need because the connection identifier
tells me onlythe LSAP (AA in this case) but not for example the SNAP which
correponds to the upper network protocol. Im missing something maybe?? I
have thought that maybe the connection must be identified in the
AA-LSAP-situation witha n additional 5 five identifier (the SNAp of teh
upper protocol)
I dont know if i have explained myself correctly, sorry for the mess.
Thanks


2006/6/29, Guy Harris <guy@alum.mit.edu>:
>
> Eduardo Escudero Sánchez wrote:
>
> > But i dont understand. If you go to teh standard 802.2-1998 to the
> > 5.4.2.1 <http://5.4.2.1> for example (Format of the I - PDU) you can see
> > in the drawing that the bits are numbered from 1 to 16 and teh only
> > indication it gives you is that the bit numbered with 1 is the least
> > significant byte so one can deduce from here that the most significant
> > bit of teh conrol field is teh bit numbered with 16 so the first byte of
> > the control field will be the byte whose eight bits are the last eigth
> > bits of the drawing. So you can not go to the last bit of the first byte
> > to see the type of frame because you will be seeing the value of the P/F
> > bit, dont you?
>
> If bits are transmitted in the order in which they're shown in 5.4.2.1;
> the only way in which bit 1 would be the low-order bit of the *second*
> octet of a 2-octet control field would be if the second octet were
> transmitted first.
>
> That seems unlikely to be the case.
>
> Note that the control field is two octets, not a single 16-bit quantity;
> see 3.3.2 "Control field":
>
> The control field shall consist of one or two octets that shall be
> used
> to designate command and response functions, and shall contain sequence
> numbers when required.
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>

Eduardo Escudero Sánchez wrote:
> Hi . I have been searching in a lot of pages and in books to see if
> there could be LLC frames other than those that have a 0x03 control
> field value using SNAP (so they have 5 additional bytes after the LLC
> control field) and i have found that many of them say that the control
> field must have the 0x03 value;

I found one that doesn't. It says:

The LLC control field (CTL) is shown for PDU type UI, Unnumbered
Information, which is the most commonly used PDU type in this context;
*however, other information-carrying LLC PDU types may also be used with
SNAP*.

(emphasis mine).

Its short title is "IEEE Std 802®-2001", and its full title is "IEEE
Standard for Local and Metropolitan Area Networks: Overview and
Architecture". I'm somewhat more inclined to believe the IEEE than
Javvin or McGraw-Hill on this matter.

> I have thought that maybe the
> connection must be identified in the AA-LSAP-situation witha n
> additional 5 five identifier (the SNAp of teh upper protocol)

That's what I would expect anything managing LLC Type 2 connections
using SNAP to do.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev