On Sep 7, 2005, at 5:27 AM, fanci wrote:
That's really complicated.... @_@
Yes, that's what happens if you have more than one e-mail address.
One thing to remind... actually you don't have to quote
"Broadcom"'s name in the manpage if you're to indicate the SAP-
overwriting problem...
I didn't mention Broadcom, as they're not necessarily the only ones
with a driver with that problem.
Another suggestion: what about adding a "mac" field to "pcap_if_t"
so that when calling pcap_findalldevs() we also retrieve the MAC
address of each ethernet adapter?
Unfortunately, changing the structure returned for each interface
would break binary compatibility - and, as a number of OSes supply
libpcap as a shared library (major Linux distributions, all the BSDs
including OS X) and WinPcap is also distributed as a shared library,
that would break applications.
Supplying an array of fixed structures like that isn't extensible; I
want to provide a different API in the next major release of libpcap
where the interfaces have a list of properties associated with them,
so that new properties can be added without breaking binary
compatibility (applications should just ignore properties they don't
know about). Using as the tags for the properties the values from
the Interface Description Block in the pcap-NG file format:
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionidb
would probably be the right thing to do. Those tags include tags for
IPv4 and IPv6 addresses, as well as 6-byte MAC addresses and a 64-bit
interface speed in bits/second.
When constructing a raw packet, this information is really essential,
It's essential only if you have to construct the link-layer header
for the packet.
However, if you're implementing a protocol that runs directly on top
of the link layer, the "raw network access" mechanisms in many OSes
can be set up to construct the link-layer header for you - libpcap
isn't really designed as a library for protocol implementations, it's
a library for packet capture, and the right answer for people trying
to construct protocol implementations might be a separate library that:
binds to the link-layer type of the protocol as the SAP, and doesn't
enable SAP promiscuity, for systems using DLPI, so it doesn't see
packets for other protocols *and* so that it doesn't get the wrong
SAP value put into the link-layer header for outgoing packets
(instead, the networking stack would probably put the *right* one
there, so that the protocol implementation doesn't have to do so);
creates the PF_PACKET socket with the link-layer type of the
protocol on Linux, again so that it only sees packets for that
protocol, *and* uses SOCK_DGRAM rather than SOCK_RAW, so that it
doesn't have to construct the link-layer header (the address of the
"sendto" will specify the destination address; the source address
will be the one for the adapter on which it's being sent and the link-
layer type will be the SAP);
uses DLPI rather than BPF on AIX (thus avoiding some of the bugs in
AIX's BPF);
doesn't do any buffering, so when a packet arrives it's delivered
*immediately* to the application;
etc..
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
