Payload decoder: check the port number

TTN V2 to V3 Upgrade V3 Applications
1

On TTN Mapper I recently started seeing a lot of invalid data points, like below:
image

This also happens to devices that were mapping fine for years on V2.

Further investigation shows that V3 is forwarding port 0 data to the payload formatter. Naive payload formatters do not check the port number, and decode port 0 mac commands as if they are coordinates.

See the raw data for the device in the above screenshot here:
port0decoding.csv.txt (120.8 KB)

In this CSV we can see that it is the packets received on port 0 that is causing the invalid locations on the map.

How to fix this:
Add a check for the port number in your payload decoder. If you know you are sending gps coordinates on port 1, add a if check like this:

function decodeUplink(input) {
  decoded = {};
  
  if(input.fPort === 1) {
    decoded.latitude = bytes[0]...
    decoded.longitude = ...
  }

  return {
    data: decoded,
    warnings: [],
    errors: []
  };
}
3 Likes
2

Good reminder indeed!

What’s interesting is that while an argument could be made that MAC-only packets shouldn’t be going to an application packet decoder, I feel like a while back someone was loudly complaining that an older version of this wasn’t sending them there.

Regardless if port 0 packets should be going to the decoder or not, a decoder that doesn’t check the port number at all is a bad decoder…

3

I’d say this is a bug. The Application Server has no business with MAC commands on port 0 uplinks. If people want to debug MAC commands they can use events emitted by the Network Server.

@johan @adrianmares what do you think?

4

Related Github issue: fPort 0 data confuses naive payload formatters · Issue #4668 · TheThingsNetwork/lorawan-stack · GitHub

5

Thanks for the reference. Let’s have further discussion in that issue (and not here on the forum).

6

Because?

If it’s open source, then it’s open source and all can contribute.

7

A slack channel perhaps?

8

What’s wrong with on here?

9

Indeed, anyone can see, and AFAIK comment on issues at the github repo

In terms of user needs, the forum makes a lot of sense, and I’m not convinced the change now enacted was not a bit hasty - particularly, “protecting naive decoders from their naivety” is perhaps not a great motivation.

But in terms of the software itself, having decision history tied to issues is a lot more typical than having it tied to external forum posts.