Why only v2.2.x of the Forwarder can be used?

(Vanthome) #1

There is only a hint buried in the docs in the page below that only version 2.2.x of the forwarder can be used:


why is that? I would like to use the mainline forwarder from the Lora Alliance for TTN.


Semtech changed the protocol for version 3.x which makes it incompatible with TTN. Keep in mind the forwarder provided by semtech is an example program, not an implementation to be used everywhere. TTN will be using a custom forwarder in the near future to enhance security and reliability.
(Other LoRaWAN providers also use their own protocols)

(Vanthome) #3

ok, many thanks for the explanation. I'm aware that it's only a sample implementation but have the impression most networks use it and I also think it's in the best interest of the LoRAWAN Community to align stuff with each other. Anyways, I'm curious to see why and what TTN will do in the forwarder area.


All commercial providers I know of software with a proprietary protocol.

The why:
The reference implementation uses an unreliable (UDP) unsecured protocol (meta data unencrypted) without any authorisation build. This means anyone knowing the receiving IP and port can start sending data, valid or otherwise. The TTN protocol implements authentication, uses a reliable transport (TCP) and (I assume) will use encryption.

(Hylke Visser) #5

I'm pretty sure the v3 version of the packet forwarder works fine with TTN. We just don't do anything with the TX_ACK that was introduced in that version.


So you just ignore the protocol version byte in the UDP datagramms, right?

(Hylke Visser) #7

No, we actually support both protocol versions.

(Vanthome) #8

would be nice if anyone could confirm that the latest semtech package forwarder works with TTN.


I'm curious what you think you gain by using the latest semtech package in stead of a known working poly forwarder? (Which is more or less the reference implementation forwarder for TTN :wink: )

(Vanthome) #10

well I thought that's obvious. In SW engineering you try why to prevent to have two diverging (or even more) forks of something. You try to have a main line to prevent the risk that branches fall behind. And looking at the semtech forwarder's repo exactly that happened. There were a lot of commits since the TTN fork was created.


And of obviously all updates are improvements. So Semtech dropping support for USB connected LoRaWAN concentrators leaving MultiTech conduit owners out in the cold is something TTN immediately wants to implement as well? :wink:

Be assured we're working on integrating improvements into the TTN fork, however we would prefer not to exclude a large part of the (current) community while doing so.