-
Notifications
You must be signed in to change notification settings - Fork 0
Changes
While it is sometimes difficult to follow the intention to make fairly atomic, compact code changes and commit those, I'll try and keep a list of major changes/developments in the code while that ideal is saught.
Not yet published, most likely after current redesign is completed. f new code, which doesn't quite work yet. Just trying to keep track.. Noteably either all packets are being rejected because of a number of typos or broadcast type packets are being added to the DB. -- Well, that is fixed, now to fix the checkDevice function.
Converted the config.js into a few specific yaml files. Logs will no longer go to stdout/pm2 unless --verbose is specified. New lib/config module which uses .get retrieve settings and .module to select configuration root.
Device and sensor modules device.wifiv2.js and device.sensor.js will calculate their own stats, freeing up smwss. This will also be used in the CLI to display per sensor/over all statistics.
The current logger.js will be replaced by logbuffer.js, which holds a limited number (256) of logs in JSON format until they are read. This will be combined with streaming to be able to save/redirect logs from/to any sensor/server/client.
Select the size of UI elements in the CLI with the 1 of 3 included console.layout objects: small - average cmd.exe font size, seperate device info and log pages, medium - more room for more table fields, and large, for 160+ Column terminals
I think all packetes are now being counted, but until we've determined if it was an AP or STA through beacon or probe tags or certain packet types, those packets will be ignored.
This allows an interesting statistic, comparing the last sequence number to the latest one, which can show how many packets were 'lost' in transmission.
Considering iw is more likely to be on a machine, wifi.hopper.js uses this now to change channels, but an option may be added to use that or iwconfig.
The list of channels available is scraped from iwfreq, but the potential to get the same information plus dBm ratings is present when using iw, it's just a little more complex to scrape.
This list of channels is returned by hopper.list_channels(), retrieved through msg.cmd 'channels', and used to construct the channel graph in the CLI. Soon, it will be a 'set' type array, but this
will still be problematic..
Struggling to organize the next upload, but here is what I can find.. oh, more major changes in DB format and config.js ... yay.
js-yaml and tail are now being used to read the new devices.yaml file and stream the output from rtl_433 - I found it had unreliable output when streaming results to stdout while saving them to a JSON file, but now I just tail the json file, which is located at data/rtl_433_[index].json by default.
And device manager/tracker functionality is forming in the ability to list your/their/our devices and add various fields of information.
Additionally devices can either expire after a set time (through nedb) or be forgotten if they are not in a list, an AP or client, or soon if they are very quiet and probably randomized/transient.
For up to a few days of logging NEDB has been performing pretty well, but we will look at other storage options in the future.
I finally got some 802.11AC cards and have updated the wifi.packet.js library and cli to accomodate this, with 2 graphs for G/N and AC bands being shown on page 2 of the CLI UI above the packet graph.
My card/driver/platform (8812AU/aircrack-ng driver 5.6.4 something?/RPI or debian) combination produce some odd results, but overall super pleased in finally being able to see all of those mythical 5.8G networks that I've only seen on my phone. Waiting on some Panda PAU09's, have heard pretty good things about.
Moved a bunch of files around, to device.xxx and wifi.xxx and such, hopefully it will inspire a plugin format and make it easier to keep track of things. Also, added auto (weekly) updating of the OUI file, which now wants to be in data/oui.json.
PCAP files can be saved to data/pcap/ periodically - though the pcap continually gives the silly 'may not work' error.
Speaking of PCAP, there is "experimental" support for node v 12.00 which I have used for a good bit without issue. I'm not sure how long it will take to be merged into the PCAP source, but for now 10.16.3 is the latest version that is easily supported.
While attempting to enable two way messaging via web socket, I've enabled some simple (yet kinda dangerous) commands for sensors, which will be disabled by default, such as restarting the client, restarting the machine, and perhaps spawning an xterm.js terminal. Sensors also log some channel/packet type data themselves, and will soon send that data when sending regular status updates.
If it is not feasible to stream all log files to a client/misc, I will look at some other logging frameworks.
Everywhere... like my old friend once said, at a very inopportune time.
Related to my new Alfa dual band card, rssi values and channels are either mixed up or way off.
Time issues.. either constantly converting or machines drifting
RTL322 can't be integrated until a uniform way of storing, searching and displaying all of these things is decided upon. The new Kismet does it fairly well.
The bluetooth scanner module eats up all memory when continually loaded in one node session, so it will have to be constantly spawned.
Have not had a change to set everything up again and go war driving, so the map functionality still remains to be updated.
And, there is persistent obstruction present when it comes to getting further info from the PCAP packets. TShark does the best decoding, but without in-depth node support, this is becoming the main drawback from using a python based wifi sensor.
Oh well. back to the fab lab.