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

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

sarjoon — Wed, 06 Jul 2022 08:02:19 GMT

Hello Joakim,

As of now,

Once after getting the Provisioned Successfully message and flag set, planning to do a workaround by starting a timer and wait for 20 seconds to finish off the Remaining Configurations

Till then all packets will be allowed and will not enable my Custom Logic check.

But this way may not be a ideal one. So let me know for any steps that I can consider as generic and proper.

Thanks and Regards,

Sarjoon.

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

Joakim Jakobsen — Tue, 28 Jun 2022 21:12:46 GMT

Thank you.

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

[quote user="sarjoon"]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.[/quote]

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

Br,
Joakim

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

sarjoon — Fri, 24 Jun 2022 05:47:54 GMT

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

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

Joakim Jakobsen — Thu, 23 Jun 2022 17:46:06 GMT

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

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

sarjoon — Thu, 23 Jun 2022 08:51:59 GMT

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.

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

Joakim Jakobsen — Thu, 23 Jun 2022 06:03:39 GMT

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.

[quote user="sarjoon"]There are still few transfer been happening with Network PDU type.[/quote]

What kind of transfer are you seeing?

Br,
Joakim

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

sarjoon — Wed, 22 Jun 2022 14:39:57 GMT

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

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

Joakim Jakobsen — Wed, 22 Jun 2022 14:17:44 GMT

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