something wrong with JSON format in Copper

[Shan Desai]

Hello Mr. Kovatsch,
I am using Zolertia Z1 motes which implement resources like information of parent node, and routing information using GET request.
the format is

{"parent": eui of parent, "pref": true, etx: aaa} for parent 

for routing is

 {"dest": mac of destination, "next": next hop address}

there are some other resources too on the CoAP.
Every time try getting a GET for Parent or route info Copper starts running into a like a infinite loop state while showing only a certain characters of requested JSON format.

the code has been written using erbium and there seems to be no issue when implemented using a different implementation like SMCP. Could there be a potential glitch in Copper when parsing JSON?

would like you help on this matter.
for my implementation with a complete README --> (https://github.com/shantanoo-desai/coap-wsn)
(Note: I checked the implementation out by directly connecting a border router to my linux PC and though the resources are discovered and TEXT_PLAIN formats are returned there is only a problem with JSON formating.)

thank you for the plugin though, it is fun to play with Copper.

Regards
Shan

[Matthias Kovatsch]

I wrote your JSON to coap://californium.eclipse.org:5683/large-update and when I GET it with Copper, I have no issues in the current version. Could you provide a wireshark trace? Maybe also paste the exact payload here.

[Shan Desai]

hi Mr. Kovatsch,
This is the PCAP of the Issue I was talking about
https://drive.google.com/file/d/0B1qhSdvn56atcU5BbHIxOEsxNnc/view?usp=sharing
(Captured using Wireshark Version 1.12.3 (v1.12.3-0-gbb3e9a0 from master-1.12))

Refer to the last part of the pcap since that is where the trouble is. The initial packets are the "handshake signals" between the pc's ethernet port and the raspberry pi

this snapshot shows that the well-known core is discovered perfectly:

this is when I do the following

GET /rplinfo/parents?index=0

Setup: 1 Zolertia Z1 mote as coap-server
1 Zolertia Z1 mote as slip radio connected to Raspberry Pi running the 6lbr from CETIC
Packet capturing on ethernet eth0 port
and using Private Mozilla Firefox window not the normal one.

the other side of the gnome-terminal is a simple program that accepts the POST of the sensor and sends CON back to sensor.

I am not sure why this could be happening, I am sceptical if I should use Copper on the firefox Private window, but I don't think that should be a problem or would it?

Thanks again Mr. Kovatsch.
Regards
Shan

[Matthias Kovatsch]

The pcap shows that the server keeps sending the first block despite increasing the block number. Hence, the problem lies in your resource implementation. In your parents_handler() C-code, I cannot see you using the offset to generate the right block...

[Shan Desai]

Hi Matthias,
I figured it out. Thanks. Actually the *offset wasn't required at all. Hence I removed it an now I get the rendered JSON form of my data. thank you for pointing it out.