is there any reason to upload more than the legacy 2016 kismet .nettxt?

[arkasha]

Absolutely; the KML export just disqualifies those because broken time stamps are often a proxy sign of bad GPS signal. You can gather data and export upload once the patch is in. You can also upload on a rolling basis and re upload when the date stamps are fixed

[arkasha]

you'll still recieve discovery credit for any APs you're the first to find, and they'll still be geolocated - the timestamps-less locations will just be given lower weights than later observations with valid timestamps, and so long as you don't clear your DB, you'll be able to re-export these with valid times when the fix is incorporated.

[cortijocare]

Ok... currently reprocessing my older wiggle files and will upload all of them tonight to report back. We're getting there

[cortijocare]

Ok! wish there was a way to batch process all this, but we got there in the end.

IDs are:

20190318-01339
20190318-01334
20190318-01333
20190318-01329
20190318-01328
20190318-01324
20190318-01302
20190318-01287
20190318-01286

... with 334 and 339 being new files and containing new wifi data, the rest are re-uploads.

I'm pleased with the results from a geolocation point of view (looking at the resulting kml that is), where the re-uploaded files didn't add new data (and therefore spit out empty kml, as expected), and the ones appear to be a good solid match to what i observed on the ground.

That being said, considering how much data gets trimmed off as part of the kismetdb_to_wigle file, I'd like to know from the guys at Wiggle whether or not the output is acceptable and, more importantly, as complete as it could be (after all, I want to be walking around for a reason - it's no small task to put this rig together and carry it around

[cortijocare]

The adventure continues ... so far every git pull from my past messages to the most recent april (compiled from source) release has given me trouble with one of my card (the rtl88xxau) locking to 'nill' channel ,with the workaround to restart kismet 3-5 times until it 'accepts' to switch back to hopping. A lot of crashes ensued. I'm going to spend some proper time digging into this and report back , this time armed with proper debug logs.

[arkasha]

Kismet R1 dropped yesterday (go Dragorn!)- similar issues with the full release?

[cortijocare]

Thank you @arkasha - sadly, it's worse - I've raised my concerns on https://github.com/kismetwireless/kismet/issues/135 - problem is beside "source failed', kismet is no helping much. Tough situation when the alternatives are either window based or the wiggle app (which is fantastic, but because of the android 9 throttling bug, is no longer useful for 'hardcore' users).

Will keep you updated.

[-kw]

@arkasha
Can you have a look at 20190504-01168, please? Uploaded with kismet 2019-04 R1, but no download from upload page possible 693 Networks in file, all other files uploaded from stack are working.

[arkasha]

looks like nothing but "WIFI,<BSSID>" rows in a CSV file - not one of our supported upload formats on its own.

[-kw]

Very interesting. This was converted using kismetdb_to_wiglecsv.