Hi, does RAK7258 gateway and other RAK gateways have full and latest OpenWrt version?
Is it possible to build a custom OpenWrt firmware for RAK7258 with custom packages?
No. RAK’s builds use old 15.x OpenWRT versions because MediaTek hasn’t released a wifi driver for current kernels. However, wifi is not what you would typically want to use for an actual deployed gateway anyway, so in theory someone who wanted to forward port key customizations could use something more recent.
Upstream OpenWRT post LEDE re-merge does have a more recent version for the MT76x8 in general, mostly limited in uptake by the wifi situation, but if you write that out of the requirement you could probably adapt the gateway functionality to work on top of it. It will take some work however.
Is it possible to build a custom OpenWrt firmware for RAK7258 with custom packages?
Indeed, it is. But you have to look at the sources for their MT7628 kits - those work on the productized gateways too. They don’t seem to provide sources (even for the components like Linux itself with licenses that legally obligate them to) for the version they ship on their product-like gateways, though there may not be any actual difference in those GPL etc components from the sources they do provide for the kits. Note that in such case you get only traditional barebones gateway functionality - not their luci extensions to configure gateway functionality, the embedded loraserver/chirpstack, packet visualizer, etc. But those aren’t really what would typically be wanted when supporting a serious network anyway - instead you’d want to setup a path for remote access.
Mostly what you need are their modifications to the kernel SPI driver, and to the HAL library used by the packet forwarder - both of which are in their sources for the kits. In theory you could take the diffs of those commits as a guide and make corresponding changes to other kernels and the hal versions backing other packet forwarders.
If you know your way around OpenWRT it’s also possible to modify the system in some ways, add additional executables, etc without doing a full rebuild.
Worth noting that Dragino seems to offer the actual (and more recent) sources for their productized OpenWRT gateways based on the competing Atheros AR9331 SoC. Dragino’s sin is more selling node class radios labelled as “gateways” at the lower end of their product line (both the fakes with node radios and the real gateways with actual SX130x concentrators seem to use the same OpenWRT source repository)
That was in the past. Dragino specifically mention only the sx1301 based ones are LoRaWAN compliant these days. Now the dealers need to catch up and update their product descriptions.
I was referring specifically to their current behavior of selling node class radios as “gateways” of at most obscure and narrow purpose, and especially doing so in their own listings on consumer-ish channels where often those are the only models offered and buyers may not understand the difference they are subtly encoding by using the word “LoRa” vs. “LoRaWAN”. Most non-LoRaWAN LoRa networks need actual concentrators just as much as LoRaWAN networks do. The things that don’t are more the point-to-point serial links.
If there was an actual identified and routinely utilized purpose Dragino were promoting them for, I might believe that. As is, those boxes seem to exist to make money disappointing people.
But I do give them credit for providing what seems (at least in quick examination) to be a proper open source release to support their actual gateways. They just need to market those instead of the useless boxes.
I understand your point about the casual user not knowing the difference between LoRa and LoRaWAN, however the node class radios can be considered a gateway for LoRa solutions, not everyone requires a full SX130x class concentrator for a gateway. Your define those as ‘point-to-point serial links’, other people view that differently. Such a solution is perfectly valid for 100 devices sending data every once in a while (15-30 minutes) so are a low cost entry to long distance communication. Not to LoRaWAN, that’s where we are in agreement.
If you look at the actual economics, after pricing out the hundred nodes and installing them, the tiny cost difference between these overpriced nodes and an actual gateway can’t cover even a single hour of engineering time fighting with the limitations (not just channels, but SF). Accepting the limitations of a node-class radio only makes sense where you need almost as many boxes in one role as the other - and these are too expensive for such use - similarly some kid using their after school job earnings to play with LoRa would do better to get two actual nodes at node pricing and wire one to their PC or pi, rather than waste 2/3 of what an actual gateway would have cost.
And it’s not like these are carried on a price sheet for rare applications; they are the only “gateway” Dragino lists in their own storefront on a certain e-commerce platform, where they show up just below where the pricing of actual gateways from others starts.