On Fri, Jan 05, 2001 at 12:32:27AM +0200, Pekka Savola wrote:
> * promiscuous mode setting is reversed, should be disabled by default?.
> -> well, this is a matter of taste I suppose.
At least one person submitted a bug against Red Hat's tcpdump
complaining that promiscuous mode was not the default; I assume Alexey
did that because his tcpdump also defaults to sniffing on all devices
with an unbound PF_PACKET/SOCK_DGRAM socket, which might not support
promiscuous mode, but
1) sniffing on all devices in that fashion is a Linuxism, and
tcpdump isn't a "Linux application", it's a portable
application one of whose supported platforms is Linux, and
not all the other platforms support an unbound packet-capture
device in that fashion - the way Torsten did it is better,
you can, *on Linux*, capture on the "any" device, but the
default behavior is still to capture on the default device;
2) I consider both the default-behavior change and the
no-promiscuous-mode change not to have been a good idea even
on Linux, as it would surprise anybody used to the standard
tcpdump behavior.
> * no token ring layer 2 support. No tr/x.25 printing.
libpcap 0.6/tcpdump 3.6 *do* support Token Ring.
libpcap supports filter expressions on them, although those expressions
work only on non-source-routed packets (handling source-routed packets
is more complicated, as they make the link-layer header variable-length,
and there are situations where this would require the generated code to
store the offset of the IP header or to compute it more than once
(consider the filter expression
tcp src port 80 and (host 167.160.247.66 or tcp dst port 80)
which, although perhaps somewhat of an artificial example, would require
that on Token Ring).
tcpdump 3.6 does print Token Ring headers - the code is a combination of
the FreeBSD and NetBSD code (one of which, I forget which, is the only
set of Token Ring changes I've seen that fully handles source-routing
headers).
By "x.25" do you mean "AX.25"? If so, "print-ax25.c" doesn't look as if
it'd involve much porting (it'd involve getting it dual-licensed, as
it's GPLed), and the code to handle AX.25 in libpcap also doesn't look
as if it'd require much porting (although it doesn't actually support
any link-layer protocol type tests, even though the "print-ax25.c" code
appears to suggest that there is a link-layer header with a packet
type).
In any case, the 0.6/3.6 code would, for any Linux link-layer type it
doesn't support, fall back on cooked mode, which, although it doesn't
give you the link-layer header, is better than nothing.
> * print-ether format is different: doesn't show interface,
> '<','>','B','M' (incoming, outgoing, broadcast, multicast, ...), etc:
>
> 20:01:54.633721 netcore.fi.ssh > xxx.fi.45811: P 1:65(64) ack 0
> win
> 32120 (DF)
>
> vs.
>
> 20:02:19.741408 eth0 > yyy.fi.ssh > zzz.fi.973: P
> 132:928(796) ack 1 win 6432 (DF) [tos 0x10]
>
> -> would require a change in libpcap too?
That's another Linuxism, using stuff from the "sockaddr_ll" address
returned by a "recvfrom()" on a PF_PACKET socket.
> -> interface name is really handy IMO!
...at least if you're capturing on all devices; if you're capturing on a
specific device, it may not tell you anything you don't already know.
The problem is that the way it's implemented in Alexey's patches, the
interface *index* is put into the per-packet savefile header;
unfortunately, that index is
1) specific to the machine on which the capture is done
and
2) specific to the *current* configuration of that machine
so there's no guarantee that the interface names you get if you read a
capture file on another machine are the actual interface names.
Storing the interface names somewhere in the capture file would probably
be better.
-
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
