(Blah blah blah wrong From: address bounce blah blah blah fool the
duplicate message detector into not bouncing this retransmission from
the right address blah blah blah.)
On Sep 6, 2005, at 1:45 AM, fanci wrote:
So, libpcap is passing "0" for the "sap" parameter to invoke a
DLPI_BIND_REQ. The user has no way to specify this parameter. Yet
this parameter is significant.
It shouldn't be significant on Solaris. If it is, that's a bug -
probably a driver bug.
A DLPI tutorial article (found at http://sunsite.bilkent.edu.tr/pub/
sun-info/sun-faq/Docs/snit-to-dlpi.txt) explains the "sap"
parameter as follows:
And the Solaris 10 GLD(7) man page explains the DLIOCRAW ioctl, which
libpcap does, as follows:
The DLIOCRAW ioctl function is used by some DLPI applications, most
notably the snoop(1M) command. The DLIOCRAW command puts the stream
into a raw mode, which, upon receive, causes the the full MAC-level
packet to be sent upstream in an M_DATA message instead of it being
transformed into the DL_UNITDATA_IND form normally used for reporting
incoming packets. Packet SAP filtering is still performed on streams
that are in raw mode; if a stream user wants to receive all incoming
packets it must also select the appropriate promiscuous modes. After
successfully selecting raw mode, the application is also allowed to
send fully formatted packets to the driver as M_DATA messages for
transmission. DLIOCRAW takes no arguments. Once enabled, the stream
remains in this mode until closed.
and the DLPI tutorial says of DLIOCRAW:
One feature which is not included in the USL DLPI Version 2
specification but
is frequently necessary for several types of applications is "raw"
mode. Support for this mode has been added to SunOS 5.x. The user
enables raw mode by issuing the DLIOCRAW ioctl, which is defined in
the version of dlpi.h shipped with SunOS 5.x. After this, "raw"
Ethernet frames which include the 14-byte
Ethernet header may be sent downstream in M_DATA type messages, and
all received frames will be sent upstream with Ethernet header
included in M_DATA type messages.
If, in any driver, the SAP parameter has any effect whatsoever on the
Ethernet type field of a frame being transmitted in DLIOCRAW mode,
I'd say that driver had a bug. In DLIOCRAW mode, the driver should
just take the packet supplied to it and transmit it, without
modifying anything in the packet, *including* any part of the MAC
header (i.e., it shouldn't modify the destination address, the source
address, or the type/length field).
Whatever the cause, after I hard-coded 88-8e for the sap parameter,
recompiled libpcap, and relinked my program, everything worked.
tcpdump displays 88-8e in the etherneet-type field, rather than the
previous 00-00.
You should complain to Broadcom about this.
Your workaround (setting the SAP) works for applications that send
*only* packets with the specified Ethernet type; however, libpcap's
pcap_inject() and pcap_sendpacket() routines are intended to support
sending arbitrary packets, regardless of Ethernet type, and the
workaround won't work for them.
Conclusion: libpcap might consider adding some method to enable the
user specify the SAP field upon construction of a pcap_t.
An option to let a link-layer packet type be specified would provide
a workaround for this problem, and might also allow libpcap to use
the native OS's non-BPF-style mechanisms, if present, to filter out
packets of protocols the application isn't interested in; those
mechanisms might be more efficient. As such, I'll consider adding
such a mechanism in the next major release of libpcap.
However, as noted, there are applications where such a feature
wouldn't help, so, even with such an option, broken drivers such as
the Broadcom one still need to be fixed.
At least, the libpcap manpage should inform the developer about its
default parameter 0 for dlpi-sap,
Or, rather, it should note that there might be OSes, and drivers,
that don't support sending raw link-layer packets, and cite that as
an example.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
