DevStatusReq downlink without any application data uses uplink's application port instead of port 0

[avbentem]

This is a bug report for the Backend (and the Console).

• When an unconfirmed uplink has ADR enabled and uses, say, application port 2, then when the application does not require any downlink itself, TTN might still send a DevStatusReq downlink using that port 2. I think it should then use port 0, as it's only a DevStatusReq MAC command without any application data, for which the LoRaWAN specifications state:

  4.3.2 Port field (FPort)

  If the frame payload field is not empty, the port field must be present. If present, an FPort value of 0 indicates that the FRMPayload contains MAC commands only; see Chapter 4.4 for a list of valid MAC commands. FPort values 1..223 (0x01..0xDF) are application-specific.

• TTN Console shows the downlink is using port 0, while the payload really includes another value.

• According to a forum post, Actility uses port 0 for the same use case.

Example:

1. Node sends 403A140126C0820002005629CDB1F73640BEDEF047 which is an Unconfirmed Uplink for application port 2, with the FCtrl.ADR bit set.

2. In the gateway traffic, TTN Console shows it's responding with 603A140126200300022A0F94A8:

   

3. 603A140126200300022A0F94A8 decodes to an Unconfirmed Data Down without any application data, but with FPort set to 2:

   Message Type = Data
     PHYPayload = 603A140126200300022A0F94A8
   
   ( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
           MHDR = 60
     MACPayload = 3A14012620030002
            MIC = 2A0F94A8
   
   ( MACPayload = FHDR | FPort | FRMPayload )
           FHDR = 3A140126200300
          FPort = 02
     FRMPayload = 
   
         ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
        DevAddr = 2601143A (Big Endian)
          FCtrl = 20
           FCnt = 0003 (Big Endian)
          FOpts = 
   
   Message Type = Unconfirmed Data Down
      Direction = down
           FCnt = 3
      FCtrl.ACK = true
      FCtrl.ADR = false

4. In the application data, TTN Console shows that the downlink was using port 0 (which it should, but did not, so maybe there's a bug in Console as well?):

   

Environment

• My application:
  • App ID: arjanvanb-bb-1
• My gateway:
  • EUI: eui-5ccf7ff42f1970ec
  • Connected to: router.eu.thethings.network:1700
• My node:
  • Device ID: arjanvanb-bb-1
  • AppEUI: 70B3D57EF00037B4
  • DevEUI: 70B3D5B020035CD1

[htdvisser]

Confirmed. Shouldn't be too hard to fix.