LoRaWAN 1.1 uplink issues #2171

sidpat · 2020-03-17T10:53:18Z

Summary

TTN enterprise cloud hosted: Uplinks not working anymore.

Steps to Reproduce

Create an OTAA v1.1 end device on the console
Send confirmed uplink from end device (also doesnt work for unconfirmed uplinks)

What do you see now?

The console shows the following 2 messages in the gateway logs after an uplink,
dropped uplink:

{
  "namespace": "pkg/gatewayserver",
  "name": "host_handle",
  "message_format": "host `{host}` failed to handle message",
  "attributes": {
    "host": "cluster"
  },
  "cause": {
    "namespace": "pkg/networkserver",
    "name": "device_not_found",
    "message_format": "device not found",
    "correlation_id": "3304c25c69a744c8ae1a519f9c8d7ad3",
    "code": 5
  },
  "code": 5
}

dropped uplink:

{
  "namespace": "pkg/encoding/lorawan",
  "name": "unknown_field",
  "message_format": "unknown `{lorawan_field}`",
  "attributes": {
    "lorawan_field": "MType",
    "value": "CONFIRMED_DOWN"
  },
  "code": 3
}

What do you want to see instead?

successful uplinks

Environment

TTN enterprise cloud-hosted (things were working 5 days ago, probably the new update broke something)

How do you propose to implement this?

...

Can you do this yourself and submit a Pull Request?

...

The text was updated successfully, but these errors were encountered:

rvolosatovs · 2020-03-18T20:41:35Z

Thanks for reporting, RekeyInd handling was broken recently, indeed. This is fixed in #2186 and will land in 3.6.2, which will be released and deployed very soon.

sidpat · 2020-04-01T04:04:13Z

@rvolosatovs, Is this patch deployed on the enterprise cloud-hosted version? I am still getting the below dropped uplink error on gateway logs in console,

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
  "namespace": "pkg/gatewayserver",
  "name": "host_handle",
  "message_format": "host `{host}` failed to handle message",
  "attributes": {
    "host": "cluster"
  },
  "cause": {
    "namespace": "pkg/networkserver",
    "name": "device_not_found",
    "message_format": "device not found",
    "correlation_id": "bded1a692f1c4a849e545c35ca0dc98d",
    "code": 5
  },
  "code": 5
}

rvolosatovs · 2020-04-01T07:59:27Z

This error by itself does not indicate that something is wrong, it is normal for gateways to receive and forward traffic of unknown devices due to nature of LoRaWAN. Do you miss device traffic?

sidpat · 2020-04-01T09:43:54Z

@rvolosatovs , This is traffic from my end device.
Steps to reproduce issue:

create end device with latest mac and phy
from this device, send an uplink after join

rvolosatovs · 2020-04-01T10:19:46Z

I cannot reproduce the issue neither locally, nor on the cloud-hosted instance.
Can you confirm that your device sends RekeyInd in all uplink frames until RekeyConf is received as required by the 1.1 spec?

rvolosatovs · 2020-04-01T10:22:37Z

Could you try simulating an uplink from your device after join via:

ttn-lw-cli simulate uplink --f-nwk-s-int-key <f-nwk-s-int-key> --s-nwk-s-int-key <s-nwk-s-int-key> --nwk-s-enc-key <nwk-s-enc-key> --app-s-key <app-s-key> --lorawan-version 1.1.0 --frm-payload 0x0B01 --dev-addr <dev-addr> --gateway-id <gateway-id>

And confirm that you get a downlink with RekeyConf back?

sidpat · 2020-04-01T12:14:06Z

Hi @rvolosatovs, my first uplink does contain the RekeyInd mac command and is persisted till RekeyConf is received. Please find below my first uplink data,

Frm_Payload={0x01, 0x0A, 0x02, 0x0B, 0x03, 0x0C}
Fopts={0x0B, 0x01}
Port=10

sidpat · 2020-04-01T12:25:40Z

I ran the asked command and got the error below,

$ ttn-lw-cli simulate uplink --f-nwk-s-int-key 753485B5099DC11C4788338739686B87 --s-nwk-s-int-key D4A47455AD2C459F383F10B5689F8435 --nwk-s-enc-key D4A47455AD2C459F383F10B5689F8435 --app-s-key 41A38CF5E2F1FF45C84EA5ADC1C68ABA --lorawan-version 1.1.0 --frm-payload 0x0B01 --dev-addr 27000043 --gateway-id nu-mtc-1
  INFO Sent uplink                             
error:unknown:unknown (context deadline exceeded)

In my gateway logs in console I got disconnect gateway after this command. Had to restart my gateway to get it back online.
My gateway is multitech conduit AEP.

rvolosatovs · 2020-04-01T13:20:37Z

Please try this (make sure dev nonce is high enough):

ttn-lw-cli simulate join-request --dev-eui <dev-eui> --join-eui <join-eui> --dev-nonce <dev-nonce> --lorawan-version 1.1.0 --lorawan-phy-version 1.1.0-b --app-key <app-key> --nwk-key <nwk-key> --gateway-id nu-mtc-1

You should receive a join-accept, then use the data from the join-accept to simulate an uplink:

ttn-lw-cli simulate uplink --f-nwk-s-int-key <f-nwk-s-int-key> --s-nwk-s-int-key <s-nwk-s-int-key> --nwk-s-enc-key <nwk-s-enc-key> --app-s-key <app-s-key> --lorawan-version 1.1.0 --frm-payload 0x0B01 --dev-addr <dev-addr> --gateway-id nu-mtc-1

Unfortunately, ttn-lw-cli simulate uplink does not support FOpts at this time(PR incoming), but locally I modified it and was able to send uplink from #2171 (comment) and have it successfully processed (got a class A downlink)

Log

cli simulate uplink --f-nwk-s-int-key CFF2EEE0479B057AE67905316ED34485 --s-nwk-s-int-key C3589D2E68237D94A9F78EFF4C99DBBF --nwk-s-enc-key BDE24CB08F472D6F995A2ABB2A320600 --app-s-key AF99A9CF1285B0F77FF5F5FE42089D87 --lorawan-version 1.1.0 --frm-payload 0x010A020B030C --f-opts 0x0B01 --f-port 0x10 --dev-addr 0x270000A7 --gateway-id <gateway-id>
 DEBUG Using access token (valid until 4:10PM) 
 DEBUG ccResolverWrapper: sending update to cc: {[{tti.eu1.cloud.thethings.industries:8884  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG Channel switches to new LB policy "pick_first"
 DEBUG Subchannel Connectivity change to CONNECTING
 DEBUG Subchannel picks a new address "tti.eu1.cloud.thethings.industries:8884" to connect
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc0007929c0, {CONNECTING <nil>}
 DEBUG Channel Connectivity change to CONNECTING
 DEBUG Subchannel Connectivity change to READY 
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc0007929c0, {READY <nil>}
 DEBUG Channel Connectivity change to READY    
  INFO Sent uplink                             
  INFO Received downlink (after 1.981240952s) for transmission 5s relative to uplink
  INFO Read MAC command                         cid=CID_REKEY payload=&MACCommand_RekeyConf_{RekeyConf:&MACCommand_RekeyConf{MinorVersion:MINOR_1,},}
  INFO Read MAC command                         cid=CID_DEV_STATUS payload=<nil>
{
  "raw_payload": "YKcAACeAAQAAy/SZ5vVCig==",
  "payload": {
    "m_hdr": {
      "m_type": "UNCONFIRMED_DOWN"
    },
    "mic": "5vVCig==",
    "mac_payload": {
      "f_hdr": {
        "dev_addr": "270000A7",
        "f_ctrl": {
          "adr": true
        },
        "f_cnt": 1
      },
      "frm_payload": "CwEG"
    }
  },
  "scheduled": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 12
      }
    },
    "coding_rate": "4/5",
    "frequency": "868100000",
    "timestamp": 1811252046,
    "downlink": {
      "tx_power": 16.15,
      "invert_polarization": true
    }
  },
  "correlation_ids": [
    "gs:conn:01E4TXY40DA2DXZ8AD1FED4B9H",
    "gs:uplink:01E4TXY41X80GQG616H08T5X25",
    "ns:downlink:01E4TXY5WK3C89VQK9BC375Y9T",
    "ns:uplink:01E4TXY41YVBTYF6MMW0STM05S",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01E4TXY41YAWY0QY3M8R85WM8E",
    "rpc:/ttn.lorawan.v3.GtwGs/LinkGateway:01E4TXY3Z8SCFA64RGFETTDSD5",
    "gs:conn:01E4TXY40DA2DXZ8AD1FED4B9H",
    "rpc:/ttn.lorawan.v3.GtwGs/LinkGateway:01E4TXY3Z8SCFA64RGFETTDSD5",
    "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01E4TXY5WKENEVW1V7V0W8JZEZ"
  ]
}

 DEBUG Channel Connectivity change to SHUTDOWN 
 DEBUG Subchannel Connectivity change to SHUTDOWN
 DEBUG Finished streaming call                  duration=1.98282056s error=context canceled grpc_method=LinkGateway grpc_service=ttn.lorawan.v3.GtwGs

rvolosatovs · 2020-04-01T13:23:01Z

Please make sure the device does not send uplinks when executing the commands

sidpat · 2020-04-01T13:42:45Z

@rvolosatovs,
I tried the join accept cli command,

$ ttn-lw-cli simulate join-request --dev-eui 0908070605040304 --join-eui 0000000000000001 --dev-nonce 1234 --lorawan-version 1.1.0 --lorawan-phy-version 1.1.0-b --app-key 11223344556677889900AABBCCDD0233 --nwk-key 11223344556677889900AABBCCDD0222 --gateway-id nu-mtc-1
  INFO Sent uplink                             
error:unknown:unknown (context deadline exceeded)

my gateway received the join accept uplink but got dropped with below error (also gateway got disconnected again, had to restart),

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
  "namespace": "pkg/gatewayserver",
  "name": "host_handle",
  "message_format": "host `{host}` failed to handle message",
  "attributes": {
    "host": "cluster"
  },
  "cause": {
    "namespace": "pkg/networkserver",
    "name": "uplink_channel_not_found",
    "message_format": "uplink channel not found",
    "correlation_id": "59a293b794a24548b72184fccefea2b6",
    "code": 5
  },
  "code": 5
}

cli version info:

$ ttn-lw-cli version
The Things Network Command-line Interface: ttn-lw-cli
Version:             3.6.3
Build date:          2020-03-30T14:16:58Z
Git commit:          a37768827
Go version:          go1.13.9
OS/Arch:             darwin/amd64

In your test end device can you try the RekeyInd mac command with piggybacked data(like how I mentioned above) as first uplink from your side and see if that works?

rvolosatovs · 2020-04-01T16:14:02Z

What band are you in? You will have to configure --band-id accordingly (by default it uses EU868)

In your test end device can you try the RekeyInd mac command with piggybacked data(like how I mentioned above) as first uplink from your side and see if that works?

I have done that, see #2171 (comment) (under Log)

sidpat · 2020-04-02T02:15:11Z

Hi @rvolosatovs, my first uplink does contain the RekeyInd mac command and is persisted till RekeyConf is received. Please find below my first uplink data,
Frm_Payload={0x01, 0x0A, 0x02, 0x0B, 0x03, 0x0C}
Fopts={0x0B, 0x01}
Port=10

@rvolosatovs, I meant have you tested with a similar uplink data({0x0B, 0x01}=RekeyInd) on your actual end device(not simulation) immediately after join request?

What band are you in? You will have to configure --band-id accordingly (by default it uses EU868)

Tried this, got same error and disconnect gateway.

rvolosatovs · 2020-04-02T08:03:52Z

The gateway "disconnect" you see after executing the command does not influence the connectivity of the actual physical gateway.

@rvolosatovs, I meant have you tested with a similar uplink data({0x0B, 0x01}=RekeyInd) on your actual end device(not simulation) immediately after join request?

Unfortunately, I do not have a physical 1.1 device at hand, so cannot test it that way. Which device are you using?

Tried this, got same error and disconnect gateway.

That's weird, is your gateway configured for the right frequency plan?

sidpat · 2020-04-02T08:52:29Z

The gateway "disconnect" you see after executing the command does not influence the connectivity of the actual physical gateway.

Well my gateway stops receiving traffic after running that cli command. TTI console shows gateway last seen: disconnected.

Unfortunately, I do not have a physical 1.1 device at hand, so cannot test it that way. Which device are you using?

Using STM32 discovery board.

That's weird, is your gateway configured for the right frequency plan?

Yes, I am able to successfully perform join with my end device.

rvolosatovs · 2020-04-02T09:43:51Z

Using STM32 discovery board.

And which firmware are you using with it?

sidpat · 2020-04-02T09:49:13Z

And which firmware are you using with it?

LoRaMac-Node

rvolosatovs · 2020-04-02T16:07:40Z

Please see Lora-net/LoRaMac-node#862
LoRaWAN 1.1 support is broken in LoRaMac-Node versions available at https://github.com/Lora-net/LoRaMac-node

I suggest you register your device as MAC version 1.0.4 instead and use it in 1.0-compatibilty mode.

sidpat · 2020-04-03T05:03:03Z

Please see Lora-net/LoRaMac-node#862
LoRaWAN 1.1 support is broken in LoRaMac-Node versions available at https://github.com/Lora-net/LoRaMac-node

We are using the feature branch which supports v1.1. Please check that branch also. We are tried this with TTI v3.6.0 and, join and uplinks were working properly.

rvolosatovs · 2020-04-03T09:16:11Z

We are using the feature branch which supports v1.1

The issue is present in both develop and feature/5.0.0, which branch are you referring to?

sidpat · 2020-04-03T13:36:33Z

Feature/5.0.0 only. Agree on the brute force method for selecting the right key for MIC for handling join accept frame, but join accept (from join-request) does work with v1.1.0 NS. Haven't tested rejoin-request though.

rvolosatovs · 2020-04-03T16:52:39Z

join accept (from join-request) does work with v1.1.0 NS

That must then indicate either a bug in the Network Server or Network Server operating in 1.0-compatiblity mode.
According to 1.1 spec, the join-accept following a join-request (when operating in 1.1 mode, i.e. when OptNeg is set) MUST be encrypted using NwkKey and the MIC must be calculated using JSIntKey.
https://github.com/Lora-net/LoRaMac-node only uses either NwkKey for both encryption and MIC calculation or JSEncKey for encryption and JSIntKey for MIC computation, hence it may never successfully process a join-accept from a 1.1 LoRaWAN Network Server running in 1.1 mode by definition.

sidpat · 2020-04-04T11:49:05Z

My end device does use the right key for encryption and MIC calculation, which is why the v1.1 join procedure is working. Coming back to the issue of this topic, could you have someone test the v1.1 uplinks in TTI cloud?

rvolosatovs · 2020-04-06T12:04:04Z

I just opened a pull request, which fixes a bug I found in LoRaWAN 1.1 spec implementation #2307 related to DeviceModeInd.
I also fixed the 1.1 operation in mbed-os(ARMmbed/mbed-os#12762).
Using these 2 versions I was able to let my FF1705 join, send uplinks and receive downlinks. Please confirm that works for you, if you're able to use mbed-os(with my patchset applied) on your device.

~~The uplink MIC calculation in the stack version currently deployed is broken, which will be fixed in #2307~~ Unless you use class C, your devices should be able to operate on our currently deployed version of the stack in 1.1 mode.

sidpat · 2020-04-07T05:58:57Z

@rvolosatovs,

Any reason why session information is blank in the device overview page in console, simultaneously session keys are also not shown in the general settings page inside network layer tab. Previously it did show all the keys that were generated after the join procedure.

Also what issues would cause this dropped uplink error message? (my dev address is correctly received after join accept)

{
  "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
  "namespace": "pkg/gatewayserver",
  "name": "host_handle",
  "message_format": "host `{host}` failed to handle message",
  "attributes": {
    "host": "cluster"
  },
  "cause": {
    "namespace": "pkg/networkserver",
    "name": "device_not_found",
    "message_format": "device not found",
    "correlation_id": "989000f89ad24f1fade698479ae2efbd",
    "code": 5
  },
  "code": 5
}

rvolosatovs · 2020-04-07T10:59:10Z

The reason why you don't see any session information is because the session is not confirmed yet (i.e. a device still has not sent an uplink using the derived DevAddr, which Network Server would successfully process)
You can see the pending session via ttn-lw-cli devices get <app-id> <dev-id> --pending-session

Assuming right DevAddr is used it's either missing RekeyInd or MIC mismatch.
As an example, mbed-os was using incorrect key pair for uplink MIC computation(see ARMmbed/mbed-os#12762).

sidpat · 2020-04-08T09:38:54Z

Got my uplinks working. So the issue is that my first uplink is with RekeyInd piggybacked with data which doesn't work, but when I send the RekeyInd in frame-payload on port 0 it works. I don't see the necessity of sending RekeyInd using port 0 in the v1.1 lorawan specs, so is this a NS issue?

Also I see the NS sending LinkAdrReq repeatedly even after my end device answers correctly, again using piggybacked uplink mode, which makes me think that piggybacking mac command with data doesn't work in the current version of TTI.

sidpat · 2020-04-08T11:03:55Z

Additional finding was that console logs shows incorrect channel index for 2 particular instances, though Tx MIC was correctly accepted by NS. In the IN865 region, frequency 865.985 Mhz has id-2(its the 3rd of the 3 fixed channels according to specs) but console show id-3 and conversely channel id-3, 865.2325 Mhz(i.e. received in CFList) is label id-2 in the console.

...    
},
    "coding_rate": "4/5",
    "frequency": "865985000",
    "timestamp": 631348531
  },
  "rx_metadata": [
    {
      "gateway_ids": {
        "gateway_id": "xx",
        "eui": "xx"
      },
      "timestamp": 631348531,
      "rssi": -32,
      "channel_rssi": -32,
      "snr": 10.5,
      "uplink_token": "ChYKFAoIbnUtbXRjLTESCACAAACgADKIELO6hq0C",
      "channel_index": 3
    }
  ...

Also when tx channel index is 0, console logs skips that data point in the json.

htdvisser · 2020-04-08T11:34:55Z

I'll quickly reopen this issue so that it doesn't get lost, but maybe we should open new issues for these problems instead.

@rvolosatovs please triage the last 2 comments from @sidpat.

rvolosatovs · 2020-04-10T09:11:41Z

Additional finding was that console logs shows incorrect channel index for 2 particular instances, though Tx MIC was correctly accepted by NS. In the IN865 region, frequency 865.985 Mhz has id-2(its the 3rd of the 3 fixed channels according to specs) but console show id-3 and conversely channel id-3, 865.2325 Mhz(i.e. received in CFList) is label id-2 in the console.

The channel_index in rx_metadata is not necessarily the channel index used by the device, perhaps you're looking for device_channel_index field, that must be correct - can you confirm?

Got my uplinks working. So the issue is that my first uplink is with RekeyInd piggybacked with data which doesn't work, but when I send the RekeyInd in frame-payload on port 0 it works. I don't see the necessity of sending RekeyInd using port 0 in the v1.1 lorawan specs, so is this a NS issue?

Also I see the NS sending LinkAdrReq repeatedly even after my end device answers correctly, again using piggybacked uplink mode, which makes me think that piggybacking mac command with data doesn't work in the current version of TTI.

Sorry, I cannot reproduce this, see:

$ ttn-lw-cli simulate join-request --dev-eui DEADBEEF01020304 --join-eui 01020304DEADBEEF --dev-nonce 0x0001 --lorawan-version 1.1.0 --lorawan-phy-version 1.1.0-b --app-key "01020304050607080102030405060708" --nwk-key "01020304050607080102030405060708" --gateway-id test-gtw        
 DEBUG Using access token (valid until 11:52AM)
 DEBUG ccResolverWrapper: sending update to cc: {[{localhost:8884  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG Channel switches to new LB policy "pick_first"
 DEBUG Subchannel Connectivity change to CONNECTING
 DEBUG Subchannel picks a new address "localhost:8884" to connect
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc00081fbb0, {CONNECTING <nil>}
 DEBUG Channel Connectivity change to CONNECTING
 DEBUG Subchannel Connectivity change to READY 
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc00081fbb0, {READY <nil>}
 DEBUG Channel Connectivity change to READY    
  INFO Sent uplink                             
  INFO Received downlink (after 1.984256144s) for transmission 5s relative to uplink
  INFO Derived AppSKey AF99A9CF1285B0F77FF5F5FE42089D87 (r5mpzxKFsPd/9fX+Qgidhw==)
  INFO Derived FNwkSIntKey CFF2EEE0479B057AE67905316ED34485 (z/Lu4EebBXrmeQUxbtNEhQ==)
  INFO Derived SNwkSIntKey C3589D2E68237D94A9F78EFF4C99DBBF (w1idLmgjfZSp947/TJnbvw==)
  INFO Derived NwkSEncKey BDE24CB08F472D6F995A2ABB2A320600 (veJMsI9HLW+ZWiq7KjIGAA==)
{
  "raw_payload": "IBctPx2IG8LN0ZpcYmJJ9qO/vjgdzqSwLmEt/abWzjcr",
  "payload": {
    "m_hdr": {
      "m_type": "JOIN_ACCEPT"
    },
    "mic": "p/YcZQ==",
    "join_accept_payload": {
      "encrypted": "Fy0/HYgbws3RmlxiYkn2o7++OB3OpLAuYS39ptbONys=",
      "join_nonce": "000001",
      "net_id": "000000",
      "dev_addr": "009E4002",
      "dl_settings": {
        "opt_neg": true
      },
      "rx_delay": 5,
      "cf_list": {
        "freq": [
          8671000,
          8673000,
          8675000,
          8677000,
          8679000
        ]
      }
    }
  },
  "scheduled": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 12
      }
    },
    "coding_rate": "4/5",
    "frequency": "868100000",
    "timestamp": 59637156,
    "downlink": {
      "tx_power": 16.15,
      "invert_polarization": true
    }
  },
  "correlation_ids": [
    "gs:conn:01E5HN9KF70Y6500YXNAR80R6Z",
    "gs:uplink:01E5HN9KGH58S58JG4AVTMZNZV",
    "ns:downlink:01E5HN9NC63PQYFQHZXCX49GAT",
    "ns:uplink:01E5HN9KGHEK06BXR0EP6SSTNW",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01E5HN9KGHZ0YGG127S309F6N5",
    "rpc:/ttn.lorawan.v3.GtwGs/LinkGateway:01E5HN9KE758WZTAJDCW1V4DBQ",
    "gs:conn:01E5HN9KF70Y6500YXNAR80R6Z",
    "rpc:/ttn.lorawan.v3.GtwGs/LinkGateway:01E5HN9KE758WZTAJDCW1V4DBQ",
    "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01E5HN9NC6BM4J1QDPSSAJDA20"
  ]
}

 DEBUG Channel Connectivity change to SHUTDOWN 
 DEBUG Subchannel Connectivity change to SHUTDOWN

$ ttn-lw-cli simulate uplink --f-nwk-s-int-key CFF2EEE0479B057AE67905316ED34485 --s-nwk-s-int-key C3589D2E68237D94A9F78EFF4C99DBBF --nwk-s-enc-key BDE24CB08F472D6F995A2ABB2A320600 --app-s-key AF99A9CF1285B0F77FF5F5FE42089D87 --lorawan-version 1.1.0 --frm-payload 0x010A020B030C --f-opts 0x0B012001 --f-port 0x42 --dev-addr 0x009E4002 --gateway-id test-gtw        
 DEBUG Using access token (valid until 11:52AM)
 DEBUG ccResolverWrapper: sending update to cc: {[{localhost:8884  <nil> 0 <nil>}] <nil> <nil>}
 DEBUG Channel switches to new LB policy "pick_first"
 DEBUG Subchannel Connectivity change to CONNECTING
 DEBUG Subchannel picks a new address "localhost:8884" to connect
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc0002e6110, {CONNECTING <nil>}
 DEBUG Channel Connectivity change to CONNECTING
 DEBUG Subchannel Connectivity change to READY 
 DEBUG pickfirstBalancer: HandleSubConnStateChange: 0xc0002e6110, {READY <nil>}
 DEBUG Channel Connectivity change to READY    
  INFO Sent uplink                             
  INFO Received downlink (after 2.146592287s) for transmission 5s relative to uplink
  INFO Read MAC command                         cid=CID_REKEY payload=&MACCommand_RekeyConf_{RekeyConf:&MACCommand_RekeyConf{MinorVersion:MINOR_1,},}
  INFO Read MAC command                         cid=CID_DEVICE_MODE payload=&MACCommand_DeviceModeConf_{DeviceModeConf:&MACCommand_DeviceModeConf{Class:CLASS_A,},}
  INFO Read MAC command                         cid=CID_DEV_STATUS payload=<nil>
{
  "raw_payload": "YAJAngCAAAAAhvOCFvEtbOGy",
  "payload": {
    "m_hdr": {
      "m_type": "UNCONFIRMED_DOWN"
    },
    "mic": "LWzhsg==",
    "mac_payload": {
      "f_hdr": {
        "dev_addr": "009E4002",
        "f_ctrl": {
          "adr": true
        }
      },
      "frm_payload": "CwEgAAY="
    }
  },
  "scheduled": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 12
      }
    },
    "coding_rate": "4/5",
    "frequency": "868100000",
    "timestamp": 140958158,
    "downlink": {
      "tx_power": 16.15,
      "invert_polarization": true
    }
  },
  "correlation_ids": [
    "gs:conn:01E5HNC2WEXYZH51BE8VKAHGYD",
    "gs:uplink:01E5HNC2XQN4PDWJCCVXC81HTD",
    "ns:downlink:01E5HNC4YDZNFSSB5FXC18RW7R",
    "ns:uplink:01E5HNC2XQ0473E3ZF97S0TM0G",
    "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01E5HNC2XQ234HYFWHQCYRA823",
    "rpc:/ttn.lorawan.v3.GtwGs/LinkGateway:01E5HNC2VC56GDG2RB5QT2RHMM",
    "gs:conn:01E5HNC2WEXYZH51BE8VKAHGYD",
    "rpc:/ttn.lorawan.v3.GtwGs/LinkGateway:01E5HNC2VC56GDG2RB5QT2RHMM",
    "rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01E5HNC4YEGKD8RZF1Y8JE1YJS"
  ]
}

 DEBUG Channel Connectivity change to SHUTDOWN 
 DEBUG Subchannel Connectivity change to SHUTDOWN

MAC commands in FOpts are treated exactly the same as the ones in FRMPayload when FPort==0. Regarding repeated sending that's probably an instance of #2192. Does your device confirm the LinkADRReq?

sidpat · 2020-04-10T19:30:49Z

The channel_index in rx_metadata is not necessarily the channel index used by the device, perhaps you're looking for device_channel_index field, that must be correct - can you confirm?

The TTI console only shows channel_index in the gateway logs. I am looking for the channel index that the end device uses, perhaps it's device_channel_index as you mentioned, but that field is not present in the logs.

MAC commands in FOpts are treated exactly the same as the ones in FRMPayload when FPort==0.

Then the implementation is incorrect. The v1.1 specs has a slightly different scheme for encryption for FOpts and frame-payload. Compare the respective A blocks at lines 686 and 750 of the spec document.

Created a pull-request here - #2339

rvolosatovs · 2020-04-14T08:19:59Z

The channel_index in rx_metadata is not necessarily the channel index used by the device, perhaps you're looking for device_channel_index field, that must be correct - can you confirm?

The TTI console only shows channel_index in the gateway logs. I am looking for the channel index that the end device uses, perhaps it's device_channel_index as you mentioned, but that field is not present in the logs.

Currently zero values are not rendered, so if device_channel_index is not shown, it means it's 0.

MAC commands in FOpts are treated exactly the same as the ones in FRMPayload when FPort==0.

Then the implementation is incorrect. The v1.1 specs has a slightly different scheme for encryption for FOpts and frame-payload. Compare the respective A blocks at lines 686 and 750 of the spec document.

Created a pull-request here - #2339

Good one, thank you! I will review it now and do the changes necessary to make it work.

…ture/doc-images-clickable Make doc images clickable and TTES specific

KrishnaIyer added the bug Something isn't working label Mar 17, 2020

KrishnaIyer assigned KrishnaIyer and rvolosatovs Mar 17, 2020

KrishnaIyer added this to the March 2020 milestone Mar 17, 2020

rvolosatovs mentioned this issue Mar 18, 2020

Network Server uplink handling fixes and testing #2186

Merged

6 tasks

rvolosatovs closed this as completed in #2186 Mar 19, 2020

rvolosatovs mentioned this issue Apr 1, 2020

Support simulating FOpts #2279

Merged

6 tasks

rvolosatovs mentioned this issue Apr 3, 2020

Device stack does not support joining on LoRaWAN 1.1 Network Servers Lora-net/LoRaMac-node#862

Closed

rvolosatovs mentioned this issue Apr 6, 2020

Fix LoRaWAN 1.1 support #2307

Merged

6 tasks

rvolosatovs modified the milestones: March 2020, April 2020 Apr 6, 2020

htdvisser reopened this Apr 8, 2020

sidpat mentioned this issue Apr 10, 2020

Fix FOpts encryption and decryption in LoRaWAN 1.1 frames #2339

Merged

6 tasks

rvolosatovs unassigned KrishnaIyer Apr 14, 2020

rvolosatovs added the in progress We're working on it label Apr 14, 2020

rvolosatovs changed the title ~~TTN enterprise cloud hosted: Uplinks not working~~ LoRaWAN 1.1 issues Apr 14, 2020

rvolosatovs changed the title ~~LoRaWAN 1.1 issues~~ LoRaWAN 1.1 uplink issues Apr 14, 2020

rvolosatovs closed this as completed in #2339 Apr 14, 2020

rvolosatovs mentioned this issue Apr 22, 2020

Support RekeyInd retransmissions and improve security #2399

Merged

6 tasks

rvolosatovs pushed a commit to rvolosatovs/lorawan-stack-fork that referenced this issue Sep 15, 2020

Merge pull request TheThingsNetwork#2171 from TheThingsIndustries/fea…

74586e3

…ture/doc-images-clickable Make doc images clickable and TTES specific

Ollrogge mentioned this issue May 30, 2022

gnrc/lorawan: add basic LoRaWAN 1.1 features RIOT-OS/RIOT#17884

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LoRaWAN 1.1 uplink issues #2171

LoRaWAN 1.1 uplink issues #2171

sidpat commented Mar 17, 2020

rvolosatovs commented Mar 18, 2020

sidpat commented Apr 1, 2020 •

edited

rvolosatovs commented Apr 1, 2020

sidpat commented Apr 1, 2020 •

edited

rvolosatovs commented Apr 1, 2020

rvolosatovs commented Apr 1, 2020

sidpat commented Apr 1, 2020 •

edited

sidpat commented Apr 1, 2020 •

edited

rvolosatovs commented Apr 1, 2020 •

edited

rvolosatovs commented Apr 1, 2020

sidpat commented Apr 1, 2020 •

edited

rvolosatovs commented Apr 1, 2020 •

edited

sidpat commented Apr 2, 2020 •

edited

rvolosatovs commented Apr 2, 2020 •

edited

sidpat commented Apr 2, 2020 •

edited

rvolosatovs commented Apr 2, 2020

sidpat commented Apr 2, 2020

rvolosatovs commented Apr 2, 2020 •

edited

sidpat commented Apr 3, 2020

rvolosatovs commented Apr 3, 2020

sidpat commented Apr 3, 2020

rvolosatovs commented Apr 3, 2020

sidpat commented Apr 4, 2020

rvolosatovs commented Apr 6, 2020 •

edited

sidpat commented Apr 7, 2020 •

edited

rvolosatovs commented Apr 7, 2020 •

edited

sidpat commented Apr 8, 2020

sidpat commented Apr 8, 2020 •

edited

htdvisser commented Apr 8, 2020

rvolosatovs commented Apr 10, 2020

sidpat commented Apr 10, 2020 •

edited

rvolosatovs commented Apr 14, 2020

LoRaWAN 1.1 uplink issues #2171

LoRaWAN 1.1 uplink issues #2171

Comments

sidpat commented Mar 17, 2020

Summary

Steps to Reproduce

What do you see now?

What do you want to see instead?

Environment

How do you propose to implement this?

Can you do this yourself and submit a Pull Request?

rvolosatovs commented Mar 18, 2020

sidpat commented Apr 1, 2020 • edited

rvolosatovs commented Apr 1, 2020

sidpat commented Apr 1, 2020 • edited

rvolosatovs commented Apr 1, 2020

rvolosatovs commented Apr 1, 2020

sidpat commented Apr 1, 2020 • edited

sidpat commented Apr 1, 2020 • edited

rvolosatovs commented Apr 1, 2020 • edited

rvolosatovs commented Apr 1, 2020

sidpat commented Apr 1, 2020 • edited

rvolosatovs commented Apr 1, 2020 • edited

sidpat commented Apr 2, 2020 • edited

rvolosatovs commented Apr 2, 2020 • edited

sidpat commented Apr 2, 2020 • edited

rvolosatovs commented Apr 2, 2020

sidpat commented Apr 2, 2020

rvolosatovs commented Apr 2, 2020 • edited

sidpat commented Apr 3, 2020

rvolosatovs commented Apr 3, 2020

sidpat commented Apr 3, 2020

rvolosatovs commented Apr 3, 2020

sidpat commented Apr 4, 2020

rvolosatovs commented Apr 6, 2020 • edited

sidpat commented Apr 7, 2020 • edited

rvolosatovs commented Apr 7, 2020 • edited

sidpat commented Apr 8, 2020

sidpat commented Apr 8, 2020 • edited

htdvisser commented Apr 8, 2020

rvolosatovs commented Apr 10, 2020

sidpat commented Apr 10, 2020 • edited

rvolosatovs commented Apr 14, 2020

sidpat commented Apr 1, 2020 •

edited

sidpat commented Apr 1, 2020 •

edited

sidpat commented Apr 1, 2020 •

edited

sidpat commented Apr 1, 2020 •

edited

rvolosatovs commented Apr 1, 2020 •

edited

sidpat commented Apr 1, 2020 •

edited

rvolosatovs commented Apr 1, 2020 •

edited

sidpat commented Apr 2, 2020 •

edited

rvolosatovs commented Apr 2, 2020 •

edited

sidpat commented Apr 2, 2020 •

edited

rvolosatovs commented Apr 2, 2020 •

edited

rvolosatovs commented Apr 6, 2020 •

edited

sidpat commented Apr 7, 2020 •

edited

rvolosatovs commented Apr 7, 2020 •

edited

sidpat commented Apr 8, 2020 •

edited

sidpat commented Apr 10, 2020 •

edited