Lorawan-stack: Downlinks rejeitados por gateways para certos poderes de TX

O erro parece ocorrer com Lora-net/packet_forwarder . Código relevante: https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L2517 -L2527

Com as configurações de gateway que foram distribuídas por meio de TTN (https://github.com/TheThingsNetwork/gateway-conf/), os seguintes poderes TX são aceitos por gateways:

-6 , -3 , 0 , 3 , 6 , 10 , 11 , 12 , 13 , 14 , 16 , 20 , 23 , 25 , 26 , 27

Em The Things Stack, usamos a mesma lista quando construímos a configuração dinâmica para gateways: https://github.com/TheThingsNetwork/lorawan-stack/blob/master/pkg/pfconfig/shared/shared.go#L259 -L276

Isso significa que o _ERRO: Pacote REJEITADO, potência de RF sem suporte para TX-11_ é apenas uma configuração incorreta do gateway, mas os outros relatórios são válidos.

Suspeito que isso seja causado por um servidor Gateway v3 enviando um valor de potência TX incompatível. Precisamos ter certeza de que o GS só envia valores de potência TX para gateways UDP se eles estiverem na lista de potências TX suportadas.

Alguma atualização recente ou insights sobre isso?

Você pode adicionar um relatório a https://status.thethings.network/ ? Obrigado!

https://status.thethings.network/ destina-se a incidentes de rede. Esse não é o lugar para isso. Vamos lançar uma nova atualização em que o servidor verificará se há TX Power compatível antes de enviar.

Oi Kirshna,

Você pode ser um pouco mais preciso quando esta atualização será lançada? Há muitas pessoas esperando por essa correção.

A propósito, o que você quer dizer com "verificará se há TX Power compatível antes de enviar"? O servidor garantirá que a potência TX é "padrão" ou descartará o pacote?

Obrigado pela ajuda

https://status.thethings.network/ destina-se a incidentes de rede.

Só para expressar que sinto que é muito rígido. Isso _é_ um problema operacional para alguns, certo? Pelo menos para alguns usuários, os dispositivos caem para SF12 devido a não receberem downlinks ADR, e outros repentinamente veem falha do OTAA. Sem acesso a um registro de gateway, eles não sabem a causa, ainda mais porque as coisas estavam funcionando bem até recentemente, algo foi alterado para o roteamento do tráfego V2. (Ou algo parecido; não há uma comunicação clara sobre essas mudanças também.)

@avbentem : Isso não seria classificado como um problema operacional, pois está relacionado ao comportamento do software e não à conectividade / taxa de transferência / disponibilidade etc. No entanto, entendo que é importante corrigir isso. Você pode esperar uma correção nos próximos dias.
PS: Você está completamente certo. Esta mudança não foi comunicada corretamente.

Esta mudança não foi comunicada corretamente.

À parte: nunca é tarde para pelo menos consertar isso? Não está totalmente claro para mim o que mudou, quando e se as pessoas deveriam olhar para V2 ou V3 ao depurar problemas, @KrishnaIyer e @htdvisser.

Eu recebo muito bem, digamos, uma postagem no fórum ou algo em https://www.thethingsnetwork.org/updates sobre essa mudança e futuras mudanças. Obrigado!

Acabamos de implantar um patch que deve reverter o comportamento. Vou esperar algum feedback antes de fechar isso.

Obrigado Krishna!
Você pode nos dar alguns detalhes do que foi corrigido? Sem culpar ninguém, só porque isso nos ajudaria a entender melhor os problemas que tivemos com nossos gateways e encaminhadores de pacotes e para ter certeza de que o comportamento que observamos foi causado por essa mudança.

A mudança basicamente foi esta:

certifique-se de que o GS só envia valores de potência TX para gateways UDP se eles estiverem na lista de potências TX suportadas

https://github.com/TheThingsNetwork/lorawan-stack/issues/2106#issuecomment -596502171

Além dessa alteração, descobrimos que a conversão da potência TX nos downlinks recebidos dos sistemas v2 não foi feita corretamente, resultando em uma diferença de 3 dBm (11 deveriam ser 14; 17 deveriam ser 20 e 24 deveriam ser 27). Isso também foi corrigido.

Obrigado pelos detalhes, "_24 deveria ter sido 27_" é exatamente o que causou nossos problemas. Sabendo desse detalhe, não precisamos mais depurar o GW no local.

Não consegui reproduzir mais o problema do meu lado. Obrigado pela atualização!

Obrigado, @htdvisser e @KrishnaIyer. Como isso está de alguma forma relacionado à conexão de V2 e V3: você pode documentar em algum lugar como as coisas estão conectadas hoje em dia, para a rede da comunidade?

Aparentemente, conforme foi anunciado brevemente durante a conferência do final de janeiro de 2020, o tráfego de gateways que foram configurados em V2 está sendo roteado por meio de V3? Talvez eu tenha perdido algo, mas não está muito claro para mim quais componentes do V2 ainda são usados ​​e o que agora está sendo delegado ao V3. Além disso, não está claro quando as alterações foram feitas.

(Por exemplo: a rede da comunidade ainda usa o Console TTN V2, e isso funciona bem. Também presumo que o ADR ainda está sendo tratado pela V2, pois https://github.com/TheThingsNetwork/ttn/issues/767 ainda está sendo relatado Dispositivos OTAA que aderiram antes de outubro de 2019. Mas, como o problema acima foi corrigido na V3, algo é feito pela V3 também? Saber quando as coisas mudaram pode ajudar na depuração futura.)

@dermatthias

não precisamos mais depurar o GW no local

Observe que ainda pode ser uma boa ideia consertar o lado do gateway também, para implementar um mecanismo de fallback para mudanças futuras ou para uso futuro do V3? Não tenho certeza ; veja alguns comentários do Slack em https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833/14

Não consigo ver como isso resolveu o problema quando alguém tem (por exemplo) uma antena de 5dBi em seu gateway. Se eles deixarem o ganho de antena no arquivo de configuração como 0dBi, eles excederão a potência máxima de transmissão legal e se eles alterarem o arquivo de configuração para 5dBi, então haverá casos em que o pacote será rejeitado pelo gateway.

responda a @avbentem :

Uma vez que todos os clusters de nossa rede comunitária parecem diferentes e as coisas estão mudando o tempo todo, nos custaríamos muito tempo manter uma visão geral atualizada de como as coisas estão conectadas em cada região.

Na imagem abaixo, você verá como os gateways podem se conectar a uma rede v2. A situação antiga (amarelo) será migrada lentamente para a nova situação (verde). Fazemos isso primeiro roteando uma pequena porcentagem do tráfego para um determinado protocolo de gateway por meio dos novos componentes e aumentando lentamente essa porcentagem. O mesmo para os outros protocolos de gateway.

Como @johanstokking mencionou durante sua apresentação na conferência, muitos gateways de rede da comunidade já se conectam por meio de um servidor de gateway v3 e, lentamente, estamos conectando mais gateways por meio de servidores de gateway v3 ao longo do tempo.

Além desses servidores de gateway, toda a rede da comunidade pública ainda executa componentes v2.

responda a @ tonysmith55 :

Isso não aconteceu. Isso apenas muda o comportamento de volta ao que era antes. Sim, é (e sempre será) possível que os gateways excedam a potência máxima de transmissão legal se esses gatways não tiverem sido configurados corretamente por seus proprietários.

Espero que isso responda às suas perguntas. Uma vez que estamos saindo um pouco do assunto aqui e já que o problema foi confirmado como resolvido, encerrarei o problema agora.