Linux Frame-Relay and misc

[Krzysztof Halasa <khc () pm waw pl>]

Hello,

1. The attached patch adds Frame-Relay support to tcpdump on Linux.
   It should be self-explaining.
   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.

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?
- the condition is bogus as the first while loop will always fail on "i++"
  test (i is initially zero). 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;

--------------------------------------------------------

#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.

--------------------------------------------------------

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

tcpdump output on link with ANSI LMI:

22:56:50.608323 DLCI-0-R Q.933 14: Call Ref: 75, MSG Type: 95 UNKNOWN MSG Type
                IE: 01 Len: 1, FULL STATUS
                IE: 03 Len: 2, TX Seq:   2, RX Seq:   1

                         0001 0308 0075 9501 0100 0302 0201
22:56:50.608972 DLCI-0-R Q.933 29: Call Ref: 7d, MSG Type: 95 UNKNOWN MSG Type
                IE: 01 Len: 1, FULL STATUS
                IE: 03 Len: 2, TX Seq:   2, RX Seq:   2
                IE: 07 Len: 3, DLCI 101: status new, Inactive
                IE: 07 Len: 3, DLCI 102: status new, Inactive
                IE: 07 Len: 3, DLCI 110: status new, Inactive

                         0001 0308 007d 9501 0100 0302 0202 0703
                         06a8 8807 0306 b088 0703 06f0 88

Call Ref is wrong (should be 0), MSG Type is wrong (0x95 is ANSI lock
shift byte), but the rest is magically correct.


These defines:
#define REPORT_TYPE_IE    0x01
#define LINK_VERIFY_IE_91 0x19
#define LINK_VERIFY_IE_94 0x03
#define PVC_STATUS_IE     0x07
would suggest that it supports ANSI LMI (unfortunately I don't have full
documentation for it). Certainly 0x1 is a "report type", 0x3 is "link
integrity verification" and 0x7 is "PVC status" in ANSI LMI.

ITU-T Q.933a LMI uses 0x51, 0x53 and 0x57, respectively, so I guess
it isn't supported. tcpdump gives bogus results on such link:

22:55:02.535722 DLCI-0-R Q.933 13: Call Ref: 75, MSG Type: 51 UNKNOWN MSG Type
                IE: 01 Len: 1, Reserved Value
                IE: 02 Len: 181, Non-decoded Value

                         0001 0308 0075 5101 0153 02b5 b4
22:55:02.536213 DLCI-0-R Q.933 13: Call Ref: 7d, MSG Type: 51 UNKNOWN MSG Type
                IE: 01 Len: 1, Reserved Value
                IE: 02 Len: 181, Non-decoded Value

                         0001 0308 007d 5101 0153 02b5 b5


Cisco LMI isn't supported (NLPID_LMI not handled in main switch() in
fr_if_print()).


--------------------------------------------------------

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 */


Comments?
-- 
Krzysztof Halasa, B*FH

Attachment: libpcap-linux.diff
Description: