On Sun, Sep 09, 2001 at 11:29:09PM +0300, Hugh Daniel wrote:
> I just tryed the current (2001.09.09) tcpdump/libpcap on my HDLC
> (T1, Link encap:(Cisco)-HDLC) link and it failed again (rather badly,
> I was getting LOTS of bogus output that looked like serious DDoS and
> was just plain bogosity).
(I'm assuming, from previous mail from you, and from the second word in
the next-to-last line of your signature line, that this is on Linux.)
What's the ARPHRD_ type for it?
If it's ARPHRD_HDLC, that seems to imply that the link-layer header you
get in cooked mode isn't (or isn't always) a standard Cisco HDLC
link-layer header (which wouldn't surprise me; the link-layer headers
for ARPHRD_PPP seem, at times, to be generated by code that uses a
random-number generator to decide what flavor of header to show, at
least for outgoing packets with PPP-over-ISDN).
> I am sure it's fixable, but it's not been done and I need to go do
> other (DNS, IPsec, etc.) things myself just now, but maybe this bug
> report will do some good? Maybe you should considder failing hard if
> you don't know the link layer encapsulation?
That won't help - the problem here is that the code currently *does*
handle ARPHRD_HDLC, but, apparently, handles it incorrectly.
In those cases where we *don't* explicitly handle the ARPHRD_ value, we
don't fail hard, because we don't have to - we instead punt to cooked
mode.
The current version of libpcap also punts to cooked mode for ARPHRD_PPP;
perhaps the same needs to be done for ARPHRD_HDLC. (I'd be interested
in seeing a savefile for your HDLC link, though, to see if this is
another case of the same sort of irritating randomness we see with PPP -
especially PPP-over-ISDN - or if the ARPHRD_HDLC headers are always the
same, but aren't just Cisco HDLC headers.)
-
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
