Is there a way to indicate that Provisioning mode is in progress

[sarjoon]

Hello Nordic Team,

I have a nRF52833 DK and I am running Light switch Server and client applicaiton in it.

I am in the moment customizing the application for our custom need.

So we are in a process to modfyin the application.

I would like to know is there a way to tell that current mode is in Provisioning mode ?

I know there is a PDU type but during provisioning mode we can see other PDUs as well

For our requirement I am going to define a custom PDU for my need.

So would like to know whether is way to indicate that Provisioning is started and its ended.

Thanks and Regards

Sarjoon.

[Joakim Jakobsen]

Hi.

Just to clarify; Which device do you want to know if other devices are in active provisioning?

Do you want the light switch client (or other nodes in the network) to know that the light switch server is currently beein provisioned?

Also, if you could add information about SDK version etc. that could be useful in order to assist you in the best possible way.

Br,
Joakim

[sarjoon]

Hello Joakim Jakobsen,

Not with the other nodes.

Its in the same application not with other application, Assume Light switch Client application has started provisioning , I would like to indicate that Provisioning has started and would like to indicate once Provisioning is done.

I have seen "m_device_identification_started"  flags present.

But I see even after "m_device_provisioned" is set to true. There are still few transfer been happening with Network PDU type.

I want to exactly tell and indicate my application when the Provisioning is ended.

nRF SDK version is 17.1.0

SDK for MESH version is v5.0.0_src

I am using nRF Connect for SDK to build my application.

Thanks and Regards

Sarjoon

[Joakim Jakobsen]

I understand. Sorry for the misunderstanding.

When the provisioning process is complete, you willl get the NRF_MESH_PROV_EVT_COMPLETE event. Receiving the event will set m_device_provisioned = true.

sarjoon said:

There are still few transfer been happening with Network PDU type.

What kind of transfer are you seeing?

Br,
Joakim

[sarjoon]

Hello Jaakim,

Yes that is happening. Its just the packets right after that.

Below is the log for reference.

<t: 568087>, prov_provisionee.c, 465, Provisionee: public key message received!
<t: 568097>, mesh_gatt.c, 177, HVN data: 0303F6954CF6E240BFA41CF62E7BD8D2C55F234B898476D133A933AD66DCD705900C9A0F1AA25A0B7C65C39910FF16022EEAFED2B350D40EFA52632B02F5E9F7A46C
<t: 568105>, mesh_gatt.c, 228, status: 0 len: 66 usable-mtu:66 sar_type: 0
<t: 584272>, mesh_gatt.c, 946, LENGTH 18
<t: 584274>, mesh_gatt.c, 498, pdu_length :17 p_data_type 0x3
<t: 584278>, prov_provisionee.c, 493, Provisioning: provisioning confirmation received!
<t: 584295>, mesh_gatt.c, 177, HVN data: 0305F97A07592676157F8C927636BCC4BD34
<t: 584300>, mesh_gatt.c, 228, status: 0 len: 18 usable-mtu:66 sar_type: 0
<t: 600491>, mesh_gatt.c, 946, LENGTH 18
<t: 600494>, mesh_gatt.c, 498, pdu_length :17 p_data_type 0x3
<t: 600497>, prov_provisionee.c, 521, Provisionee: provisioner's random number received!
<t: 600507>, mesh_gatt.c, 177, HVN data: 03061C3CD5FCA6AEE340EF8C1F3CC405AE77
<t: 600512>, mesh_gatt.c, 228, status: 0 len: 18 usable-mtu:66 sar_type: 0
<t: 616715>, mesh_gatt.c, 946, LENGTH 35
<t: 616718>, mesh_gatt.c, 498, pdu_length :34 p_data_type 0x3
<t: 616721>, prov_provisionee.c, 545, Provisionee: received provisioning data!
<t: 616729>, mesh_gatt.c, 177, HVN data: 0308
<t: 616732>, mesh_gatt.c, 228, status: 0 len: 2 usable-mtu:66 sar_type: 0
<t: 616768>, device_state_manager.c, 2343, Netkey added: E51B1EB1BFF990A28A07CEDF86F7470E
<t: 616776>, device_state_manager.c, 2599, Devkey added: AD1551D490DE77C3E606F5C5109ECC82
<t: 616788>, mesh_stack.c, 262, iv_index: 0x00000000 flag:ivu: 0
<t: 666215>, main.c, 153, Successfully provisioned
<t: 666220>, main.c, 148, Node Address: 0x00A5
<t: 754179>, proxy.c, 748, Connected
<t: 762844>, net_beacon.c, 247, SNB TX ID: 95F365A90CC6A1BD ivu: 0 kr: 0 IV: 0
<t: 777432>, ble_softdevice_support.c, 104, Successfully updated connection parameters
<t: 861962>, mesh_gatt.c, 726, New MTU: 66
<t: 862700>, mesh_gatt.c, 946, LENGTH 2
<t: 862707>, proxy.c, 786, TX ready
<t: 862711>, mesh_gatt.c, 177, HVN data: 01010095F365A90CC6A1BD00000000FE5D448B6F30A327
<t: 862716>, mesh_gatt.c, 228, status: 0 len: 23 usable-mtu:66 sar_type: 0
<t: 862720>, proxy.c, 799, TX complete
<t: 863443>, ble_softdevice_support.c, 104, Successfully updated connection parameters
<t: 932990>, mesh_gatt.c, 946, LENGTH 22
<t: 932996>, mesh_gatt.c, 498, pdu_length :21 p_data_type 0x0
<t: 932999>, proxy.c, 791, RX
<t: 933001>, proxy.c, 674, RX GATT PDU type 0x0, len 21
<t: 933004>, proxy.c, 675, Expected 0x0
<t: 933006>, proxy.c, 677, Data Tx packet: 4A2B8AAAABD076D60711C2F44842AC513763EEC751
<t: 933009>, proxy.c, 703, Time is 933009 ]
<t: 933043>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x0000 alloc? 1 addr_match? 1 key_bound? 1 opcode? 1
<t: 933054>, network.c, 302, Net TX: 4A2800000000A5000180000002D5DB40609513E4272FCA4F1A00000000
<t: 933063>, mesh_gatt.c, 177, HVN data: 004A527D71D8AEDBDE6618A646344CDA4F0DD238C9F3856831B6C60B2A27
<t: 933069>, mesh_gatt.c, 228, status: 0 len: 30 usable-mtu:66 sar_type: 0
<t: 933118>, proxy.c, 738, TX complete
<t: 949217>, mesh_gatt.c, 946, LENGTH 25
<t: 949219>, mesh_gatt.c, 498, pdu_length :24 p_data_type 0x0
<t: 949222>, proxy.c, 791, RX
<t: 949224>, proxy.c, 674, RX GATT PDU type 0x0, len 24
<t: 949226>, proxy.c, 675, Expected 0x0
<t: 949228>, proxy.c, 677, Data Tx packet: 4ABC8F0D4A1395E8C61A466353D66C252D593857E5B9179F
<t: 949232>, proxy.c, 703, Time is 949232 ]
<t: 949235>, network.c, 339, Net RX (enc): 4ABC8F0D4A1395E8C61A466353D66C252D593857E5B9179F
<t: 949242>, net_packet.c, 228, Unencrypted data: : 00A500000000000007
<t: 949245>, network.c, 348, Net RX (unenc): 4A8500028C000100A50000000000000708D0030031460200
<t: 949253>, proxy.c, 738, changes_affected
<t: 957320>, mesh_gatt.c, 946, LENGTH 25
<t: 957327>, mesh_gatt.c, 498, pdu_length :24 p_data_type 0x0
<t: 957330>, proxy.c, 791, RX
<t: 957331>, proxy.c, 674, RX GATT PDU type 0x0, len 24
<t: 957334>, proxy.c, 675, Expected 0x0
<t: 957337>, proxy.c, 677, Data Tx packet: 4A962F058604211DE8FBA9F423EDF6E53EBE39AF79406963
<t: 957340>, proxy.c, 703, Time is 957340 ]
<t: 957343>, network.c, 339, Net RX (enc): 4A962F058604211DE8FBA9F423EDF6E53EBE39AF79406963
<t: 957350>, net_packet.c, 228, Unencrypted data: : 00A500000000000007
<t: 957353>, network.c, 348, Net RX (unenc): 4A8500028D000100A50000000000000708D0030031460200
<t: 957360>, transport.c, 1657, Could not find active session for ACK packet
<t: 957363>, proxy.c, 738, changes_affected
<t: 965429>, mesh_gatt.c, 946, LENGTH 21
<t: 965436>, mesh_gatt.c, 498, pdu_length :20 p_data_type 0x0
<t: 965438>, proxy.c, 791, RX
<t: 965440>, proxy.c, 674, RX GATT PDU type 0x0, len 20
<t: 965443>, proxy.c, 675, Expected 0x0
<t: 965445>, proxy.c, 677, Data Tx packet: 4A639AEA9D45DF2AC329355421430C0891ABDB88
<t: 965448>, proxy.c, 703, Time is 965448 ]
<t: 965451>, network.c, 339, Net RX (enc): 4A639AEA9D45DF2AC329355421430C0891ABDB88
<t: 965458>, net_packet.c, 228, Unencrypted data: : 00A5005CE993956384
<t: 965461>, network.c, 348, Net RX (unenc): 4A0500028E000100A5005CE99395638408D00300
<t: 965467>, transport.c, 1045, Message decrypted
<t: 965472>, access.c, 253, RX: [aop: 0x800C]
<t: 965475>, access.c, 275, RX: Length 0
<t: 965477>, access.c, 277, RX: Msg:
<t: 965479>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x0000 alloc? 1 addr_match? 1 key_bound? 1 opcode? 1
<t: 965488>, network.c, 302, Net TX: 4A2800000300A5000100195F67BF36133614A1B6BF0F0CDFFA04E435EC
<t: 965496>, mesh_gatt.c, 177, HVN data: 004A7254437A7C6985A5E1F09189C65EE32EA8C8E22A
<t: 965501>, mesh_gatt.c, 228, status: 0 len: 22 usable-mtu:66 sar_type: 0
<t: 965504>, access.c, 426, TX: [aop: 0x800E]
<t: 965507>, access.c, 427, TX: Msg: 800E28
<t: 965509>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x0002 alloc? 1 addr_match? 1 key_bound? 0 opcode? 0
<t: 965514>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x1001 alloc? 1 addr_match? 0 key_bound? 0 opcode? 0
<t: 965518>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x1001 alloc? 1 addr_match? 0 key_bound? 0 opcode? 0
<t: 965523>, proxy.c, 738, changes_affected
<t: 965526>, proxy.c, 799, TX complete
<t: 1030308>, mesh_gatt.c, 946, LENGTH 22
<t: 1030315>, mesh_gatt.c, 498, pdu_length :21 p_data_type 0x0
<t: 1030317>, proxy.c, 791, RX
<t: 1030319>, proxy.c, 674, RX GATT PDU type 0x0, len 21
<t: 1030322>, proxy.c, 675, Expected 0x0
<t: 1030324>, proxy.c, 677, Data Tx packet: 4A6A1C16808FF3DFBCE415DF169DE610C3C85A7752
<t: 1030327>, proxy.c, 703, Time is 1030327 ]
<t: 1030330>, network.c, 339, Net RX (enc): 4A6A1C16808FF3DFBCE415DF169DE610C3C85A7752
<t: 1030337>, net_packet.c, 228, Unencrypted data: : 00A500FF1D2272B13258
<t: 1030340>, network.c, 348, Net RX (unenc): 4A0500028F000100A500FF1D2272B13258D0030031
<t: 1030346>, transport.c, 1045, Message decrypted
<t: 1030352>, access.c, 253, RX: [aop: 0x8024]
<t: 1030354>, access.c, 275, RX: Length 1
<t: 1030356>, access.c, 277, RX: Msg: 0A
<t: 1030359>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x0000 alloc? 1 addr_match? 1 key_bound? 1 opcode? 1
<t: 1030372>, network.c, 302, Net TX: 4A2800000400A5000100EAB98E02DD5117A8C8E22A0F0CDFFA04E435EC
<t: 1030379>, mesh_gatt.c, 177, HVN data: 004A0784470DBE4C4CD4A2CDA91DFA7EECAE6A889967
<t: 1030385>, mesh_gatt.c, 228, status: 0 len: 22 usable-mtu:66 sar_type: 0
<t: 1030388>, access.c, 426, TX: [aop: 0x8025]
<t: 1030391>, access.c, 427, TX: Msg: 80250A
<t: 1030393>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x0002 alloc? 1 addr_match? 1 key_bound? 0 opcode? 0
<t: 1030398>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x1001 alloc? 1 addr_match? 0 key_bound? 0 opcode? 0
<t: 1030402>, access.c, 1073, cmp_id: 0xFFFF mdl_id: 0x1001 alloc? 1 addr_match? 0 key_bound? 0 opcode? 0
<t: 1030408>, proxy.c, 738, changes_affected
<t: 1030411>, proxy.c, 799, TX complete
<t: 1090524>, net_beacon.c, 247, SNB TX ID: 95F365A90CC6A1BD ivu: 0 kr: 0 IV: 0
<t: 1095189>, mesh_gatt.c, 946, LENGTH 30
<t: 1095192>, mesh_gatt.c, 498, pdu_length :29 p_data_type 0x0
<t: 1095195>, proxy.c, 791, RX
<t: 1095197>, proxy.c, 674, RX GATT PDU type 0x0, len 29
<t: 1095200>, proxy.c, 675, Expected 0x0
<t: 1095202>, proxy.c, 677, Data Tx packet: 4A831DC8F295B58DA92DA03AA78B0F41646BEEB28D1C520010A5D9A69A
<t: 1095206>, proxy.c, 703, Time is 1095206 ]
<t: 1095214>, network.c, 339, Net RX (enc): 4A831DC8F295B58DA92DA03AA78B0F41646BEEB28D1C520010A5D9A69A
<t: 1095227>, net_packet.c, 228, Unencrypted data: : 00A5800A400153AFD486B17AEB5480FD7962
<t: 1095231>, network.c, 348, Net RX (unenc): 4A05000290000100A5800A400153AFD486B17AEB5480FD7962D00300AC
<t: 1095235>, transport.c, 931, Got segment 0
<t: 1095239>, proxy.c, 738, changes_affected
<t: 1095242>, mesh_gatt.c, 946, LENGTH 30
<t: 1095245>, mesh_gatt.c, 498, pdu_length :29 p_data_type 0x0
<t: 1095247>, proxy.c, 791, RX
<t: 1095249>, proxy.c, 674, RX GATT PDU type 0x0, len 29
<t: 1095252>, proxy.c, 675, Expected 0x0
<t: 1095254>, proxy.c, 677, Data Tx packet: 4A5CDAB25C30BC390D7538CC146210E5EDDFFB29770073B8082ACE596F
<t: 1095258>, proxy.c, 703, Time is 1095258 ]
<t: 1095261>, network.c, 339, Net RX (enc): 4A5CDAB25C30BC390D7538CC146210E5EDDFFB29770073B8082ACE596F
<t: 1095269>, net_packet.c, 228, Unencrypted data: : 00A5800A4021D89CAEEC90CE940F10BD27B7
<t: 1095273>, network.c, 348, Net RX (unenc): 4A05000291000100A5800A4021D89CAEEC90CE940F10BD27B7D00300AC
<t: 1095277>, transport.c, 931, Got segment 1
<t: 1095280>, transport.c, 611, Sending ACK...
<t: 1095283>, transport.c, 2053, TX: control opcode: 0x00 secmat: 0x200041DA
<t: 1095287>, network.c, 302, Net TX: 4A8800000500A50001000A4000000003AE6A8899670F0CDFFA04E435EC
<t: 1095294>, mesh_gatt.c, 177, HVN data: 004A7717685FD49406B398AE1CB090F935FFC8BFEC7C79B846
<t: 1095299>, mesh_gatt.c, 228, status: 0 len: 25 usable-mtu:66 sar_type: 0
Message decrypted
<t: 1095384>, proxy.c, 799, TX complete

See the above log,

once after Successfully Provisioned message and flag is done,

there are still few more packets been sent as Network PDU(0x0) packets.

I wanted to start doing a custom check on the packets i receive after Provisioning is done.

This check cannot be done during Provisioning as this will give errors during the process.

FYI I am using nRF Mesh app for Android to do the provisioning.

I guess these packets is to discover and finish the Services if I am not wrong.

Hope its clear on what I wanted to do.

Thanks and Regards

Sarjoon.

[Joakim Jakobsen]

Thanks.

I see the:

<t: 666215>, main.c, 153, Successfully provisioned

From your logs. Specifially which messages after this is it that you are concerned about?

Br,
Joakim

[sarjoon]

Please see these prints as well

<t: 932990>, mesh_gatt.c, 946, LENGTH 22
<t: 932996>, mesh_gatt.c, 498, pdu_length :21 p_data_type 0x0
<t: 932999>, proxy.c, 791, RX
<t: 933001>, proxy.c, 674, RX GATT PDU type 0x0, len 21
<t: 933004>, proxy.c, 675, Expected 0x0
<t: 933006>, proxy.c, 677, Data Tx packet: 4A2B8AAAABD076D60711C2F44842AC513763EEC751
<t: 933069>, mesh_gatt.c, 228, status: 0 len: 30 usable-mtu:66 sar_type: 0
<t: 933118>, proxy.c, 738, TX complete
<t: 949217>, mesh_gatt.c, 946, LENGTH 25
<t: 949219>, mesh_gatt.c, 498, pdu_length :24 p_data_type 0x0
<t: 949222>, proxy.c, 791, RX
<t: 949224>, proxy.c, 674, RX GATT PDU type 0x0, len 24
<t: 949226>, proxy.c, 675, Expected 0x0
<t: 949228>, proxy.c, 677, Data Tx packet: 4ABC8F0D4A1395E8C61A466353D66C252D593857E5B9179F

These are also as part of provisioning process is coming.

The prints you see after Successfully provisioned print is also part of the provisioning process.

It sends composition data, then TTL status and then Sending network transmit data.

All these are part of provisioning is happening and with the custom logic I am doing in my source code will ignore all these transfers.

Hope this is clear.

Any discrepancy please let me know

Thanks and Regards

Sarjoon

[Joakim Jakobsen]

Thank you.

I'll investigate these messages closer, and why they are sent after the provisioning complete flag is set.

sarjoon said:

All these are part of provisioning is happening and with the custom logic I am doing in my source code will ignore all these transfers.

If I understand you correctly, you found a workaround for your "custom check" and ignore these transfers?

Br,
Joakim