examples/gcoap: take full URI as input
Contribution description
The gcoap example should better accept an URI as input instead of a host and path.
This avoids some module dependent port selection and prepares the example to deal with different kinds of coap proxies.
The client should be able to specify any scheme independent of modules as dealing with coaps or maybe even http or quic is the job of the proxy.
Testing procedure
As described in #20454.
To get the /.well-known/core payload from the libcoap server you still nedd to increase CONFIG_GCOAP_PDU_BUF_SIZE.
Client: examples/gcoap
main(): This is RIOT! (Version: 2024.04-devel-619-g920b4-pr/examples/gcoap_input_URI_and_proxy_fixes)
gcoap example app
All up, running the shell now
> ifconfig
ifconfig
Iface 6 HWaddr: 5E:B0:EA:2B:C8:53
L2-PDU:1500 MTU:1500 HL:64 Source address length: 6
Link type: wired
inet6 addr: fe80::cafe:cafe:cafe:1 scope: link VAL
inet6 addr: fe80::5cb0:eaff:fe2b:c853 scope: link VAL
inet6 addr: fd00::5cb0:eaff:fe2b:c853 scope: global VAL
inet6 group: ff02::1
inet6 group: ff02::1:fffe:1
inet6 group: ff02::1:ff2b:c853
> coap info
coap info
CoAP server is listening on port 5683
CLI requests sent: 0
CoAP open requests: 0
Configured Proxy: None
> coap proxy set coap://[fd01::ac8e:ebff:fe62:bf97]
coap proxy set coap://[fd01::ac8e:ebff:fe62:bf97]
> coap info
coap info
CoAP server is listening on port 5683
CLI requests sent: 0
CoAP open requests: 0
Configured Proxy: coap://[fd01::ac8e:ebff:fe62:bf97]
> coap get -c coap://[fd01::1]/.well-known/core
coap get -c coap://[fd01::1]/.well-known/core
gcoap_cli: sending msg ID 38508, 42 bytes
> gcoap: response Error, code 5.00, empty payload
coap put -c coap://[fd01::1]/.well-known/core
coap put -c coap://[fd01::1]/.well-known/core
gcoap_cli: sending msg ID 38509, 42 bytes
> gcoap: response Error, code 4.05, 18 bytes
Method Not Allowed
coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38510, 42 bytes
> gcoap: timeout for msg ID 38510
coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38511, 42 bytes
> coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38512, 42 bytes
> coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38513, 42 bytes
gcoap_cli: msg send failed
> coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38514, 42 bytes
gcoap_cli: msg send failed
> coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38515, 42 bytes
gcoap_cli: msg send failed
> coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38516, 42 bytes
gcoap_cli: msg send failed
> v
v
shell: command not found: v
> coap get -c coap://[fd01::2]/.well-known/core
coap get -c coap://[fd01::2]/.well-known/core
gcoap_cli: sending msg ID 38517, 42 bytes
gcoap_cli: msg send failed
> gcoap: timeout for msg ID 38511
gcoap: timeout for msg ID 38512
coap info
coap info
CoAP server is listening on port 5683
CLI requests sent: 5
CoAP open requests: 0
Configured Proxy: coap://[fd01::ac8e:ebff:fe62:bf97]
Proxy: examples/gcoap
main(): This is RIOT! (Version: 2024.04-devel-619-g920b4-pr/examples/gcoap_input_URI_and_proxy_fixes)
gcoap example app
All up, running the shell now
> ifconfig
ifconfig
Iface 6 HWaddr: AE:8E:EB:62:BF:97
L2-PDU:1500 MTU:1500 HL:64 Source address length: 6
Link type: wired
inet6 addr: fe80::cafe:cafe:cafe:1 scope: link VAL
inet6 addr: fe80::ac8e:ebff:fe62:bf97 scope: link VAL
inet6 addr: fd01::ac8e:ebff:fe62:bf97 scope: global VAL
inet6 group: ff02::1
inet6 group: ff02::1:fffe:1
inet6 group: ff02::1:ff62:bf97
> gcoap_forward_proxy: allocating client context 0x8088fe0
gcoap_forward_proxy: freeing client context 0x8088fe0
gcoap_forward_proxy: allocating client context 0x8088fe0
gcoap_forward_proxy: freeing client context 0x8088fe0
gcoap_forward_proxy: allocating client context 0x8088fe0
gcoap_forward_proxy: freeing client context 0x8088fe0
gcoap_forward_proxy: allocating client context 0x8088fe0
gcoap_forward_proxy: allocating client context 0x8089014
gcoap_forward_proxy: freeing client context 0x8088fe0
gcoap_forward_proxy: freeing client context 0x8089014
Server: coap-server-openssl -A fd01::1
Apr 08 12:38:34.443 DEBG created UDP endpoint [fd01::1]:5683
Apr 08 12:38:34.443 DEBG created DTLS endpoint [fd01::1]:5684
Apr 08 12:38:34.443 DEBG created TCP endpoint [fd01::1]:5683
Apr 08 12:38:34.443 DEBG created TLS endpoint [fd01::1]:5684
Apr 08 12:39:42.323 DEBG ***[fd01::1]:5683 <-> [fd01::ac8e:ebff:fe62:bf97]:5683 (if18) UDP : session 0x5ccc1fde81a0: new incoming session
Apr 08 12:39:42.324 DEBG ***EVENT: COAP_EVENT_SERVER_SESSION_NEW
Apr 08 12:39:42.324 DEBG * [fd01::1]:5683 <-> [fd01::ac8e:ebff:fe62:bf97]:5683 (if18) UDP : netif: recv 23 bytes
v:1 t:CON c:GET i:966c {25ce} [ Uri-Path:.well-known, Uri-Path:core ]
Apr 08 12:39:42.324 DEBG call custom handler for resource '.well-known/core' (3)
Apr 08 12:39:42.324 DEBG * [fd01::1]:5683 <-> [fd01::ac8e:ebff:fe62:bf97]:5683 (if18) UDP : netif: sent 160 bytes
v:1 t:ACK c:2.05 i:966c {25ce} [ Content-Format:application/link-format ] :: '</>;title="General Info";ct=0,</time>;if="clock";rt="ticks";title="Internal Clock";ct=0;obs,</async>;ct=0,</example_data>;title="Example Data";ct=0;obs'
Apr 08 12:40:13.253 DEBG * [fd01::1]:5683 <-> [fd01::ac8e:ebff:fe62:bf97]:5683 (if18) UDP : netif: recv 23 bytes
v:1 t:CON c:PUT i:966d {ebd0} [ Uri-Path:.well-known, Uri-Path:core ]
Apr 08 12:40:13.253 DEBG * [fd01::1]:5683 <-> [fd01::ac8e:ebff:fe62:bf97]:5683 (if18) UDP : netif: sent 25 bytes
v:1 t:ACK c:4.05 i:966d {ebd0} [ ] :: 'Method Not Allowed'
Apr 08 12:45:13.253 DEBG ***EVENT: COAP_EVENT_SERVER_SESSION_DEL
Apr 08 12:45:13.254 DEBG ***[fd01::1]:5683 <-> [fd01::ac8e:ebff:fe62:bf97]:5683 (if18) UDP : session 0x5ccc1fde81a0: closed
Issues/PRs references
#20454
Murdock results
:heavy_check_mark: PASSED
7e97ee857195ce5874c3b75031cefd3b08dccc98 examples/gcoap: adjust README after taking URI as input
| Success | Failures | Total | Runtime |
|---|---|---|---|
| 10083 | 0 | 10083 | 14m:16s |
Artifacts
Not the authors fault here but RIOT really should change the way it interacts with URIs. That's awful...
Change looks good to me, didn't test it.
I dropped the static IP configuration in the Makefiles I used for testing and adjusted the README.
Thank you
Note to self: #18107 needs rebase and major rework.