Introduction
Firmware management:
LoRa network management
Interfaces:
Gateway administration
Support and resources:
Introduction
Firmware management:
LoRa network management
Interfaces:
Gateway administration
Support and resources:
This is an old revision of the document!
Wanesy SPN can be reset to recover it's default configuration. All received/send data, configuration, and logs will be removed. This will not remove Wanesy SPN. This action is irreversible.
Factory reset is available in menu Administration ⇒ Gateway ⇒ Factory reset
.
To uninstall Wanesy SPN firmware, refer to the Uninstall Wanesy SPN firmware page.
Refer the Quick start page.
The Wanesy SPN version is available on the web user interface. Click on the (i)
button in the upper right corner of the screen.
nmap
or any scanning tool from a PC connected to the same network. 192.168.4.0/24
:
$ nmap 192.168.14.0/24 | grep -i wifc Nmap scan report for klk-wifc-03002E.klksi.fr (192.168.14.164)
For class C end-devices, the RX window can be forced to RX2 but not to RX1. If the RX window is forced to RX1, then this is no longer class C. Class C relies on being able to send frames during RX2 window. The user must choose between RX2 window and Auto.
The join requests traces are available in the LoRa MAC Server logs in Logs ⇒ LoRa MAC server
menu.
Quick logs analysis:
Nov 28 16:01:12 NS: Received join request from Mote 34-37-37-39-5c-33-6a-08
Nov 28 16:01:12 NS: JoinController received accept for Mote 34-37-37-39-5c-33-6a-08
Nov 28 16:01:12 NS: Class A Tx Rq for Mote 34-37-37-39-5c-33-6a-08 W0 SF7BW125 (Symbol time 1024us) W1 SF12BW125 (Symbol time 32768us) Window 0 is better Nov 28 16:01:12 NS: Use frequency 868300000 SF7BW125
Nov 28 16:01:17 NS: GW 72-76-ff-00-39-03-00-04 Tx to Mote 34-37-37-39-5c-33-6a-08 {"txpk":{"tmst":1790938763,"freq":868.300000,"rfch":0,"powe":24,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"ncrc":true,"size":17,"data":"IKP4WomIcDX0eOWq
The hardware serial number can be found in the Overview ⇒ Information
menu.
If the gateway has a static IP address and the network does not have a DNS (Domain Name System), the NTP server address in the gateway needs to be changed in Administration ⇒ Gateway ⇒ Time configuration
menu. In this scenario, the gateway is not able to link 2.pool.ntp.org
and 3.pool.ntp.org
to the corresponding IP addresses. To permit the gateway to access the NTP server, the server name (e.g 2.pool.ntp.org) needs to be changed by its IP address.
To find the IP address of a NTP server, use the command nslookup
on any Linux machine.
$ nslookup > 2.pool.ntp.org Server: 192.168.4.83 Address: 192.168.4.83#53 Non-authoritative answer: Name: 2.pool.ntp.org Address: 129.250.35.251 Name: 2.pool.ntp.org Address: 151.80.19.218 Name: 2.pool.ntp.org Address: 212.83.145.32 Name: 2.pool.ntp.org Address: 163.172.61.210
Then replace the name of the server by its IP address in the configuration file of the Wanesy SPN and upload it.
get_logs
. The execution of the script takes less than 1 minute.
Logs_2E0605F5_7b26_20200124-095206.tar.gz
)
Gathering logs from the interface
This section explains how to configure OpenVPN with the Wanesy SPN in a multi-gateways configuration over ethernet or cellular in order to setup a secure channel between the master gateway and the slave gateways.
You will need:
The OpenVPN server can be installed :
The OpenVPN server must use a static IP definition.
For ethernet, you can use a static-IP addressing (LAN configuration) or a domain name (WAN configuration with optionally the dynamic DNS feature if the IP address of the server is often changing but we recommend to use a static-IP address).
Note that if the configuration works for cellular, the same configuratio will work for ethernet.
The Master gateway (an OpenVPN client) must have a fixed-IP adressing (ethernet and cellular)
in order the packet forwarder of the slave gateways to forward properly the received LoRa packets to the Master gateway.
It is not mandatory that the slave gateways (OpenVPN clients) have a fixed-IP adressing (ethernet and cellular).
The great convenience of using OpenVPN is the fact that it is using a static-IP addressing (10.8.x.x).
So the only preconditions to have are:
For ethernet, fixed-IP addressing is not mandatory for slave gateways. For cellular, standard SIM cards can be used in the slave gateways.
The following diagram shows the kind of configuration required for each type of backhaul used for the OpenVPN clients gateways (ethernet/cellular) :
The configuration of the VPN requires:
ca.crt
server-openvpn.conf
. This is the main configuration file.
server.p12
client-openvpn.conf
.
client.p12
For configuration files, make sure that non-interactive authentication is enabled (left empty) since the connection is established by a daemon, the password cannot be entered manually.
All those files can to be uploaded via the web interface of the gateway (see below)
Here is the VPN truth chain used for this architecture:
The following chart shows the packet forwarding feature in an SPN architecture using OpenVPN:
The VPN fixed IP addressing is used to target the Master gateway in the Packet Forwarder configuration of the slave gateway.
For the SPN architecture, since a particular VPN client acts as the Master gateway, a communication “client-to-client” must be enabled to allow the slave gateways to forward LoRa packets to the Master gateway. If the SPN Master gateway is used as the OpenVPN server, this directive is not mandatory.
To generate keys and certificates, please refer to the following wiki page:
https://wikikerlink.fr/wanesy-spn/doku.php?id=wiki:webui:administration:openvpn:pki
Here is a simple server side configuration file to put in /etc/openvpn
directory:
port 1194 proto udp dev tun #tls-version-min "1.0" #tls-version-max "1.0" # CA certificate ca ca.crt # Server certificate cert server.crt # Private Server key # This file should be kept secret key server.key # Diffie-Hellman parameters dh dh2048.pem # LAN information and network configuration topology subnet server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt 86400 mssfix 1200 push "route 172.17.0.0 255.255.0.0" push "route 172.18.0.0 255.255.0.0" push "dhcp-option DNS 10.8.0.1" # Connection management comp-lzo keepalive 15 120 cipher AES-256-CBC # Daemon configuration user nobody group nogroup # Persist across restarts persist-key persist-tun persist-local-ip persist-remote-ip # Management options status openvpn-status.log verb 4 management localhost 6666 script-security 2 # Enable clients to talk each others client-to-client
Note: if you set a passphrase to access your private key, just add the following line in your configuration file :
askpass pass.txt
fill the pass.txt file with your password and chmod 600 it.
Start OpenVPN with the following command:
# sudo openvpn /etc/openvpn/server-openvpn.conf
Here is an example of a client configuration file to use and to put in /etc/openvpn
directory:
################################################# # # # Client-side OpenVPN 2.X config file for # # connecting to multi-client server. # # # # Comments are preceded with '#' or ';' # # # ################################################# # Specify that we are a client and that we # will be pulling certain config file directives # from the server. client tls-client #remote-cert-tls server # Protocol proto udp #Tunnel dev tun #Server remote 192.168.1.14 #Certification Authority Certificate - Server Authentication ca ca.crt #User Key and Certificate - Client Authentication pkcs12 client.p12 cipher AES-256-CBC #auth SHA256 tls-version-min "1.0" tls-version-max "1.0" mssfix 1200 comp-lzo
In this exemple, we are using a static IP for the server IP definition (192.168.1.14).
Note: if you set a passphrase to access your private key, just add the following line in your configuration file :
askpass pass.txt
fill the pass.txt file with your password and chmod 600 it.
Select the “Enable” button from the Administration > OpenVPN menu option and drag and drop the following files :
Automatically the openvpn process will be launched at boot time and be monitored by the monit
tool.
The last step to perform is the configuration of the slave gateway's packet forwarder. The VPN IP of the Master gateway will be used as the “node” information of the packet forwarder (here 10.8.0.2).
Due to a bug in the packet forwarder when rebooting the slave gateway (error “operation not permitted”), a specific patch must be applied to each slave gateway in order to restart the packet forwarder at the end of the boot process.
Do the following for each slave gateway:
Create the file S97lorafwd_restart in /etc/rcU.d
and order the execution of the command “monit restart lorafwd”:
# cd /etc/rcU.d/ # vi S97lorafwd_restart monit restart lorafwd
Don't forget to change file permissions:
# chmod 777 S97lorafwd_restart
A specific magic link should be used to keep the actual OpenVPN configuration and patches.
When SPN slaves are using the FW 4.x.x, you must be aware that: