Beard wrote:It's going great, I've moved from 127 to 45 overall.
I do have a couple of questions now.
1- Which file/log is it you recommend replacing after ~10k entries, can't find it through a search.
2- Have you had an AP cause Flite to say an extremely long number at the end, maybe 40 or better? The only thing I found that may be it is a probe.
1 - Its not a file, but a parameter in a configfile. GPSDRive 2.09 starts to lag behind, when you get a lot of AP's in the Mysql DB, since the way its mysql support was coded is a bit stupid.
In your users home directory there's a hidden gpsdrive directory, which contains the gpsdrive config file. This file is named ".gpsdriverc", and contains a param called "dbwherestring".
By editing this parameter, and using the Kismet generated gpsdrive waypoint file for display, instead of the MySQL support, you'll get the best of two worlds : a display of the AP's found during your current drive, as well as logging and updating of new and previous found AP's in the MySQL DB with the added benefit of only hearing GPSDrive reading out and keeping a tally of the new detections for this run.
So edit the "~/.gpsdrive/.gpsdriverc" file, and change the param to "dbwherestring = WHERE ( name = 'xxxx' )". The xxxx can be any name of an AP, I'm using my own SSID.
What this does is ensuring that the SQL query GPSDrive uses only pulls one AP, the AP with that name, out from the MySQL DB, and into the temporary text file it reads the waypoints to display from. By default gpsdrive will query for ALL the AP's in the DB even if you haven't set it to display the MySQL POI's. Having 10K+ records being pulled into a textfile and then read to be displayed on the map, takes time.
Then when using Kismet and Gpsdrive together, don't enable the SQL support on the map display, i.e. remove the checkmark from the SQL box on the map. Gpsdrive will still log any AP's that Kismet reports into the DB, but just don't display it from the MySQL DB. If you enable the Show Waypoints in the map display, and in the configurationmenu tab for waypoints, select the gpsdrive compatible file generated by Kismet ("way_kismet.txt", remember to have it enabled in the kismet.conf file, with the "waypoints", "waypointsdata", and "waypoints_essid" statements), you've got the best of the two worlds IMHO.
2 - The question is whether it is GPSDrive or kismet_client that reads up the long numbers. I think you were running kismet_client at the same time, so both kismet_client and GPSDrive announces the AP with the texttospeech engine.
In the GPSDrive I patched for you, the malformed SSID's should be read out as "Malformed SSID", while Kismet_Client will read out all the numbers.
And you are right, its from proberequest, originating from XP boxes, due to the fact that XP spills bits of memory into the probe in some cases. This used to show up as a random character stream in the SSID field which could look like this "^L^j^x^n^A" and go on forever.
Kismet since ver. 2005-08-R1 changed the SSID munging to display unprintable character in an octal presentation, and thats why you get it read out as a string of numbers in those cases. Kismet_client will allways read them out like that when using its voiceannouncement capability, while the patched GPSDrive normally don't, unless the first character is a printable character.
The only way to avoid this, is to kill all XP boxes, or hope for MS to fix their WiFi stack..
Dutch
All your answers are belong to Google. SEARCH DAMMIT!
Warning. Warning.
Low C8H10N4O2 level detected. Operator halted....