ABP: Disable mac sending of commands

TTN V2 to V3 Upgrade Migrating Devices to V3
8

I have tried to decode the package using the Lora Packet Decoder. https://github.com/anthonykirby/lora-packet
But it doesn’t make any sense. It says it’s a Join request with the completely wrong AppEUI and DevEUI.

decoding from Hex:  0503D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500350FF00030805
Decoded packet
--------------
          Message Type = Join Request
            PHYPayload = 0503D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500350FF00030805

          ( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
                  MHDR = 05
            MACPayload = 03D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500350FF
                   MIC = 00030805

          ( MACPayload = AppEUI[8] | DevEUI[8] | DevNonce[2] )
                AppEUI = 1803070684ADD203
                DevEUI = 8456E8040750844F
              DevNonce = 0750

I am using a HopeRF RFM95W module. With the 1.5.0 version of the LMIC library.
It seems that whatever the commmand is our software is not handling it. The problem is that this concerns devices that are already in use and cannot be modified. Therefore i’m really hoping there is some way to prevent this command from being sent without any changes to the end device.

@TD-er
I have checked the RX2 frequency and it looks to be alright. I have also tried to remove it from the settings, but this doesn’t make a difference.

9

A version that knows what a MAC is but can only really process ADR requests.

Try the MCCI LMIC 3.1.0 or above - that is declared as being actually compliant - I’ve been using 3.2.0 for non-critical devices with no issues and using 4.0.0 on the bench.

Leave the Rx2 settings alone for now, getting “a stack that can mac” is the priority here.

Try this for packet decoding, it makes using the Kirby code base simpler and has lots more explanations:

https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh

10

Thank you for your help, but that is not an option right now unfortunately. In the next iteration i’ll be sure to update my software to something that is completely compliant to prevent these kind of issues.
My current pilot devices can however not be updated with new software.

I’ve also tried the online packet decoder. This gives me the same response:

Assuming hex-encoded packet
0503D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500350FF00030805

Message Type = Join Request
  PHYPayload = 0503D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500350FF00030805

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 05
  MACPayload = 03D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500350FF
         MIC = 00030805 (from packet) INVALID (tried MSB 0000-FFFF)
             = 57AF86F3 (expected, assuming 32 bits frame counter with MSB 0000)

( MACPayload = AppEUI[8] | DevEUI[8] | DevNonce[2] )
      AppEUI = 1803070684ADD203
      DevEUI = 8456E8040750844F
    DevNonce = 0750
11

LMIC I can do, decoding MAC commands not so much. But just checking, is this an encrypted packet or have you got it from the web console?

12

The hex-encoded packet does not look to be a valid LoRaWAN frame.

We can say this by just looking at first byte on the hex-encoded packet.

The LoRaWAN specification describes the first byte as follows
image

This means that 0x05 corresponds to the MHDR field.
The MHDR field decodes to the following:

0x05 -> 0b0000_0101
FType[7:5]: 000
RFU  [4:2]: 001
Major[1:0]: 01

Has per LoRaWAN specification RFU fields must be set to 000 (001 in this case) and the Major field has always a value of 00 (01 in this case).

RFU field definition:
image

Major field definition:
image

Another indication telling us that this is not a valid packet is the length of it. A JoinReq has always a size of 23 bytes => MHDR(1)+JoinEUI(8)+DevEUI(8)+DevNonce(2)+MIC(4) = 23
The hex-encoded packet has a size of 45 bytes.

It has to be noted as well that the JoinReq packet is not encrypted. This packet is only authenticated by the MIC computed using the AppKey.

Therefore the possibilities to have this happening are:

  1. This packet has been transmitted by a LoRa (Not LoRaWAN) device. There is nothing that can be done. Just ignore this packet.
  2. The Gateway is setup to forward all received packets including the ones having a wrong CRC.
    The Gateways should be setup to only forward valid packets.
  3. The end-device stack is not correctly implemented. As you say that LMIC is the used stack I doubt this to be the case. The JoinReq packet definition is the same since LoRaWAN 1.0.0
13

The OP implies that this is from his gateway - if it was a LoRa packet surely it’s preamble, id code and inversion bit or what not (this area of LoRaWAN I’m still learning as you can tell) would be totally wrong. And very co-incidental that it be transmitted dead on the start of an Rx window.

He says it’s a downlink.

He says it is a downlink after a join.

Hopefully Mr @577e4e6de7caf50f0070 will answer my question regarding if it’s an encrypted packet or if it’s taken from the web console.

But given that he’s using a very old un-compliant version of LMIC, anything could be happening!

14

Even if this is a downlink the MHDR field is always transmitted not encrypted. Which means that this downlink is not a LoRaWAN packet.

In case this packet is a downlink I don’t think this issue to be related to the end-device.
I would more suspect a gateway setup issue.

It would be helpful if @577e4e6de7caf50f0070 could provide the gateway log as well as the Network Server log in order to identify what could be the cause for this issue.
With such gateway log we can see if this packet has been received from the Network Server or if it is something received on the RF interface.

I have doubts that the TTN network server would send to a gateway a non LoRaWAN packet.

15

My packet is a downlink i receive immediatly after sending an uplink. Not after a join.
I got the string directly from my arduino which prints the exact bytes it receives in the downlink.

I’ve been trying to decrypt the message using this go library lorawan package - github.com/brocaar/lorawan - pkg.go.dev, but i’m really not sure if its encrytped or not since i don’t exactly understand what it’s supposed to be.

When i change the gateway to use the V2 implementation or a private lora backend i do not have these problems. The only thing i change about the gateway is the forwarder address.

I will let you know if i have any succes getting more information out of the packet.

16

If I understand well the hex-decode packet is what your end-device receives (end-device log would be helpful).
Then this may mean that the problem is on the end-device side. Maybe a wrong handling of the end-device radio reception buffer.

As @descartes indicated maybe the only way to fix this would be to upgrade your firmware to use a more compliant stack implementation.

Would it be possible for you to check what the gateway really transmits (gateway log would be useful)?

Like this we can compare what has been transmitted and what has been received.

17

So, not encrypted then. Is there any chance you sent a confirmed downlink at some point? Because if it’s never ACKd, the v3 stack is very very persistent (as I found out).

So if the device is on v3 but you change the gateway back to v2, this problem goes away?

Ah, OK. Really must fill in the blanks on the bit between “send this” and the app server. :smile:

Maybe write a device stack of my own - I mean, how hard can it be! :wink:

As I don’t recall 1.5 printing any MAC commands as standard, unless this has been added by Mr577, it will take a bit of testing to figure out what it might actually mean.

As @mluis says, an actual gateway log would be good, even better run the gateway and device web consoles and capture the exchange in verbose mode (screen shot) and give us the full JSON of the downlink (text) and even better, both!

18

@577e4e6de7caf50f0070 Can you also post the end-device source code excerpt where you execute the print of the log?

I’m wondering if the hex-encoded packet that you provided is the full LoRaWAN packet or just the application payload contents.

19

The problem goes away when i switch to v2 yes.
Here is part of the log of my device where the message is received:

12:58:20.887 -> Pkt q(43): 860408800079EF9DE0
12:58:22.007 -> TXCMPLT
12:58:22.045 -> Dnlnk:0503D2AD84060703184F84500704E85684500705B85E84500706886684500707586E84500350FF00030805

And the gateway log at the same moment:

2021-09-08T10:58:20.930036+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Received uplink message:
2021-09-08T10:58:20.930170+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | lora uplink (3A100007), payload 24 B, channel 868.1 MHz, crc ok, bw 125 kHz, sf 7, cr 4/5
2021-09-08T10:58:20.930275+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | Confirmed Data Up, DevAddr 26011D91, FCtrl [ADR], FCnt 43, FPort 1
2021-09-08T10:58:20.930337+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |  - radio (00000105)
2021-09-08T10:58:20.930450+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |   - demodulator counter 418591468, UTC time 2021-09-08T10:58:20.922835Z, rssi -41 dB, snr 5.75< 10.25 <15.25 dB
2021-09-08T10:58:20.932273+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BA34) sent
2021-09-08T10:58:20.933165+00:00 klk-fevo-0300E6 lorad[900]: <6> Sent 1 uplink message
2021-09-08T10:58:20.981935+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BA34) acknowledged in 49.6422 ms
2021-09-08T10:58:21.406396+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Downlink message (0001) received
2021-09-08T10:58:21.406868+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Received downlink message:
2021-09-08T10:58:21.407248+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | lora downlink (00000001), payload 56 B, required 1, preamble 8 B, header enabled, crc disabled, polarity inverted
2021-09-08T10:58:21.407626+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | Unconfirmed Data Down, DevAddr 26011D91, FCtrl [ADR] [ACK] [FPending], FCnt 19, FPort 0
2021-09-08T10:58:21.408008+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |  - radio (00000000), channel 868.1 MHz, bw 125 kHz, sf 7, cr 4/5, power 14 dB
2021-09-08T10:58:21.408469+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |   - transmission (00000000), priority 1, on counter 419591468
2021-09-08T10:58:21.410049+00:00 klk-fevo-0300E6 lorad[900]: <6> Received downlink message
2021-09-08T10:58:21.823255+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Heartbeat (BA51) sent
2021-09-08T10:58:21.844039+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BA35) sent
2021-09-08T10:58:21.869622+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Heartbeat (BA51) acknowledged in 46.3489 ms
2021-09-08T10:58:21.892771+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BA35) acknowledged in 48.7081 ms
2021-09-08T10:58:21.901176+00:00 klk-fevo-0300E6 lorad[900]: <6> Sent downlink message
2021-09-08T10:58:21.902138+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Received uplink message: transmission event (00000001 / 00000000), status "Transmitted"
2021-09-08T10:58:21.902591+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Downlink message (0001) acknowledged

Now that you mention it i did accidentally shedule a confirmed downlink at some point. I will try to clear the queue.

20

The entire packet is printed. Its taken from the LMIC.frame and LMIC.dataBeg fields.

process_gateway_downlink(LMIC.frame + LMIC.dataBeg, LMIC.dataLen);

21

That’s certainly the downlink data but the entire packet will start at 0 and end using a variable I can’t remember because I’ve only ever printed the payload I sent, not the entire incoming downlink.

It would help if you turned off confirmed uplinks so the logs are cluttered with the gateway sending the ACK - leaving aside the FUP.

This looks like it may be the culprit!

22

I have cleared the downlink queue for my device and unfortunately i still get the weird reponse.

Made sure the queue is empty using the cli:

▶ ttn-lw-cli end-devices downlink list <appId> <deviceId>
[]

I have also disabled the confirmed uplinks so i can provide a more clear gateway log. When i do this i obviously dont receive the downlink because it’s sent in the confirm. Here is the log:

2021-09-08T12:10:35.712590+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | lora uplink (3A100043), payload 20 B, channel 867.9 MHz, crc ok, bw 125 kHz, sf 7, cr 4/5
2021-09-08T12:10:35.712669+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | Unconfirmed Data Up, DevAddr 26011D91, FCtrl [ADR], FCnt 0, FPort 1
2021-09-08T12:10:35.712727+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |  - radio (00000004)
2021-09-08T12:10:35.712836+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |   - demodulator counter 458398067, UTC time 2021-09-08T12:10:35.698002Z, rssi -38 dB, snr 7.5< 9.5 <11.5 dB
2021-09-08T12:10:35.714519+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BACF) sent
2021-09-08T12:10:35.716353+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Received uplink message:
2021-09-08T12:10:35.716788+00:00 klk-fevo-0300E6 lorad[900]: <6> Sent 2 uplink messages
2021-09-08T12:10:35.717508+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | lora uplink (3A100044), payload 20 B, channel 868.1 MHz, crc error, bw 125 kHz, sf 7, cr 4/5
2021-09-08T12:10:35.718210+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |  - radio (00000105)
2021-09-08T12:10:35.718919+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |   - demodulator counter 458398068, UTC time 2021-09-08T12:10:35.698003Z, rssi -91 dB, snr -7.75< -5.25 <-2.75 dB
2021-09-08T12:10:35.719318+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Dropping message with invalid CRC
2021-09-08T12:10:35.763720+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BACF) acknowledged in 49.1615 ms
2021-09-08T12:10:42.036391+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Heartbeat (BC03) sent
2021-09-08T12:10:42.100121+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Heartbeat (BC03) acknowledged in 63.7106 ms
2021-09-08T12:10:42.319388+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Received uplink message:
2021-09-08T12:10:42.319526+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | lora uplink (3A100045), payload 20 B, channel 867.9 MHz, crc error, bw 125 kHz, sf 7, cr 4/5
2021-09-08T12:10:42.319591+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |  - radio (00000004)
2021-09-08T12:10:42.319699+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |   - demodulator counter 465006787, UTC time 2021-09-08T12:10:42.306722Z, rssi -89 dB, snr -9.75< -5.25 <-1.5 dB
2021-09-08T12:10:42.319748+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Dropping message with invalid CRC
2021-09-08T12:10:42.321531+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Received uplink message:
2021-09-08T12:10:42.322009+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | lora uplink (3A100046), payload 20 B, channel 868.1 MHz, crc ok, bw 125 kHz, sf 7, cr 4/5
2021-09-08T12:10:42.322410+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | Unconfirmed Data Up, DevAddr 26011D91, FCtrl [ADR], FCnt 1, FPort 1
2021-09-08T12:10:42.322768+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |  - radio (00000105)
2021-09-08T12:10:42.323172+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |   - demodulator counter 465007068, UTC time 2021-09-08T12:10:42.307003Z, rssi -40 dB, snr 5.75< 10.25 <14.75 dB
2021-09-08T12:10:42.325182+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BAD0) sent
2021-09-08T12:10:42.326012+00:00 klk-fevo-0300E6 lorad[900]: <6> Sent 3 uplink messages
2021-09-08T12:10:42.327675+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Received uplink message:
2021-09-08T12:10:42.328156+00:00 klk-fevo-0300E6 lorafwd[928]: <6> | lora uplink (3A100047), payload 20 B, channel 868.3 MHz, crc error, bw 125 kHz, sf 7, cr 4/5
2021-09-08T12:10:42.328653+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |  - radio (00000106)
2021-09-08T12:10:42.329087+00:00 klk-fevo-0300E6 lorafwd[928]: <6> |   - demodulator counter 465007076, UTC time 2021-09-08T12:10:42.307011Z, rssi -89 dB, snr -8.25< -5 <-2.25 dB
2021-09-08T12:10:42.329436+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Dropping message with invalid CRC
2021-09-08T12:10:42.373923+00:00 klk-fevo-0300E6 lorafwd[928]: <6> Uplink message (BAD0) acknowledged in 48.7115 ms

It concerns me it keeps repeating: Dropping message with invalid CRC The messages are all delivered as expected though.

At this point it is really starting to look like my only option is to move away from The Things Network entirely. :c

23

The hex-decoded command received by the end-device is what the Network Server has sent on FPort 0 (MAC commands).

As you can see on the gateway log the packet has a size of 56 bytes while the hex-decoded is 43 bytes.
The difference corresponds to the LoRaWAN frame overhead which is 13 bytes.

Knowing this the received payload is valid and corresponds to MAC commands sent by the Network Server. At the end of this post I have put the how to decode these MAC commands.

As you can see the Network Server is creating the additional channels, setup the Rx windows parameters and instructing the end-device to use highest datarate and power on all setup channels.

As @descartes mentioned the end-device stack must be able to correctly handle these MAC commands in order to have everything work properly.

Therefore, I think that you have no other choice than update the firmware on your devices in order to be LoRaWAN compliant.

MAC commands decoding:

0503D2AD84    - RXParamSetupReq :
                                  RX1DROffset: 0
                                  RX2DataRate: 3
                                  Frequency  : D2AD84 -> 0x84ADD2 * 100 = 869.525 MHz

06            - DevStatusReq    : No payload

0703184F8450  - NewChannelReq   :
                                  ChIndex     : 03
                                  Frequency   : 184F84 -> 0x844F18 * 100 = 867.1 MHz
                                  DRRange     : 50 -> Max: DR_5, Min: DR_0
0704E8568450  - NewChannelReq   :
                                  ChIndex     : 04
                                  Frequency   : E85684 -> 0x8456E8 * 100 = 867.3 MHz
                                  DRRange     : 50 -> Max: DR_5, Min: DR_0
0705B85E8450  - NewChannelReq   :
                                  ChIndex     : 05
                                  Frequency   : B85E84 -> 0x845EB8 * 100 = 867.5 MHz
                                  DRRange     : 50 -> Max: DR_5, Min: DR_0
070688668450  - NewChannelReq   :
                                  ChIndex     : 06
                                  Frequency   : 886684 -> 0x846688 * 100 = 867.7 MHz
                                  DRRange     : 50 -> Max: DR_5, Min: DR_0
0707586E8450  - NewChannelReq   :
                                  ChIndex     : 07
                                  Frequency   : 586E84 -> 0x846E58 * 100 = 867.9 MHz
                                  DRRange     : 50 -> Max: DR_5, Min: DR_0

0350FF0003    - LinkADRReq      : 
                                  DataRate_TXPower: 50 -> DR_5, TX_P_0: Max output power
                                  ChMask          : FF00 -> 00FF: 8 first channels enabled
                                  Redundancy      : 03 -> ChMaskCntl: 0, NbTrans: 3

0805          - RXTimingSetupReq: 
                                  RxTimingSettings: 05 -> RFU:0, Del:5 -> Rx1Delay is 5 seconds
2 Likes
24

Alright then. I want to thank you all for the incredible help. Wouldn’t have figured all this out without it!

25

This is a known issue - it’s no longer in the queue so it’s not something you can clear easily - I’ll get the commands sorted.

26

The magic flush command is:

ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink

3 Likes
27

The invalid CRC comes about because your node is too close to the gateway, overloading the ftont end and bleeding over into false reception on a different channel, which ends up ~40 dB weaker and the 300uS difference in timing is little more than a rounding error.

You need to run spec compliant firmware with TTN but you also need your nodes you be a few meters away from the gateway so they don’t overload it.

1 Like