Prime example of a bad ns parse

[izzy4505]

Check on trans. id 20031031-00014. Practically everything is said to be encrypted, even though when the file loaded in netstumbler is not. If you need the original file, let me know.

[uhtu]

rock. thanks!

[uhtu]

yeah, we were parsing fine, but inspecting the ns1 flags field incorrectly. doh.

this has been fixed in the tree, still testing some additional NS1s for positive wep-indication before we roll it out.

[izzy4505]

Ok, this is a bad deal. Do you have previous uploaded files archived somewhere so you could reparse 'em all? Because this has been a long long problem. I posted about it months ago, but lost the files before I could send 'em to ya. If it's not possible to get the data back, is it possible to give those ap's an unknown wep status?

[uhtu]

we're examining the best way to go about this.

we record all the flags fields (which is how we determine wep status)
and we're looking into a consistency run against the database to make sure the flags match the data derived from them. so there will be no need to repost any files, and infact it wouldn't help.

we always try and be responsive to problems with our parsers when we can get data to work with (there's a lot of them against a lot of moving and byzantine targets :-)

the current, fixed and tested NS1 parser is in production.

[izzy4505]

You guys rock!

[izzy4505]

I noticed you mentioned that you guys have flags in the database. Is there anyway you could return that field along with the rest of the data in a query? For the machine readable version anyway.