Add getFOpts call to return FOpts for MAC processing

[rgillan]

Would be convenient if there was also a getFOpts call that returned MAC commands where present

[anthonykirby]

sure, I can add that: If you know anywhere I can easily get sample packets for testing this, it'd really help!

[tibortiz]

Here is an exemple of FOpts with a MAC Command:

            PHYPayload = 4084412505A3010009110308B33750F504D4B86A

          ( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
                  MHDR = 40
            MACPayload = 84412505A3010009110308B33750F5
                   MIC = 04D4B86A

          ( MACPayload = FHDR | FPort | FRMPayload )
                  FHDR = 84412505A30100091103
                 FPort = 08
            FRMPayload = B33750F5

                ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
               DevAddr = 05254184 (Big Endian)
                 FCtrl = A3
                  FCnt = 0001 (Big Endian)
                 FOpts = 091103

          Message Type = Unconfirmed Data Up
             Direction = up
                  FCnt = 1
             FCtrl.ACK = true
             FCtrl.ADR = true```

[anthonykirby]

many thanks, I'll have a look

[anthonykirby]

Hi Rob, can I quickly check what you're asking?

Option #1: If you want a method to get the FOpts buffer, then you can already read that like any of the other buffers, for example packet.getBuffers().FOpts (& I'm really sorry I didn't suggest that earlier, I thought it was #2 you wanted). The getXxx functions are only needed to retrieve things in forms other than buffers, like flags or numbers.

Option #2: If you want decoding of the FOpts MAC commands, that's possible, but I have literally no test data for this; there are more than a dozen commands & lots of possible options. I don't like writing code that I'm not able to test! ;-) I've tried decoding the FOpts in this example, 091103 but it doesn't make sense to me, which doesn't bode well:

• 0x09 = TxParamSetupReq/TxParamSetupAns
• 0x11 = data for TxParamSetupReq (1 byte expected) & is plausible. ... or if it's a TxParamSetupAns, it would be the next MAC command, but it's not one of the valid values
• 0x03 = LinkADRReq/LinkADRAnd ... but that expects a further 4 bytes (LinkADRReq) or 1 byte (LinkADRAns) which we don't get.

[rgillan]

Anthony, So to be really useful we need full MAC decoding, but understand that this is likely beyond the scope of this module as it's a state machine that needs to be implemented to handle them properly. Option 1 is fine for now. Cheers

[a-backman]

Hi, Any news? Option #2 suggested above would be really useful. I can provide some sample packages. Here is one containing a LinkADRReq command:

	Message Type = Data
	  PHYPayload = 60F6FC2F00850200035507000168174D95

	( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
	        MHDR = 60
	  MACPayload = F6FC2F008502000355070001
	         MIC = 68174D95 (from packet)
	             = 68174D95 (expected, assuming 32 bits frame counter with MSB 0000)

	( MACPayload = FHDR | FPort | FRMPayload )
	        FHDR = F6FC2F008502000355070001
	       FPort = 
	  FRMPayload = 

	      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
	     DevAddr = 002FFCF6 (Big Endian)
	       FCtrl = 85
	        FCnt = 0002 (Big Endian)
	       FOpts = 0355070001

	Message Type = Unconfirmed Data Down
	   Direction = down
	        FCnt = 2 (from packet, 16 bits) 
	             = 2 (32 bits, assuming MSB 0x0000)
	   FCtrl.ACK = false
	   FCtrl.ADR = true

[bertrik]

I would very much like to see that too, FOpts decoding in MAC commands. Even better would be if TheThingsNetwork could integrate it into their TTN console.

[Cloolalang]

Great project! To be able to both receive and send MAC commands would be extremely useful to the LoraWan Dev environment. Im using chirpstack to build a lab-network for developing end-devices. One major issue with Chirpstack it the lack of ADR fine/manual control of MAC commands to set up the end-device data-rate and TX power. To be able to send these commands and see the response would be very useful indeed as the ADR is not at all accessible in TTN (for example). Yes there are a large range of Mac commands! For small, non-public lorawan systems for labs, universities etc, we really need to be able to control the PHY parameters better.

Please,...pretty-please...:)