On Aug 1, 2008, at 12:36 AM, Gert Doering wrote:
On Thu, Jul 31, 2008 at 11:53:27PM -0400, U. George wrote:
Without a detailed study, on my part, I am unable to jump to that
conclusion.
There is nothing to "study" here, or any conclusion to "jump to".
Guy has described the way tcpdump currently works. It works that way
because it was implemented that way.
Exactly.
Specifying port does not necessarily also specify ether type
( or anything else ).
It does, for tcpdump. Ports are only defined in the context of TCP
and
UDP (for tcpdump),
(and SCTP, in current versions of libpcap/tcpdump - I'd forgotten that
- but it doesn't change the conclusion)
and TCP and UDP are only defined for IP, and IP
(for tcpdump) implies "IP over Ethernet".
(On Ethernet, at least.)
If you don't like that, change the source - but be aware of the
implications
that Guy already pointed out: more complex BPF filter, which might
have
performance impacts on high-bandwidth links.
In IPv6-enabled libpcaps, the expression is already a bit more
complex, and if the Ethernet type testing is done early in the
process, it might not be *too* much of a performance hit (and if you
have a JIT compiler for BPF, as WinPcap has on Windows and as FreeBSD
has - both for x86, and in FreeBSD and maybe newer versions of
WinPcap, for x86-64 as well - it might be an even smaller hit).
However, even if the performance hit of testing for
IPv4-over-Ethernet
IPv6-over-Ethernet
IPv4-over-PPPoE
IPv6-over-PPPoE
IPv4-on-a-VLAN
IPv6-on-a-VLAN
and possibly also
IPv4-over-PPPoE-on-a-VLAN
IPv6-over-PPPoE-on-a-VLAN
is small, I don't think it'd be trivial to implement, given the
current architecture of the code generator.
(Note also that kernel BPF implementations also limit the maximum size
of a BPF program, and the additional tests might push some filters
over the edge.)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
