# Excess LinkADRReq parameter bytes? **URL:** \ **Category:** The Things Stack v3\ **Created:** [April 5, 2023, 2:43pm UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415 "2023-04-05T14:43:47Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Kater](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kater/32/44393_2.png) [@Kater](https://www.thethingsnetwork.org/forum/u/Kater)\ **Post date:** [April 5, 2023, 2:43pm UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/1 "2023-04-05T14:43:47Z")
I am not completely sure if this is a bug, but I recently observed a **LinkADRReq** downlink command with `"f_opts": "AzH/AAEG"` which decodes to `03 31 ff 00 01 06`. Command `0x03` has 1+2+1 = 4 bytes of parameters, but here we have 5. This is consistent with the outer parameters (FOptsLen iirc), but the trailing `0x06` seems to be in excess. Unfortunately it looks like that this somehow causes problems in the RN2483 LoRaWAN controller on my node (kind of buffer overflow, maybe). Any comments? ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [April 5, 2023, 3:18pm UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/2 "2023-04-05T15:18:40Z")
Could 06 be another MAC command? For instance DevStatusReq? ---
**Author:** ![Kater](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kater/32/44393_2.png) [@Kater](https://www.thethingsnetwork.org/forum/u/Kater)\ **Post date:** [April 5, 2023, 3:46pm UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/3 "2023-04-05T15:46:10Z")
Thank you. You are right, if I understand the spec correctly: “A single data frame can contain any sequence of MAC commands, either piggybacked in the FOpts field […]”. Seems the bug is in the RN2483 firmware which misbehaves whenever such a telegram is received. ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [April 5, 2023, 4:51pm UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/4 "2023-04-05T16:51:36Z")
Which version of the firmware is loaded on the module? And what settings at TTN are you using for the device? (LoRaWAN version, Regional Parameters version) ---
**Author:** ![Kater](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kater/32/44393_2.png) [@Kater](https://www.thethingsnetwork.org/forum/u/Kater)\ **Post date:** [April 6, 2023, 8:22am UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/5 "2023-04-06T08:22:00Z")
It’s 1.05, i.e. the latest “official”/supported release. TTN settings are LoRaWAN 1.0.2, EU868 with SF9 for RX2, RP001 Rev.B, OTAA. The error occurs with dynamic ADR mode. If I set that option to disabled, no problem occurs – which is evident because the critical downlink telegram is not generated. ---
**Author:** ![marcel\_hecko](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/marcel_hecko/32/44787_2.png) [@marcel\_hecko](https://www.thethingsnetwork.org/forum/u/marcel_hecko)\ **Post date:** [May 31, 2023, 9:18am UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/6 "2023-05-31T09:18:14Z")
I think we are hitting the same issue. @Kater would you be so king and be more specific on how is the problem with rn2483 demonstrated on your end? In our case the radio becomes completely unresponsive until reset using external pin. ---
**Author:** ![marcel\_hecko](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/marcel_hecko/32/44787_2.png) [@marcel\_hecko](https://www.thethingsnetwork.org/forum/u/marcel_hecko)\ **Post date:** [May 31, 2023, 10:04am UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/7 "2023-05-31T10:04:27Z")
I can confirm, that disabling ADR on RN2483 puts the module into correct state. Previously: after sending “mac tx uncnf” a response “ok” was received and packet sent, then the module went into inresponsive state on uart interface (never received the second mac\_tx\_ok response) Now with ADR explicitly disabled: after sending “mac tx uncnf” a response “ok” was received and packet sent, then after about additional 8 seconds the mac\_tx\_ok is received and all works correctly further on Only tested with 1.0.5 fw ---
**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\ **Post date:** [May 31, 2023, 6:25pm UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/8 "2023-05-31T18:25:42Z")
Are you using 1.0.5 as well? Could you test with older firmware versions? ---
**Author:** ![Kater](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kater/32/44393_2.png) [@Kater](https://www.thethingsnetwork.org/forum/u/Kater)\ **Post date:** [June 1, 2023, 11:32am UTC](https://www.thethingsnetwork.org/forum/t/excess-linkadrreq-parameter-bytes/62415/9 "2023-06-01T11:32:26Z")
From memory (would have to search my notes which I have not handy atm): Joining with ADR disabled lets the Stack send a single downlink message, which is ok for the RN2483 radio module. Enabling ADR _ **and** _ having a good connection lets the Stack send a combined downlink message with the additional **LinkADRReq** command to modify the radio parameters (i.e. a changed spreading factor). The combination of more than one downlink action seems to be the problem for the RN2483.