Kismet and Wireless Stuff ... Extended development logs, up and coming features, and general wireless link-whorery.
r2946 | dragorn | 2009-11-20 11:29:45 -0800 (Fri, 20 Nov 2009) | 5 lines
Added volatile flag to logging (allow logfile to be deleted if no matches)
Fix segfault when plugins use logfiles (shutdown order killed plugins first)
Add volatile to pcapdump
Set dot15d4 logfile to volatile
r2945 | dragorn | 2009-11-20 10:34:10 -0800 (Fri, 20 Nov 2009) | 3 lines
Fix dot15d4 includes
Fix dot15d4 to generate a linkframe component in the packet properly
r2944 | dragorn | 2009-11-20 08:34:30 -0800 (Fri, 20 Nov 2009) | 6 lines
re-order errors slightly opening sources
move netracker::gpsdata into kis_gps_data in gpscore for common use by other
code (ie, plugins)
Remove invalid key from autowep fail tag
Set autowep guess and fail tags to temporary
r2943 | dragorn | 2009-11-17 11:51:59 -0800 (Tue, 17 Nov 2009) | 2 lines
Update warnings for libusb to explain we need libusb-0.1.x
r2942 | dragorn | 2009-11-13 18:18:07 -0800 (Fri, 13 Nov 2009) | 2 lines
Change plugin version to match kismet version
Coming up on the second main release of Kismet-Newcore based code, I've realised that
plugins lacking a revision control (version matching plugin to binary) was a major
oversight and could lead to massive problems (plugins being compiled against an old
version of Kismet are very likely going to crash a newer version, if they even load).
Not wanting to break existing third-party plugins, a new revision api has been added.
If the function kis_revision_info(...) is present, a plugin is expected to return version
info from when it was compiled.
To allow for future expansion, the revision info struct contains a version field which,
when passed to the plugin, indicates what revision struct Kismet allocated, and when
returned, indicates what version the plugin can handle (ie, a future Kismet release may
include binary checksums or somesuch for versioning, and pass revision 2, but a plugin
which only checks against revision 1 would set this and return).
Almost every plugin will have the same kis_revision_info function:
void kis_revision_info(plugin_revision *prev) {
if (prev->version_api_revision >= 1) {
prev->version_api_revision = 1;
prev->major = string(VERSION_MAJOR);
prev->minor = string(VERSION_MINOR);
prev->tiny = string(VERSION_TINY);
}
}
Third-party plugins should update to include this function so that they can be
version-checked before loading. Plugins which don't include this will still be loaded,
but with warnings that they may be unreliable.
This revision API is only as granular as the Kismet release. Users tracking the SVN
development tree will have to rebuild plugins whenever something acts weird (or whenever a
svn update is done, to be safest). Some future plugin tracking mechanism might handle this,
but honestly it would be a big pain for users and for me so it'll probably stay at the
release-level control.
r2941 | dragorn | 2009-11-10 12:52:47 -0800 (Tue, 10 Nov 2009) | 11 lines
Added versioning to plugins (at the kismet release version level)
Plugins will load w/ no version info, but complain (doesn't break old API)
Plugins will fail to load when the version is present, and wrong
SVN users must still manually compile plugins themselves.
Updated version.h to 2009-11-R1 in preparation of impending release
Updated plugins to use new version API
Updated make plugins/plugins-userinstall/etc to use current Kismet directory,
if plugins are compiled from kismet, no system symlink needed
Added popup alerts for plugin failures in kismet_ui
Added Kismet_UI plugin versioning (same rules as server)
r2940 | dragorn | 2009-11-05 20:53:11 -0800 (Thu, 05 Nov 2009) | 2 lines
Fix client plugin path on system install
r2939 | dragorn | 2009-11-05 20:09:00 -0800 (Thu, 05 Nov 2009) | 3 lines
reworked crypt detect in autocrypt so that the first data packet is immediately
decrypted
r2938 | dragorn | 2009-11-05 19:33:00 -0800 (Thu, 05 Nov 2009) | 2 lines
Fix LDFLAGS to PLUGINLDFLAGS (find and replace fail)
