Dear Muhammad,
Thank you for your comment.
Now it works!
"testdata" was magic keyword!
By the way, could you help me solve another issue?
I have posted below mail about virtual resource "/oic/d" before.
but, nobody has replied to this mail yet.
Do you know someone who can handle this issue?
------------------------------------------------------------
Hello folks,
I am testing iotivity server codes on arduino with ITT now.
While I'm testing this, I found some problem;
The IoTivity server for "arduino" can't handle virtual resource (/oic/d).
When client sends request like below, server just returns error (4.00;
bad request).
===================
TE --------> Get Request --------> DUT
Protocol Type : COAP
Destination URI : 192.168.100.185:55555/oic/d
Confirmable Type : True
Query : if=oic.if.r
===================
I tried to find where the problem happened and I found:
Since "SRMInitSecureResponses()" is not called while OCInit() is running,
server couldn't get device id and finally it failed to send response to
request for "/oic/d".
<ocstack.c>
initResources() {
...
#ifndef WITH_ARDUINO
if (result == OC_STACK_OK )
{
result = SRMInitSecureResources();
}
#endif
...
}
After removing preprocessor directives, server returns response correctly.
Is this a bug? or is there some reason?
Thanks & regards
------------------------------------------------------------
thanks & regards,
- Kevin
On 04/25/2016 01:49 PM, Muhammad Mushfiqul Islam wrote:
>
> Dear Mr. Kevin,
>
> Looks like there was not enough information provided in the
> DUTDescriptor.json file to send the POST request. It was lacking testdata.
>
> Please use the DUTDescriptor I am attaching instead.
>
> - Thanks & Regards,
>
> Mushfiqul Islam Antu
>
> ------- *Original Message* -------
>
> *Sender* : ???<rune at etri.re.kr>
>
> *Date* : Apr 25, 2016 11:55 (GMT+09:00)
>
> *Title* : RE: [cftg] Re: [dev] Question regarding ITT test case
>
> Dear Muhammad,
>
> Thank you for your help!
>
> I attached "DUTDescriptor.json, log.html, *.pcapng file".
> It includes two test cases: CT1_2_3::1, CT1_2_3::5.
> CT1_2_3::1 failed, however I don't know reason.
> CT1_2_3::5 succeeded, but I don't see "POST" message in *.pcapng file.
>
> I hope you will find the reason, please... :-)
>
> Thanks & regards,
>
> - Kevin
>
>
> ------------------------------------------------------------------------
> *From:* cftg at openconnectivity.org [cftg at openconnectivity.org] on
> behalf of Muhammad Mushfiqul Islam [i.mushfiq at samsung.com]
> *Sent:* Friday, April 22, 2016 9:44 PM
> *To:* Joo-Chul Lee
> *Cc:* iotivity-dev at lists.iotivity.org; cftg at openconnectivity.org
> *Subject:* [cftg] Re: [dev] Question regarding ITT test case
>
> Dear Mr. Kevin,
>
> Can you please provide the wireshark logs and the html
> report generated in the "bin/linux/ConformanceTestTool/testreport"
> folder? Then I would be able provide you better help to understand
> what is going wrong.
>
> Also, have you configured the DUTDescriptor.json file according to
> your testing device?
>
> By the way, even though it is not mentioned in the test procedure, ITT
> first sends GET request to resources prior sending POST request, to
> ensure it is trying to update the resource representation with a new
> value.
>
> - Thanks & Regards,
>
> Mushfiqul Islam Antu
>
> ------- *Original Message* -------
>
> *Sender* : Joo-Chul Lee<cms.rune at gmail.com>
>
> *Date* : Apr 22, 2016 16:56 (GMT+09:00)
>
> *Title* : [dev] Question regarding ITT test case
>
> Hello, folks
>
> I'm currently testing our codes with "ITT (IoTivity Test Tool)
> (https://wiki.iotivity.org/conformance_test_tool)".
> While I'm running ITT test case CT1_2_3, I face weird situation.
>
> Below is test description of CT1_2_3::1
> =========================================
> ... |procedure |1. CTT sends a unicast RETRIEVE request message
> (i.e. CoAP GET) to the IUT to the first supported OIC Resource. |
> ... |procedure |2. IUT receives the request message and sends a
> unicast response message to the CTT. |
> ... |procedure |3. CTT creates a list of current values for each
> supported Property. |
> ... |procedure |4. CTT sends a unicast CON UPDATE request
> message (i.e. CoAP POST) to the IUT with no OIC Resource Interface
> specified to the first writable supported Property (excluding common
> Properties rt, if, p, n, etc.) on the first supported OIC Resource. The
> Property value to be written must be valid (e.g. within the allowable
> range, valid enumeration value, etc.) and must be different than the
> current Property value. |
> ... |procedure |5. IUT receives the request message and verifies
> that it is valid (i.e. Can the Property be updated? Does the OIC
> Resource Interface support UPDATE requests? Etc.) |
> ... |procedure |6a. If the request message is valid, the IUT
> shall update the target OIC Resource Property as requested and send a
> successful UPDATE response message to CTT using the appropriate OIC
> Resource Interface. |
> ... |procedure |6b. If the request is not valid, the IUT shall
> not update the target OIC Resource Property and shall send an
> appropriate error message to CTT.. |
> ... |procedure |7. CTT receives the response message and caches
> it for later evaluation. |
> ... |procedure |8. CTT sends a unicast CON RETRIEVE request
> message (i.e. CoAP GET) to the first supported OIC Resource of the IUT. |
> ... |procedure |9. IUT receives the request message and sends a
> RETRIEVE response message to CTT. |
> ... |procedure |10. CTT receives the response message and caches
> it for later evaluation. |
> ... |procedure |11. Repeat steps 1 to 10 for all other writable
> Properties supported by the OIC Resource. |
> ... |procedure |12. Repeat steps 1 to 11 for all other OIC
> Resources supported by the IUT. |
> ... |post_condition |None |
> ... |expected| Check 1. The IUT shall indicate support for CBOR
> and payload encoding shall use CBOR unless a different content type
> (i.e. JSON) has been negotiated (8.1 CRUDN Overview [CORE], 7.2.1.2
> Resource interface property definition [CORE]). |
> ... |expected| Check 3. The IUT shall send a response code of
> "2.04 Changed" (for CoAP) when the Property value has been successfully
> updated in Step 6a (8.1 CRUDN Overview [CORE], 12.2.1 Mapping of CRUDN
> to CoAP. Overview [CORE]). |
> ... |expected| Check 4. The Property(s) and its value from the
> UPDATE request message shall be included in the response from Step 6a
> (5.2.1.2 Update behavior [RT]. |
> ... |expected| Check 5. The value UPDATED in Step 4 and the
> value RETRIEVED in Step 10 shall be the same (8.4.2 Update. Processing
> by the OIC Server [CORE]). |
> ... |expected| Check 7. In the absence of an "if" query the
> Default Interface shall be used (7.1.4.2.3 OIC Resource Interface
> [CORE]). |
> ... |expected| Check 10. Every message with a payload body shall
> contain a Content-Format option with a numeric value from Table 32
> (12.2.3 Content Type negotiation [CORE]). |
> =========================================
>
> According to the test description of CT1_2_3::1, CTT (I mean ITT) will
> send CON UPDATE request message (== CoAP POST message), however I can't
> see any POST message, rather I could only find GET messages.
>
> Is this situation ok, or am I doing something wrong about this?
>
> Thanks & regards
>
> - Kevin
>
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Joo-Chul Kevin Lee
Service Standard Research Team, PEC, ETRI
161 Gajeong-dong, Yuseong-gu, daejon, 305-700, KOREA
E-mail:rune at etri.re.kr/cms.rune at gmail.com Tel: +82-42-860-1021
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160425/5dfd2ab1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 13168 bytes
Desc: not available
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160425/5dfd2ab1/attachment.gif>
