请选择 进入手机版 | 继续访问电脑版
查看: 892|回复: 0

[技术交流] 【异常案例分析】入网成功后miic校验错误问题

[复制链接]

74

主题

169

帖子

573

积分

利尔达员工

Rank: 9Rank: 9Rank: 9

积分
573
发表于 2020-7-31 18:00:24 | 显示全部楼层 |阅读模式
[size=17.1429px]

[size=17.1429px]客户: 某路灯行业客户
[size=17.1429px]日       期: 2020-06-18

[size=17.1429px]支持人员: 顾超杰
[size=17.1429px] 固件版本

[size=17.1429px]LR-Modem-CN470P-V2.21.14.190802.Release

[size=17.1429px] 项目背景

[size=17.1429px]1、项目为CLASS C路灯应用,项目位于某港口,节点、网关、NS均为利尔达产品,
[size=17.1429px]2、811个节点,使用利尔达CN470标准LoRaWAN模组,客户使用缺省配置参数,仅配置三要素及class C
[size=17.1429px]3、8个网关,均为4G网关,4G信号较差,平均网络延时100ms+,安装位置在灯杆上
[size=17.1429px]4、整个LoRaWAN网络信号覆盖较好,射频通信质量较好。4G网络存在一定波动。网关部署密度大,上行多路径包较多。

[size=17.1429px] 问题描述

[size=17.1429px]1. 部分节点入网成功后上行数据包在NS端均为mic校验错误
[size=17.1429px]
[size=17.1429px] 问题分析

[size=17.1429px]线索
[size=17.1429px]    1、异常出现在节点join成功后,join完成后节点定时上报数据,但每包数据的mic校验都错误
[size=17.1429px]    2、该现象为偶发异常,项目下有5个异常节点出现,且重新join后能恢复

[size=17.1429px]    3、NS端日志显示异常出现时间附近网关上报的rxpk内pingtime(网关最近一包心跳包的双向通信延时)较大,最大有8s。
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]    4、NS前端显示所有异常节点出现异常前最后两次join使用的通信速率及频点相同
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]

[size=17.1429px]分析
[size=17.1429px]    1、数据包MIC在NS及节点侧各自计算,aes数据源为帧内容,秘钥为NwkSKey。因为数据crc校验通过则推断mic校验失败的原因在于双方NwkSKey不一致。
[size=17.1429px]
[size=17.1429px]    2、选择当前还存在异常的设备,根据其最后一次joinRequest中的DevNonce及最后一次JoinAccept中的AppNonce、DevID,和APPKEY手动计算出NwkSKey,与NS上计算的NwkSKey进行对比验证,完全一致,NS侧秘钥计算正确。
[size=17.1429px]
[size=17.1429px]
[size=17.1429px]    3、根据NS后台日志,复查异常节点的rxpk、txpk时间及网关的tmst时间,均无异常,但注意到最后一包JoinAccept的txpk被网关回复 "TOO EARLY"

[size=17.1429px]    4、rxpk内的data字段经base-64解密后获取JoinRequest内容,最后发现异常节点的最后两包JoinRequest内容完全一致,且所有异常节点都是如此。

[size=17.1429px] 问题结果

[size=17.1429px]1、综合以上信息,推断mic校验错误出现的原因:
[size=17.1429px]    节点发起JoinRequest时被多网关收到,大部分网关正常上报至NS,之后选择一个网关正常下发JoinAccept,节点侧入网成功。但是在整个join流程结束后,存在网络延迟极大的网关(十几秒后)才刚刚将节点的JoinRequest上报至NS,该延迟时间远超过NS端多路径包的接收窗口时间。因此NS当做新join包处理,再随机生成一个AppNonce并更新NwkSKey,并下发txpk给网关。网关根据tmst判断出该包时间错误,回复TOO EARLY,不进行下发。NS前端可以看到这最后两轮Join交互,但是实际节点已经在倒数第二轮Join中入网成功,而NS因为延迟上报的rxpk又更新了一次NwkSKey,两端秘钥不一致,导致后续数据mic校验错误。
[size=17.1429px]

[size=17.1429px]2、解决方案:
[size=17.1429px]    该问题由网关网络延迟极大(>10s)导致,客户已完成工程部署,优化4G网络环境可行性较低。因此从NS的角度增加对该异常的识别及处理机制即可:
[size=17.1429px]    NS在Join处理流程中加入DevNonce去重处理:NS在下发JoinAccept的txpk后存储该JoinRequest内的DevEUI-DevNonce键值对,并在接收到JoinRequest时判断DevNonce,若与存储值重复则不处理这包rxpk。

[size=17.1429px]

[size=17.1429px] 总结
[size=17.1429px]1、按照以上解决方案处理后,经验证,所有设备工作稳定,异常状况不再复现。
[size=17.1429px]2、Lierda Unicore 3.0 网络服务器本身具备DevNonce判重(防止JoinRequest重放攻击)及网络波动状况下的多路径包处理能力。本次网络延时的时间大于处理预期因而导致异常。
[size=17.1429px]3、经本次NS服务器版本升级后,NS优化了对极差网络条件下LoRaWAN系统的稳定性。
[size=17.1429px]

[size=17.1429px]

[size=17.1429px]


[size=17.1429px]


本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表