That way you should get a log saved (I think) in the system, and we could see if it was trying to do anything when you got the error... but also, it'll auto-restart itself if there is a problem :)
Basically what's happened is some advertising data has been received that is malformed (or most likely just truncated). So either a device is broadcasting the wrong stuff (less likely as I think the Nordic SDK actually sanity checks things), or very occasionally an advertising packet is received wrong and the CRC for it passes.
Actually I'd guess that in:
case 0x02: // Incomplete List of 16-bit Service Class UUID
case 0x03: // Complete List of 16-bit Service Class UUIDs
for (j = 0; j < bytes.length; j += 2) {
serviceUuid = bytes.readUInt16LE(j).toString(16);
if (advertisement.serviceUuids.indexOf(serviceUuid) === -1) {
advertisement.serviceUuids.push(serviceUuid);
}
}
break;
The buffer's length is somehow not a multiple of two, and that causes the out of bounds access.
You could just drop them a PR with for (j = 0; j < bytes.length; j += 2) { changed to for (j = 0; j < bytes.length-1; j += 2) { and that'd fix it.
Same for all of the loops in that function - if it's 128 bit (16 bytes) it should check against length-15, and so on. Otherwise I could do it?
Good job it's JavaScript - if that was C it'd be a massive security hole that you could exploit with malformed advertising packets :)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Could you maybe try setting it up with the headless startup? https://github.com/espruino/EspruinoHub#headless-startup
That way you should get a log saved (I think) in the system, and we could see if it was trying to do anything when you got the error... but also, it'll auto-restart itself if there is a problem :)
This does look like 100% a Noble issue though, so you could try and raise it there. Looking at it, the error comes from https://github.com/noble/noble/blob/master/lib/hci-socket/gap.js#L149
Basically what's happened is some advertising data has been received that is malformed (or most likely just truncated). So either a device is broadcasting the wrong stuff (less likely as I think the Nordic SDK actually sanity checks things), or very occasionally an advertising packet is received wrong and the CRC for it passes.
Actually I'd guess that in:
The buffer's length is somehow not a multiple of two, and that causes the out of bounds access.
You could just drop them a PR with
for (j = 0; j < bytes.length; j += 2) {
changed tofor (j = 0; j < bytes.length-1; j += 2) {
and that'd fix it.Same for all of the loops in that function - if it's 128 bit (16 bytes) it should check against length-15, and so on. Otherwise I could do it?
Good job it's JavaScript - if that was C it'd be a massive security hole that you could exploit with malformed advertising packets :)