Lorawan-stack: 网关拒绝某些TX功率的下行链路

创建于 2020-03-09  ·  18评论  ·  资料来源: TheThingsNetwork/lorawan-stack

概括

我们收到来自社区的报告,由于不支持的TX Power值,一些网关拒绝下行链路。

https://thethingsnetwork.slack.com/archives/C1D8GQMU5/p1582630203014800
https://thethingsnetwork.slack.com/archives/C1Q5XLNDT/p1582206674209100
https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833
https://www.thethingsnetwork.org/forum/t/packet-forwarder-who-sets-powe-in-json-downstream-txpk-packet/34481

重现步骤

  1. 通过网关发送下行链路
  2. 检查网关日志

您现在看到什么?

  • 错误:封包被拒绝,TX不支持的RF功率-11
  • 错误:封包被拒绝,TX不支持的RF功率-17
  • 错误:封包被拒绝,TX不支持的RF功率-24

您想看什么呢?

成功传播

bug gateway server in progress

最有用的评论

我们刚刚部署了一个补丁,可以还原该行为。 在关闭此功能之前,我将等待一些反馈。

所有18条评论

Lora-net/packet_forwarder似乎发生了错误。 相关代码: https :

使用通过TTN(https://github.com/TheThingsNetwork/gateway-conf/)分发的网关配置,网关可以接受以下TX电源:

-6-30361011121314162023252627

在The Things Stack中,当我们为网关建立动态配置时使用相同的列表: https :

这意味着_ERROR:数据包被拒绝,TX-11_不支持的RF功率只是网关的错误配置,但其他报告仍然有效。

我怀疑这是由v3网关服务器发送不支持的TX功率值引起的。 我们需要确保GS仅将TX功率值发送到UDP网关(如果它们在受支持的TX功率列表中)。

最近有任何更新或见解吗?

您可以将报告添加到https://status.thethings.network/吗? 谢谢!

https://status.thethings.network/用于处理网络事件。 那不是这个地方。 我们将发布一个新更新,服务器将在发送前检查受支持的TX Power。

您好Kirshna,

当此更新发布时,您能更精确一点吗? 有很多人在等待此修复程序。

顺便说一句,“在发送之前将检查支持的TX电源”对您意味着什么? 服务器会确保TX电源是“标准”电源还是会丢弃数据包?

谢谢你的帮助

https://status.thethings.network/用于处理网络事件。

仅表示我觉得这很刻板。 这对某些人来说是操作上的问题,对不对? 至少对于某些用户,由于未收到ADR下行链路而使设备跌落到SF12,而其他用户则突然看到OTAA失败。 由于无法访问网关日志,他们对原因一无所知,直到最近一切正常,直到最近V2流量的路由发生了变化。 (或者类似的东西;关于这些更改也没有明确的沟通。)

@avbentem :这不会被归类为操作问题,因为它与软件行为有关,与连通性/吞吐量/可用性等无关。但是,我确实知道,解决此问题很重要。 您可以期待在未来几天内解决问题。
PS:您完全正确。 此更改未正确传达。

此更改未正确传达。

撇开:至少解决这个问题永远不会太晚? 对我来说,目前还不清楚什么发生了什么变化,何时以及何时调试问题时人们应该使用V2还是V3 @KrishnaIyer和@htdvisser。

我非常欢迎,例如,论坛帖子或https://www.thethingsnetwork.org/updates上有关此更改以及将来更改的内容。 谢谢!

我们刚刚部署了一个补丁,可以还原该行为。 在关闭此功能之前,我将等待一些反馈。

谢谢克里希纳!
您能给我们一些细节吗? 不要怪任何人,只是因为那将帮助我们更好地了解网关和数据包转发器所遇到的问题,并确保我们观察到的行为是由此更改引起的。

更改基本上是这样的:

确保GS仅将TX功率值发送到UDP网关(如果它们在受支持的TX功率列表中)

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


除此更改外,我们发现从v2系统接收的下行链路中的TX功率转换未正确完成,导致3 dBm的差异(11应该是14; 17应该是20,而24应该是20)。 27)。 这也是固定的。

感谢您提供的详细信息,“ _ 24应该是27_”正是导致我们出现问题的原因。 了解了这些详细信息后,我们就无需在现场调试GW了。

我无法再重现这个问题了。 感谢更新!

谢谢@htdvisser和@KrishnaIyer。 由于这在某种程度上与V2和V3的连接有关:您能否为社区网络记录当今事物之间如何连接的情况?

显然,正如在2020年1月下旬会议期间简短宣布的那样,在V2中建立的网关的通信正在通过V3路由? 也许我错过了一些东西,但是对我来说,真的非常不清楚,仍然使用V2的哪些组件,以及现在将什么委派给V3。 另外,尚不清楚何时进行更改。

(例如:社区网络仍使用V2 TTN控制台,并且工作正常。我还假定ADR仍由V2处理,因为仍在报告https://github.com/TheThingsNetwork/ttn/issues/767。 OTAA设备在2019年10月之前加入。但是鉴于上述问题已在V3中解决,因此V3也可以完成某些工作?知道何时进行更改可能有助于将来的调试。)

@dermatthias

我们不需要在现场进一步调试GW

请注意,它仍可能是固定网关的方太,以实现未来变化或V3的将来使用回退机制是一个好主意? 我不确定; 在https://www.thethingsnetwork.org/forum/t/error-packet-rejected-unsupported-rf-power-for-tx-24/34833/14中查看Slack的一些评论

当某人在其网关上安装(例如)5dBi天线时,我看不到如何解决此问题。 如果他们在配置文件中将“天线增益”保留为0dBi,则它们将超过最大合法发射功率,如果将配置文件更改为5dBi,则在某些情况下,网关将拒绝该数据包。

回复@avbentem

由于我们的社区网络集群看起来各不相同,并且事情一直在变化,因此要花太多时间来维护有关每个区域中事物连接方式的最新概述。

在下图中,您将看到网关如何连接到v2网络。 旧情况(黄色)将缓慢迁移到新情况(绿色)。 为此,我们首先通过新组件路由给定网关协议的一小部分流量,然后慢慢增加该百分比。 其他网关协议也一样。

Screenshot 2020-04-03 at 10 40 38

正如@johanstokking在会议上的演讲中提到的那样,许多社区网络网关已经通过v3网关服务器进行连接,随着时间的推移,我们正在逐步通过v3网关服务器连接更多的网关。

除了这些网关服务器之外,整个公共社区网络仍在运行v2组件。

回复@ tonysmith55

还没有它只是将行为改回到以前的状态。 是的,如果网关所有者未正确配置这些网关,则网关(并且将始终)有可能超过最大合法发射功率。

我希望这回答了你的问题。 由于我们将在此处讨论一些话题,并且由于现已确认此问题已得到解决,因此我现在将结束该问题。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

adriansmares picture adriansmares  ·  8评论

bafonins picture bafonins  ·  5评论

kschiffer picture kschiffer  ·  4评论

johanstokking picture johanstokking  ·  5评论

ecities picture ecities  ·  5评论