lorabasics / basicstation Goto Github PK

The field DRs defines the available data rates of the channel plan. It MUST be an array of 16 entries with each entry being an array of three (3) integers encoding the spreading factor SF, the bandwidth BW, and a DNONLY flag. SF MUST be in the range 7..12 for LoRa, or 0 for FSK. BW MUST be one of the numbers 125, 250, 500, and BW is ignored for FSK. DNONLY MUST be 1 if the data rate is valid for downlink frames only, and 0 otherwise.

I make the assumption that the index of the array represents the DR number as specified in the LoRaWAN Regional Parameters, but from the documentation this is not clear. It is also not clear what to do with the unspecified data-rates. From the examples I see that in such a case the SF is set to -1, but this is not documented. Both points might be worth adding :)

The LNS is requested to return a muxs identifier, but the documentation does not say if/when the number may be reused and how is it used. It seems to be never sent in any other message. What is the purpose of this, please?

(Please suggest a better way to ask questions if this is not the appropriate way.)

The LNS protocol allows the server to return an error field only during the initial router-URI exchange. The error handling for other message exchanges is not defined, which feels inconsistent. It would be more debugging friendly if the server was allowed to return an error field in every message.

I've been trying the different authentication modes of the Basic Station, but I'm getting an error message when testing TLS Server and Client Authentication, which I don't understand:

[AIO:ERRO] tc contains malformed auth token - expecting: {header: value\r\n}*

To me it looks like the Basic Station is trying to use the TLS Server Authentication and Client Token authentication mode and trying to read the tc.key file as HTTP headers.

I believe all files are in their correct locations (see below), but I might be missing something.

I have installed the Basic Station (2.0.3 tag) on a Raspberry Pi. This works well and was easy to setup :-) Without TLS the Basic Station connects without any issues. When enabling TLS and with a tc.trust file containing the CA certificate, the Basic Station connects without any issues too using TLS.

When enabling client certificate verification on the LNS endpoint, the endpoint returns the error that no client certificate is provided, as expected and the Basic Station fails to connect.

After putting a tc.cert and tc.key (the tc.trust is still there) in the same directory as the station executable, I get:

2019-04-15 11:36:46.254 [SYS:INFO] Logging     : stderr (maxsize=10485760, rotate=3)
2019-04-15 11:36:46.254 [SYS:INFO] Station Ver : 2.0.3(rpi/std) 2019-04-15 07:35:24
2019-04-15 11:36:46.254 [SYS:INFO] Package Ver : (null)
2019-04-15 11:36:46.254 [SYS:INFO] proto EUI   : 102:304:506:708        (station.conf)
2019-04-15 11:36:46.254 [SYS:INFO] prefix EUI  : ::1    (builtin)
2019-04-15 11:36:46.254 [SYS:INFO] Station EUI : 102:304:506:708
2019-04-15 11:36:46.254 [SYS:INFO] Station home: ./     (builtin)
2019-04-15 11:36:46.254 [SYS:INFO] Station temp: /var/tmp/      (builtin)
2019-04-15 11:36:46.255 [SYS:WARN] Station in NO-CUPS mode
2019-04-15 11:36:46.456 [TCE:INFO] Starting TC engine
2019-04-15 11:36:46.458 [any:INFO] cert. version     : 3
serial number     : 6B:49:E8:D8:BB:2F:13:99:2E:51:7F:56:35:48:7C:18:88:D0:66:C4
issuer name       : CN=LoRa Server CA
subject name      : CN=LoRa Server CA
issued  on        : 2019-04-15 11:01:00
expires on        : 2024-04-13 11:01:00
signed using      : RSA with SHA-256
RSA key size      : 2048 bits
basic constraints : CA=true
key usage         : Key Cert Sign, CRL Sign
2019-04-15 11:36:46.458 [AIO:ERRO] tc contains malformed auth token - expecting: {header: value\r\n}*

Below the certificates and key files (these are for testing so there is no harm in making these public):

ls -la
total 760
drwxr-xr-x 2 root root   4096 Apr 15 12:48 .
drwxr-xr-x 6 root root   4096 Apr 15 08:35 ..
-rwxr-xr-x 1 root root 743028 Apr 15 08:35 station
-rw-r--r-- 1 root root    381 Apr 15 09:17 station.conf
-rw-r----- 1 root root      0 Apr 15 08:46 tc-bak.done
-rw-r----- 1 root root     29 Apr 15 08:46 tc-bak.uri
-rw-r--r-- 1 root root   1196 Apr 15 12:21 tc.cert
-rw-r--r-- 1 root root   1679 Apr 15 12:46 tc.key
-rw-r--r-- 1 root root   1103 Apr 15 12:15 tc.trust
-rw-r--r-- 1 root root     21 Apr 15 12:13 tc.uri

tc.cert

-----BEGIN CERTIFICATE-----
MIIDRjCCAi6gAwIBAgIUBb1faRYMOxW5bQvXcfATnMM4q7UwDQYJKoZIhvcNAQEL
BQAwGTEXMBUGA1UEAxMOTG9SYSBTZXJ2ZXIgQ0EwHhcNMTkwNDE1MTEwMzAwWhcN
MjAwNDE0MTEwMzAwWjAbMRkwFwYDVQQDExAwMTAyMDMwNDA1MDYwNzA4MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx3vfuton3olZl19nESNuYk7Q2clh
WqVjuyG7MFayVK5zSI79beHdb4UdhYFPMQVSonQaxgSzLZEOZeDirjAaQlM/+rWt
U+lDCXb0KHnvDuaqkr2AoGiyb6vTpODspCerGreE6BFrDjmQMFCx1UTaIPIKfzHH
5rS79nvGcJoAeeTTT/diOCUMXGPHHSjY6Dnxw0gollCazp/7z+QhhfgJN6Ty0/AN
Uoi3OCrztJLLsx/ja9k7mhCtncyZCm5AY27v5gSnPTEDFs4qKVzUwKb5yXtoye03
sE+NRz5B5o68/yo2E+0SPgFunY53MvvHeGERIBOr/RP+0yQIXkv72VWnYwIDAQAB
o4GDMIGAMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNV
HRMBAf8EAjAAMB0GA1UdDgQWBBRQ6AGzlradLcRYcage7p4agL51vzAfBgNVHSME
GDAWgBQ+pTn4AEqRnQxvN07cOrmTTofEPDALBgNVHREEBDACggAwDQYJKoZIhvcN
AQELBQADggEBAHpKWmAE7xArRILU9IC+8Ui7DIudk8ZN4s1P08fbBGR1HPVV0tAI
6tUI/Ez25om9nKM2uoDYQmDMVADpZo6ah4lUYBxj3rZgD2+2syjhqsUz905Bbfuo
2XU+atV0yVvkxRt7mN7bZ7ZBukOi/mgARfqFyrfWXgmzxLDit1MmlYDm5qNTldpr
koYSi1n/W5ffg7UJmqhVzGXCem6UuA2Czr+7nnieQ3ISHMDN9iHXzwhF8xcJAjbM
C3nQbl/H9uF8gMoEM/TeyKnn3wPLS0TqAd3EYC35CzL/hI0QYLmPPJwf/nWxT1y7
Eo3//iR56srdkokkpM3qBQ7prcqk5pK1h3U=
-----END CERTIFICATE-----

tc.key

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAx3vfuton3olZl19nESNuYk7Q2clhWqVjuyG7MFayVK5zSI79
beHdb4UdhYFPMQVSonQaxgSzLZEOZeDirjAaQlM/+rWtU+lDCXb0KHnvDuaqkr2A
oGiyb6vTpODspCerGreE6BFrDjmQMFCx1UTaIPIKfzHH5rS79nvGcJoAeeTTT/di
OCUMXGPHHSjY6Dnxw0gollCazp/7z+QhhfgJN6Ty0/ANUoi3OCrztJLLsx/ja9k7
mhCtncyZCm5AY27v5gSnPTEDFs4qKVzUwKb5yXtoye03sE+NRz5B5o68/yo2E+0S
PgFunY53MvvHeGERIBOr/RP+0yQIXkv72VWnYwIDAQABAoIBAG02fH6oATvspogh
SyQu6bgYvm79ubcO5VMGXJ1SWb/S4nrPDiCij8EGd+snqFuGNn+KYT4YRKCl0eQl
AvWqkDXPri9sV8Cg7Hq6DWI7n43g63H7Hfi0WTyaLf0Ox3/3182Au9rx7lKTYUWS
aEoCsAlpeiW482BzgpSnnzT2m1wf27n1QnXK815ElcistFyUcu3Un5NpShZdAZ61
GnoFa3TEzEA/MKikpxCfNfpRH0upw5iX5/MUmMEz0LDmElbVFUiqPopDlWMVrsxv
kkWl7WzTVtTkjfWqypm3+WHQXg2O2FF+Ns63YzRge20PWEX0vi+kAr2L97CeJl97
S5LCJsECgYEA5O//IkipvFwAyn/bbOFiRH9GcvLpOJyfNSWDuQ2bITaHtqoXc4s7
fke6yzGJ7RghLgQGvbBiMD7/auOXRNDDcuTzqZmmd7BzrjNcbZ1S5PYSvsLRWLUc
slGLzz5Pb6gt1VxcLs702w5PB7Y+Mjp8gc6iY3RsfFQwo7IirH8XNTcCgYEA3xCQ
ynHec2HDl8ZwUYhoCJN2zCCSfwXUijE058NO/zhO1FuJmMCV4uIfoSqRgWsKeOKE
dfUfQDJ5t5CPJ26K+xurKtA4EVEnujgcYYHLAysw7cdxA0SKPdiC4Pp8YLRVGA2J
oyCin7DItlcMbaXpjaGuHNttprVc012qZrY29TUCgYEApWRE243HIg8Nez3XVdeV
2IpiaNTYbE+qLQkHGn+b3Oi6Ltq+yniB6H8FkZoeXK0b+1RpUkzFArngaGY3eD2h
lbWV2qboPnu5dtYgJgiMRGEJtcqk1wMw0hpbeMM5PB8xzXxGFILrHf4+VgHw+PSL
0nNnmZYYcdGYugoNRrUiHQ0CgYEApzQ+pFFogqqkt48awDL0cIFBCk/cH/TZ1WB/
HL7s5yhpBos6/9JUSAZh2SgUe6Ml7Wk2C0lbTH7JeAyXEeKtsP6Tdnsvm+NuWQsY
Uwq8hzqH6aSXFPD6gtNZf5SjSMXEB0yWgD3FSNh2CyADA+nawLyRy7W7YrwNwa4z
PdyWI4UCgYAitY5jmokTL3kxLG2Ty4ups5dxfWEacMaLs+wbBW6iepeAIaCE6l3n
AKninyJgOPgVoIXktVfpWAadUcch6C66KuhbRaPYW744QQOGOCSRaPmVquzJveN+
TE9HRD80y03rT8QaWDNG316ZPF590uOm6eD6N5lMdK+LebL8GBOhIQ==
-----END RSA PRIVATE KEY-----

tc.trust

-----BEGIN CERTIFICATE-----
MIIDAjCCAeqgAwIBAgIUa0no2LsvE5kuUX9WNUh8GIjQZsQwDQYJKoZIhvcNAQEL
BQAwGTEXMBUGA1UEAxMOTG9SYSBTZXJ2ZXIgQ0EwHhcNMTkwNDE1MTEwMTAwWhcN
MjQwNDEzMTEwMTAwWjAZMRcwFQYDVQQDEw5Mb1JhIFNlcnZlciBDQTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBALqlCFJiil7wjP/bY2j1cMkKbQSQkkHX
DYNutq4fdL82DhDtUP0snSoHBiQD3APNdhUK6XISXQ2uRUtWL15fbEzbPOqIJsTR
gJv41qEwHe+rVkmNjGaWbbiCyasSYD3xCJnT8M3Im7pFmkbTrv3yjSeufiKIr3iv
vrK5oTmmuoLKOLkiXB3QypALFr6uVOgQ2q4etihaoCVGZTtC2Ut9Dn5fTR8Ddnp4
Z0Teh8ZV6+63O990A3JwIb8UjcfZU9bf3m5ibQGK9123NIuFrTTTjZLc9DMGBeVS
B9076Yc5FOQwZmowNHd1C5H+aKlrrDava4TvrigISYZGjITxuaCePJsCAwEAAaNC
MEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFD6l
OfgASpGdDG83Ttw6uZNOh8Q8MA0GCSqGSIb3DQEBCwUAA4IBAQBPrzqC5UY4V8wO
QJC4bTcSBBynW6RLWrPLzdPF+c0JvAjYpo1eIRP+V2Fm7XKoDlBy+xbx6qdCyE7h
q4iWVq2WQxPWk4QO8UT1P2Epx1O+YkQWhipdMmhDMbO2hm39Ho/2Jh0knrkUe0p1
+WSZOfe5zGyQ39q2u6j+LY/OHkbzmYpKosK9Oz0rUmljEt2eR7DwBZMVKwt+Fn7J
OlnzOjJXOKzXIc6ZKUK2gqdMHv6SmD1+tYPwuw+gNLpyhkklhcnVaZD4Q4G6kXcP
lQuJDrx02F2wlQb/6FPahBH7ZsPkMz7Izua03ea2vHp7s6SNEe6+E7amATdIX+xF
O23QEaIm
-----END CERTIFICATE-----

README.md contains:
git clone https://github.com/lorabasics/station.git $STATION_REPO
This should be
git clone https://github.com/lorabasics/basicstation.git $STATION_REPO

Kerlink WirnetStation
Try example

2020-01-15 15:06:40.911 [AIO:INFO]
2020-01-15 15:06:40.973 [TCE:INFO] Connecting to INFOS: wss://s2.sm.tc:7000
2020-01-15 15:06:41.932 [TCE:ERRO] Infos error: router-xxxx:xxxx:xxxx:xxxx no such router
2020-01-15 15:06:41.932 [AIO:DEBU] [3] ws_close reason=1000
2020-01-15 15:06:41.933 [AIO:DEBU] [3] Server sent close: reason=1000
2020-01-15 15:06:41.933 [AIO:DEBU] [3] WS connection shutdown...
2020-01-15 15:06:41.934 [TCE:INFO] Router rejected or retry limit reached. Invoking CUPS in 30 seconds.
2020-01-15 15:06:41.935 [TCE:INFO] Terminating TC engine

Files from example folder

-rw-r--r--    1 root     root           607 Jan 15 14:55 cups-boot.crt
-rw-r--r--    1 root     root           227 Jan 15 14:55 cups-boot.key
-rw-r--r--    1 root     root           611 Jan 15 14:55 cups-boot.trust
-rw-r--r--    1 root     root            21 Jan 15 14:55 cups-boot.uri
-rw-r-----    1 root     root           421 Jan 15 15:06 cups.crt
-rw-r-----    1 root     root           121 Jan 15 15:06 cups.key
-rw-r-----    1 root     root           411 Jan 15 15:06 cups.trust
-rw-r-----    1 root     root            21 Jan 15 15:06 cups.uri
-rw-r--r--    1 root     root           320 Jan 15 14:55 makefile
-rwxr-xr-x    1 root     root        756728 Jan 15 14:56 station
-rw-r--r--    1 root     root           968 Jan 15 14:55 station.conf
-rw-r-----    1 root     root           421 Jan 15 15:06 tc.crt
-rw-r-----    1 root     root           121 Jan 15 15:06 tc.key
-rw-r-----    1 root     root           411 Jan 15 15:06 tc.trust
-rw-r-----    1 root     root            19 Jan 15 15:06 tc.uri
-rw-r--r--    1 root     root             6 Jan 15 14:55 version.txt

station.conf

{
  "SX1301_conf": {		     /* Actual channel plan is controlled by server */
    "lorawan_public": true,      /* is default */
    "clksrc": 1,		     /* radio_1 provides clock to concentrator */
    "device": "/dev/spidev32766.0",
	  "radio_0": {
	    "type": "SX1257",
	    "rssi_offset": -166.0,
	    "tx_enable": true,
	    "antenna_gain": 0
	   },
	  "radio_1": {
	     "type": "SX1257",
	     "rssi_offset": -166.0,
	     "tx_enable": false
    }
  },
  "station_conf": {
          "routerid": "xxxxxxxxxx",
          "radio_init": "modem_off.sh && modem_on.sh",
	  "log_file":  "stderr",
          "log_level": "XDEBUG",
	  "log_size":  10000000,
  	  "log_rotate":  3,
  	  "CUPS_RESYNC_INTV": "1s"
  }
}

Any ideas?

Gateway receives Up-link and tries to upload it to the server ASAP, but the connection has been dropped after 60 seconds of inactivity, so reconnect is forced immediately, at the same time Down-link message should be sent out, but the timing is messed up now, because Gateway is busy with less important stuff.

Gateway should send out queued DL messages first, then attempt to upload UL to the server.

p.s. it's about "The Things Indoor Gateway". I guess, this was the right place to post this issue?
https://www.thethingsnetwork.org/forum/t/ttig-does-not-support-downlinks-when-not-frequently-receiving-uplinks/32052

Although Picocell Gateway is an official Semtech product, it is not yet supported by Basic Station. What is the plan and schedule of support for Picocell Gateway?

Let's try and use a different name for the update and configuration server and protocol. CUPS is the name of a unix printing server. We're causing a lot of headaches for everyone by using this same name. Googling for CUPS will give results for the more common one, which is the printing server.

Currently the EUIs are being encoded (both from Basic Station to LNS as LNS to Basic Station) as either ID6, EUI or integer.
Some example:

https://doc.sm.tc/station/tcproto.html#querying-the-lns-connection-end-point-discovery
router can be either ID6, EUI or integer encoded:

{
  "router": ID6 | EUI | integer
}

The response is expected as ID6

{
  "router": ID6,
  "muxs"  : ID6,
  "uri"   : "URI",
  "error" : STRING   // only in case of error
}

https://doc.sm.tc/station/tcproto.html#router-config-message
The JoinEui is integer encoded:

{
  "msgtype"    : "router_config"
  "NetID"      : [ INT, .. ]
  "JoinEui"    : [ [INT,INT], .. ]  // ranges: beg,end inclusive
  "region"     : STRING             // e.g. "EU863", "US902", ..
  "hwspec"     : STRING
  "freq_range" : [ INT, INT ]       // min, max (hz)
  "DRs"        : [ [INT,INT,INT], .. ]   // sf,bw,dnonly
  "sx1301_conf": [ SX1301CONF, .. ]
  "nocca"      : BOOL
  "nodc"       : BOOL
  "nodwell"    : BOOL
}

https://doc.sm.tc/station/tcproto.html#lorawan-join-requests

Here the JoinEui and DevEui are eui encoded:

{
  "msgtype" : "jreq",
  "MHdr"    : UINT,
  "JoinEui" : EUI,
  "DevEui"  : EUI,
  "DevNonce": UINT,
  "MIC"     : INT32,
  ..
}

For a future version, it would be great if these encodings can be unified into a single encoding as it would make it easier to implement the protocol 🙂

The exception raised on this line is silently hidden by the except: pass bloc on this line

Even when the LoRa Std channel is disabled, the Basic Station seems to validate the bandwidth of this channel:

         "chan_Lora_std": {
            "enable": false,
            "radio": 0,
            "if": 0,
            "bandwidth": 0,
            "spread_factor": 0
         },

Raises the following error:

2019-04-03 12:48:46.085 [TCE:VERB] Connecting to MUXS...
2019-04-03 12:48:46.103 [TCE:VERB] Connected to MUXS.
2019-04-03 12:48:46.134 [JSN:ERRO] @.chan_Lora_std.bandwidth: Illegal bandwidth value: 57 (must be 125000, 250000, or 500000)
2019-04-03 12:48:46.134 [RAL:ERRO] Parsing of JSON failed - 'router_config.sx1301_conf' ignored
2019-04-03 12:48:46.134 [any:ERRO] Closing connection to muxs - error in s2e_onMsg

This works fine:

         "chan_Lora_std": {
            "enable": false,
            "radio": 0,
            "if": 0
         },

Wouldn't it be better when enable is set to false to completely ignore the fields for this channel?

https://doc.sm.tc/station/tcproto.html

The field region specifies the region of channel plan and thereby controls certain regulatory behavior such as clear channel assessment as well as duty-cycle and dwell-time limitations. Valid names are compatible with the names of the LoRaWAN Regional Parameters specification, except the end frequency is dropped (e.g., EU863 and US902).

As the LoRaWAN Regional Parameters also provide a common name, wouldn't these be more suitable for region values?

We are using MType=Proprietary to broadcast messages between gateways for discovery / collecting meta-data. For normal gateway to device use-cases the polarization-inversion (iPol) field must be set to true. For communication between gateways, we set this to false.

Is or will this be possible with the Basic Station? This field doesn't seem to be exposed looking at the documentation.

Hi!

I'm new to Lora things, so, likely, it's not an issue and I just can't read documentation properly, but for me it's a bit confusing.
Are there any ways to use Basic Station(on hardware) with existing network server implementations which support the pkfwd protocol without porting python3.6 to the board, as it mentioned in st2pkfwd example?
If not, could you please help me and tell the minimum version(release) of LNS, which supports Basic Station features or provide me with helpful links concerning implementation LNS&CUPS+Basic Station?

Thank you in advance!

When do you plan to publish the next release?

What is the use of the device's devEUI field in the downlink messages sent to the Gateway ?
Is it mandatory or can it be filled with a default value?

You can contact me back by mail [email protected]

There is RX1DR and RX2DR and also RX1Freq and RX2Freq, but there is just a single RxDelay although the protocol defines different delay for RECEIVE_DELAY1 and RECEIVE_DELAY2 (and similarly JOIN_ACCEPT_DELAY1 and JOIN_ACCEPT_DELAY2). What is the meaning of RxDelay, please? (I think it should be documented.)

Multiple failed retries as below, and eventually segment faults and dies (which it should not do)

2019-02-22 23:13:16.253 [CUP:INFO] Starting a CUPS session
2019-02-22 23:13:16.254 [CUP:ERRO] No CUPS-bak URI configured
2019-02-22 23:13:17.254 [CUP:INFO] Starting a CUPS session
2019-02-22 23:13:17.254 [CUP:INFO] Connecting to CUPS-boot ... https://s2.sm.tc:7007 (try #3)
2019-02-22 23:13:17.256 [any:INFO] cert. version     : 1
serial number     : 0C
issuer name       : CN=Root CA, OU=TrackCentral (eiaPoUc9), O=TrackNet.io, C=CH
subject name      : CN=Root CA, OU=TrackCentral (eiaPoUc9), O=TrackNet.io, C=CH
issued  on        : 2018-11-08 12:42:00
expires on        : 2024-11-06 12:42:00
signed using      : ECDSA with SHA256
EC key size       : 256 bits
2019-02-22 23:13:17.270 [any:INFO] cert. version     : 3
serial number     : 10
issuer name       : CN=Root CA, OU=TrackCentral (eiaPoUc9), O=TrackNet.io, C=CH
subject name      : CN=gwprov-::0, OU=TrackCentral, O=TrackNet.io, C=CH
issued  on        : 2018-11-08 12:43:52
expires on        : 2020-11-07 12:43:52
signed using      : ECDSA with SHA256
RSA key size      : 2048 bits
2019-02-22 23:13:17.270 [AIO:INFO]
2019-02-22 23:13:17.463 [CUP:VERB] Retrieving update-info from CUPS-boot https://s2.sm.tc:7007...
2019-02-22 23:13:18.112 [any:VERB] Failed to retrieve TCURI from CUPS: (404) Some exception occured!
2019-02-22 23:13:18.112 [AIO:DEBU] [3] HTTP connection shutdown...
2019-02-22 23:13:18.112 [CUP:INFO] Interaction with CUPS failed - retrying in 1s
2019-02-22 23:13:19.113 [CUP:INFO] Starting a CUPS session
2019-02-22 23:13:19.113 [CUP:ERRO] No CUPS URI configured
2

   ...
   "station_conf": {
        "routerid":  "0000e8eb1141xxxx",
        /*    "euiprefix": "",   */
   ...

...
2019-11-07 07:14:29.498 [SYS:INFO] proto EUI   : 0:e8eb:1141:xxxx       (station.conf)
2019-11-07 07:14:29.498 [SYS:INFO] prefix EUI  : ::1    (builtin)
2019-11-07 07:14:29.498 [SYS:INFO] Station EUI : e8eb:11ff:fe41:xxxx
...
2019-11-07 07:14:29.734 [TCE:INFO] Infos: e8eb:11ff:fe41:xxxx e8eb:11ff:fe41:xxxx ws://127.0.0.1:3001/gateway/e8eb11fffe41xxxx
...

This will caused to operate incorrect gataway MAC e8eb11fffe41xxxx, but real MAC is 0000e8eb1141xxxx
(real data replaced by xxxx for security reason)

I am very new to LoRa tech (but very linux knowledgeable) so I may be ideal to sort out documentation issues :-D

Will the station2pkfwd stuff be what I need to connect my rpi/rak831 gateway to the TTN console? I understand that basicstation runs the new V3 protocol that TheThingsNetwork.org does not understand yet. And that I could have chosen a more well trodden path instead of testing basicstation as my first foray into LoRa. But it is more fun to test something new...

Will I have to install a packet forwarder on my pi in addition to basicstation? Or can I somehow point the code in the station2pkgfwd directly at some TTN endpoint? Googling doesn't really give me any answers.

https://doc.sm.tc/station/tcproto.html#lorawan-proprietary-frames

{
  "msgtype"   : "propdf",
  "FRMPayload": "HEX",
  ..
}

Frames marked as proprietary are forwarded in the following form, whereby the entire frame payload is passed along uninterpreted.

Does frame payload in this context mean the complete PHYPayload or the PHYPayload without the MHDR? As I don't think "frame payload" within the context of MType=Proprietary is specified by the LoRaWAN specification, this line might need some additional wording in the documentation.

In case it would be the latter (thus remaining bytes after the MHDR), then please note that you would lose the Major field information.

(In general, I would have preferred to just receive an uplink PHYPayload, without the Basic Station splitting this out by MType and PHYPayload fields.)

LoRaWAN 1.1 specifies a RejoinRequest MType. Is it correct that this MType is not (yet) supported by the Basic Station?

Are there plans to support Websocket PING / PONG messages?

Currently it seems that pings are ignored:

    case WSHDR_PING:
    case WSHDR_PONG: {
        LOG(MOD_AIO|WARNING, "[%d] Ignoring WS ping/pong message", conn->netctx.fd);
        break;
}

It would be great if at least the Basic Station could respond with a PONG.

AU915 has the same EIRP limitations as US902 and should therefore have s2ctx->txpow set to 30 in handle_router_config.

It is presently being set to 14, the default.

Hi,

1. could you add an example binary file to server s2.sm.tc which can be received by GW after request of update-info command?
2. could you add an example router_config that can be received from s2.sm.tc
   Using examples from repo I don't get this from test server s2.sm.tc, just info.

What is the thinking behind the POST request using a JSON encoding and the response encoded as binary?

Health status messages are mentioned in the online documentation Transmit Confirmation section:

"There is no feedback to the LNS if a frame could not be sent (e.g., because it was too late, there was
a conflict with ongoing transmit, or the gateway’s duty cycle was exhausted). These conditions are
summarized in health status messages and do NOT trigger an individual response."

What is the health status reporting interval and where can I find the message format?

I am seeing the below messages when I am bringing up Gateway. Any ideas what is going wrong here?

2019-06-10 07:07:04.840 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-06-10 07:07:09.041 [SYN:VERB] Time sync rejected: quality=266 threshold=230
2019-06-10 07:07:11.142 [SYN:VERB] Time sync rejected: quality=399 threshold=230
2019-06-10 07:07:28.994 [SYN:INFO] Time sync qualities: min=70 q90=220 max=399 (previous q90=230)
2019-06-10 07:07:49.996 [SYN:INFO] MCU/SX1301 drift stats: min: -1.9ppm q50: -4.3ppm q80: -5.7ppm max: -18.6ppm - threshold q90: -10.5ppm
2019-06-10 07:07:49.997 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-06-10 07:08:32.001 [SYN:INFO] Time sync qualities: min=117 q90=139 max=146 (previous q90=220)
2019-06-10 07:08:32.001 [SYN:INFO] MCU/SX1301 drift stats: min: -1.0ppm q50: -4.3ppm q80: -5.2ppm max: -7.6ppm - threshold q90: -7.1ppm
2019-06-10 07:08:32.001 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-06-10 07:09:01.404 [SYN:VERB] Time sync rejected: quality=180 threshold=139
2019-06-10 07:09:16.106 [SYN:INFO] MCU/SX1301 drift stats: min: -1.4ppm q50: -4.3ppm q80: -5.2ppm max: -6.2ppm - threshold q90: -5.7ppm
2019-06-10 07:09:16.106 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-06-10 07:09:35.008 [SYN:INFO] Time sync qualities: min=118 q90=137 max=180 (previous q90=139)
2019-06-10 07:09:51.810 [SYN:VERB] Time sync rejected: quality=138 threshold=137
2019-06-10 07:10:00.211 [SYN:INFO] MCU/SX1301 drift stats: min: -3.3ppm q50: -3.8ppm q80: -4.3ppm max: -5.2ppm - threshold q90: -4.8ppm
2019-06-10 07:10:00.211 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-06-10 07:10:13.863 [SYN:VERB] Time sync rejected: quality=148 threshold=137
2019-06-10 07:10:26.464 [SYN:VERB] Time sync rejected: quality=142 threshold=137
2019-06-10 07:10:36.965 [SYN:INFO] Time sync qualities: min=75 q90=138 max=148 (previous q90=137)
2019-06-10 07:10:45.366 [SYN:INFO] MCU/SX1301 drift stats: min: -2.9ppm q50: -4.3ppm q80: -4.8ppm max: -14.3ppm - threshold q90: -4.8ppm
2019-06-10 07:10:45.366 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-06-10 07:10:49.567 [SYN:VERB] Time sync rejected: quality=161 threshold=138
2019-06-10 07:10:57.968 [SYN:VERB] Time sync rejected: quality=139 threshold=138
2019-06-10 07:11:21.071 [SYN:VERB] Time sync rejected: quality=162 threshold=138
2019-06-10 07:11:23.171 [SYN:VERB] Time sync rejected: quality=146 threshold=138
2019-06-10 07:11:29.472 [SYN:VERB] Time sync rejected: quality=140 threshold=138
2019-06-10 07:11:35.773 [SYN:VERB] Time sync rejected: quality=140 threshold=138
2019-06-10 07:11:37.873 [SYN:INFO] Time sync qualities: min=120 q90=146 max=162 (previous q90=138)
2019-06-10 07:11:37.873 [SYN:INFO] MCU/SX1301 drift stats: min: -2.4ppm q50: -4.3ppm q80: -4.8ppm max: -6.7ppm - threshold q90: -5.7ppm
2019-06-10 07:11:37.873 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-06-10 07:12:13.577 [SYN:VERB] Time sync rejected: quality=148 threshold=146
2019-06-10 07:12:17.778 [SYN:VERB] Time sync rejected: quality=155 threshold=146

any info?

This is probably a bug.

I noticed that the Basic Station crashes when the server closes the Websocket connection (e.g. because read timeout, termination / restart of the LNS, ...). The following log is printed:

*** Error in `./station': free(): invalid pointer: 0x00a7d728 ***
Aborted

I have compiled the latest (c29b850) release on a Raspberry Pi 3.

Edit:

The same error also happens when the Basic Station fails to start the concentrator:

2019-04-15 13:08:40.904 [RAL:INFO] Station device: /dev/spidev0.0 (PPS capture disabled)
2019-04-15 13:08:41.418 [RAL:ERRO] lgw_start failed: /dev/spidev0.0
2019-04-15 13:08:41.419 [any:ERRO] Closing connection to muxs - error in s2e_onMsg
2019-04-15 13:08:41.419 [AIO:DEBU] [3] ws_close reason=1000
*** Error in `./station': free(): invalid pointer: 0x01e36728 ***
Aborted

https://doc.sm.tc/station/tcproto.html#version-message

The first message sent by Station is a version message reporting to the LNS its version information (station, firmware, model), the protocol version (the constant 2 for now), and a list of optional features supported by the gateway:

{
  "msgtype"   : "version"
  "station"   : STRING
  "firmware"  : STRING
  "package"   : STRING
  "model"     : STRING
  "protocol"  : INT
  "features"  : [ STRING, .. ]
}

However, the received JSON message does not contain a list for features, instead it contains a string.

Received from gateway:

{"msgtype":"version","station":"2.0.0(minihub/debug)","firmware":"2.0.0","package":"2.0.0","model":"minihub","protocol":2,"features":"rmtsh"}

My Network Server (NS) is receiving a Join Request from a lora node as below:

{"msgtype":"jreq","MHdr":0,"JoinEui":"00-00-00-00-00-00-00-00",
"DevEui":"00-00-00-00-00-00-00-01","DevNonce":36030,"MIC":2133412239,
"RefTime":0.000000,"DR":3,"Freq":902500000,"upinfo":{"rctx":0,"xtime":36873222082651916,"gpstime":0,"rssi":-46,"snr":13,"rxtime":1565742560.383883}}

NS is sending a JoinAccept response to Gateway like below:

var str_obj = {
"msgtype":"dnmsg",
"DevEui":"00-00-00-00-00-00-01",
"dC":0,
"diid":0,
"pdu":enc_pdu,
"RxDelay":0,
"RX1DR":8,
"RX1Freq":923300000,
"RX2DR":13,
"RX2Freq":923300000,
"priority":0,
"xtime":msg_obj.upinfo.xtime,
"rctx":msg_obj.upinfo.rctx
};

and NS is receiving an acknowledgement from Gateway as below:

{"msgtype":"dntxed","seqno":0,"diid":0,"DevEui":"00-00-00-00-00-00-00-01","rctx":0,"xtime":36873222083651920,"txtime":283578.392170,"gpstime":0}

But the lora node is not receiving the JoinAccept.

I am thinking that the Gateway is NOT transmitting the JoinAccept to Lora node in the correct receive window.

Using the data between Gateway and NS, how can NS decide on what should be the RXDelay for Gateway?

Can the experts help in letting me know whats the mistake here?

thanks
Sreekanth

Hello,

I'm from Brazil and I connected my TIG (US-915) this Sunday and it was so easy, everything was working great, uplink, downlink, etc.
But on the next day, I noticed the gateway was offline on the TTN console, but the led was solid green, no packages.
I tried to turn off for some time, reset but nothing works. Then I decided to open the TIG and check the debug serial...

I found this error.

2019-02-11 21:11:08.546 [SYS:DEBU]   Free Heap: 19104 (min=16816) wifi=5 mh=7 cups=8 tc=4
2019-02-11 21:11:09.135 [AIO:DEBU] ssl_tls.c:6546 MBEDTLS[1]: mbedtls_ssl_read_record() returned -30848 (-0x7880)
2019-02-11 21:11:09.141 [AIO:ERRO] Recv failed: SSL - The peer notified us that the connection is going to be closed
2019-02-11 21:11:09.146 [AIO:DEBU] [2] WS connection shutdown...
2019-02-11 21:11:09.157 [TCE:VERB] Connection to MUXS closed in state 4
2019-02-11 21:11:09.165 [TCE:INFO] MUXS reconnect backoff 2s (retry 1)

I really have no idea what that's mean.

Someone?!

There notes in commits about release version but no tags to the commit.

Issue 11 is not resolved.

#11

Please confirm resolutions either by testing yourself or asking the submitter to confirm the fix.

The documentation says BW MUST be one of the numbers 125000, 250000, 500000, wheres the implementation expects 125, 250 or 500.

https://doc.sm.tc/station/tcproto.html#router-config-message

{
  "radio_0": { .. } // same structure as radio_1
  "radio_1": {
    "enable": BOOL,
    "freq"  : INT
  },
  "chan_FSK": {
    "enable": BOOL
  },
  "chan_Lora_std": {
    "enable": BOOL,
    "radio": 0|1,
    "if": INT,
    "bandwidth": INT,
    "spread_factor": INT
  },
  "chan_multiSF_0": { .. }  // _0 .. _7 all have the same structure
  ..
  "chan_multiSF_7": {
    "enable": BOOL,
    "radio": 0|1,
    "if": INT
  }
}

The only documented option for chan_FSK is the enable key. I would expect to also be able to set the if, radio, ... Are these implemented but missing in the documentation?

Hi!
Is this Basic Station compatible with libloragw for sx1302?

The basicstation performs a TX window selection, and sends a Transmit Confirmation (dntxed) when the transmission is done.
Would you mind extending the "dntxed" to indicate which TX window (what frequency and DR) was selected for the transmission? The server may want to calculate the gateway TX duration and select a GW (if multiple gateways are used) based on dwell constraints.

Please note that splitting the frame into pieces doesn't help the server at all. The server is required to verify the MIC based on the entire Frame, so it has to parse the JSON content and reconstruct the frame back to its original form. The reconstruction requires parsing the dash-separated EUI back to a binary form, which (at least in my case) is more complicated than if I had to parse the binary frame on my own.

https://doc.sm.tc/station/tcproto.html#router-config-message

The sx1301/**N** should be rendered as sx1301/N I believe :-)

Is this key really needed? Can't the Basic Station derive this from the sx1301_conf JSON key as I believe N == length(sx1301_conf)?

After short time, regularly, basicstation process interupted
Log:

2020-01-17 06:39:27.729 [TCE:INFO] MUXS reconnect backoff 1s (retry 0)
2020-01-17 06:39:28.745 [TCE:VERB] Connecting to MUXS...
2020-01-17 06:39:28.748 [TCE:VERB] Connected to MUXS.
2020-01-17 06:39:28.805 [any:CRIT] Radio device '/dev/spidev32766.0' in use by process: 1609

but ps | grep 1609 show nothing.

When you run :

station --version

The station prints the output in stderr. I would expect this going to stdout as it is the asked result.

In the readme, add a line to set STATION_REPO before using it in the instructions.
Also, I had to reset my RAK 831 with this little script before starting station, so perhaps add it to the repo or instructions?

#!/bin/bash 
echo "17" > /sys/class/gpio/export 
echo "out" > /sys/class/gpio/gpio17/direction 
echo "1" > /sys/class/gpio/gpio17/value 
sleep 5 
echo "0" > /sys/class/gpio/gpio17/value 
sleep 1 
echo "0" > /sys/class/gpio/gpio17/value 

Otherwise this seems to have worked fine on my rpi/RAK 831. Now I am just wondering what the next steps are to get my gateway onto the map.

The Things Indoor Gateway makes use of an ESP8266 speaking the basicstation protocol to the backend. See: https://www.thethingsnetwork.org/forum/t/ttig-the-things-indoor-gateway/22049

It is therefore possible to use this basicstation software on an ESP8266. Could you please give us an example of how to do this, or opensource the TTIG's firmware. It would be tremendously useful to be able to build our own ESP8266 or ESP32 based gateways that are full 8 channels, not single channel gateways. Using an ESP8266 or ESP32 is muh cheaper than using a Raspberry Pi, so make deploying more gateways possible.

Initialization of some radios take longer than 200ms. There is an undocumented RADIO_INIT_WAIT parameter, which can be used to increase this number. The "radio_init" works as lowercase, but "RADIO_INIT_WAIT" seem to work as uppercase, which is a bit confusing.

The following works for me

"station_conf": {
...
   "radio_init": "./reset_lgw.sh start",
   "RADIO_INIT_WAIT": 500
}

The frequency plan of the Gateway is exchanged with the LNS .
Is this file mandatory in the exchange sequence with the LNS when connecting or can it be stored directly in the Gateway and update later using CUPS?

See: https://help.github.com/articles/setting-guidelines-for-repository-contributors/

Just looking for details on what you expect if someone is to contribute back (style guides, CCLA if any, process, etc).