In iotivity-lite v2.2.4.3, UNOWNED multiple devices are not discovered at once, but one or two irregularly in OnboardingTool

[Askidea]

There are the following differences when discovering multiple devices between iotivity-lite v2.2.0 and v2.2.4.3.

(1) v2.2.0 : all devices are discovered by one discovery request in OnBoardingTool MultiDeviceServer (Android) : v2.2.0 <===> OnBoardingTool (Android and Linux) : v2.2.4.3

(2) v2.2.4.3 : devices are discovered one by one for each discovery request MultiDeviceServer (Android) : v2.2.4.3 <===> OnBoardingTool (Android and Linux) : v2.2.4.3

Is this because the specification has changed or is it a code issue? I tested using the Android app samples, MultiDeviceServer and OnBoardingTool at 'swig/apps/oc' directory. Also onboarding_tool binary for Linux shows same result. I chose v2.2.4.3 because it is the latest version verified by CTT.

Can anyone please answer this situation?

[Danielius1922]

@jkralik do you have an idea what might have changed? v2.2.0 is before my time, so I'd have to look in commit history.

[Askidea]

I guess that perhaps the discovery mechanism for the '/oic/sec/doxm' resource in the OCFServer stack has changed as the upgrade to v2.2.4.3 is made (v2.2.5.1 also).

• method call hierarchy (UNOWNED device discovery) OnBoardingTool --> OcObt.discoverUnownedDevices() ( Android, Java ) ------> discover_unowned_devices() (oc_obt.c) --> oc_do_ip_multicast("/oic/sec/doxm", "owned=FALSE", ...) ===========> MultiDeviceServer (10 devices added)

It seems that this issue occurs when registering two or more devices in one app. If an app has one device (server), needless to say that's ok.

When discovery was performed on '/oic/res' or 'oic/d', all devices were discovered. (in my case, 10 devices), as follows (1) OcUtils.doIPMulticast("/oic/res", ...) (2) OcUtils.discoverAllDevices() --> OcUtils.doIPMulticast("/oic/d", ...) (3) OcObt.discoverOwnedDevices() --> discover_owned_devices() --> oc_do_ip_multicast("/oic/res", "rt=oic.r.doxm", ...)

I think it is necessary to check the iotivity stack code that handles the doIPMulticast request to the /oic/sec/doxm resource. But, I'm not sure because I don't understand all code level of Iotivity stack.

[Askidea]

Build options for iotivity-lite.jar, iotivity-lite-jni.so

...port/android$ make NDK_HOME=~/toolchains/ndk18-android-arm-23 ANDROID_API=23 DEBUG=1 CLOUD=1 SECURE=1 IPV4=1 TCP=1 PKI=1 DYNAMIC=1 JAVA=1 IDD=1 OSCORE=1 MNT=1

[Danielius1922]

@Askidea if I understand correctly what @jkralik told me then this is correct behavior and reflects a change in specification. Though I wasn't able to pinpoint the precise place in some document from https://openconnectivity.org/developer/specifications where it is mentioned, maybe @ondrejtomcik can help?

[jkralik]

@Askidea You use MultiDeviceServer with 10 devices, right? It is not 10 single-device servers. For MultiDeviceServer - it is the same issue #300.

Regardles discover owned devices - [OCF Security Specification v2.2.5] (https://openconnectivity.org/specs/OCF_Security_Specification_v2.2.5.pdf) section 7.3.1:

[Askidea]

When iotivity-lite v2.2.4.1 is applied, all unowned OCFServer devices in the MultiDeviceServer are discovered at once in the OnBoardingTool. JW OTM is also applied well to each device in order.

[Askidea]

@Askidea You use MultiDeviceServer with 10 devices, right? It is not 10 single-device servers. For MultiDeviceServer - it is the same issue #300.

Regardles discover owned devices - [OCF Security Specification v2.2.5] (https://openconnectivity.org/specs/OCF_Security_Specification_v2.2.5.pdf) section 7.3.1:

@jkralik Anyway, if OCF platform can contain multiple OCF Servers(logical devices), it seems right that each OCF server(unowned state) should respond to the multicast request designated as "owned=false". Is this right?