Hello,
I am looking for lorawan gateway which is officially supported by openwrt. This has the advantage of getting the latest updates directly from openwrt and not depending on the device maker which usually is very slow to update.
If you have recommendations please let me know.
Thanks.
OpenWRT is a project based around WiFi routers that has morphed in to an embedded OS others can use with low cost SoC, but fundamentally is a community endeavour - so if they happen to âofficiallyâ support a LoRaWAN gateway, it will be on the OpenWRT website, but not in the commercial support sense: https://openwrt.org/toh/views/toh_available_16128 - a quick find on that page for LoRa didnât get anything.
Mostly we leave our gateways alone - if it works, donât fix it - only if there is a significant security issue would I look to upgrade the OS - and as both of my M2M OpenWRT based gateways are on NAT behind a fibre router, getting to them would be a bit tricky, so no need really.
The M2M gateway is available here: https://m2m-tele.com/shop/ but they havenât had any in stock for a while so Iâm not sure if they are still making them. They give all the details you need to do OpenWRT things with the Orange Pi board they use so this is an option if you do want to play, but I doubt they can provide you with free ongoing support if you find issues each time you update. As they use the Orange Pi this will give you an officially supported OpenWRT release and the update instructions are here: https://m2m-tele.com/blog/2019/05/18/lorawan-gateway-gw-01-developers-guide-openwrt/
Thatâs relatively unlikely to happen, unless a manufacturer or community member makes a very determined effort to make it happen.
In practical terms, what really matters is having a setup for which you have all the sources. Dragino publishes what appears what appears to be everything you need for their production 8 channel gateways. RAK does not, but what theyâve published in the past for their MT7628 dev kit where you had to wire the concentrator up by hand can be made to run on the production gateways and other similar platforms - key things are some SPI related patches to the kernel and the lora gateway hal, otherwise itâs just the Semtech repos.
If you really want an officially supported gateway, then pick an embedded computer with SPI that is officially supported and add a concentrator to it. Or one with USB and add a picoGW concentrator.
The true advantage of OpenWrt on a gateway comes about mainly in systems using router SoCâs that can boot from NOR flash.
Thanks for the response!
Yup, I was looking at the same page and found no entries for RoLa that much.
They did have the dragino node, but not the gateway, although dragino does have their own support for their gateway - a bit behind still using version 18.
How is your experience with gw-01 so far? Whatâs the range? Is it easy to upgrade to latest openw
It just works. If I need to see what they are hearing from nodes, I ssh in and look at the logs. All good.
As I have a âproperâ antenna, Iâve got ranges from 10m to 100km depending on line of sight & location of the device - Iâve no reason to suspect they are any worse or any better than any other gateway. But the range question is always a mistake to ask as there are too many variables & options.
As above, they are behind NAT routers and ONLY run the packet_forwarder so Iâve never bothered updating them.
Thanks for the feedback!
I plan to do lots of experiments with openvswitch on the lorawan gateway, this is why the ability to upgrade to latest version is important to me.
But you are right it really depends on the device makerâs commitment or someone from the community.
For dragino, I am leaning towards their 308 gateway. I am just a bit hesitant because I need to manually build and update the firmware to the latest (v19). It currently has v18.
Your suggestion to use embedded device + concentrator is very interesting, and certainly worth pursuing. I am learning something from pros in this forum. 
Thanks!
Why do you need to update the perfectly running OS?
Up to 100km is awesome. 
I think I mightâve missed something here. I thought most lorawan gateway will be setup behind nat router out of the box. It seems like you have to set it up differently. Do we need to expose public ip/port for it? Does it matter whether you want to connect it to TTN or just for private use?
Several virtualization packages. Notably the openvswitch.
You have experience with the dragino 308? I would like to hear it. 
I think you missed the note about range being a distraction - in the right situation you can get 832km (live demo at a TTN conference with atmospheric ducting) https://www.thethingsnetwork.org/article/lorawan-world-record-broken-twice-in-single-experiment-1
Re-read what I typed twice, I have my gateways behind NAT routers that only make outgoing connections for which the aforementioned routers were told to allow outgoing connections so no particularly configuration was necessary. And as they ARE behind NAT routers I donât feel the need to upgrade them. If I want to kill a gateway, I have a selection of Pi based units that I can royally screw the firmware/OS on and not have to do battle with anything other than swapping an SD card, the instructions for updating an Orange Pi almost look like they start with âhow to brick your deviceâ.
If you have a private set of servers (a whole new learning curve) how you configure them & their ports is up to you.
Seems to be two very differing things being put on the same piece of hardware!
He he he, this is the secret sauce of the project.
??? Why would you want a LoRaWAN gateway to run other software? A LoRaWAN gateway needs to process LoRaWAN packets and pass them on to a backend, not juggle other tasks as well. That will only result in suboptimal performance of the LoRaWAN packet forwarder.
I do have experience with LG308, works very well out of the box, the latest firmware makes setup very easy. However it does not have a lot of ram and flash to spare for other tasks. (And it does not need it, so no need to increase the price of the hardware)
If you want to experiment with openwrt stuff and you are looking for supported hardware I would look at non LoRaWAN hardware as that is where the projects focus is.
Thanks for the feedback on LG308.
So far the best advice I got for openwrt/lorawan platform is the following:
Being a LoRaWAN gateway is a very trivial and low resources job for even a rather old router platform.
Putting something in the field and getting it power and Ethernet is enough of a project that if there are other useful things it can do that can make sense, too.
One could of course put out two boxes but then which should own the Internet backhaul and provide connectivity to the other? If you were really concerned youâd almost need three - one to be the local router, one for LoRaWAN, one for the other tasks. Iâm happy just using one Openwrt system for it all, but your mileage may vary.
Having over 15 gateways in the field and having written and released a packet forwarder I am aware of the (low) load it imposes on the CPU. However for forwarders not using the ancient UDP protocol the memory footprint is relatively large for the mostly limited amount of memory in the average openwrt device. So the basic router functions and wireless (WiFi and 3G) backhaul wonât be a problem but something like SDN might well be something that tips the scales the wrong way.
I assume youâve based your hardware on something with a decent amount of ram and flash and not the 16 MB flash the LG308 has. For that device with the stock firmware thatâs sufficient flash but It is not a lot when you want to add functionality. At least not for the average programmer these days, theyâre used to gigabytes not megabytes.
(I happily use controllers with a couple of KB. I started programming on a CBM3008 with a whopping 8K ram and tapes for permanent storage and a ZX81 where the 1 KB of ram was shared between the program and display memory)
In the context that the OP was hoping to run some massive piece of virtual network switching software designed to route packets between virtual machines, I too would expect the gateway to suffer.
Are you familiar with the Monty Python Four Yorkshire Men sketch? 1024 bytes, luxury, when I were a lad, punched cards to program & magnetic core memory âŚ
Still have my Uni stack of FORTRAN punched cards in the loft! (Really should have a clear out 
) Also still have old Nascom, acquired as pre-uni apprentice, that came as a kit of componentsâŚbare pcb upâŚthat supported 1-8K of (IIRC) 2708 UVEPROM & 1k Static RAM. Started building Friday evening finished > 2,000 solder joints and next to no sleep later on Sunday a.m. and powered up 1st time (
might be only time have ever managed that 
) then off to pub for pint to celebrate for lunch! ⌠and you try telling the youth of today, they never believe you⌠now where did I put my knotted hanky?.. (M.P. Ref = 
)
You made me actually check. My current OpenWrt image with all sorts of fun stuff, and actually using python as an intermediary to turn the UDP into MQTT-over-ssl, tips the scales at just over 8 megabytes.
For me, thatâs huge. Iâm more used to OpenWrt coming out in the 5 megabyte range.
But even in a 16 megabyte NOR flash that leaves ample room for U-Boot and even to add a fallback compact Linux image for issue recovery.
Other people (eg, the gateway manufacturers) go so far as to run an installation of Chirpstack on these platforms - which means not just the LoRaWAN network server, but postgres and redis to support it, too.
Is it allowed to ask what advantage you see for running openvswitch on a simple LoraWAN Gateway? For now i see only a overcomplication, waste of ressources and multiple additional points of possible failureâŚ
Iâd missed some of the possible nuance of that, though perhaps because the goal is less than clear.
So what Iâd say is:
Running other sorts of âbox in the fieldâ things of the sort that people are already making OpenWrt do can be reasonable - one certainly needs to watch image size, network, usage, and beware anything that could cause the system overall to pause, but in general terms a gateway can juggle other tasks within reason.
VPN solutions are things people commonly put on gateways not really to protect their traffic, but to give a path in for remote administration: as such theyâre one of maybe three classes of solution: virtual network actually allowing inbound connection, SSH outbound connection with a port forward back in, and task-based daemons that poll a dispatch server for specific commands and run them. There are probably other ideas, too. Both VPN and SSH tunnel solutions are commonly deployed on OpenWrt gateways.
In terms of a gateway participating in some cloud packet interchange scheme, itâs good to remember that gateways tend to be far less physically secure than cloud machines, and are out on the big bad Internet rather than on data centerâs private and peering interconnect. What all of that means is that a gateway should probably interact with your cloud only through a narrow and guarded door. Itâs from the ingest server that you then start routing things on whatever fun internal scheme you want to use, to servers inside the fence which arenât even routable from the Internet. Think of gateways a lot like web browsers as being largely external to data infrastructure. And just as with field-deployed IoT devices in general, any client trust tokens or keys you have in gateways should be unique to that box, not common across all of your system or fleet of ownership, such that if someone steals one gateway and starts abusing its keys, you can just cut invalidate that gatewayâs keys server side and cut it off while everything else keeps running.