Re: Linux Frame-Relay and misc

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

On Fri, Oct 03, 2003 at 10:47:00PM +0200, Krzysztof Halasa wrote:
> 1. The attached patch adds Frame-Relay support to tcpdump on Linux.

Checked in.

>    It should be self-explaining.

Do ARPHRD_DLCI devices supply a useful link-layer header (from which the
protocol running atop Frame Relay can be determined), or not?  (If not,
then the patch handles it correctly; if so, it *might* be worth
supplying that header.)

>    The newer Linux kernels use ARPHRD_CISCO rather than ARPHRD_HDLC
>    to refer to Cisco HDLC protocol, so I changed it as well. Hope it
>    doesn't break anything.

It shouldn't break anything, unless in some kernel the right ARPHRD_
type for Cisco HDLC has the name ARPHRD_HDLC and a value other than 513,
which I presume isn't the case.

> 2. A less-obvious thing: tcpdump/print-fr.c LMI parser.
>    I haven't prepared a patch yet as I'm not sure what some parts of the
>    code do (comments will be appreciated):
>
> --------------------------------------------------------
>
> /* find out how many bytes are there in a frame */
> static u_int
> fr_addr_len(const u_char *p)
> {
>         u_int i=0;
>         
>         while (!FR_EA_BIT(p[i]) && i++ && !FR_EA_BIT(p[i+1])) i++;
>         return (i+1);
> }
>
> - The comment should rather read "... in an address", right?

Probably - that code, and that comment, originally came from FreeBSD's
tcpdump.

> - the condition is bogus as the first while loop will always fail on "i++"
>   test (i is initially zero).

Yes, it'll always return 2 (on the first trip through the loop, i is 0,
so i++ is 0, so i is one when the loop terminates.

>   I understand it should now return 2, the
>   default Q.922 address length, or it should return 2 - 4 depending on
>   Q.922 EA bits;

It should return the actual length based on the EA bits.

> #define NLPID_Q933      0x08
>
> 0x08 value is being used by both Q.933a and ANSI LMI.
>
> #define NLPID_LMI       0x09
>
> This is the original, aka Cisco, aka Gang of Four LMI.
> I would rather use "NLPID_LMI" for ITU-T/ANSI and "NLPID_CISCO_LMI"
> for CISCO.

So are Q.933a and ANSI LMI the same thing, or is one an extension of the
other, or are the two different such that, to correctly dissect a frame,
you have to look at, for example, the DLCI?

> Not sure what LMI does the print-fr.c currently support.

I don't, either - as indicated, we just picked it up from FreeBSD.  It
was originally written by, I think, Paul S. Traina (pst () freebsd org),
given that he originally checked it in to the FreeBSD CVS tree.

> What does the following code do? Is it a part of ANSI LMI?
>
> #define ONE_BYTE_IE_MASK 0xF0
>
>
>         /* Loop through the rest of IE */
>         while( length > 0 ) {
>             if (ptemp[0] & ONE_BYTE_IE_MASK) {
>                 ie_len = 1;
>                 printf("\t\tOne byte IE: %02x, Content %02x\n", 
>                        (*ptemp & 0x70)>>4, (*ptemp & 0x0F));
>                 length--;
>                 ptemp++;
>             }
>             else {  /* Multi-byte IE */

I assume it's intended to handle the Q.933 "single octet information
elements" such as Shift and Repeat indicator, although it doesn't
actually do any shifting....

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe