RelayForwardUplinkReq uplinkMetadata RSSI field not correctly re-marshalled

[StevenCellist]

Summary

Math rules strike again - there appears to be a minor re-encoding mistake on the RSSI field in the uplinkMetadata of RelayForwardUplinkReq that results in the forwarded RSSI to be 30 off (or, more accurately, 2*15).

Steps to Reproduce

1. Send a forwarded uplink from a Relay-enabled device, observing the RSSI of the relay from the end-device's uplink.
2. Observe the output on the end-device's console (or the relay's console in the rx_metadata field).

Current Result

Relay:

20:43:37.330 > DevAddr: 260BAF11, RSSI: -22.0, SNR: 12.8

Console:

    "rx_metadata": [
      {
        ...
        "rssi": -52,
        "channel_rssi": -52,
        "snr": 11,

The RSSI value on the end-device console ends up 30 dBm lower than what the relay sends to the network server. This is due to a minor brackets problem. The unmarshalling is done right...

lorawan-stack/pkg/encoding/lorawan/relay.go

Line 80 in 569c2cc

req.Rssi = -int32(uplinkMetadata>>9&0x7f) - 15

... but the re-marshalling is applied incorrectly:

lorawan-stack/pkg/encoding/lorawan/relay.go

Line 53 in 569c2cc

uplinkMetadata |= uint32(-(req.Rssi+15)&0x7f) << 9

Notice the very subtle difference in brackets - the +15 should be applied outside the brackets instead of inside.

Expected Result

The RSSI for the end-device should be set back to original.

Relevant Logs

No response

URL

No response

Deployment

The Things Stack Community Edition

The Things Stack Version

3.32.1

Client Name and Version

No response

Other Information

No response

Proposed Fix

Change ...

lorawan-stack/pkg/encoding/lorawan/relay.go

Line 53 in 569c2cc

uplinkMetadata |= uint32(-(req.Rssi+15)&0x7f) << 9

... to ...

uplinkMetadata |= uint32((-req.Rssi+15)&0x7f) << 9

(I guess?)

Contributing

• I can help by doing more research.
• I can help by implementing a fix after the proposal above is approved.
• I can help by testing the fix before it's released.

Validation

• The fix is tested in a staging environment.
• The fix is documented in The Things Stack Documentation

Code of Conduct

• I agree to follow TTN's Community Code of Conduct.

[KrishnaIyer]

I'm not sure this is the cause.
If you look at the tests, the marshaling and unmarshaling tests are mirrored.

[StevenCellist]

The tests look OK to me, but that doesn't take away the behaviour that I see on the console.
In similar vein to the other issue, here is a collection of outtakes from the Relay log and device consoles to investigate.

Relay's metadata setup after receiving a NodeR-uplink (that is an end-device):

15:43:29.387 > End-device uplink: Freq = 868.500, DR = 2
...
15:43:29.987 > DevAddr: 260BA89A, RSSI: -17.0, SNR: 8.8
15:43:29.997 > Metadata / frequency:
15:43:30.000 > 00000000: c2 41 00 c8 85 84                                .A....

Base64 payload on the Relay console:

QFWJCyYAAwDi26KfFvq5nYUYv8Z7GrBqpkNJdWOkFZw2nbkEAbE=

NwkSEncKey:

7D25EA4F096314590A882E6BDD3732F0

Online decoder:

   ( MACPayload = FHDR | FPort | FRMPayload )
           FHDR = 55890B26000300
          FPort = E2
     FRMPayload = DBA29F16FAB99D8518BFC67B1AB06AA643497563A4159C369D (from packet, encrypted)
                = C24100C88584409AA80B2680020001FD8BC3C606787045B2C1 (decrypted)

The first six bytes are the Metadata as described in section 9.1 of TS011:

The Uplink metadata is C2 41 00, the Uplink Frequency is C8 85 84 (0x8485C8 = 8685000, identical to log). Reversing the bytes for the metadata in similar fashion, it reads 0x0041C2. Decoding this according to Table 27, we see:

• Uplink Datarate = 2 (identical to log)
• Uplink SNR = 28 (Relay reported 8, +20 from encoding)
• Uplink RSSI = 32 (Relay reported -17, so negated and +15 from encoding)

But looking at the Console for the NodeR device, I see the following:

      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "relay"
          },
          "relay": {
            "device_id": "relay"
          },
          "rssi": -47,
          "channel_rssi": -47,
          "snr": 8,

While the SNR is reported correctly, the RSSI value is 30 off. I think the issue is in the line I originally posted, but that may be wrong. Please let me know your thoughts @KrishnaIyer