The sdk cannot access the network

[253242935]

Version

4.6.1 (latest)

Ask the question

iOS users cannot access the network using the nRF Mesh APP, but Android users can access the network using the nRF Mesh APP

Relevant log output

Connecting to VM40S-1BDC27...
Connected to VM40S-1BDC27
Discovering services...
Service found
Discovering characteristics...
Data In characteristic found
Data Out characteristic found
Enabling notifications...
Data Out notifications enabled
GATT Bearer open and ready
Requesting Provisioning Capabilities
Sending Provisioning Invite (attention timer: 5 sec)
-> 0x030005
<- 0x03010100010000000000000000
Device Capabilities: Number of elements: 1
Algorithms: BTM ECDH P256 CMAC AES128 AES CCM
Public Key Type: None
OOB Type: None
Output OOB Size: 0
Output OOB Actions: None
Input OOB Size: 0
Input OOB Actions: None received
Provisioning Capabilities received
Provisioning started
Sending Provisioning Start (algorithm: BTM ECDH P256 CMAC AES128 AES CCM, public key: No OOB Public Key, authentication method: No OOB)
-> 0x03020000000000
Sending Provisioner Public Key (0x97EFEE7FA191F1E6E99CD21EAECF87AE093E6424ECF5E35C88CAC865D56E874B2067E3C77D2BD50E9CFA1324ABDFEF1AED32857D8184CF418F983360FDB645DE)
-> 0x030397EFEE7FA191F1E6E99CD21EAECF87AE093E6424ECF5E35C88CAC865D56E874B2067E3C77D2BD50E9CFA1324ABDFEF1AED32857D8184CF418F983360FDB645DE
<- 0x0303D178A1BFB785CF02CC740AFF3D08E331F969A7E53EF336DD2E7F30BB63D41634CE60BEF8C7430D1D664B7B3443DEA50994B941E30857D3B5928A9731C52E5D96
Device Public Key (0xD178A1BFB785CF02CC740AFF3D08E331F969A7E53EF336DD2E7F30BB63D41634CE60BEF8C7430D1D664B7B3443DEA50994B941E30857D3B5928A9731C52E5D96) received
Sending Provisioner Confirmation (0x5AAF2717FEBA53D6B012DDA88819C014)
-> 0x03055AAF2717FEBA53D6B012DDA88819C014
<- 0x03055D4DBB0B8A912647155782592B1895E4
Device Confirmation (0x5D4DBB0B8A912647155782592B1895E4) received
Sending Provisioner Random (0x270E5B88D2F4099B23A4080E83BA30A4)
-> 0x0306270E5B88D2F4099B23A4080E83BA30A4
<- 0x0306F30661E1153DC7889D674F153ACF9E2A
Device Random (0xF30661E1153DC7889D674F153ACF9E2A) received
Sending Encrypted Provisioning Data (0x3B82A838AA532ED2856F8375C4C8F6E9947E142C340B70DFD04DA68C1066644CD1)
-> 0x03073B82A838AA532ED2856F8375C4C8F6E9947E142C340B70DFD04DA68C1066644CD1
<- 0x0308
Complete received
Provisioning complete
Cancelling connection...
Disconnected from VM40S-1BDC27
Provisioner is ready
Central Manager state changed to .poweredOn
Connecting to VM40S-1BDC27...
Connected to VM40S-1BDC27
Discovering services...
Service found
Discovering characteristics...
Data In characteristic found
Data Out characteristic found
Enabling notifications...
Data Out notifications enabled
GATT Bearer open and ready
Cancelling connection...
XPC connection invalid
Disconnected from VM40S-1BDC27
XPC connection invalid
Central Manager state changed to .poweredOn
Connecting to VM40S-1BDC27...
Connected to VM40S-1BDC27
Discovering services...
XPC connection invalid
XPC connection invalid
XPC connection invalid
Warning once only: UITableView was told to layout its visible cells and other contents without being in the view hierarchy (the table view or one of its superviews has not been added to a window). This may cause bugs by forcing views inside the table view to load and perform layout without accurate information (e.g. table view bounds, trait collection, layout margins, safe area insets, etc), and will also cause unnecessary performance overhead due to extra layout passes. Make a symbolic breakpoint at UITableViewAlertForLayoutOutsideViewHierarchy to catch this in the debugger and see what caused this to occur, so you can avoid this action altogether if possible, or defer it until the table view has been added to a window. Table view: <UITableView: 0x10b18dc00; frame = (0 88; 820 1092); clipsToBounds = YES; autoresize = W+H; tintColor = UIExtendedSRGBColorSpace 0 0.466667 0.784314 1; gestureRecognizers = <NSArray: 0x114a38600>; backgroundColor = <UIDynamicSystemColor: 0x10b10fa40; name = systemGroupedBackgroundColor>; layer = <CALayer: 0x114b71020>; contentOffset: {0, 0}; contentSize: {0, 0}; adjustedContentInset: {0, 0, 0, 0}; dataSource: <nRF_Mesh.NodeViewController: 0x114a0c000>>
Service found
Discovering characteristics...
Data In characteristic found
Data Out characteristic found
Enabling notifications...
Data Out notifications enabled
GATT Bearer open and ready
Error: No GATT Proxy connected or no common Network Keys

[philips77]

After

Enabling notifications...
Data Out notifications enabled
GATT Bearer open and ready

the connected Proxy Node should senda Secure Network beacon, or a Private Beacon to inform the client about the Network ID, IV Update flag and Key Refresh flag. Without it, the client does not know which Network Key to use on this connection.

Do you have a logger delegate set for the GattBearer? It should log a message starting from -> when a notification is received.

[philips77]

This is what I get in Console:

13:01:23.007787+0100	Bearer	Central Manager state changed to .poweredOn
13:01:23.008699+0100	Bearer	Connecting to Mesh DFU Distributor 54L 2.0...
13:01:25.295375+0100	Bearer	Connected to Mesh DFU Distributor 54L 2.0
13:01:25.295460+0100	Bearer	Discovering services...
13:01:25.475514+0100	Bearer	Service found
13:01:25.475595+0100	Bearer	Discovering characteristics...
13:01:25.477677+0100	Bearer	Data In characteristic found
13:01:25.477835+0100	Bearer	Data Out characteristic found
13:01:25.477988+0100	Bearer	Enabling notifications...
13:01:25.537674+0100	Bearer	Data Out notifications enabled
13:01:25.537739+0100	Bearer	GATT Bearer open and ready
13:01:25.537798+0100	Bearer	<- 0x010100C00EB07AF59889E500000000F1F0BAE4B0F17900
13:01:25.537856+0100	Bearer	<- 0x010100DE3E35AB61D19F5D00000000BCD9A6EBD1A23C0C
13:01:25.571464+0100	Network	Secure Network beacon (Network ID: 0xC00EB07AF59889E5, IV Index: 0 (normal operation), Key Refresh Flag: false) received (authenticated using key: Primary Network Key (index: 0))
13:01:25.571494+0100	Network	Secure Network beacon (Network ID: 0xDE3E35AB61D19F5D, IV Index: 0 (normal operation), Key Refresh Flag: false) received (authenticated using key: Network Key 2 (index: 1))
13:01:25.571521+0100	Network	Discarding beacon for secondary network (key index: 1)
13:01:25.572437+0100	Proxy	New Proxy connected
13:01:25.583151+0100	Proxy	Sending SetFilterType(filterType: Accept List) from: 0x3366 to: 0000
13:01:25.586720+0100	Network	Sending Control Message (opCode: 0x00, data: 0x00)
13:01:25.593435+0100	Network	Sending Network PDU (ivi: 0, nid: 0x69, ctl: 1, ttl: 0, seq: 2457, src: 0x3366, dst: 0x0000, transportPdu: 0x9720, netMic: 0xD463074C49B120E3) encrypted using Network Key 2 (index: 1)
13:01:25.593640+0100	Bearer	-> 0x0269B9406B43E42F54449720D463074C49B120E3
13:01:25.653347+0100	Bearer	<- 0x026991484FB90C15D49AA658917C3C6B06616889C65C
13:01:25.658842+0100	Network	Network PDU (ivi: 0, nid: 0x69, ctl: 1, ttl: 0, seq: 388, src: 0x3354, dst: 0x0000, transportPdu: 0xA658917C, netMic: 0x3C6B06616889C65C) received
13:01:25.658870+0100	Network	Control Message (opCode: 0x03, data: 0x000000) received (decrypted using key: Network Key 2 (index: 1))
13:01:25.664625+0100	Proxy	FilterStatus(filterType: Accept List, listSize: 0) received from: 0x3354 to: 0x0000
13:01:25.668205+0100	Proxy	Sending AddAddressesToFilter(addresses: Set([13159, 65535, 13158, 49152])) from: 0x3366 to: 0000
13:01:25.668288+0100	Network	Sending Control Message (opCode: 0x01, data: 0x33663367C000FFFF)
13:01:25.670242+0100	Network	Sending Network PDU (ivi: 0, nid: 0x69, ctl: 1, ttl: 0, seq: 2458, src: 0x3366, dst: 0x0000, transportPdu: 0x2DC8638C2FF7D4D27E, netMic: 0x0381FBFA20FEC527) encrypted using Network Key 2 (index: 1)
13:01:25.670353+0100	Bearer	-> 0x0269B9B3BCE6F8DAFBED2DC8638C2FF7D4D27E0381FBFA20FEC527

[leodim21]

For the next person who runs into this issue: after device provisioning and reconnecting to the proxy device, you need to wait not for the bearerReady event, but for the proxy device’s network keys to appear. You can choose your own implementation, but the following approach worked for me

    func startConfig() {
        // Wait for the Proxy to be ready and to know the required Network Key before starting configuration.
        Task { [weak self] in
            guard let self = self else { return }
            let timeout: TimeInterval = 10.0
            let pollInterval: TimeInterval = 0.2
            let deadline = Date().addingTimeInterval(timeout)
            
            func proxyKnowsKey() -> Bool {
                guard let netKey = self.meshNetwork.networkKeys.first else { return false }
                return self.meshManager.proxyFilter.proxy?.knows(networkKey: netKey) == true
            }
            
            // Wait for the proxy to appear.
            while self.meshManager.proxyFilter.proxy == nil && Date() < deadline {
                try? await Task.sleep(nanoseconds: UInt64(pollInterval * 1_000_000_000))
            }
            guard self.meshManager.proxyFilter.proxy != nil else {
                print("conf::Proxy is not connected within timeout, aborting configuration start.")
                return
            }
            // Wait until the proxy knows the Network Key.
            while !proxyKnowsKey() && Date() < deadline {
                try? await Task.sleep(nanoseconds: UInt64(pollInterval * 1_000_000_000))
            }
            guard proxyKnowsKey() else {
                print("conf::Proxy does not know the required Network Key within timeout, aborting configuration start.")
                return
            }
            // All set — request Composition Data.
            self.getCompData()
        }
    }

P.S. Since in the nRF Mesh App the configuration is not performed automatically, I couldn’t find any of the suggested ways to do this using the SDK (please correct me if I’m wrong).

[philips77]

You may also assign a delegate to ProxyFilter and await proxyFilterUpdateAcknowledged:

https://github.com/NordicSemiconductor/IOS-nRF-Mesh-Library/blob/9eacb787982980fb28a85d0bd2f805909885e84e/Library/ProxyFilter.swift#L222-L223

https://github.com/NordicSemiconductor/IOS-nRF-Mesh-Library/blob/9eacb787982980fb28a85d0bd2f805909885e84e/Library/ProxyFilter.swift#L92