> [EMAIL PROTECTED] writes:
>
> > i believe we need some fix into sys/dev/pci/if_lmc*.c. the code
> > calls bpf_mtap() with mbuf that does not meet its DLT type.
>
> Whatever is wrong, goes wrong only when a filter is used.
>
> Invoking tcpdump without a filter expression, either on-line or with a
> saved file, parses packets correctly. Could that happen with a wrong
> DLT type?
tcpdump's handler for DLT_PPP_SERIAL captures, "ppp_hdlc_if_print()",
can handle either PPP or Cisco HDLC headers; it looks at the first byte
of the packet - if it's PPP_ADDRESS (0xff), it treats the packet as PPP,
and if it's CHDLC_UNICAST (0x0f) or CHDLC_BCAST (0x8f), it treats the
packet as Cisco HDLC.
The code generator in libpcap, however, doesn't generate code to check
the first byte of the packet and, based on that, either do PPP-style or
Cisco HDLC-style frame-type, etc. checks. (This is true both in
tcpdump.org libpcap and in NetBSD libpcap, NetBSD being whence
DLT_PPP_SERIAL came.)
I.e., the fact that tcpdump can handle Cisco HDLC packets on
DLT_PPP_SERIAL captures doesn't mean that libpcap's filter compiler can
necessarily handle them - those are completely different pieces of code.
The compiler could, in theory, generate code to do those tests.
However, that would mean that the link-layer header would be
variable-length; I think the BPF engine can handle variable-length
headers - but it may require that the length of the link-layer header be
put into a temporary variable, and correctly handling both
variable-length link-layer headers *and* the variable-length
network-layer headers of IPv4 and IPv6 would complicate the code
generator.
(I suspect that it *might* be easier if the internal form of the
compiled filter expressions was different - the BPF+ paper says that the
code generator for BPF+ uses SSA form internally:
This new architecture, which we call BPF+, affords a
substantially refined, improved, and generalized design, an
extended optimization framework based on "static single
assignment" (SSA) [6], and a number of new optimization
primitives. ...
o The BPF+ compiler translates the predicate language into
an imperative, control-flow graph representation with an
SSA intermediate. SSA is particularly well-suited for
our optimization algorithms.
BPF+'s machine language has multiple registers, and I think using an SSA
form might make it easier to allocate registers; BPF has only an
accumulator and an index register, but SSA still might make it easier to
handle moving temporary variables into and out of the accumulator and
index register.)
For now, it'd probably be best to use DLT_C_HDLC as the DLT_ type on
interfaces where packets *always* have Cisco HDLC headers rather than
PPP headers, as that'd remove the requirement to make the BPF compiler
generate the address tests referred to above.
-
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
