I am trying to use the CoAP resource discovery in RIOT using the /.well-known/core and CoAP multicast. I am testing the feature in the gcoap example. I am working on the 2022.01 release and communicating via tap interfaces between two native riot instances.
using the command coap get fe80::407e:78ff:fe73:786c 5683 /.well-known/core in client ,I could see the resources in fe80::407e:78ff:fe73:786c as response to the request.It works very well.( here fe80::407e:78ff:fe73:786c is the address of my server).
But I want to use the Multicast to know about the resources in neighbors as explained here.
So i change my command to coap get ff02::1 5683 /.well-known/core, using the multicast address ff02::1.But I don’t get any response from any of the neighbors (gcoap: timeout for msg ID 24827 event happens) . Why does this happen ? Could someone help to resolve this issue ?
Is it possible to add query parameters during discovery in RIOT? for eg. coap get ff02::1 5683 /.well-known/core?rt=temp
Generally with multicasts, you’ll have to set the interface number, which you get from ifconfig. If that says 7, you’ll have to send your requests to ff02::1%7.
That should work; if it does not, it’s a bug. (Note that other RIOT devices will usually not implement resource discovery and send all their .well-known/core information, which is acceptable behavior).
I have added the interface number and the command looks like this .coap get ff02::1%6 5683 /.well-known/core. Still I get timeout.
In the gcoap example,I have tried to use the query options. For eg coap get fe80::28ba:1ff:fe52:4483%6 5683 /.well-known/core?rt=“count” .I get error 4.04 (Not Found).Is there any option that needs to set to mention that its a query ?
I am testing these features in the gcoap example in RIOT.
There is obviously an issue with assigning multicast responses; I wonder how Hauke’s RD discovery tests ever worked. Either way, on it (_find_req_memo probably compares IP addresses, which is generally a good idea but needs to be suspended for multicasts).
#17978 fixes this; @ad6sh you may want to give it a try and report whether it does the trick for you.
I get error 4.04 (Not Found). Is there any option that needs to set to mention that its a query?
Nothing needs to be set, but 4.04 is AFAIR the correct response to send to a request for something for which there are not resources on a given server. (Beware that rt values usually don’t take quotes around them).
@chrysn thanks…now I can see resources using multicast address
still I get not found when adding query parameters. coap get ff02::1 5683 /.well-known/core?rt=xx
Is it because the client specifically looks for the URI /.well-known/core?rt=xx in server.But there is no URI like that in server? I have also added the resource type(rt) in link params of the server.
@chrysn my server also runs on RIOT OS and is built from from the gcoap example.And I am adding link parameters. My plan is to send a multicast coap get ff02::1 5683 /.well-known/core?rt=10 and get the responses only from a server with rt 10.
Ah, there’s indeed a “bug” in the coap client – it really only takes a “path” (so it’s documented correctly, technically, it’s not a URI reference), and entering /.well-known/core?rt=temp treats all the argument as a path, thus the URI that’s being accessed is really /.well-known/core%3Frt=temp, which indeed is a path that’s unavailable.
I’m in a lot of other work right now – could you open an issue on github.com/RIOT-OS/RIOT/issues describing what you tried, that it didn’t work, and mention @chrysn to ensure it lands on my radar? (I’m also happy to review a pull request; might be a bit tricky because there might be an API change, depending on what the intention behind the gcoap_req_initpath argument is).
just to make sure,is the bug in server or client ?So as per my understanding,the server should be able to parse the URI the it gets from the request and check for the query parameters and respond accordingly.But now it considers the whole requested URI as path.
The nice thing in CoAP is: The server doesn’t need to parse the URL, the URL is transported in pre-parsed form. Neither the client nor the server would need to assemble it into a full URI. Only when dealing with end user input (as is the case in the gcoap example) someone needs to convert a URL into CoAP options, and this is what the gcoap example gets wrong. (Not technically, as it advertises that it takes a path and not a URI).
Hi @chrysn …as a first step,i was trying to use the coap_opt_add_uri_query() from nanocoap.But this functionality does not seems to work in my case.
I have tried to add the query paramerts in the gcoap example itself,to check the functionality.In this example,you can see a command “disc” which specifically tests this function.
For testing purposes I have started two RIOT CoAP servers on native.The resources in server has different link parameters.For eg.rt=xyz and rt=abc. On the client side I use coap_opt_add_uri_query(&pdu, "rt", "abc"); to specifically query from one server only. It doesn’t matter whatever query parameters that I have added. The code works like there is no query parameters.Sometimes I get reply from one server and sometimes from another.You could test this by running two server and one client ,then typing the command “disc” on the client several times.
I have also tried removing the link params from the server and start discovery from client using query params.(To check if the coap_opt_add_uri_query works ).Still in this condition client gets the resources in server as response.
