On Mon, Sep 10, 2001 at 12:55:13AM +0300, Hugh Daniel wrote:
> - ----: Unresonable output:
> hugh@burpelson $ so tcpdump -e -n -i hdlc0
> 15:21:39.562131 < 0:0:0:0:0:0 0:0:0:0:0:1 ip 62: 217.2.192.181.4663 > 
>192.171.112.89.www: S 668895481:668895481(0) win 8760 <mss 1460,nop,nop,sackOK> (DF)
> 15:21:39.562144 > 0:0:0:0:0:0 0:0:0:0:0:0 ip 62: 217.2.192.181.4663 > 
>192.171.112.89.www: S 668895481:668895481(0) win 8760 <mss 1460,nop,nop,sackOK> (DF)
> 15:21:39.562916 > 0:0:0:0:0:0 0:0:0:0:0:0 ip 54: 216.235.246.130.2490 > 
>216.240.42.137.www: . 1:1(0) ack 1460 win 17520 (DF)
> 15:21:39.563961 < 0:0:0:0:0:0 0:0:0:0:0:1 0007 186: null > sap 0f I (s=4,r=0,C) 
>len=168
>                        4500 00a8 ea61 4000 fe06 1045 d8f0 2a89
>                        411a 3d15 0050 0e5c 611b 55a9 892f 3225
>                        5018 2238 c82f 0000 e38f f1aa 72ea d752
>                        2ed0 563e b9d8 3afe 7594 b110 5e66 b1c3
>                        cdf9 1bae e918 cc8e a833 8cb1 c552 9b57
>                        b78c af96 1a6c f271 f2e3 f123 afe1 deb0
>                        9dda 462c ec59 8f52 4e4d 2573 cb15 27f0
>                        e86f 1c2c 57c5 a966 e6fe 7bae 1db6 a7f7
>                        1781 ff00 d7aa d451 5ced b6ee

Hmm.

Are the "null > sap 0f" packets the only ones that are wrong?  I.e., are
the other ones OK?

It looks as if the LLC print routine is being handed data with a
Cisco HDLC header - "null > sap 0f" would means an LLC frame with a DSAP
of 0x0f and an SSAP of 0x00, and 0x0f 0x00 are the first two bytes of a
unicast Cisco HDLC frame.

The routines to print PPP and Cisco HDLC packets won't call the LLC
print routine, so it looks as if the link-layer type probably isn't
ARPHRD_HDLC (which would turn into a DLT_ type of DLT_C_HDLC, causing
the Cisco HDLC print routine to be called).

However, we don't generate DLT_PPP on Linux in the latest libpcap; we
punt to cooked mode.  The cooked mode print routine *can* call the LLC
print routine if the kernel claimed that the frame was an 802.2 frame. 
One would hope that the kernel did so only if the frame really had an
802.2 header, but....

The easiest way to find out the ARPHRD_ type would probably be to
temporarily modify "map_arphrd_to_dlt()" in "pcap-linux.c" in libpcap by
adding, before the "switch (arptype)", the lines

        fprintf(stderr, "Arptype %d\n", arptype);

and seeing what it prints to the standard error.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe

Reply via email to