Hi Trond, On further testing, it now works. I must have not properly flashed my board. Sorry for the noise and thanks for the fix. Steve

Hi Trond, The patch didn't fix the problem. I've attached the meshd and zephyr debug output. Steve MESHD Nov 3 03:55:38 mesh0 bluetooth-meshd[21346]: mesh/node.c:dev_key_send_call() DevKeySend Nov 3 0

I bisected this to eca014115 Bluetooth: Mesh: Isolate cryptographic material I suspect segmented messages. The successful sequence number starts at 2 whereas the failing one starts at 1. I'm not famil

Hi Emil, Thanks for the files. Neither work on my boards. I suspect my silicon may be too old. I've had the boards for a couple of years. The build/date codes on both boards are: QIAAAA/1716AK. The la

Hi Johann, Could you email me a zephyr.hex of a USB app that enumerates? With it I can eliminate my nrf52 boards as the problem. Thanks, Steve

Hi Carles, This is the first time I've tried the nrf usb so I have no "working version" to compare. West version: v0.6.3 zephyr-sdk-0.10.3 The desc_section test was build with: west build -b nrf52840_

All the USB samples and tests fail to enumerate. git HEAD 77006e896 Output from the desc_sections test is below: Nov 27 09:11:57 nm-ws kernel: [520538.130145] usb 7-2: USB disconnect, device number 65

Hi Johan, Works for me. Provisioning completes on samples/bluetooth/mesh and connects for configuration. The identity connection had previously failed. It's curious that the SILabs provisioner reporte

#meshctl #bluetoothmesh

Hi, I had a chance to look at this further. More at the bottom. It doesn't appear that bt_mesh_proxy_identity_enable() gets called in prov.c:proxy_data(). The earlier call to bt_mesh_provision() close

#meshctl #bluetoothmesh

Hi Carles, The test now builds and runs successfully. Thanks, Steve

From bisect dts: bindings: add support for the flash driver name ***** BOOTING ZEPHYR OS v1.10.99 - BUILD: Jan 27 2018 10:01:12 ***** Running test suite nffs_fs_basic_test ============================

Hi Ashish Steve

Hi Ashish, If the target of heartbeat publish is 0077 (meshctl's unicast address), it will display the returned status. Steve

Hi Ashish, The board name is nrf52840_pca10056 That works on my boards. Steve

I agree. Just a few nodes with relay enabled and a nominal TTL of 7 would create a lot of traffic. The retransmit count and period are hardwired to 2 and 200 ms (4 * 50ms) respectively in meshctl. I'l

Hi Johan, Yes, I've conflated sequence number and transaction id. It's clear now. Thanks for the clarification, Steve

Hi Johan, These are publish retransmits. However, the transaction ID's in the received messages are all the same. It's the "trans_id" field in the log in my earlier post. An upper layer, like my serve

Is replay protection implemented? The reason for the question is that my server is receiving both the initial publish transmit as well as the subsequent retransmits. The server is at 0x0100 and is sub

Hi Charles, I started with 2 Nitrogens and attempted to connect to them with a CSR dongle. I received no unprovisioned beacons. I fired up the ubertooth sniffer and didn't see any traffic either. My c

Hi Gene, You can program it with drag/drop CMSIS bootloader's disk, pyocd or openocd over USB. The "make flash" uses pyocd and worked fine for me. The softdevice is only the Nordic SDK. Zephyr's Bluet