配网常见问题排查 - 设备端
更新时间：2018-10-19 11:29:34
整体流程：
1 HAL移植阶段
2 AWSS配网数据解析阶段
3 设备连接路由器
4 设备配网成功通告
5 设备与云端的建连
6 设备与云端同步设备绑定的Token
7 设备对外通告用于绑定的Token
8 设备控制
1.HAL 层移植排查
设备收不到配网的包主要由各家芯片或模组厂商的Driver导致， 解决问题也以各家模组或芯片厂商为主，如需协助，请通过工单系统反馈问题。
Step 1：排查设备端是否可以收到AP列表
设备上电的日志：
Note：
- mac一般不会出现前面三个字节全为0的情形，如果mac:000000XXXXXXX，出现这种情形一般是厂商适配的HAL出了问题；
- rssi的取值范围要在[-1, -127]，超出这个范围是适配的HAL出了问题。
如果没有收到上述日志，排查对应的HALAPI，主要查看HAL_Awss_Open_Monitor接口，该接口传入了一个函数指针，模组或芯片收到包时，会通过注册的回调函数告知AWSS，回调函数的参数说明：
*sniffer_cb(buf, len, type, fcs, rssi)
-buf：存储的是802.11 Header和对应的payload，以802.11 Header开始；
-len：802.11 Header的长度+ payload的长度（不包含最后4个字节的FCS）
-type：建议使用AWSS_LINK_TYPE_NONE
-fcs：设置0
-rssi：当前包的RSSI，取值范围[-1,-127]*
Step 2：排查设备是否收到配网包
确认设备是否收到配网的包可直接查看设备端日志：
(1)使能AWSS：
awss_config_press是否调用使能AWSS，如果使能了，设备会有如下日志：
(2)设备端收到配网包，会有如下日志：
2. SSID/Password解析排查
2.1 一键配网问题排查
Step 1：排查可以收到配网包
设备端出现诸如以下此类的日志，表明设备可以收到配网的包：
Step 2：排查设备是否解密Password失败
设备解密Password失败，一键配网方式会有如下日志：
出现该类问题的唯一原因就是App选择的设备信息和设备本身的信息不一致，有多种情况导致设备信息不一致：
a) 用户选择了错误的设备类型
b) 多个用户在配网，并且配不同类型的设备，可能相互干扰
c) App的UI和App SDK的交互出现错误
Step 3：排查能否收到完整配网包
如果设备可以收到配网包，但是没有收到完整的配网包，有没有收到完整的配网包也比较容易确认：
如果设备可以收到配网包，但是配网包不完整，可通过工单系统反馈问题。
2.2 热点配网问题排查
Step 1：排查设备端是否可以扫描并连接手机热点 aha
设备端调用awss_start和awss_config_press后进入配网阶段，设备发现并连接aha热点的日志如下，如果失败，分析步骤如下:
(1) 用户通过手机开启的aha热点可能存在问题，可以尝试关闭aha热点，然后再重新开启;
(2) 如果设备连接aha失败，尝试用其他手机连接aha热点，判断该aha是否可以接入；
(3) 如果手机可以连接aha热点，而设备连接失败，具体由模组/芯片厂商解决。
Step 2：设备端配网信息通告
连接路由器的过程是芯片厂商的驱动，连接失败请联系模组/芯片厂商解决，成功的日志如下：
Step 3：设备端收到WiFi列表请求
Step 4：设备端回复WiFi列表
正确的日志如下: 扫描过程中如果出现死机，建议排查一下HAL_Wifi_Scan的实现，HAL层的实现由芯片或模组厂商解决;
Step 5：设备端收到SwitchAP的命令
Step 6：设备端解析SSID和Password
正确的日志如下，设备端解析出SSID和Password，后续的流程参见“连接路由器排查”
中文GBK编码的中文SSID，SSID的编码规则是"xssid": "HEX_STRING"，目前ESP8266芯片Wi-Fi Scan最多支持20个热点，有可能扫描不到目的热点，需要由芯片厂商解决。
2.3 路由器配网问题排查
Step 1：排查设备端是否可以扫描并连接路由器热点adha
如果设备扫描路由器没有发现adha热点，排查步骤如下:
(1) 不能使能AWSS，AWSS使能之后就不会再进行设备发现，使能AWSS的日志参见HAL层移植排查部分;
a) 路由器配网的设备发现阶段是设备调用了awss_start之后, awss_config_press之前，一旦调用了 awss_config_press，设备将进入配网阶段，不再进行设备发现;
b) 使能AWSS的操作超时之后，设备又会重新进入设备发现阶段，而超时的时间由HAL_Awss_Get_Timeout_Ms决定;
c) 当设备发现adha热点后，如果adha没有完成配网，使能AWSS的操作会提前超时，再次进入设备发现阶段;
(2) 设备端对接的HAL_Wifi_Send_80211_Raw_Frame是否正确，由于adha热点是隐藏热点，需要设备主动发送探测帧(Probe-Request);
Step 2：设备端配网信息通告
连接路由器的操作都是芯片厂商的Wi-Fi驱动完成，设备端成功连接adha热点的日志如下：
Step 3：排查设备端是否可以扫描路由器热点aha
设备端调用awss_start和awss_config_press后进入配网阶段，设备发现并连接aha热点的成功日志如下：
如果失败，分析步骤如下：
(1) 用户在App发现路由器发现的待配网的设备，选择要配网的待配网设备，并开始配网；
a) 配网App把路由器绑定到自己的账户，否则无法发现设备；
b) 配网的应用程序需要连接到支持路由器配网的路由器；
c) 配网的应用程序获得的路由器BSSID和路由器上报发现的待配网设备时一起上传的BSSID是否一致，如果不一致，也是无法发现设备的；
2) 路由器会收到云端下发的配网命令，开启配网热点；
Step 4：设备端配网信息通告
设备端成功连接aha热点的日志如下：
Step 5：设备端收到SwitchAP的命令
Step 6：设备端解析SSID和Password
正确的日志如下，设备端解析出SSID和Password，后续的流程参见“连接路由器排查”
如果SSID和PASSWD解析失败，目前只有一种可能，配网的过程中设备发生了重启（用户操作重启），可以等待超时后重新测试；
3.连接路由器排查
设备连接路由器失败，解决连接路由器失败的问题，原则上以芯片或模组厂商为主。如需协助，请通过工单系统反馈问题。
Step 1：设备发起连接路由器
设备经过配网后，如果获得SSID和PASSWD后会尝试连接路由器，日志如下：
Step 2：设备连接路由器的结果
路由器连接成功会有IP打印，日志如下：
连接路由器失败的日志：
各家模组或芯片厂商的实现方式不同，日志可能会有差异，连接路由器失败主要由各模组或芯片厂商排查为主。
4.配网成功通告排查
可通过查看设备端日志确认是否发送配网成功的通告，如果出现“/sys/awss/event/connectap/notify”关键字，表示AWSS配网成功的通告已经发出，也可以通过wireshark抓包确认；
- 如果设备端发送了/sys/awss/event/connectap/notify，App提示配网失败，则需排查app端日志；
- 如果设备端没有发送/sys/awss/event/connectap/notify，先确认一下设备的Debug是否打开，aos1.3.1，aos1.3.2，aos1.3.3都是打开的；
- 如果Debug打开，而设备的/sys/awss/event/connectap/notify没有发送，可通过工单系统反馈问题。
5.设备与云端的建连排查
Step 1：设备发起连接
开始建立连接的日志：
Step 2：建连的结果
成功连接的日志：
连接失败的日志：
- 如果建连失败，先检查设备的四元组信息是否正确；
- 建连失败常见错误如下：
a) 0x0044：TCP握手失败
b) 0x0050：服务器剔除了设备的连接请求
c) 0x0052：DNS解析失败
6、7.设备绑定信息排查
(1) 查找关键字"awss_report_token_reply";
如果设备端日志没有这个关键字，则表示设备端token上报失败，导致无法发现。
report token:{"id":"0", "version":"1.0", "method":"thing.awss.enrollee.match", "params":{"token":"9FA49022EC668E99A9634E97320FE526"}}
report token result:0
[err] iotx_mc_handle_recv_SUBACK(1004): MQTT SUBSCRIBE failed, ack code is 0x80
[inf] iotx_cloud_conn_mqtt_event_handle(190): event_type 5
[err] _find_topic(131): no list
[err] _delete_topic(88): no list
[err] iotx_mc_cycle(1279): recvSubAckProc error,result = -24
(2) 查找关键字"sending message to app"；
从设备端日志分析，设备端是否把包含token的信息返回到APP端。
20180530_17:52:00 awss_report_token_reply
20180530_17:52:00 dev_info:{"awssVer":{"smartconfig":"2.0","zconfig":"2.0","router":"2.0","ap":"2.0"},"productKey":"b1iuHMGJYGI","deviceName":"IOT_test01","mac":"2C:3A:E8:22:05:CE","ip":"192.168.1.31","cipherType":4,"token":"750D8D55678899D1580E25D4948977E6","type":0}
20180530_17:52:00 sending message to app: {"id":18, "code":200, "data":{"awssVer":{"smartconfig":"2.0","zconfig":"2.0","router":"2.0","ap":"2.0"},"productKey":"b1iuHMGJYGI","deviceName":"IOT_test01","mac":"2C:3A:E8:22:05:CE","ip":"192.168.1.31","cipherType":4,"token":"750D8D55678899D1580E25D4948977E6","type":0}}[068620] Send a response message
(3) 查找关键字 "dump end";
设备端 dump 了，无法正常工作，无法处理APP层的请求了。
state: 5 -> 0 (0)
rm 0
pm close 7 0 0/7727226
!!!!!!!!!! Exception !!!!!!!!!!
========== Regs info ==========
PC 0x4021A285
PS 0x00000030
A0 0x4021A189
A1 0x3FFF3170
A2 0x00000000
A3 0x00000000
A4 0x00008000
A5 0x00000000
A6 0x3FFF118C
A7 0x00200400
A8 0x00000000
A9 0x0000000 A10 0x000000D0
A11 0x00000002
A12 0x3FFF118C
A13 0x3FFEA2C0
A14 0x3FFF7788
A15 0x00000001
SAR 0x00000010
EXCCAUSE 0x0000001C
EXCVADDR 0x0000001A
========== Stack info ==========
stack(0x3FFF3170): 0x3FFEA911 0x4021EF37 0x00000030 0x40226C6D
stack(0x3FFF3180): 0x00000003 0x00000001 0x00000000 0x0000C000
stack(0x3FFF3190): 0x00000000 0x3FFF118C 0x3FFE9D48 0x3FFEDC40
stack(0x3FFF31A0): 0x3FFF138C 0x3FFEA478 0x3FFF7788 0x402215BE
stack(0x3FFF31B0): 0x3FFEB528 0x3FFF77A8 0x3FFE9BF8 0x4021A344
stack(0x3FFF31C0): 0x00250003 0x00001002 0x00000000 0x402222C5
stack(0x3FFF31D0): 0x4021B3D6 0x4000DC0D 0x00000030 0x4022166B
stack(0x3FFF31E0): 0x3FFF138C 0x3FFEA478 0x3FFF7788 0x4021F8A8
stack(0x3FFF31F0): 0x00000000 0x00000000 0x00000000 0x00000000
stack(0x3FFF3200): 0x00000000 0x00000000 0x00000000 0x00000000
stack(0x3FFF3210): 0x00000000 0x00000000 0x00000000 0x00000000
stack(0x3FFF3220): 0x00000000 0x00000000 0x00000000 0x00000000
stack(0x3FFF3230): 0x00000000 0x00000000 0x00000000 0x00000000
stack(0x3FFF3240): 0x00000000 0x00000000 0x0A7FCF5C 0x40243B14
stack(0x3FFF3250): 0x000000D0 0x3FFE9D48 0x00000000 0x00000000
stack(0x3FFF3260): 0x00000034 0x0000000@ 0x00000000 0x402141FA
========== Call stack ==========
Call Stack: 0x4021A285
Call Stack: 0x402215BE
Call Stack: 0x4021A344
Call Stack: 0x4022166B
Call Stack: 0x4021F8A8
Call Stack: 0x0000C000
========== Heap Info ==========
free = 0x00005388 | used = 0x00008EA8 | max used = 0x000095B0
========== Task Info ==========
dyn_mem_proc_tas: stacksize=0x00000200, freesize=0x00000000
idle_task : stacksize=0x00000400, freesize=0x00000224
timer_task : stacksize=0x00000200, freesize=0x00000004
ppT : stacksize=0x00000800, freesize=0x0000022C
pmT : stacksize=0x00000400, freesize=0x00000230
tiT : stacksize=0x00000800, freesize=0x000004B0
rtT : stacksize=0x00000800, freesize=0x000002C4
event_task : stacksize=0x00000500, freesize=0x000000E4
main : stacksize=0x00001800, freesize=0x00001324
netmgr : stacksize=0x00001000, freesize=0x00000944
work_queue : stacksize=0x00000800, freesize=0x0000068C
!!!!!!!!!! dump end !!!!!!!!!!
(4) 查找关键字 "/sys/device/info/notify";
如果设备端日志中能搜索到“/sys/device/info/notify”关键字 ，则表示设备与云端的同步成功，并且用户绑定的通告已经发出，也可以通过wireshark抓包确认；
- 如果设备已经发送了sys/device/info/notify通告，但是App提示绑定设备失败，则需排查app端日志；
- 如果设备没有发送出sys/device/info/notify，首先检查设备与云端的建连是否成功。
8.设备在线控制排查
正常的设备在线控制日志：
如果设备离线，检查一下设备与云端的建连的ping操作是否还在工作：
以上是设备端配网的整体流程及常见问题日志排查，部分问题需结合App端日志共同排查。