Date: Tue, 04 Nov 2003 02:28:54 -0500 From: "Brian F. Feldman" <green@FreeBSD.org> To: Sam Leffler <sam@errno.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpcap Makefile src/contrib/libpcap gencode.c scanner.l Message-ID: <200311040728.hA47Ssx2059692@green.bikeshed.org> In-Reply-To: Message from Sam Leffler <sam@errno.com> of "Mon, 03 Nov 2003 23:11:14 PST." <200311032311.14119.sam@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sam Leffler <sam@errno.com> wrote: > On Monday 03 November 2003 10:12 pm, Brian Feldman wrote: > > green 2003/11/03 22:12:21 PST > > > > FreeBSD src repository > > > > Modified files: > > lib/libpcap Makefile > > contrib/libpcap gencode.c scanner.l > > Log: > > * Modify libpcap to work a bit better with our 802.11 code. This means > > tcpdump -y ieee802_11 will work in the basic senses, including the > > code compilation for filters (where you may specify "link[]" to refer > > to parts of the 802.11 header, as well as treat it like a normal > > Ethernet header). Previously, it was just too far off to do anything > > useful for us. > > * While I'm here, fix some compile problems that will result from lex > > and yacc namespace polution when linking with -lpcap. The namespace > > is now "pcapyy*" instead of "yy*", and it tests fine with world and > > some external applications that may or may not use "yy*". > > Er, doesn't this take us off the vendor branch? I thought the right way to > get this stuff in was to pass it through Guy and buy it back with an import? > > FWIW it would be nice to get libpcap+tcpdump updated to get the radiotap > support. These files weren't on the vendor branch, so if there's a problem with them there shouldn't be any harm backing them out. I haven't tried out radiotap support yet, but I'm sure that I'll add it if I do. More interesting to me is radiotap support in ethereal, as radiotap support for libpcap itself should be just the same amount of work as fixing the 802.11 format support. The only problem that I foresee possibly popping up is the WDS addr4 802.11 frame format; the LLC/SNAP header should always be the same if it's a data packet (shoot, guess I need to write some code to check that it's a data packet before proceeding further, for libpcap's bpf code generation...), righ t? BTW, I have a lot of 802.11 changes I want to discuss with you, some I'm certain you won't mind and others you may have an objection to and propose alternatives to, but I consider them all important. Maintaining hostap state (not disassociating all nodes) when going through ENETRESET for calls which shouldn't be kicking nodes off the BSS, passing WEP encrypted frames with the WEP bit on, and vice versa, to the 802.11 layer but allowing the 802.3 layer to not receive input from select nodes/individual packets that do not have WEP, support for transmitting unencrypted individual packets in WEP "on" mode, maybe concurrent 802.11/802.3 support like wi(4)/ath(4) have for an(4) if that's possible, a smarter timeout mechanism for hostap mode that actually takes into account unsuccessfully sent packets (and has a polling mechanism).... -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311040728.hA47Ssx2059692>