Can the fport value be changed at the gateway? (No)

I am doing some research about fport. I am working on a new LoRa/LoRaWAN YouTube tutorial about payload formatters and fports. I know that the fport value can be set programmaticaly (1-223) and the fport value is not encrypted. Lets assume a device transmits its sensor data and the fport value is set to 10. The message is received by both gateways A and B. Both gateways forwards the received message to the same public LoRaWAN network, for example TTN.
Lets assume gateway B is owned by a hacker. My question is: Can the hacker change the fport value from 10 to 5 at the gateway and than forward the package to the public LoRaWAN network?

If this is possible I have to mention this in my video, that fport should not be used for something critical or sensitive. I searched this forum, Google and the LoRaWAN 1.0.2 specification (https://lora-alliance.org/wp-content/uploads/2020/11/lorawan1_0_2-20161012_1398_1.pdf) but could not find ANY information about the subject.

I’m no expert on this subject. There is a MIC (message integrity code) that is calculated over the MAC payload. This includes the fport and fcnt fields. It is calculated using the NwkSKey.
See paragraph 4.4 in the document you linked:
msg = MHDR | FHDR | FPort | FRMPayload

The NwkSKey is only known on the device side and somewhere in the backend (network server?). If you modify the fport, the MIC will no longer match. The gateway does not know the NwkSKey that was used to calculate it, so it cannot verify or recalculate the MIC, it just passes the data along.

So, if the gateway just modifies the fport, the backend will notice the resulting MIC mismatch and drop the message.

The payload formatter has absolutely nothing to with this.

1 Like

Betrik, thank you very much. I just read paragraph 4.4 and you are right. Stupid of me that I didn’t read that!

I was working on a payload formatter decodeUplink and the required input to this function is a json object for example {“fPort”: 4, “bytes”: [09,60,07]}. I needed more information what exactly fport was, … and one thing lead to another… and finally to my question. Again thanks.

Also if doing a tutorial be sure to call out restricted/reserved FPort values and ones to be avoided (e.g. 200 or 201 IIRC, recommended by L-A for use in Multicast/FUOTA implementation set ups etc.) if avoiding possible conflicts in use cases.

Please make sure to create your tutorial for TTS CE (formerly known as V3). Creating new content for V2 which will be read only (no new nodes/gateways/applications) in 32 days does not make sense…

Hi Jeff, is there a document or link where I can find this information?
On this forum i found this information:
… there are other well known port numbers defined by lora alliance, so avoid to use them freely:
200 Remote Multicast Setup
201 Fragmented Data Block Transport
202 Clock synchronization …

Hi Jac, starting from my last tutorial “LoRa/LoRaWAN tutorial 52: The Things Stack Community Edition V3” all my new tutorials will be based on TTS CE.

1 Like

You won’t find these ports in any of the current LoRaWAN v1.x specifications.

See the following topic:

bluejedi, thanks! I will mentioned this in my tutorial.

1 Like