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 ([EMAIL PROTECTED]),
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:[EMAIL PROTECTED]
