New APs scanned with kismet appear as all WEP off?
I just got kismet and linux on my laptop and scanned a couple areas over the last couple days, but it seems that they all appear as WEP off networks in JiGLE even though I know a large percent of them have encryption turned on. Is this a bug/thing due to the multiple log files kismet uses, or some other problem?
Very impressed with kismet detection ability, getting way more on average than in Windows with this old lappy and the amount of data collected seems impressive, until it gets (or rather doesn't get) into the WiGLE database.
What am I doing wrong here? Should I upload the log files in another order?
Very impressed with kismet detection ability, getting way more on average than in Windows with this old lappy and the amount of data collected seems impressive, until it gets (or rather doesn't get) into the WiGLE database.
What am I doing wrong here? Should I upload the log files in another order?
if you let us know the transaction id (and an example MAC) either here or at wigle-admin[at]wigle.net we can check and make sure the parser is recognizing the reported flags correctly for your file.
In general, the results you see through wigle.net are aggregate ones, some (such as wep status) are "most recently seen". so depending on what network you're looking at its status (just like in real life) may be different.
with kismet, it may well be a bug (either in the logging or our parsing) so the transaction id and a MAC would be of great help!
In general, the results you see through wigle.net are aggregate ones, some (such as wep status) are "most recently seen". so depending on what network you're looking at its status (just like in real life) may be different.
with kismet, it may well be a bug (either in the logging or our parsing) so the transaction id and a MAC would be of great help!
Here are the transactions for the first set I uploaded:
20050604-00009 - Kismet-Jun-04-2005-1.csv
20050604-00010 - Kismet-Jun-04-2005-1.xml
20050604-00011 - Kismet-Jun-04-2005-1.gps
00:0F:66:A7:9A:6D should have WEP on, according to what's in my .xml file, and 00:12:17:BA:2D:9C uses WPA.
The channels appear as 0 as well, so maybe I should be uploading the .gps file first?
20050604-00009 - Kismet-Jun-04-2005-1.csv
20050604-00010 - Kismet-Jun-04-2005-1.xml
20050604-00011 - Kismet-Jun-04-2005-1.gps
00:0F:66:A7:9A:6D should have WEP on, according to what's in my .xml file, and 00:12:17:BA:2D:9C uses WPA.
The channels appear as 0 as well, so maybe I should be uploading the .gps file first?
I did another run, and uploaded the .gps files first, then the .xml files. Seems everything worked this time, channels and WEP properly identified in JiGLE.
Did you guys change anything, or was it the order that I uploaded them that made the difference?
Did you guys change anything, or was it the order that I uploaded them that made the difference?
Okay, so we know how to avoid the problem, but since the results are aggregate, then why would the order of upload (and processing) make such a difference? Does it favor the latest set of data, even if the data is basically invalid, like all channel 0? Perhaps something can be done about that, or if not then maybe a reminder as to what order the kismet logs should be uploaded in on the Post File page to avoid future mis-parsing of data?
Last-one-wins has been changed to not update when things are unknown, hopefully that'll prevent this kind of thing.
Wouldn't gzip'ing also have worked around this issue? It seems unnecessary to upload three files for a single wardrive when one would do.
OTOH, I haven't tried gzip'ing myself, does a gzip expand to one transaction per file?
OTOH, I haven't tried gzip'ing myself, does a gzip expand to one transaction per file?
currently gzip is compression, not archive (.gz not .ZIP)
we're testing spooooky future technology as we speak, because we're all sick of waiting to upload files one at a time, really.
luckily arkasha was less lazy than the rest of us. :-)
it will be announced on the front page and sung from the hills when it goes into production, i assure you.
we're testing spooooky future technology as we speak, because we're all sick of waiting to upload files one at a time, really.
luckily arkasha was less lazy than the rest of us. :-)
it will be announced on the front page and sung from the hills when it goes into production, i assure you.
Who is online
Users browsing this forum: No registered users and 9 guests