Noble crashing EspruinoHub intermittently

This may be a tough one to get to the bottom of since it might only happen once a week (sometimes more sometimes less).

I have a Puck that I use as a Bluetooth "button". Pressing the button causes it to advertise "on" or "off". Then I have a simple NodeRed setup that reacts to the change and turns on/off a light.

However at random intervals on the Node Red RaspberryPi, Noble crashes and takes down EspruinoHub. I've tried updating to latest EspruinoHub master a few times but that hasn't helped. Console output below.

I know it's probably more a bug for the Noble author but I wondered if anything obvious jumped out or if there was more debug output I could generate?

30:e1:37:00:43:1d - ? (RSSI -65)
48:d6:d5:58:3b:db - Office TV (RSSI -64)
  fe9f => {"type":"Buffer","data":[0,0,0,0,0,0,0,0­,0,0,0,0,0,0,0,0,0,0,0,0]}
  fea0 => {"type":"Buffer","data":[3,250,143,202,1­50,110,139,98,32,32,32,15,255]}
98:7b:f3:96:06:28 - YUNMAI-SIGNAL-H1US (RSSI -82)
c0:28:8d:37:ae:15 -  (RSSI -82)
c5:2e:b9:d5:27:a3 - Im On A Call Switch (RSSI -73)
  ffff => {"level":0}

buffer.js:977
    throw new RangeError('Index out of range');
    ^

RangeError: Index out of range
    at checkOffset (buffer.js:977:11)
    at Buffer.readUInt16LE (buffer.js:1023:5)
    at Gap.onHciLeAdvertisingReport (/home/pi/EspruinoHub/node_modules/noble­/lib/hci-socket/gap.js:149:31)
    at emitMany (events.js:147:13)
    at Hci.emit (events.js:224:7)
    at Hci.processLeAdvertisingReport (/home/pi/EspruinoHub/node_modules/noble­/lib/hci-socket/hci.js:651:10)
    at Hci.processLeMetaEvent (/home/pi/EspruinoHub/node_modules/noble­/lib/hci-socket/hci.js:608:10)
    at Hci.onSocketData (/home/pi/EspruinoHub/node_modules/noble­/lib/hci-socket/hci.js:479:12)
    at emitOne (events.js:116:13)
    at BluetoothHciSocket.emit (events.js:211:7)
pi@raspberrypi:~/EspruinoHub $ ./start.sh 

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/mast­er/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:

      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(serv­iceUuid) === -1) {
            advertisement.serviceUuids.push(serviceU­uid);
          }
        }
        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 :)

Thanks Gordon. I wasn't able to get headless working on the original install. Everything appeared to be ok but it never detected devices. Worked fine with start.sh. I assume I'm missing a permission or something somewhere. Will try again, particularly for the auto-restart!

Interesting re malformed data. There are quite a few BLE devices in the room, several of which, like the Milestone Pod, sleep until they are moved. So it may be one of them.

I'll sort out step one and report back.

@ConorONeill - by any chance, have you had any luck with this? I believe I may be seeing the same or a similar issue. I'm in the process of updating everything from circa June 2018 to current - just wondering if there's a chance fresh updates might clear the issue.

@cottjr I believe some updates from later in 2018 have sorted it out. But once I switched it to running it as a service, I stopped checking, as systemd will automatically restart it after a crash.

If you're experiencing crashes after an update, is it possible you updated to Node 10? I believe the Noble library still has issued with Node 10 - Node 8 should work fine though.

@Gordon - I recall you left a good hint about Node 10 by the time I first set EspruinoHub up middle of 2018 - so it's been at v8.15.0 all along. FWIW - last I dug in, it seemed to be something about bluetooth signals for a Samsung TV we have that was typically the culprit...

@ConorONeill - good to know - thanks - I'll finish the round of updates & try the instructions to set it up as a service... That exercise should also help improve my ongoing Linux learning curve. Auto restart should be good enough if the root cause is going to remain lurking around.