Being forced to sent packet through fport0

Hi all

I am facing a problem that chirpstack receives packet from my end device with data = null through fport 0, while my device is configured to send data through fport2.

I’ve setup a LoRaWan gateway with the Things Network(TTN) and it received the payload correctly with fport = 2. The firmware of my end device used for testing on both TTN and Chirpstack were the same.

I wonder how to fix this problem. Do you guys have solution upon this question yet?
It is devastatingly urgent to solve this issue.

Please read this to the end.

Chirpstack SHOULD received null data on fport = 0 because that’s used exclusively for MAC commands. See this TTN V3 bug, if you don’t believe me.

In my limited experience, only fport > 0 are valid for data. That is, most of my devices send data on fport 1…5, depending on intended meaning of data. This is a great way to minimize number of bytes sent out: “ff12” can mean battery voltage when sent on fport = 1, or firmware version number when sent on fport = 2, and can even signify actual sensor data when sent on fport = 3, for example.

1 Like

Yes I believe you. I know that Chirpstack should never receive data on fport0.

My setting is: one device with SX1276, two LoRaWAN routers with two Gateway Bridge respectively: Chirpstack and TTN.

When I sent my data to TTN, TTN received our packet with the whole customized payload, with fport2 as programmed. While when I sent my data to Chirpstack, Chirpstack received our packets with data:null, and with fport0 for no reason.

do you guys think of any possible case causing such issue?

Is there any possible scenario that Chirpstack would automatically change the fport to zero?

I configured my device to send payload to LoRaWAN gateway through fport2 and it succeeded on TTN.

While I could never get my payload transferred to Chirpstack. Chirpstack recognized my packet but with no data, and it showed that the packets were from fport2.

I have no clue how to fix the problem or even dig into the problem right now. Do any of you get any hunch or insight on fixing this problem?

I can provide any information if needed

I know that Chirpstack should never receive data on fport0.

That is wrong, Chirpstack should never receive data on fport0.

I already answered this question in an other topic where the same was asked. In summary, fport = 0 is used for mac-commands in the frmpayload field, thus mac-layer data. ChirpStack exposes these fport = 0 uplinks to the end-application as even they don’t contain data, the RX meta-data (RSSI, SNR, …) can be very useful. If you are only interested in fport = 2, just ignore these message.

2 Likes

Thanks for clarifying that fport 0 is for mac-layer data.

Yes at the moment I am only interested in fport = 2, and I found out the actual situation already.

I think you may be one of the expert or active member here. In case you have never come cross a problem like mine, you may take my answer and help the others.

I have been searching for a fix including browsing in this forum but yet I didn’t quite see an answer here even if someone has asked similar questions.

I am not authorized to manage the Chirpstack gateway bridge. I had been able to send 30 bytes data to the gateway but not suddenly after some time. Finally I found that the authorized party did some changes on the gateway bridge and limited the size of data to process.

Therefore, if someone is having similar problem, you may want to try sending less data to the gateway to see what happen.

The cause/reason:
If Chirpstack gateway bridge receives data packets larger than allowed size, the fport would be automatically changed to zero and no data shall be processed.

Incorrect.

First off, the gateway bridge does no processing at all, only format translation between two different backhaul protocols. The transcribed radio packet itself, where both the fport and any payload are found is copied through entirely unaltered and not even interpreted - it’s just “I heard this on my antenna”. Processing only happens in the central servers. But even there, this kind of change is not made.

Packets sent on port 0 are network housekeeping traffic, likely part of a series of settings and confirmations between Chirpstack and your node’s LoRaWAN stack. They don’t contain application data, but they’re still important, having either an ack bit or a more meaningful response in the fOpts rather than they packet payload field. If there is network housekeeping traffic that needs to be sent up, and it cannot be attached to an ordinary application data packet (retaining that packet’s non-zero fport), then a typical node’s LoRaWAN stack will either send that instead of any requested application packet, or autonomously on its own, as a housekeeping-only packet on fport 0. A situation where the combination of housekeeping content and application payload would exceed the legal maximum (for that spreading factor, bandwidth, and location) is one where the stack would have to send the housekeeping traffic instead rather than as well. But it’s the node’s own LoRaWAN stack doing that - Chirpstack is NOT altering a message already transmitted. The one way that Chirpstack is involved is that the details of the conversation between network server and node would be different for different servers - Chirpstack and TTN aren’t going to be having exactly the same conversation in the same way, even if they need to send similar configuration down to the node.

If you want to understand exactly what is going on, you’ll need to post the full details of one of these packets, and also any downlinks preceding it.

Remember also that a given node can only be registered with one of Chirpstack or TTN at a time - if it were registered with both, completely chaos would ensue.