Today i started to install LoRa Server on Raspberrypi 3 (OS: Jessie). My aim is to install network server (LoRa Server) and Application Server (App server) on the Pi, while LoRa gateway bridge on the Multitech conduit.
As first part i installed both LoRa server and App server on the Raspberrypi.
Since i was newbie to linux commands, i had some difficulties in installing the packages. But after spending some time and with the help of google and different forums i am able to successfully install all the packages for LoRa server and app server.
I have questions about what i have to edit in the configuration files of both LoRa server config and LoRa app config
I have opened the file (config file for lora App server) in editor mode using the command
Unfortunately, till now, i am not successful about setting up the LoRa server (network server and application server) on my raspberry pi3. Since, there are lot of concepts it would be kind if you could guide me with patience.
I am summarizing what i have done.
I have successfully installed LoRa packet forwarder and LoRa gateway bridge on the multitech conduit. Both instances are running. The lora-gateway-bridge file and LoRa packet forwarder (global_conf.json) are attached as below:
Then i took one raspberry pi 3 and deployed other components (LoRa server and application server). At first, I have installed LoRa server following the instructions posted here. The installation gave me no error. In the configuration file (/etc/loraserver/loraserver.toml) i have made following changes using nano editor
//
postgres://loraserver_ns:dbpassword@localhost/loraserver?sslmode=disable
//
enabled_uplink_channels=[0 1 2] // i want to use first three default channels 868.1,868.3,868.5M Hz
//
jwt_secret=“abc” /// just took from your post, i am totally blank about security issues.
//MQTT settings
username=“loraserver”
password = “********”
//
I have left all the ca_cert,tls_cert, tls_key as blank (similar to default configuration.) Since it is optional so i thought i could do it without them.
I haven’t tried this configuration, but according to the example in the configuration file, the correct would be
enabled_uplink_channels=[0, 1, 2]
Not the best for security, but should work fine.
Do you really need to change those? Personally, I avoid changing these unless really necessary. I believe these credentials should match the broker’s where the lora-gateway-bridge expects to publish to.
No problem. However, there are some of the certificates that need to have their path correctly indicated for lora-app-server. For loraserver, should be fine.
Please, check these configurations and try again.
If the journal still can’t be found, please, feel free to ask again.
I installed the application server on the same raspberry pi3 using the instructions posted here.
Similarly, in the configuration file (/etc/lora-app-server/lora-app-server.toml), i have the following changes.
//
postgres://loraserver_as:dbpassword@localhost/loraserver_as?sslmode=disable
//
MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
server=“tcp://localhost:1883”
Connect with the given username (optional)
username=“loraappserver”
Connect with the given password (optional)
password=“xxxxxxx”
I have left all the ca_cert,tls_cert, tls_key as blank (similar to default configuration.).
the command
I think i have set mqtt credentials as in the docs section.
Mosquitto authentication
Mosquitto, as the main conduit for messaging between the gateways and the LoRa servers and the applications receiving LoRa data, should be secured to prevent third party access to the data. To set up Mosquitto security:
Create a password file for your mosquitto users, starting with a “root” user.
The “-c” parameter creates the new password file. The command will prompt for
sudo chmod 600 /etc/mosquitto/pwd
Note that further configuration is possible, such as limiting the topics to which the various users can have access. These settings are beyond the scope of this document.
Mosquitto configuration
Add a new local configuration file (this should survive mosquitto upgrades) called /etc/mosquitto/conf.d/local.conf with the following configuration:
Tell mosquitto where the password file is by adding the lines:
I finally managed to get some positive output. I have only changed [dsn] in both configuration files (lora server and lora app server) and added the following security.
The log results from LoRa server are as below:-
– Logs begin at Thu 2018-03-01 15:43:52 UTC. –
Mar 01 15:43:56 raspberrypi systemd[1]: Starting LoRa Server…
Mar 01 15:43:56 raspberrypi systemd[1]: Started LoRa Server.
Mar 01 15:43:57 raspberrypi loraserver[569]: time=“2018-03-01T15:43:57Z” level=info msg=“starting LoRa Server” band=EU_863_870 docs=“https://docs.loraserver.io/” net_id=010203 version=0.24.3
Mar 01 15:43:57 raspberrypi loraserver[569]: time=“2018-03-01T15:43:57Z” level=info msg=“setup redis connection pool” url=“redis://localhost:6379”
Mar 01 15:43:57 raspberrypi loraserver[569]: time=“2018-03-01T15:43:57Z” level=info msg=“connecting to postgresql”
Mar 01 15:43:57 raspberrypi loraserver[569]: time=“2018-03-01T15:43:57Z” level=error msg=“ping database error, will retry in 2s: dial tcp [::1]:5432: getsockopt: connection refused”
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“backend/gateway: TLS config is empty”
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“backend/gateway: connecting to mqtt broker” server=“tcp://localhost:1883”
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“configuring join-server client” ca_cert= server=“http://localhost:8003” tls_cert= tls_key=
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“no network-controller configured”
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“applying database migrations”
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“backend/gateway: connected to mqtt server”
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“backend/gateway: subscribing to rx topic” topic=gateway/+/rx
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“backend/gateway: subscribing to stats topic” topic=gateway/+/stats
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“migrations applied” count=0
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“starting api server” bind=“0.0.0.0:8000” ca-cert= tls-cert= tls-key=
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“starting gateway api server” bind=“0.0.0.0:8002” ca-cert= tls-cert= tls-key=
Mar 01 15:43:59 raspberrypi loraserver[569]: time=“2018-03-01T15:43:59Z” level=info msg=“starting downlink device-queue scheduler”
Mar 01 15:44:43 raspberrypi systemd[1]: Started LoRa Server.
the log from lora-app-server
– Logs begin at Thu 2018-03-01 15:43:52 UTC. –
Mar 01 15:43:59 raspberrypi systemd[1]: Starting LoRa App Server…
Mar 01 15:43:59 raspberrypi systemd[1]: Started LoRa App Server.
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“starting LoRa App Server” docs=“https://docs.loraserver.io/” version=0.18.0
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“connecting to postgresql”
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“setup redis connection pool”
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“handler/mqtt: TLS config is empty”
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“handler/mqtt: connecting to mqtt broker” server=“tcp://localhost:1883”
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“handler/mqtt: connected to mqtt broker”
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“handler/mqtt: subscribling to tx topic” topic=application/+/node/+/tx
Mar 01 15:44:00 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:00Z” level=info msg=“applying database migrations”
Mar 01 15:44:01 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:01Z” level=info msg=“migrations applied” count=0
Mar 01 15:44:01 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:01Z” level=info msg=“starting application-server api” bind=“0.0.0.0:8001” ca-cert= tls-cert= tls-key=
Mar 01 15:44:01 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:01Z” level=info msg=“starting join-server api” bind=“0.0.0.0:8003” ca_cert= tls_cert= tls_key=
Mar 01 15:44:01 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:01Z” level=info msg=“starting client api server” bind=“0.0.0.0:8080” tls-cert=/etc/lora-app-server/certs/http.pem tls-key=/etc/lora-app-server/certs/http-key.pem
Mar 01 15:44:01 raspberrypi lora-app-server[768]: time=“2018-03-01T15:44:01Z” level=info msg=“registering rest api handler and documentation endpoint” path=/api
Mar 01 15:44:54 raspberrypi systemd[1]: Started LoRa App Server.
///////////////////////////////////////////////////////////////////////////////////////////////////////////
I hope this is the right configuration.
I think there is still one problem left to be solved:
Try this:
cat /var/log/postgresql/postgresql-9.6-main.log
If you see something like
2018-02-18 16:32:14.334 UTC [1042] loraserver_ns@loraserver_ns DETAIL: Password does not match for user "loraserver_ns". Connection matched pg_hba.conf line 94: "host all all ::1/128 md5"
you still have to change a postgresql configuration file.
No, there’s no error, is just that when loraserver started, postgres wasn’t running yet, but in a second try it was and loraserver carried on initializing. If postgres was indeed permanently unreachable, something like these would be seen, with the error message continuing to repeat every 2 seconds:
INFO[0000] starting LoRa Server band=US_902_928 docs="https://docs.loraserver.io/" net_id=010203 version=0.21.0-99-g8c309f3
INFO[0000] setup redis connection pool url="redis://localhost:6379"
INFO[0000] connecting to postgresql
INFO[0000] backend/gateway: TLS config is empty
INFO[0000] backend/gateway: connecting to mqtt broker server="tcp://localhost:1883"
ERRO[0000] backend/gateway: connecting to mqtt broker failed, will retry in 2s: Network Error : dial tcp 127.0.0.1:1883: getsockopt: connection refused
ERRO[0002] backend/gateway: connecting to mqtt broker failed, will retry in 2s: Network Error : dial tcp 127.0.0.1:1883: getsockopt: connection refused
ERRO[0004] backend/gateway: connecting to mqtt broker failed, will retry in 2s: Network Error : dial tcp 127.0.0.1:1883: getsockopt: connection refused
That may be fine for testing purposes, but it means that anyone may connect to your mosquitto broker, so don’t do this for any serious case (also see this, allow anonymous won’t always give access to topics, which could be confusing). Instead, follow carefully the docs on securing mosquitto.
The same goes for this, which is trusting any connection to postgres from any user who can access the server. This is a security risk, and this authentication method shouldn’t be used in production:
When in need to debug, try running programs manually to check the ouput directly so you can see what’s going on.
In summary, relaxing conditions on services in which loraserver relies may be fine just to get it working for the first time, but now that you have, you should try to address all security issues that this creates. You’ll eventually have to deal with them anyway, so why not do it now while you are still configuring things?
After you’re able to register a device for your application, you can check either the data received by the gateway or by the device.
Look for the JSON field that represents the data, but keep in mind that it will be Base64-encoded.
Could you tell me how to check if my Lora-gateway bridge is working properly or not? I have installed the lora-gateway bridge on the multitech conduit but i could not find any command to test that its functioning.
Having the same issue that was mentioned here. And your example for a Postgres issue doesn’t seem to be my problem despite what you posted here at the beginning of last month.
My Postgres seems to be working fine, and from what I can tell is on the port that my other files should looking at by default. This issue has come up multiple other times without any direct resolution from what I’ve been able to tell through this forum. If people are fixing their problem they aren’t sharing that fix for others like Osman here. It just seems to fall into place without any further comment.