Thanks Guy :-) I too think this might be a bug with the broadcom driver, anyway since I've got a workaround I'm not taking too much concern about this paricular bug~~
As for my workaround, I didn't really hardcoded 88-8e in libpcap; instead I modified a bit in pcap_open_live() to let it parse the "char *ebuf" parameter in "$SAP=%d" format. If the parse succeeds, then libpcap would take the user-supplied number for SAP. Otherwise, it uses 0 for the parameter. Thus the interface remains source-level compatible while providing a workaround for the driver's bug :-) The current libpcap manpage mentions that the MAC_SRC field may be changed in certain OS. It also mentions that filtering rule doesn't work under certain OS. So, as you have said, it may as well add a comment that certain device driver misinterprets the SAP field, so that programmers using libpcap can have one more thing to check if their program doesn't work as expected~~ One more thing: the documentation for libpcap on http://www.tcpdump.org is not up-to-date (Updated: 21 November 2003...hmmm...). It lacks pcap_inject() and pcap_sendpacket() functions ... -,- Maybe you could get it updated to reflect this important feature :-) BTW, I don't really understand the following comment... > (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.) Anyway this is the first time I use a mailing list so please excuse me if I did anything wrong.... :-P ----- Original Message ----- From: "Guy Harris" <[EMAIL PROTECTED]> To: "tcpdump workers" <tcpdump-workers@lists.tcpdump.org> Sent: Wednesday, September 07, 2005 5:41 AM Subject: Re: [tcpdump-workers] libpcap: raw write to ethernet header not working under Solaris? > (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. > - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
