nanocoap_vfs: add nanocoap_vfs_put()

[benpicco]

Contribution description

This adds a function to upload a file from VFS to a CoAP server via block-wise PUT request.

Testing procedure

You can test this with aiocoap-fileserver -w:

download a file from the CoAP server

> ncget coap://[fe80::2454:cfff:fea7:4598]/LICENSE
Saved as /nvm0/LICENSE

upload the file again under a different name

> ncput /nvm0/LICENSE coap://[fe80::2454:cfff:fea7:4598]/LICENSE-2
Saved to coap://[fe80::2454:cfff:fea7:4598]/LICENSE-2

the files should be identical

$ md5sum LICENSE*
a4ce26a8dcc018faa99a6cd08cbcd1c3  LICENSE
a4ce26a8dcc018faa99a6cd08cbcd1c3  LICENSE-2

Issues/PRs references

depends on #17937, #17960, #17958

[fabian18]

Two nitpicks inline. PUTting and re-GETting a file works well, also with BWT.

[fabian18]

Something I have not noticed before. The first transfer goes well, but during the second or sometimes the third, the client seems to send the blocks twice and sys/net/application_layer/nanocoap/sock.c:187 fires.
nanocoap_vfs-put.pcapng.txt

[benpicco]

Uh good catch!
Is that with coap-server and netdev_tap?
(btw: you can run Wireshark traces directly if you run them through gzip and Wireshark understands to open .pcapng.gz files)

[fabian18]

No netdev_tap but an Ethernet connection between board and PC and CFLAGS += -DCONFIG_GNRC_IPV6_NIB_ARSM=1. In nanocoap_sock_request_cb(), data is not sent after the first call to sock_udp_sendv() and sock_udp_recv_buf() returns a timeout. I don´t know why, yet.

[fabian18]

(btw: you can run Wireshark traces directly if you run them through gzip and Wireshark understands to open .pcapng.gz files)

Thanks for the hint.

[benpicco]

Hm maybe we have a bug in gnrc_sock. I see something similar with SUIT update when routing it via an intermediate RIOT node, but that might also be something else - still investigating.

[benpicco]

When I tried to reproduce this on same54-xpro it would crash because it ran out of stack space - might that be the issue here?

[fabian18]

Stack size is not the problem. I also had to increased stack sizes with:

CFLAGS += -DTHREAD_STACKSIZE_MAIN=2*THREAD_STACKSIZE_LARGE
CFLAGS += -DGCOAP_STACK_SIZE=2*THREAD_STACKSIZE_LARGE

But this is just may configuration, and is probably not necessary for everyone.

[benpicco]

I'm still looking for a way to reproduce this - do you also see this issue with the put command in tests/nanocoap_cli?

[fabian18]

Yes it also happens with tests/nanocoap_cli.
The first transmission is ok but takes a while.
client put fe80::3478:9157:9fd5:81c3%5 5683 /data datendatendaten
And then, there (almost) always happens a retransmission if I repeat the command, but the retransmission seems to happen immediately and not after [ACK_TIMEOUT, ACK_TIMEOUT * RANDOM_FACTOR].
(look how close the retransmission is to the original transmission regarding the timestamp)

nanocoap_cli_put.pcapng.gz

[fabian18]

So what are we going to do? The error does not come from this PR. This PR looks fine. It is something with gnrc_sock and/or timers. I think it is annoying to stop this PR because of that. If you agree, we could merge this anyway.

[benpicco]

Thank you!
Can you open an issue about this so we don't lose track?