Given the frequency 869.525, the downlinks are all in RX2, except for the very first one, which is in RX1 (and is the Join Accept). Of those RX2 downlinks, only the first is sent at the TTN-specific SF9 (as expected), all others use the LoRaWAN default SF12 (as a workaround).
Now, an example has proved that, when using RX2, TTN surely is smart enough to repeat ADR on SF12 if nothing changed when the node ignored the ADR downlink in the documented SF9. The same can been seen in the code. But I feel TTN should not keep using SF12 for ADR in RX2 then†; assuming your node is using the TTN specific settings that it got in the EU868 OTAA Join Accept, it will never receive the RX2 downlinks when TTN uses SF12…
On the other hand, maybe the bug is that it should not repeat forever, but only once. And maybe it uses SF9 again when the node sets ADRAckReq at some later time again. And the other nodes do accept the RX2 SF9 downlink?
That’s the gateway’s configuration for the downlink. Like frequency, data rate and power that is to be used for the transmission. It’s not some configuration payload that is sent to the node.
The data sent to the node is taken from, e.g., "payload": "YOEvASaFGAADVf8AAzz/Bqw=" for the SF9 downlink, which indeed is a MAC command in FOpts = 0355FF0003, which according to the 1.0.2 specification and the EU868 regional parameters decodes to:
- 0x03 = LinkADRReq MAC command
- 0x55 = DataRate_TXPower: data rate 5 (SF7/125KHz); TX power 5 = 6 dBm
- 0xFF00 (LSB) = 0b00000000 11111111 (MSB) = ChMask = channels 1 thru 8
- 0x03 = 0b00000011, so ChMaskCntl = 0b000, so indeed the bits in ChMask above directly refer to individual channels. This also sets NbTrans = 3, telling the node that each unconfirmed uplink should be transmitted 3 times.
(I don’t understand that, but I assume it’s unrelated to your problems, as I assume it’s the same for the other nodes…)
And the first SF12 downlink, which your node will not have received, gives FOpts = 0503D2AD84 0355FF0003, which indeed first tells the node about the TTN specific RX2 settings:
- 0x05 = RXParamSetupReq MAC command
- 0x03 = DLsettings: RX1DRoffset = 0 (RX1 downlink uses the same data rate as the preceding uplink) and RX2DataRate = 3 (SF9/125kHz for RX2)
- 0xD2AD84 (LSB) = 0x84ADD2 (MSB) = RX2 frequency 869.5250 MHz
…followed by the LinkADRReq MAC command 0x0355FF0003 as described above.
So, all above aside: why didn’t that specific node receive or process the SF9 downlink? (As other nodes do process it, so certainly receive it, I doubt the gateway is to blame.)
† It seems that for OTAA, this was fixed in October 2019: RX2 fallback leads to endless downlinks · Issue #767 · TheThingsArchive/ttn · GitHub, for devices that joined after that fix.