RangeError

[deathslocus]

After running for a while radioparse throws new RangeError('Trying to access beyond buffer length');

relevant stack trace

at parse_tag (/radioparse/80211_tags.js:107:23)
at parse_tag (/radioparse/80211_tags.js:179:19)

[arselzer]

I see this has something to do with the frame tags in a packet you have received. It is probably a bug in the parser, a device not following standards, or both.

The way I tested this libray was to let the program run for a while and fix it if it crashes. Identifying the cause could be challenging without the raw packet data.

Although it isn't a nice fix, I would suggest catching the exceptions and discarding packets for which they occur. Radioparse shouldn't throw exceptions if devices don't conform to standards, so I'll try to fix it.

[deathslocus]

What's weird is that it only throws if I attempt to do something with the parsed JSON. I can run for hours just logging the entire packet but less than 20 minutes when I log src_addr

[arselzer]

That does indeed seem weird... maybe some other function is catching and discarding the exception...
If you had the chance to capture the packet causing the RangeError, I would be able to track down the problem easier.

something like this should be sufficient:

try {
radioparse.parse(packet)
} catch (err) {
  fs.writeFileSync("badPacket", packet)
}

[sumeetkpatel]

I am having a similar problem parsing the packets.
Specifically 80211_tags.js line 164 & line 6.
It is trying to read the uint8 from the vendor specific tag and fails due to an index out of bounds.
I have attached a sample bad packet.

bad_packets.txt

[arselzer]

Thanks for reporting the issue. I'd love to fix it but I haven't used node.js in a while and don't have that much time now.

To find the exact cause of the out of bounds error a raw pcap file would probably be helpful (instead of the parsed JSON), since the error occurs while parsing the bytes.

The pcap file can then be read and decoded like this (sample.pcap):
https://github.com/AlexanderSelzer/radioparse/blob/c8ec128047694e2ec10dc213f2514ff52e0c7800/test/test_file.js

But if you have any fix I would obviously be happy to merge it!

[sumeetkpatel]

Of course it took me forever to get a bad packet again, but it seems I might've caught one.
I only captured the 'slices' to the pcap files so they are incomplete but are readable by radioparse.

You should find that "d6a5ca06-d817-49d5-95ea-bdbd625bfd5f.pcap" produces the range error.

Sample good and bad packet slices and my load.js:
bad_packets.tar.gz

[arselzer]

Thank you! I'll see what I can do.

Of course it took me forever to get a bad packet again
I can imagine that.

Originally this library was made for a school project that involved carrying a raspberry pi in a backpack and capturing packets together with GPS data. However relatively infrequent (days) or frequent intervals depending on the location some packets managed to crash the library. So the function call just ended up in a try block which wasn't a nice solution but satisfactory for the purpose :)

[arselzer]

The main issue was that parse_vendor_specific tried to access bytes with an index beyond the size of the Buffer, which was 2 in the case of the bad packet. I've "fixed" it by returning a {oui: null, type: null} object.

Now I don't know if this is a valid vendor specific field in the IEEE 802.11 standard that can be interpreted in any way and I admit I don't have a complete overview over my own code at this point, but this quick fix should at least prevent the error.

(size), (bytes)
11 <Buffer 00 17 f2 0a 00 01 04 00 00 00 00>
8 <Buffer 00 50 f2 08 00 10 00 00>
9 <Buffer 00 10 18 02 00 00 10 00 00>
2 <Buffer ae d4>
buffer.js:840
    throw new RangeError('Index out of range');
    ^

RangeError: Index out of range
    at checkOffset (buffer.js:840:11)
    at Buffer.readUInt8 (buffer.js:878:5)
...

[sumeetkpatel]

Thanks!

[sumeetkpatel]

Got some more bad packets of a different type, with "traffic_indication_map" tags.

RangeError: Index out of range
    at checkOffset (buffer.js:839:11)
    at Buffer.readUInt8 (buffer.js:877:5)
    at parse_tag (80211_tags.js:116:27)
    at parse_tags (80211_tags.js:194:19)
    at probe_request (80211_frame.js:45:11)
    at Object.parse (80211_frame.js:151:22)
    at Object.parse (radiotap.js:156:24)

More sample slices:
bad_packets.tar.gz

[arselzer]

Thank you for the help!

That issue should also be fixed now. See 84a2fe1

I have no idea why tags of length 2 can even occur. For now it is just checked whether or not the Buffer is large enough that the fields can be read without nullpointer errors occuring.

[sumeetkpatel]

Got some more bad packets of 3 more types, similar type of error for both traffic_indication_map and sadly channel as well.

I am checking the tag length for all of the traffic_indication_map and channel fields now.
bad_packets.tar.gz

I also noticed you left a console.log at line 112 of 80211_tag.js

I created a pull request with the necessary fixes and other minor difference in my fork: #5

[arselzer]

I would have guessed that more and more issues keep coming up :)
In a way the decoder is fundamentally flawed. Checking the length for all types is probably necessary.

I also noticed you left a console.log at line 112 of 80211_tag.js

Right. That shouldn't be there.

I have merged your pull request. Thanks.