Hi Max,

I met a similar issue of the data size difference after doing “Post request”.

But the problem of mine is the size of received pdu of “Get response” will be 
larger than regular after a “Post request” been performed.

Client: Android(2.0.1)
Server: OCSample/OCServer(2.0.1)

Step1. Discovery [OK]
Step2. Get [OK]…Get [OK]…Get [OK]…
Step3. Post [OK]
Step4. Get [NG], Android client crashed.

The received pdu data of both cases are list below.
The main difference appeared just after token bytes.
received pdu data [OK]:
68 45 EF 0E 57 66 4D B2 3C 91 8A EC 82 01 00 31
61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08 00 E1
F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C 69 67
68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E 62 61
73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E 72 77
65 70 6F 77 65 72 18 32 FF

Msgid: EF 0E
Token: 57 66 4D B2 3C 91 8A EC
Difference: 82 01

received pdu data [NG]:
68 45 7A EC 4F CA 0D 98 6A 23 A1 C4 84 E8 3B 01
00 31 61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08
00 E1 F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C
69 67 68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E
62 61 73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E
72 77 65 70 6F 77 65 72 18 32 FF

Msgid: 7A EC
Token: 4F CA 0D 98 6A 23 A1 C4
Difference: 84 E8 3B 01

Android log
A/art: art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: input 
is not valid Modified UTF-8: illegal start byte 0xa8

--
However, if I use Android Client(2.0.1) + Android Server (2.0.1),  “Discovery”, 
“Get”, “Post” are all OK.

Best Regards,
ChiaYu

From: iotivity-dev@lists.iotivity.org [mailto:iotivity-dev@lists.iotivity.org] 
On Behalf Of Max
Sent: Wednesday, July 03, 2019 5:01 AM
To: iotivity
Subject: [dev] Payload issue after upgrading to IoTivity 2.0

Hi,

I am in process of upgrading my Android server device from IoTivity 1.3.1 to 
2.0 (using the latest 'master').

I face a weird issue that I never saw with the previous version.

"Randomly", the response to POST request to one of my resources - is wrapped as 
an array.
Normally, the response looks like:
 {"value":false,"x.com.sure.a.b":"abc"}

In the buggy scenarios, appearing randomly, the data is reported by the client 
as:
 [{"value":false,"x.com.sure.a.b":"abc"}]
So the data inside the array is right, but the array [] should not be there!

Unfortunately, the only way I was able to reproduce the issue (from time to 
time) is via running a specific test of the Certification Test Tool. I failed 
to reproduce the bug "manually".

I wonder what can be the cause of such a behavior, and how to debug it further.

I tried to look into the logs, and indeed I saw that in the "buggy" responses, 
same code generates 60 bytes, instead of 59 bytes.

The proper response (59 bytes) looks in the logs like:

07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0000:  44 44 3d a7 32 dc 99 23 b9 73 
74 62 53 77 69 74  DD=.2..#.stbSwit
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 
e1 f6 e2 c0 ff bf  ch.'............
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0020:  65 76 61 6c 75 65 f4 6e 78 2e 
63 6f 6d 2e 73 75  
evalue.nx.com.su<https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fevalue.nx.com.su&umid=1c6ea5a5-a514-46a3-a61e-a762a3e3ac61&auth=bd015149f2efa238c1c2b9bffc7d372c2eb7e6a6-344a707534c6b1f358bc3e1575ba09756c5684f3>
07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0030:  72 65 2e 61 2e 62 63 61 62 63 
ff                 re.a.bcabc.

The buggy response (60 bytes) looks in the logs like::

07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0000:  54 44 b8 1b 3b ca b1 13 b9 73 
74 62 53 77 69 74  TD..;....stbSwit
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0010:  63 68 12 27 10 e2 06 ec 08 00 
e1 f6 e2 c0 ff 81  ch.'............
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0020:  bf 65 76 61 6c 75 65 f5 6e 78 
2e 63 6f 6d 2e 73  .evalue.nx.com.s
07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0030:  75 72 65 2e 61 2e 62 63 61 62 
63 ff              ure.a.bcabc.

Is there any method to analyze the payload? I tried to "paste" to 
cbor.me<http://cbor.me> site - no success.

Any hint on how to analyze the data and identify the "root cause" is highly 
appreciated.


Thanks in advance
Max


Max Kholmyansky
CTO - SURE Universal Ltd.
http://www.sureuniversal.com<https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fwww.sureuniversal.com&umid=1c6ea5a5-a514-46a3-a61e-a762a3e3ac61&auth=bd015149f2efa238c1c2b9bffc7d372c2eb7e6a6-b1814f0dece526a3f0aba204ef3f411b9541712e>







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10235): 
https://lists.iotivity.org/g/iotivity-dev/message/10235
Mute This Topic: https://lists.iotivity.org/mt/32290813/21656
Group Owner: iotivity-dev+ow...@lists.iotivity.org
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to