-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infrequent missing final character on MAC address in CSV file #142
Comments
Hi, I looked through some of my captured files and seem to be affected by the same issue. For me, the problematic line always contains a \r (which would explain why Excel is showing additonal lines for you) and that is the only pattern I found. This is odd because only \n has been used since #16. I've also seen other odd behavior on these broken lines including MAC addresses with extra octets. Carriage return characters (the \r) could potentially make it into the file from side B which sends them for certain messages (specifically all of the I will investigate this some more, and expect it is related to communication from side B. If you want to find other affected lines (or if anybody else reading this does), Notepad++ can be used. Search for \r and ensure "extended" search mode is selected. The \r character should not be found in files generated by firmware v1.0.1 or higher. |
Sorry my examples above are a little misleading -- they are from four different files, the spaces between lines were just my separations from each file, not actual \r's. I'm only seeing \n for line endings in the affected files. od -c for the last line above from the full file:
I'll dig around other files and see if I find any patterns. |
One other curious pattern - in one file from 10/28, the same SSID and MAC appear 5 times, but only ONE instance has the broken MAC address.
I have not found this pattern elsewhere yet. |
Last bit of inspection for today - where there are issues with the MAC, they are consistently seen on channels 1, 6, or 11 which would tie into Side B being the source. I found four other files back to August with anomalies on WIFI lines. I found one instance of an octet other than the last one being truncated, but it's usually the last character being dropped.
|
Looking at various CSV files, once in a while I find a line or two that generate an extra column when the CSV is opened in Excel. I noticed that the lines in question always are missing one character in the MAC address. Note the last octet in the examples below is always one character instead of two.
All have this header (from 1.2.0b4 firmware) -- since they are all seen in b4 so far, perhaps this was addressed in #138 for beta 5. I haven't had enough time with b5 installed yet to have many files to explore.
WigleWifi-1.4,appRelease=1.2.0b4,model=wardriver.uk rev3,release=1.0.0,device=wardriver.uk rev3,display=i2c LCD,board=wardriver.uk rev3,brand=JHewitt
MAC,SSID,AuthMode,FirstSeen,Channel,RSSI,CurrentLatitude,CurrentLongitude,AltitudeMeters,AccuracyMeters,Type
6A:B9:D3:93:0F:8,,LEISURE470-6A5237,[WPA2_PSK],2023-11-19 03:55:37,1,-79,44.9734192,-93.2478638,154.20,7.75,WIFI
AE:97:CD:74:A9:2,,,[WPA2_PSK],2023-11-08 21:24:08,6,-86,44.8654404,-93.3223038,268.20,2.50,WIFI
7E:E3:0E:CB:CC:0,,,[WPA_WPA2_PSK],2023-10-29 02:28:40,6,-87,44.9680443,-93.2472763,261.10,2.50,WIFI
8E:EF:16:AF:32:0,,,[WPA2_PSK],2023-10-28 12:54:04,1,-79,44.9812584,-93.2410126,262.00,2.50,WIFI
4A:4B:D4:59:FE:7,,xaayow,[WPA2_PSK],2023-10-28 12:58:17,6,-84,44.9829674,-93.2486572,252.90,2.50,WIFI
I tried looking all these up on the Wireshare OUI tool and none worked. I tried adding a leading '0' and still none lookup. I don't see a pattern in the glitch, but will look at bit more.
The text was updated successfully, but these errors were encountered: