Announching LoRa Gateway OS

In order to make it even easier to get started with LoRaWAN and the LoRa Server project, I’m announcing the LoRa Gateway OS compoment. The LoRa Gateway OS provides recipes for building Yocto based images for gateways that provide a Yocto BSP layer. Pre-compiled images can be downloaded from the LoRa Gateway OS Documentation.

Getting started is as easy as flashing the image to a SD card and inserting this SD card into the gateway :slight_smile: Each image also contains a gateway-config command for basic configuration options:

The initial (test) release supports:

There are two types of images:

  • base: to use the concentrator as a gateway only
  • full: run the full LoRa Server / LoRa App Server suite on the gateway (including all dependencies)

This is a test release and I’m looking forward to your feedback how this can be improved!


Good news. :+1:

Just typo 381 instead of 831 :blush:

1 Like

Good catch! Fixed (also in the documentation).

Thanks a lot! Amazing. Few issues I’ve experienced while going through the whole process:

  1. Issue with the user id
    Somehow you’re creating a user with an id of 999 but actually I’ve had to change it manually to 1000 otherwise it wouldn’t match. That involved:
  • changing the “script” in the Dockerfile and generating a userID of 1000 instead of 999
  • obviously changing the chmod command for the build directory
    And if I remember well nothing else.

Doing that the process went to the end flawlessly which is quite something given my total lack of experience with docker, Yocto etc…

  1. There is no built-in support for other locals than en_US. That’s a serious issue for a server you’re supposed to use only in command line… I’ve hacked a dirty loadkeys post deployment but I’m sure there is a proper way of doing it.

  2. I really need OpenVPN on the gateway. TLS on the MQTT is not sufficient. I didn’t find any easy most importantly proper way of adding additional packages (in particular integrating them properly in the life cycles with monit etc…) and that would Really add a lot of value to be able to do that…

  3. I’m facing a reccurent issue once deployed on a raspberry pi 3B with a SX1301 based shield: I keep getting the following message in the admin console « INIT: Id “S0” respawning too fast: disabled for 5 minutes » and I don’t have a damn clue where it’s coming from.

Thanks again for the great work!

Thanks for the feedback!

  1. I’m not sure why 999 isn’t working for you. It works at my side, but great that changing this to 1000 solved it for you.

  2. Do you mean the docker environment or the final image?

  3. see As the meta-networking layer is already loaded, the only thing you need to do is add openvpn to Then obviously you need to rebuild the image :slight_smile: (in this case the lora-gateway-os-base image, else you need to modify the -full recipe in the same directory.

  4. I have not seen that error, but maybe this helps?


Thanks for your helpful reply. I’ve tried and checked a few things. Here is what’s going on:

  1. It has consistently been like than each time I’ve tried. I’ve tried on different hosting platforms (private), each time with a VM (Debian or Ubuntu).

  2. Final image is what I mean. It’s seriously annoying.

  3. Thanks for the guidelines. I’ve done exactly that and it works except for 2 “details”:
    a. /usr/sbin is not in path so you need to manage this by yourself. I didn’t find out how to append it to path from the recipe. I tried something but it didn’t work and didn’t spend too much time on it. Maybe there is some security reason why it’s not done anyway and it’s not very annoying.
    b. The tun interface apparently isn’t “native” in this implementation. So each time you reboot the raspberry you have to do a ‘sudo sh -c “modprobe tun”’ in order to be able to launch openvpn properly. I guess you know better than me what it does (loading some kernel module?). Once again it would be cool to be able to have all this managed directly from a recipe but I didn’t find out how.

  4. Following the guidelines in your links :wink: I’ve found out that by removing a line in the inittab, the issue disappears. The line that needs to be removed is something like:
    S0:12345:respawn:/bin/start_getty 115200 ttys0 vt102
    I think there are some side effects of removing it (like you see less messages when you boot it seems) but it seems to remove one of the big issue I was also experimenting: somehow huge waits sometimes when entering some commands in the console, particularly sudo commands I think. Someone advised to write something like ‘UART = “1”’ in one of the recipe if I remember and it made the problem disappear indeed but also the WiFi…
    This issue is not completely clear to me up to now honestly.

  5. Now this is the big issue I have realized now that I was not only working on the installation process but now also trying to prototype things: the packet forwarded doesn’t start. Monit says exactly “Execution failed | Does not exist” as a status (FYI I’ve tried on 2 different raspberry 3 B each with a different shield). That’s the killer for me. What would you advise for this one? At least to be able to investigate the issue?

Thanks again for your support.


1 Like

Few updates:
3. Is solved by just following usual openvpn deployment guidelines

  1. I’m not sure it was this issue creating the delays actually. It might be linked to monit always trying to start the packet forwarder and it failing each time.

At the end I don’t think issue 1., 4. and (most importantly) 5. should be specific to me as I’m not doing anything exotic to create them (using the normal conf/steps, vanilla RPi 3B, etc…). I really wonder if other people are facing the same issues. Issue 2. is probably common to all non English native speaking geographies.


Could you share which concentrator shield you’re using? And did you run the gateway-config command to select your packet-forwarder configuration?

Please note that on a Raspberry Pi3 it takes a couple of attempts to start the packet-forwarder. I believe this has to do with the SPI interface on the Pi3, see also:

It might take a little bit of time as Monit checks the status each x seconds. If you want to start the packet-forwarder manually and log the output:

cd /etc/lora-packet-forwarder
sudo /opt/lora-packet-forwarder/lora_pkt_fwd

Thanks a whole lot for the efficient answer.

Here we go:

  • yes I did the gateway-config, including setting up the reset PIN (22 on this shield as well as on the usual IC880A - believe me, I’ve tested it electrically). I also checked the network forwarder config file but didn’t change anything as everything seemed ok to my untrained eye

  • here are the details of the shield:
    . Product page:
    . Product “datasheet”:
    . Their proposed deployment method:

  • I read your link on the SPI issue on the RPi3. It might very well be what I’m facing. AFAIU, the packet forwarder they’re talking about in the thread is not the same one as the one included in your image so that their solution doesn’t apply. If this understanding is indeed correct it would be pretty nice if you could manage the necessary patch directly in the image generation as the intended target of the image is the RasPi… any luck of that happening anytime soon?

Whatever happens next, thanks again!!!


BTW, here is the log you asked for:

raspberrypi3:/etc/lora-packet-forwarder$ sudo /opt/lora-packet-forwarder/lora_pkt_fwd

*** Beacon Packet Forwarder for Lora Gateway ***

Version: 4.0.1

*** Lora concentrator HAL library version info ***

Version: 5.0.1;

INFO: Little endian host

INFO: found global configuration file global_conf.json, parsing it

INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters

INFO: lorawan_public 1, clksrc 1

lgw_board_setconf:427: Note: board configuration; lorawan_public:1, clksrc:1

INFO: no configuration for LBT

INFO: antenna_gain 0 dBi

INFO: no configuration for tx gain lut 12

INFO: no configuration for tx gain lut 13

INFO: no configuration for tx gain lut 14

INFO: no configuration for tx gain lut 15

INFO: Configuring TX LUT with 12 indexes

INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 0

lgw_rxrf_setconf:476: WARNING: NOT A VALID TX NOTCH FILTER FREQUENCY [126000…250000]Hz

lgw_rxrf_setconf:488: Note: rf_chain 0 configuration; en:1 freq:867500000 rssi_offset:-166.000000 radio_type:2 tx_enable:1 tx_notch_freq:0

INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0

lgw_rxrf_setconf:488: Note: rf_chain 1 configuration; en:1 freq:868500000 rssi_offset:-166.000000 radio_type:2 tx_enable:0 tx_notch_freq:0

INFO: Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 0 configuration; en:1 freq:-400000 SF_mask:0x7e

INFO: Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 1 configuration; en:1 freq:-200000 SF_mask:0x7e

INFO: Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 2 configuration; en:1 freq:0 SF_mask:0x7e

INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 3 configuration; en:1 freq:-400000 SF_mask:0x7e

INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 4 configuration; en:1 freq:-200000 SF_mask:0x7e

INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 5 configuration; en:1 freq:0 SF_mask:0x7e

INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 6 configuration; en:1 freq:200000 SF_mask:0x7e

INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12

lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 7 configuration; en:1 freq:400000 SF_mask:0x7e

INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7

lgw_rxif_setconf:581: Note: LoRa ‘std’ if_chain 8 configuration; en:1 freq:-200000 bw:2 dr:2

INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate

lgw_rxif_setconf:637: Note: FSK if_chain 9 configuration; en:1 freq:300000 bw:3 dr:50000 (50000 real dr) sync:0xC194C1

INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters

INFO: gateway MAC address is configured to B827EBFFFE6E0474

INFO: server hostname or IP address is configured to “localhost”

INFO: upstream port is configured to “1700”

INFO: downstream port is configured to “1700”

INFO: downstream keep-alive interval is configured to 10 seconds

INFO: statistics display interval is configured to 30 seconds

INFO: upstream PUSH_DATA time-out is configured to 100 ms

INFO: packets received with a valid CRC will be forwarded

INFO: packets received with a CRC error will NOT be forwarded

INFO: packets received with no CRC will NOT be forwarded


ERROR: [main] failed to start the concentrator


Where is the apt or apt-get? I can not install anything. How can I install python for example? dpkg is absent either.

This is the same error I get, but after a few retries (either manual or waiting for Monit to do this for you), I am able to start the packet-forwarder on the RPi3.

You can use opkg but please note that there is no package-repository, so everything you need you need to compile yourself or modify the Yocto recipes and generate a new image.

Well, not me: monit has been trying to launch it for 3 days and it still doesn’t work… (that’s on 2 different concentrators…). Is there no way to investigate in even more details?

That sounds like an issue. Usually it takes max. a couple of minutes. I did test with the RisingHF, RAK831 and IMST shield without any issues. Currently I have one RPi3 with RisingHF and one RPi3 with RAK831 shield connected. Let me try again with the IMST shield this week.

Thanks. It might be that the 2 shields on my side are broken but I think the probability is very low. I think it’s rather a design issue. Either on the side of the shields or on the software side. I’ll contact sandbox. Do you want me to request them to send you a sample?

I agree. I do have an IMST shield to test with, but I don’t hava a Sandbox shield. If you could arrange a sample one for me to test with, that would be really welcome. It also means I will add the shield to the list of supported concentrator shields + link to their website and will add a menu-entry for it in the gateway-config utility :slight_smile:

@Xornix please see the setup on a RisingHF shield below, will also test again with an IMST shield:

(this is using a fresly flashed lora-gateway-os-base image from the downloads).

Please note that pin 22 maps to GPIO 25, so you must enter 25 instead of 22. Maybe I could adjust the wording in the gateway-config script. I took the wording from lora_gateway/ at master · Lora-net/lora_gateway · GitHub, but I agree this could be confusing (I made the same mistake initially and ran into your error).

Afbeeldingsresultaat voor raspberrypi gpio

Raspberry Pi3 + IC880A (IMST) shield with a fresly flashed lora-gateway-os-base image downloaded from

Brocaar, that was the issue indeed…
The wording is seriously misleading and should definitely be updated!!! I thought about it but thought “no, PIN is PIN and GPIO is GPIO”. Shame on me for not trying it though.

Thanks. I’ll still contact Sandbox if you want for you to be able to reproduce further issues.

Cheers and thanks again for the support.

1 Like