Lorawan-stack: Проблемы с восходящим каналом LoRaWAN 1.1

Спасибо за сообщение, обработка RekeyInd действительно недавно была нарушена. Это исправлено в https://github.com/TheThingsNetwork/lorawan-stack/pull/2186 и попадет в 3.6.2 , который будет выпущен и развернут очень скоро.

@rvolosatovs , этот патч развернут на корпоративной облачной версии? Я по-прежнему получаю указанную ниже ошибку восходящего канала в журналах шлюза в консоли,

{
  "@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
}

Эта ошибка сама по себе не указывает на то, что что-то не так, это нормально для шлюзов получать и пересылать трафик неизвестных устройств из-за характера LoRaWAN. Вы скучаете по трафику устройства?

@rvolosatovs , это трафик с моего конечного устройства.
Шаги по воспроизведению проблемы:

1. создать конечное устройство с последними версиями mac и phy
2. с этого устройства отправьте аплинк после присоединения

Я не могу воспроизвести проблему ни локально, ни на экземпляре, размещенном в облаке.
Можете ли вы подтвердить, что ваше устройство отправляет RekeyInd во всех кадрах восходящего канала до тех пор, пока не будет получен RekeyConf как того требует спецификация 1.1?

Не могли бы вы попробовать имитировать аплинк со своего устройства после присоединения через:

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>

И подтвердить, что вы получаете нисходящий канал с возвратом RekeyConf ?

Привет, @rvolosatovs , мой первый

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

Я выполнил запрошенную команду и получил следующую ошибку:

$ 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)

В моих журналах шлюза на консоли я получил disconnect gateway после этой команды. Пришлось перезапустить мой шлюз, чтобы он снова был в сети.
Мой шлюз - это мультитехнологический канал AEP.

Пожалуйста, попробуйте это (убедитесь, что dev nonce достаточно высок):

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

Вы должны получить join-accept, а затем использовать данные из join-accept для имитации восходящего канала:

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

К сожалению, ttn-lw-cli simulate uplink время не поддерживает FOpts (входящий PR), но я локально изменил его и смог отправить аплинк с https://github.com/TheThingsNetwork/lorawan-stack / issues / 2171 # issuecomment -607213202 и успешно обработал (получил нисходящий канал класса A)

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 ,
Я попробовал команду join accept cli,

$ 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)

мой шлюз получил восходящий канал подключения, но был сброшен с ошибкой ниже (также шлюз снова отключился, пришлось перезапустить),

{
  "@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:

$ 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

Можете ли вы попробовать на своем тестовом конечном устройстве команду RekeyInd mac с совмещенными данными (например, как я упоминал выше) в качестве первого восходящего канала с вашей стороны и посмотреть, работает ли это?

В какой группе ты? Вам нужно будет настроить --band-id соответственно (по умолчанию используется EU868)

Можете ли вы попробовать на своем тестовом конечном устройстве команду RekeyInd mac с совмещенными данными (например, как я упоминал выше) в качестве первого восходящего канала с вашей стороны и посмотреть, работает ли это?

Я сделал это, см. Https://github.com/TheThingsNetwork/lorawan-stack/issues/2171#issuecomment -607245023 (под Log )

Привет, @rvolosatovs , мой первый

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

@rvolosatovs , я имел в виду, тестировали ли вы с аналогичными данными восходящего канала ( {0x0B, 0x01} = RekeyInd) на своем фактическом конечном устройстве (не моделировании) сразу после запроса на присоединение?

В какой группе ты? Вам нужно будет настроить --band-id соответственно (по умолчанию используется EU868)

Пробовал, получил ту же ошибку и отключил шлюз.

«Отключение» шлюза, которое вы видите после выполнения команды, не влияет на возможность подключения реального физического шлюза.

@rvolosatovs , я имел в виду, тестировали ли вы с аналогичными данными восходящего канала ({0x0B, 0x01} = RekeyInd) на вашем реальном конечном устройстве (не моделировании) сразу после запроса на присоединение?

К сожалению, у меня под рукой нет физического устройства 1.1, поэтому я не могу его протестировать. Какое устройство вы используете?

Пробовал, получил ту же ошибку и отключил шлюз.

Это странно, ваш шлюз настроен на правильный частотный план?

«Отключение» шлюза, которое вы видите после выполнения команды, не влияет на возможность подключения реального физического шлюза.

Что ж, мой шлюз перестает получать трафик после выполнения этой команды cli. Консоль TTI показывает последний посещенный шлюз: отключен.

К сожалению, у меня под рукой нет физического устройства 1.1, поэтому я не могу его протестировать. Какое устройство вы используете?

Использование платы обнаружения STM32.

Это странно, ваш шлюз настроен на правильный частотный план?

Да, я могу успешно выполнить соединение с моим конечным устройством.

Использование платы обнаружения STM32.

А какую прошивку с ним используете?

А какую прошивку с ним используете?

LoRaMac-Узел

См. Https://github.com/Lora-net/LoRaMac-node/issues/862
Поддержка LoRaWAN 1.1 нарушена в версиях LoRaMac-Node, доступных по адресу https://github.com/Lora-net/LoRaMac-node

Я предлагаю вам вместо этого зарегистрировать свое устройство как MAC-версию 1.0.4 и использовать его в режиме совместимости с 1.0.

Пожалуйста, смотрите Lora-net / LoRaMac-узел # 862
Поддержка LoRaWAN 1.1 нарушена в версиях LoRaMac-Node, доступных по адресу https://github.com/Lora-net/LoRaMac-node

Мы используем функциональную ветку, которая поддерживает v1.1. Также проверьте эту ветку. Мы пробовали это с TTI v3.6.0, и соединение и восходящие каналы работали правильно.

Мы используем функциональную ветку, которая поддерживает v1.1.

Проблема присутствует как в develop и в feature/5.0.0 , о какой ветви вы имеете в виду?

Только функция / 5.0.0. Согласитесь с методом грубой силы для выбора правильного ключа для MIC для обработки кадра принятия соединения, но принятие соединения (из запроса соединения) действительно работает с v1.1.0 NS. Однако еще не тестировал запрос на повторное присоединение.

join accept (из запроса на соединение) работает с v1.1.0 NS

Это должно тогда указывать либо на ошибку в сетевом сервере, либо на сетевом сервере, работающем в режиме совместимости с 1.0.
Согласно спецификации 1.1, принятие соединения после запроса соединения (при работе в режиме 1.1, т. Е. Когда установлено OptNeg ) ДОЛЖНО быть зашифровано с использованием NwkKey а MIC должен быть рассчитан с использованием JSIntKey .
https://github.com/Lora-net/LoRaMac-node использует только NwkKey для шифрования и вычисления MIC, либо JSEncKey для шифрования и JSIntKey для вычисления MIC, следовательно, он никогда не сможет успешно обработать присоединение-принятие от сетевого сервера 1.1 LoRaWAN, работающего в режиме 1.1 по определению.

Мое конечное устройство использует правильный ключ для шифрования и расчета MIC, поэтому процедура соединения v1.1 работает. Возвращаясь к теме этой темы, не могли бы вы протестировать восходящие каналы v1.1 в облаке TTI?

Я только что открыл запрос на перенос, который исправляет ошибку, обнаруженную мной в реализации спецификации LoRaWAN 1.1 https://github.com/TheThingsNetwork/lorawan-stack/pull/2307, связанной с DeviceModeInd .
Я также исправил операцию 1.1 в mbed-os (https://github.com/ARMmbed/mbed-os/pull/12762).
Используя эти 2 версии, я смог разрешить моему FF1705 подключаться, отправлять восходящие и нисходящие каналы. Пожалуйста, подтвердите, что это работает для вас, если вы можете использовать mbed-os (с примененным моим набором исправлений) на вашем устройстве.

~ Расчет MIC восходящего канала в развернутой в настоящее время версии стека нарушен, что будет исправлено в https://github.com/TheThingsNetwork/lorawan-stack/pull/2307~ Если вы не используете класс C, ваши устройства должны работать. в нашей развернутой в настоящее время версии стека в режиме 1.1.

@rvolosatovs ,

По любой причине, по которой информация о сеансе пуста на странице обзора устройства в консоли, одновременно ключи сеанса также не отображаются на странице общих настроек на вкладке сетевого уровня. Ранее он показывал все ключи, которые были сгенерированы после процедуры соединения.

Также какие проблемы могут вызвать это сообщение об ошибке отброшенного восходящего канала? (мой адрес разработчика правильно получен после принятия присоединения)

{
  "@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
}

Причина, по которой вы не видите никакой информации о сеансе, заключается в том, что сеанс еще не подтвержден (т.е. устройство все еще не отправило восходящий канал с использованием производного DevAddr, который сетевой сервер успешно обработал бы)
Вы можете увидеть ожидающий сеанс через ttn-lw-cli devices get <app-id> <dev-id> --pending-session

Предполагая, что используется правильный DevAddr , либо отсутствует RekeyInd либо несоответствие MIC.
Например, mbed-os использовала неверную пару ключей для вычисления MIC восходящего канала (см. Https://github.com/ARMmbed/mbed-os/pull/12762).

Мои аплинки заработали. Итак, проблема в том, что мой первый восходящий канал связан с RekeyInd совмещенным с данными, которые не работают, но когда я отправляю RekeyInd в полезной нагрузке кадра на порт 0, он работает. Я не вижу необходимости отправлять RekeyInd через порт 0 в спецификации lorawan v1.1, так это проблема NS?

Также я вижу, что NS повторно отправляет LinkAdrReq даже после того, как мое конечное устройство отвечает правильно, снова используя режим совмещенного восходящего канала, что заставляет меня думать, что совмещение команды Mac с данными не работает в текущей версии TTI.

Дополнительным обнаружением было то, что журналы консоли показывают неверный индекс канала для 2 конкретных экземпляров, хотя Tx MIC был правильно принят NS. В области IN865 частота 865,985 МГц имеет id-2 (это 3-й из 3 фиксированных каналов в соответствии со спецификациями), но консоль показывает id-3 и, наоборот, канал id-3, 865,2325 МГц (то есть полученный в CFList) - это метка id- 2 в консоли.

...    
},
    "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
    }
  ...

Также, когда индекс tx-канала равен 0, журналы консоли пропускают эту точку данных в файле json.

Я быстро открою эту проблему, чтобы она не потерялась, но, возможно, нам стоит вместо этого открыть новые выпуски для этих проблем.

@rvolosatovs, пожалуйста,

Дополнительным обнаружением было то, что журналы консоли показывают неверный индекс канала для 2 конкретных экземпляров, хотя Tx MIC был правильно принят NS. В области IN865 частота 865,985 МГц имеет id-2 (это 3-й из 3 фиксированных каналов в соответствии со спецификациями), но консоль показывает id-3 и, наоборот, канал id-3, 865,2325 МГц (то есть полученный в CFList) - это метка id- 2 в консоли.

channel_index в rx_metadata не обязательно является индексом канала, используемым устройством, возможно, вы ищете поле device_channel_index , которое должно быть правильным - вы можете подтвердить?

Мои аплинки заработали. Итак, проблема в том, что мой первый восходящий канал связан с RekeyInd совмещенным с данными, которые не работают, но когда я отправляю RekeyInd в полезной нагрузке кадра на порт 0, он работает. Я не вижу необходимости отправлять RekeyInd через порт 0 в спецификации lorawan v1.1, так это проблема NS?

Также я вижу, что NS повторно отправляет LinkAdrReq даже после того, как мое конечное устройство отвечает правильно, снова используя режим совмещенного восходящего канала, что заставляет меня думать, что совмещение команды Mac с данными не работает в текущей версии TTI.

Извините, я не могу воспроизвести это, см .:

$ 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 в FOpts обрабатываются точно так же, как и команды в FRMPayload при FPort==0 . Что касается повторной отправки, это, вероятно, экземпляр # 2192. Подтверждает ли ваше устройство LinkADRReq ?

channel_index в rx_metadata не обязательно является индексом канала, используемым устройством, возможно, вы ищете поле device_channel_index , которое должно быть правильным - вы можете подтвердить?

Консоль TTI показывает только channel_index в журналах шлюза. Я ищу индекс канала, который использует конечное устройство, возможно, это device_channel_index как вы упомянули, но этого поля нет в журналах.

MAC-команды в FOpts обрабатываются точно так же, как и команды в FRMPayload при FPort==0 .

Тогда реализация неверна. В спецификации v1.1 немного другая схема шифрования для FOpts и полезной нагрузки кадра. Сравните соответствующие блоки A в строках 686 и 750 документа спецификации.

Создал пул-реквест здесь - https://github.com/TheThingsNetwork/lorawan-stack/pull/2339

channel_index в rx_metadata не обязательно является индексом канала, используемым устройством, возможно, вы ищете поле device_channel_index , которое должно быть правильным - вы можете подтвердить?

Консоль TTI показывает только channel_index в журналах шлюза. Я ищу индекс канала, который использует конечное устройство, возможно, это device_channel_index как вы упомянули, но этого поля нет в журналах.

В настоящее время нулевые значения не отображаются, поэтому, если device_channel_index не отображается, это означает, что это 0 .

Команды MAC в FOpts обрабатываются точно так же, как и команды в FRMPayload при FPort==0 .

Тогда реализация неверна. В спецификации v1.1 немного другая схема шифрования для FOpts и полезной нагрузки кадра. Сравните соответствующие блоки A в строках 686 и 750 документа спецификации.

Создал здесь пул-реквест - # 2339

Хороший, спасибо! Я рассмотрю его сейчас и внесу необходимые изменения, чтобы заставить его работать.