Newcore drones, wrt54
dr
Newcore drones are looking solid.  Some critical errors exacerbated by timing
are worked out, and there is a wrt54 capture source again, WITH hopping this
time, since so many people seem to want it.

The new wrt54 source is wrt54prism, and its for any wrt distribution that uses 
the new mode of drivers that create a prism0 virtual interface in monitor mode.
Source is a typical source=wrt54prism,eth1,foo.

Drones now export the packet sources to the server.  This means when you connect
to a drone, you get all the sources it knows about as if they were local, native
sources.  This means you can lock them onto channels, control hopping, and change
the hopping sequence just like they were local sources, and it means packets show 
up as coming from individual sources, not the general drone source.  Unfortunately,
these changes make newcore incompatible with the stable kismet_client in several
ways, so sources will not show up and channel lock/hop will not work.  You can
play with these directly using the CHANLOCK, CHANHOP, and CHANSEQ commands.

Kismet server and drone now both correctly detect uclibc and uclibc++, and compile
under uclibc natively.  Set your C++ program to g++-uc and run configure to get
it building correctly.  Both now link properly against dynamic uclibc libraries.

Newcore servers running on OSX can properly talk to newcore drones on wrt54, as
well, a problem which plagued kismet-stable.  I'm fairly sure that problem was
caused by struct packing by different compilers on systems with different memory
alignments.  The newcore drone protocol avoids using 8bit values that could
cause a hole in struct packing.