iotivity-constrained
iotivity-constrained copied to clipboard
iotivity
OCF Zephyr port over Bluetooth 6LoWPAN is unstable and more resource hungry
We are using iotivity-contrained over 6lowpan running on Zephyr, ffter upgrading from Zephyr 1.7 to 1.8, it seems that Ocf has become unstable, specifically on the server side, the registered sources were not showing up on the network, and server/client would randomly crash. After investigating and playing around with Zephyr settings, it seemed that we have to manually increase CONFIG_NET_BUF_DATA_SIZE to help fix most of these issues. By default this is not set, and it will default to 128, but with Zephyr 1.8, we have to increase this value to 256 (or 512 say if you are registering multiple resources). I think the problem is that all the registered resources being sent out as one giant json string over BLE, and Zephyr BLE stack is not capable of handling such large data.
iotivity-constrain should also print some kind of error when it is failing to allocate messages or sending out those packets, since it's very difficult to know what's going on behind the scenes over BLE.
Hello @jimmy-huang
Just a few quick points:
-
The prj*conf files under port/zephyr are meant to be samples and mostly indicative of where things go. An application developer is supposed to modify them as necessary for their application. For that matter, even config.h needs to be updated to meet an application’s needs. So, feel free to bump up the BLE buffer size for your application, and also to submit a patch to the sample configs if you think it would be absolutely necessary.
-
As for being resource hungry, the OCF 1.0 schema for the discovery response just spits out more information compared to OIC 1.1 standard. The only way to keep response sizes small is to discover specific resource types by passing an rt query.
-
The stack currently prints out ”buffer: No free TX/RX buffers!" in a DEBUG build, when it cannot allocate a message structure.
@kmaloor Are you still maintaining the Zephyr samples? I tried the latest prj_bt.conf and it no longer works with Zephyr 1.9
@jimmy-huang Well, the extent of my testing is ensuring that server_zephyr_qemu can talk with client_linux via the tap interface. I don't typically do more, as much of my focus on the rest of the stack. You could try running the exact same test over bt and work your way from there. Feel free to submit patches, if required.