nRF Mesh Crashes on Android when receiving Mesh Messages via Publish in Vendor Model

[dstarling]

When I publish messages to the mesh network via a Vendor Model, after connecting to device and performing a successful vendor command sequence, I start sending publishes of sensor data to the mesh and get a few different crashes.  The stack trace of the first one is as follows:

D/AndroidRuntime: Shutting down VM
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.gamechanger.android.gcmonitor, PID: 29713
java.lang.NullPointerException: Attempt to invoke virtual method 'int no.nordicsemi.android.mesh.transport.ProvisionedMeshNode.incrementSequenceNumber()' on a null object reference
at no.nordicsemi.android.mesh.transport.LowerTransportLayer.sendBlockAck(LowerTransportLayer.java:745)
at no.nordicsemi.android.mesh.transport.LowerTransportLayer.handleImmediateBlockAcks(LowerTransportLayer.java:544)
at no.nordicsemi.android.mesh.transport.LowerTransportLayer.parseSegmentedAccessLowerTransportPDU(LowerTransportLayer.java:513)
at no.nordicsemi.android.mesh.transport.NetworkLayer.parseAccessMessage(NetworkLayer.java:319)
at no.nordicsemi.android.mesh.transport.NetworkLayer.parseMeshMessage(NetworkLayer.java:268)
at no.nordicsemi.android.mesh.transport.DefaultNoOperationMessageState.parseMeshPdu(DefaultNoOperationMessageState.java:60)
at no.nordicsemi.android.mesh.transport.BaseMeshMessageHandler.parseMeshPduNotifications(BaseMeshMessageHandler.java:147)
at no.nordicsemi.android.mesh.MeshMessageHandler.parseMeshPduNotifications(MeshMessageHandler.java:61)
at no.nordicsemi.android.mesh.MeshManagerApi.parseNotifications(MeshManagerApi.java:304)
at no.nordicsemi.android.mesh.MeshManagerApi.handleNotifications(MeshManagerApi.java:276)
at com.gamechanger.android.gcmonitor.viewmodels.NrfMeshRepository.onDataReceived(NrfMeshRepository.java:476)
at com.gamechanger.android.gcmonitor.ble.BleMeshManager$1.lambda$initialize$0$BleMeshManager$1(BleMeshManager.java:116)
at com.gamechanger.android.gcmonitor.ble.-$$Lambda$BleMeshManager$1$8MkBenSGVpQpWecQfKpVn56TTv0.onDataReceived(Unknown Source:2)
at no.nordicsemi.android.ble.ValueChangedCallback.notifyValueChanged(ValueChangedCallback.java:123)
at no.nordicsemi.android.ble.BleManager$BleManagerGattCallback.onCharacteristicChangedSafe(BleManager.java:2884)
at no.nordicsemi.android.ble.MainThreadBluetoothGattCallback.lambda$onCharacteristicChanged$4$MainThreadBluetoothGattCallback(MainThreadBluetoothGattCallback.java:135)
at no.nordicsemi.android.ble.-$$Lambda$MainThreadBluetoothGattCallback$R_hGfDgzC1ieM6HXyW_Z9E0hTuU.run(Unknown Source:8)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:237)
at android.app.ActivityThread.main(ActivityThread.java:8167)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:496)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1100)
I/Process: Sending signal. PID: 29713 SIG: 9

I have additional logs, it appears to crash in the nordic mesh library.

no.nordicsemi.android.mesh.transport.LowerTransportLayer.sendBlockAck(LowerTransportLayer.java:745)

Let me know if you need further information. I am using an nrf52840 DK and the latest NCS with Zephyr to implement Mesh. 

[dstarling]

The app version is 2.4.3 and yes I believe I was able to reproduce it with the original app, and the changes I have are very minimal at this time.

[Roshan Rajaratnam]

Hi, I'm trying to reproduce this issue, but it's not easy to reproduce this without having the same network setup and I see that you have version 2.4.3. Could you try with the latest version? From what I see, this is happening when sending black acknowledgements. Do you happen to have a node that is not listed in the phone?

[dstarling]

I can reproduce it with the stock 2.4.4 nRF mesh app with these steps:

1. Setup node and provision

2. Set publish address to 0xC000

3. Go to Proxy Filter, Whitelist, and set address to 0xC000

4. Go back to Device Page and select Elements where Vendor Model Info is shown

5. Publish Vendor packets at 10 Hz rate from device

App seems to crash at this point and restarts.

[dstarling]

If I skip step 3 it does not crash, but I don't get any vendor mesh messages either.

[dstarling]

static const struct bt_mesh_model_op vnd_ops[] = {
	{ BT_MESH_MODEL_OP_3(0x01, CID_ZEPHYR), 0, vnd_get },
	{ BT_MESH_MODEL_OP_3(0x02, CID_ZEPHYR), 3, vnd_set },
	{ BT_MESH_MODEL_OP_3(0x03, CID_ZEPHYR), 3, vnd_set_unack },
	{ BT_MESH_MODEL_OP_3(0x04, CID_ZEPHYR), 6, vnd_status },
	{ BT_MESH_MODEL_OP_3(0x05, CID_ZEPHYR), 4, vnd_data },
	BT_MESH_MODEL_OP_END,
};

struct bt_mesh_model vnd_models[] = {
	BT_MESH_MODEL_VND(CID_ZEPHYR, 0x4321, vnd_ops,
			  &vnd_pub, &vnd_user_data),
};

Simple Model

and a simple publish function called periodically

void vnd_publish(struct sensor_value value[3], bool publish) {
	struct vendor_state *state = vnd_models[0].user_data;
        struct bt_mesh_model_pub *pub = (&vnd_pub);

        //Copy new data
        for (int sample = 0; sample < 3; sample++)
        {
          //TODO: reevaluate this conversion on samples!
          state->data.samples[0].imu.acc[sample] = (value[sample].val1 << 8) | value[sample].val2;
        }

  if (publish) {
	bt_mesh_model_msg_init(pub->msg, BT_MESH_MODEL_OP_3(0x05, CID_ZEPHYR));

        for (int index = 0; index < NUM_OF_SAMPLES; index++) {
          //IMU Data Output
          net_buf_simple_add_le32(pub->msg, state->data.samples[index].imu.timestamp++);
          for (int sample = 0; sample < 3; sample++)
          {
            net_buf_simple_add_le16(pub->msg, state->data.samples[index].imu.acc[sample]);
          }
        }
        int ret = bt_mesh_model_publish(&vnd_models[0]);
	if (ret) {
		printk("Unable to publish %d\n", ret);
	}
  }
}

[Roshan Rajaratnam]

dstarling thanks for the detailed information. I will give this a shot and get back to you. Is there any chance. should the 5th step be done from the firmware side? are you using your own vendor model here?

[dstarling]

Yes, Step 5 is from NRF52840 dev board, and the vendor model that I am currently testing with is as shown in the code above.

[Roshan Rajaratnam]

Hi I have received a pull request on Github that might fix your issue. I think the library was trying to send block acknowledgements to a non-unicast addresses. I see that the crash you had was also in block acknowledgements for sensor messages published via 0xC000, when the library tried to increment the sequence number for a non-unicast address. Could you please try the latest dev branch and see if it works for you?