cvs commit: src/lib/libpcap Makefile src/contrib/libpcap gencode.c scanner.l

[Brian F. Feldman]

Sam Leffler <sam at 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 at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\