Increase log level

If you need to see additional details about the Basic Station, you can increase the log verbosity by editing the Basic Station configuration file.

The used configuration file depends on the frequency range and the antenna gain configuration, it's located at:

/etc/opt/lora-basic-station/config/<region_freq>/station_<antenna_gain>dBi.conf 

For an 868 MHz gateway with a 2dbi antenna, it will be:

/etc/opt/lora-basic-station/config/863-870/station_2dBi.conf

Edit this file and replace the log_level value with "DEBUG" or "XDEBUG":

{
  "station_conf": {
    "log_file": "stderr",  /* If you log to a file, it will not be available in the Manager anymore */
    "log_level": "DEBUG" /* XDEBUG,DEBUG,VERBOSE,INFO,NOTICE,WARNING,ERROR,CRITICAL */
  },
  
  "radio_conf": {
  [...]
  }
}
CODE


If you set a verbosity of "INFO" or less verbose (NOTICE, WARNING, ...), the packet log will not be available anymore.


A higher verbosity will make old messages unavailable earlier, so do not forget to restore the settings.

Connection errors

Bad address (does not exist)

Symptoms

[AIO:ERRO] [-1] WS connect failed: NET - Failed to get an IP address for the given hostname
[TCE:ERRO] TC connect failed - URI: wss://lnst.eu.thethings.network:443

Diagnostic

The Basic Station cannot find the IP for the given hostname, and therefore it cannot connect.

  1. The hostname is not registered in the DNS
  2. The DNS use for name resolution is not accessible

Solution

  1. Unknown hostname
    1. Check the URL for typos
    2. Ensure the hostname is registered in the DNS by pinging from another device
  2. Unreachable DNS
    1. Check if the gateway has access to the DNS network (or to the Internet)
    2. Ensure the gateway has a DNS server configured (e.g. from the DHCP) and the DNS is reachable

Workaround

Set the IP address directly as the server address.

Bad address / server certificate issue

Symptoms

[TCE:INFO] Connecting to INFOS: wss://router.eu.thethings.network:443
[AIO:INFO] TLS server certificate verification failed: The certificate Common Name (CN) does not match with the expected CN

Diagnostic

The authentication certificate given by the server does not match the configured certificate. Either because:

  1. A wrong server is configured (either address or port)
  2. A wrong certificate is configured

Solution

  1. Wrong server
    1. Update the URL with the correct address
    2. Update the port to the correct one
  2. Wrong certificate
    1. Ask the server provider the correct certificate

Workaround

Use an unsecured connection (without server authentication).

Bad address (no LNS server)

Symptoms

[TCE:INFO] Connecting to INFOS: wss://lorixone.io:443
[AIO:ERRO] [3] WS upgrade failed with HTTP status code: 301

Diagnostic

The servers is reachable but it's not running a LNS service:

  1. A wrong server is configured
  2. The LNS service is not running

Solution

  1. Wrong server
    1. Update the URL with the correct address
    2. Update the port to the correct one
    3. Ensure the network redirects you to the correct server (e.g. no company proxy redirection)
  2. LNS service not running
    1. Contact the server/service provider

Client authentication failure (401)

Symptoms

[TCE:INFO] Connecting to INFOS: wss://eu1.cloud.thethings.network:8887
[TCE:INFO] Infos: fcc2:3dff:feaa:bbcc muxs-::0 wss://eu1.cloud.thethings.network:8887/traffic/eui-FCC23DFFFEAABBCC
[AIO:ERRO] Recv failed: SSL - The peer notified us that the connection is going to be closed
[AIO:VERB] 128 certificates (trust) have been loaded from './tc.trust'
[AIO:INFO] tc has no cert configured - running server auth and client auth with token
[TCE:VERB] Connecting to MUXS...
[AIO:ERRO] [3] WS upgrade failed with HTTP status code: 401

Diagnostic

The servers is reachable but the gateway did not provide valid credentials:

  1. A wrong client certificate/key pair is configured
    or
  2. A wrong authentication token configured

Solution

  1. Use a valid certificate/key pair
  2. Use a valid authentication token

Forbidden connection (403)

Symptoms

[TCE:INFO] Connecting to INFOS: wss://eu1.cloud.thethings.network:8887
[TCE:INFO] Infos: fcc2:3dff:feaa:bbcc muxs-::0 wss://eu1.cloud.thethings.network:8887/traffic/eui-FCC23DFFFEAABBCC
[AIO:ERRO] Recv failed: SSL - The peer notified us that the connection is going to be closed
[AIO:VERB] 128 certificates (trust) have been loaded from './tc.trust'
[AIO:INFO] tc has no cert configured - running server auth and client auth with token
[TCE:VERB] Connecting to MUXS...
[AIO:ERRO] [3] WS upgrade failed with HTTP status code: 403

Diagnostic

The servers is reachable, the gateway could authenticate with valid credentials but it was not authorized to connect:

  1. The server does not authorize the gateway to connect

Solution

Configure the server to authorize the gateway to connect as a gateway.

This solution depends on LoRa Network Server used:

  • The Things Stack: edit the API key and add the "Link as Gateway to a Gateway Server for traffic exchange, i.e. write uplink and read downlink" right.

Successful connection to the server

[TCE:INFO] Connecting to INFOS: wss://lns.eu.thethings.network:443
[TCE:INFO] Infos: fcc2:3dff:fe0b:abab muxs-::0 wss://lns.eu.thethings.network:443/traffic/eui-FCC23DFFFE0B6ACA

Packets logs

Uplink packet received

Join request

[S2E:VERB] RX 868.5MHz DR0 SF12/BW125 snr=8.0 rssi=-16 xtime=0x8000003CB3EEC - jreq MHdr=00 JoinEui=7665:6761:7473:3132 DevEui=3239:3434:6638:700d DevNonce=55639 MIC=2046627856

Data (unconfirmed)

[S2E:VERB] RX 867.1MHz DR1 SF11/BW125 snr=-12.5 rssi=-111 xtime=0xF8005FDEE2C15C - updf mhdr=40 DevAddr=09B6A738 FCtrl=00 FCnt=15 FOpts=[] 0207E02D..173D mic=2062729402 (27 bytes)

Other messages

Time sync / clock drift

Some time synchronization / clock drift messages may show up:

[SYN:ERRO] Repeated excessive clock drifts between MCU/SX130X#0 (105 retries): 1615.4ppm (threshold 100.0ppm)
[SYN:VERB] Time sync rejected: quality=252 threshold=216

This is because the time flow of the MCU (CPU) and the SX1301 (LoRa chip) are slightly drifting and the Basic Station does monitor it. This typically happens when the gateway was restarted or is recovering networking as it's syncing its time with the NTP servers. To avoid a jump in time, the time flow goes slightly faster on slower on the gateway to align with the time specified by the NTP server. You will typically see the "quality" number going down (less drift), until it passes below the threshold and is not reported anymore. This means the shift is being lower as it's reaching it's synchronization point. If the shift is very high, they may be reported as errors.

You don't have to do anything related to theses messages as good MCU/SX1301 clock synchronization is not a strict requirement for Station to function properly. However, frequent occurrence of these messages in normal operation for a long period of time (multiple messages every hour for multiple days) is an indication that something is probably malfunctioning. Try to change your NTP server or contact the support.