Question about : v2.2.4.3 verified as compliant with the CTT #321
Comments
Askidea
changed the title
|
Hi, We test it only with Linux env. We use For testing we use few sample applications: ServerCertification (TCP=1 IPV4=0 SWUPDATE=1 CREATE=1 MNT=1 CLOUD=1 DEBUG=0 V6DNS=1 WKCORE=1) OnboardingTool (TCP=1 IPV4=0 SWUPDATE=1 CREATE=1 MNT=1 CLOUD=1 DEBUG=0) ClientCertification (TCP=1 IPV4=0 SWUPDATE=1 CREATE=1 MNT=1 DEBUG=0 V6DNS=1 WKCORE=1) |
|
@SiMet Thanks for your kind reply. In Android, I'm testing my OCF Client app with v2.2.4.3 or master branch and CTT 2103.0.0.
May I ask for some advice on how to test the next item of CTT? (1) CT1.2.6 RETRIEVE Message with observe indication based on CoAP - NOTIFY (2) CT2.2.7 RETRIEVE Message with observe indication based on CoAP over TCP - NOTIFY If these items are resolved, it is likely that v2.2.4.3 will be verified in the Android environment. My PICS: { |
|
|
(1) CT1.2.6 [Example: server_certification_tests.c] oc_resource_t *platform_resource = oc_core_get_resource_by_index(OCF_P, DEVICE);
(2) CT2.2.7
|
|
I'm not expert in JNI and Swig but there is probably method in Java OCCoreRes.getResourceByIndex which is bound to oc_core_get_resource_by_index. Please see: https://github.com/iotivity/iotivity-lite/blob/master/swig/swig_interfaces/oc_core_res.i |
|
Thanks for your advice. I modified the code based on your advice, and CT1.2.6 passed. |
|
@SiMet For reference, I attach 'client_certification_tests' and my OCfClient-side log in the process of performing TCP GET on the resource.
D: oc_oscore_engine.c <oc_oscore_send_message:775>: Posting INIT_TLS_CONN_EVENT could not find ongoing TCP session for endpoint:coaps+tcp://[fe80:0000:0000:0000:2c3d:ce34:1b17:3760]:49202 |
|
I'm not familiar with Android implementation. Maybe @Danielius1922 could help us or point someone who could help us. |
|
@SiMet, @Danielius1922
|
|
@Askidea: I am sorry, I didn't notice this. I'm not really familiar with Android implementation either, however as far as I'm aware it's almost identical to the Linux v2.2.5.1 port. Your log analysis seems to be on the right track, however I think the OC_CLIENT ifdef is working because the log is always under OC_CLIENT ifdef, and that log occurs in both of the log traces you posted, so that makes me think it is in order. So I think what is failing is this: oc_sec_cred_t *cred =
oc_sec_find_creds_for_subject(&endpoint->di, NULL, endpoint->device);
if (cred && cred->credtype == OC_CREDTYPE_PSK) {It cannot find the PSK certificate. If you look in the log trace of the failing case there is this: Whilst in the successful case the loading of the manufacturer cert chain succeeds. We need to find out why the loading of manufacturer cert chain is failing. Could you please attach the full My OCF Client's Log? Maybe there are some other errors preceding the ones you've posted. |
|
For IPv4, also following lines appeared. But TCP connection initiated successfully (CT 2.2.7). Please refer to log files belows. Look for "Comment by Askidea" for convience. CTT2103_CT2.2.7_master_29ccbf39_IPv4_OCFClient logcat_20221012.txt CTT2103_CT2.2.7_master_29ccbf39_IPv6_OCFClient logcat_20221012.txt |
|
Indeed those errors are also in the IPV4 trace, so they most likely aren't relevant to the problem. What is definitely an issue is this: In the IPV4 logs the TCP connection is established. We don't print the errno sadly, so we don't get the exact reason why connect fails here. The IPV6 address is one of the CTT client endpoints: Maybe the endpoint at [fe80::2c3d:ce34:1b17:3760%19]:49190 wasn't started properly or its not reachable for some reason. The only idea I currently have is to add errno to the logs, so we know why exactly it failed. |
|
Here are the log files. OCFClient_log_android-tcp-logs_20221014.txt CTT_log_android-tcp-logs_20221014.txt And there are compile errors in the branch 'android-tcp-logs' because of a typo, e.g. "ernno". |
|
Sorry about that, I've added the logs but compiled the code without enabling debug logs. I've fixed it in the branch. You've figured it out anyway, so looking at the logs: Error 22 is
Now it's possible that the scope_id value gets zeroed somewhere or it was perhaps never set? At the beginning of the logs I see the following lines I see two link-local addresses there, but no scope_id, though I don't know if the logging functions just ignore it or it is indeed not set. What are you using to print the addresses? And where do the addresses come from, some sort of configuration? If it is |
|
@Danielius1922 I think the In conclusion, CT2.2.7 passed well in IPv6/Secure/TCP. |
|
Great to know! Glad I was able to help. :-) (Before closing this issue I'll first investigate if the conversion from endpoint to string and back preserves the scope_id. I think that would constitute a bug.) |
|
Indeed when converting from a string the scope_id value is not filled (and also the parsing function |
Hello,
I have a few questions regarding the CTT certification.
I saw that v2.2.4.3 was verified to be CTT compatible in tags description. If so, I would like to know in what test environment it was performed at the time of verification. The CTT version will be 2103.0.0, I wonder what the IUT is and what the PICS file contents are.
I am developing OCF Client in the Android app to which the iotivity library is applied, and when I test with any iotivity library version with CTT 2103, several FAIL items occur for all.
Also, depending on the build options (ALL=1) or (CLOUD=0 TCP=0 others=1), the success or failure of the CTT test item may vary slightly.
To summarize the questions:
I would be grateful if someone who knows well about the above could give me some answers. I hope you know that this is very important to me and urgent.
Thanks
The text was updated successfully, but these errors were encountered: