You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 28, 2023. It is now read-only.
The IoT REST API Server, used by OCF to convert OCF resources from CoAP to HTTP, also wants to bind port 5683 for CoAP services. Trying to start the thing directory on the same computer an iot-rest-api-server is also running causes an error when the thing directory tries to bind the same port. This is non-fatal (the http server still comes up) but is problematic, especially if both the thing directory and the iot-rest-api-server are started automatically (in which case there would be a race condition on who can grab the port first...).
As a workaround, the COAP_PORT property in Californium.properties can be changed to avoid a conflict (I changed mine to 5684).
COAP_PORT=5684
[EDIT: See below, this a poor choice, as it conflicts with COAPS. 15683 is what I am trying to use now.]
Of course this may cause issues with devices looking for CoAP resource directories in a certain place... to discuss.
As a related issue, gateways are often (should be) running firewalls. You may have to explictly open the relevant ports to make the thing directory service available locally to other devices. I used the following, (similar to what is described in the iot-rest-api-server documentation) to open my (re-defined) CoAP port:
sudo iptables -A INPUT -p udp --dport 5684 -j ACCEPT
The default HTTP ports don't conflict since iot-rest-api-server uses 8000 by default (for HTTPS too) and the thing directory uses 8080.
The text was updated successfully, but these errors were encountered:
5683 is a poor choice for an alternative port, since it is the port used by CoAPS. Instead I am using 15683 (and likewise, 15684 might be reasonable for COAPS).
Changing COAP_PORT in the Californium.properties file does not seem to have any effect. Poking around in the source code however I found the following in ThingDirectory.java, so changing the coap port with the -c option (and the http port with -h) seems to be supported:
// Default values
int portCoAP = 5683;
int portHTTP = 8080;
...
options.addOption("c", true, "CoAP port number. Default is 5683.");
options.addOption("h", true, "HTTP port number. Default is 8080.");
The IoT REST API Server, used by OCF to convert OCF resources from CoAP to HTTP, also wants to bind port 5683 for CoAP services. Trying to start the thing directory on the same computer an iot-rest-api-server is also running causes an error when the thing directory tries to bind the same port. This is non-fatal (the http server still comes up) but is problematic, especially if both the thing directory and the iot-rest-api-server are started automatically (in which case there would be a race condition on who can grab the port first...).
As a workaround, the COAP_PORT property in
Californium.properties
can be changed to avoid a conflict (I changed mine to 5684).[EDIT: See below, this a poor choice, as it conflicts with COAPS. 15683 is what I am trying to use now.]
Of course this may cause issues with devices looking for CoAP resource directories in a certain place... to discuss.
As a related issue, gateways are often (should be) running firewalls. You may have to explictly open the relevant ports to make the thing directory service available locally to other devices. I used the following, (similar to what is described in the iot-rest-api-server documentation) to open my (re-defined) CoAP port:
The default HTTP ports don't conflict since iot-rest-api-server uses 8000 by default (for HTTPS too) and the thing directory uses 8080.
The text was updated successfully, but these errors were encountered: