微信配网的内核异常

jansin_shaw

用的BIT5的板，
连个板
一个板没更新刷固件，这个原板固件现还没发现此异常；
另一个板烧了自己编译出的固件,发现此现象！

代码包的版本怎么看？

mangogeek

代码包是git来看，初步怀疑你编译时候是否缺少了一些依赖。
如果自己搭建的环境有问题，可以用我们提供的虚拟机： https://cn.widora.io/compile

jansin_shaw

好吧，我再试试看你们的虚拟机开发环境！

jansin_shaw

我把虚拟机里原有的映像openwrt-ramips-mt7688-WIDORA3264-squashfs-sysupgrade.bin 烧入板子，也出类同的崩溃异常！

mangogeek

@jansin_shaw 把你用自己环境，用虚拟机环境的分别上传到论坛，我看看

jansin_shaw

是指上传映像文件吗？

mangogeek

@jansin_shaw 对

jansin_shaw

test.bin openwrt-ramips-mt7688-WIDORA3264-squashfs-sysupgrade.bin

test.bin是非虚拟机环境自己编译的
另一个是你们网上虚拟机中工程环境原有的

mangogeek

晚上我测试反馈到这里

jansin_shaw

好!

原始映像运行后只做了下修改配置以太网从静态改为dhcp

jansin_shaw

test.bin

重新上传这个test.bin映像
此映像的root密码为:root

jansin_shaw

?????

mangogeek

在BIT3和BIT5上测试了你先后上传的两个固件，均没有发现崩溃

jansin_shaw

可我手上这个板子运行确实是时不时就崩溃了，
本来我们是要用再新项目产品上的，现遇到这情况很难堪，
如不能稳定运行很难继续下去，希望能帮深入分析原因，
也可以把板子寄给你们看看！

jansin_shaw

puttywidora.log

这个是超级终端记录，放着没人为操作的时候！

mangogeek

你是不是刷成了128MB的uboot? 如果没有，那我来检查板子看看

jansin_shaw

UBOOT一直是原板内带的，我们没更新过uboot，只做过系统映像更新！

mangogeek

@jansin_shaw OK，已发邮件，我来检查

mangogeek

收到板子，默认板子带了固件root@Rise，做一些记录如下：

/etc/config/network

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option macaddr '0c:ef:af:d1:dc:07'
        option type 'bridge'
        option proto 'dhcp'
        option ipaddr '192.168.8.18'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option ifname 'eth0.2'
        option force_link '1'
        option macaddr '0c:ef:af:d1:dc:06'
        option proto 'dhcp'

config interface 'wan6'
        option ifname 'eth0.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0 6t'

config interface 'wwan'
        option proto 'dhcp'
        option ifname 'apcli0'

/etc/config/wireless

config wifi-device 'radio0'
        option type 'ralink'
        option variant 'mt7628'
        option country 'CN'
        option hwmode '11bgn'
        option htmode 'HT40'
        option channel 'auto'

config wifi-iface 'ap'
        option device 'radio0'
        option mode 'ap'
        option network 'lan'
        option ifname 'ra0'
        option ssid 'RSCTn_D1DC06'
        option encryption 'psk2'
        option key '123456789'
        option hidden '0'

config wifi-iface 'sta'
        option device 'radio0'
        option mode 'sta'
        option network 'wwan'
        option ifname 'apcli0'
        option ssid 'sssssssss'
        option key 'sstststsstst'

等待连接上AP后，运行aac命令

root@Rise:/etc/config# aac
[  531.920000] [MSC] enter monitor mode: filter:0x0, chan_id:1, width:2, chan_flags:0x0, mon0
[  531.940000] init queue success
[  532.690000] ApCliIfMonitor: IF(apcli0) - no Beacon is received from Root-AP.
[  532.690000] APCLI LINK DOWN - IF(apcli0)
[  532.700000] WLAN:STA d4:5f:25:fd:07:34(dev:ra0 rate:135Mbps singnal:-34dBm) disconnect 
[  537.690000] AP-Client probe response: SSID=ziroom304, BSSID=d4:5f:25:fd:07:34
[  537.990000] APCLI LINK UP - IF(apcli0) AuthMode(7)=WPA2PSK, WepStatus(6)=AES!
[  538.100000] WLAN:STA d4:5f:25:fd:07:34(dev:ra0 rate:135Mbps singnal:-36dBm) disconnect 
[  538.330000] APCLI LINK DOWN - IF(apcli0)
[  556.090000] AP-Client probe response: SSID=ziroom304, BSSID=d4:5f:25:fd:07:34
[  556.100000] APCLI LINK UP - IF(apcli0) AuthMode(7)=WPA2PSK, WepStatus(6)=AES!
[  570.950000] BUG: Bad page state in process sh  pfn:028a6
[  570.950000] page:810514c0 count:8560 mapcount:0 mapping:  (null) index:0x0
[  570.960000] flags: 0x0()
[  570.960000] page dumped because: nonzero _count
[  570.970000] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 n
[  571.030000] CPU: 0 PID: 3404 Comm: sh Tainted: G    B          3.18.29 #23
[  571.040000] Stack : 00000000 00000000 00000000 00000000 803541f2 0000003e 00000000 0000000
          00000001 8108b4b0 802b7694 803129e3 00000d4c 80353420 8297ede0 8108b4b0
          00020200 00467000 810514d4 800476c0 00000003 80024410 802be600 8108b4b0
          802bab98 828e5b24 00000000 00000000 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          ...
[  571.080000] Call Trace:
[  571.080000] [<80014240>] show_stack+0x50/0x84
[  571.080000] [<8006f6c8>] bad_page+0xe8/0x118
[  571.090000] [<80071cb4>] get_page_from_freelist+0x41c/0x5c0
[  571.090000] [<80071f60>] __alloc_pages_nodemask+0x108/0x68c
[  571.100000] [<800724fc>] __get_free_pages+0x18/0x4c
[  571.110000] [<800886c4>] __tlb_remove_page+0x64/0xbc
[  571.110000] [<800896dc>] unmap_single_vma+0x4b8/0x710
[  571.120000] [<8008aa74>] unmap_vmas+0x54/0x74
[  571.120000] [<8008f870>] exit_mmap+0x70/0x16c
[  571.120000] [<800223b4>] mmput+0x3c/0xd4
[  571.130000] [<800a6188>] flush_old_exec+0x4b8/0x5ec
[  571.130000] [<800dc734>] load_elf_binary+0x310/0x11a8
[  571.140000] [<800a56f4>] search_binary_handler+0x88/0x1c8
[  571.140000] [<800a69b4>] do_execve+0x32c/0x4c0
[  571.150000] [<80006b5c>] handle_sys+0x11c/0x140
[  571.150000] 
^C^C[  577.380000] [MSC] leave monitor mode.
[  577.400000] deinit queue success

目前情况，在连接上级AP后进行aac，很容易崩溃。

接下来清除所有配置，不连接上级AP，进行aac测试：(仍然出现错误！)

[  293.680000] |--------------------------------------------------------|
[  294.320000] BUG: Bad page state in process ralink.sh  pfn:02f96
[  294.330000] page:8105f2c0 count:37940 mapcount:-65535 mapping:  (null) index:0xffff
[  294.330000] flags: 0x0()
[  294.340000] page dumped because: nonzero _count
[  294.340000] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 n
[  294.410000] CPU: 0 PID: 2001 Comm: ralink.sh Not tainted 3.18.29 #23
[  294.410000] Stack : 00000000 00000000 00000000 00000000 803541f2 00000038 00000000 0000000
          00000001 8108b4b0 802b7694 803129e3 000007d1 80353420 82cf4720 8108b4b0
          000204d0 00989000 8105f2d4 800476c0 00000003 80024484 802be600 8108b4b0
          802bab98 82dcbc6c 00000000 00000000 00000000 00000000 00000000 00000000
          00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
          ...
[  294.450000] Call Trace:
[  294.450000] [<80014240>] show_stack+0x50/0x84
[  294.460000] [<8006f6c8>] bad_page+0xe8/0x118
[  294.460000] [<80071cb4>] get_page_from_freelist+0x41c/0x5c0
[  294.470000] [<80071f60>] __alloc_pages_nodemask+0x108/0x68c
[  294.470000] [<80088afc>] __pte_alloc+0x34/0x184
[  294.480000] [<8008a620>] copy_page_range+0x108/0x508
[  294.480000] [<80023034>] copy_process.part.77+0x9ac/0x111c
[  294.490000] [<8002387c>] do_fork+0xc0/0x2c0
[  294.490000] [<80006b5c>] handle_sys+0x11c/0x140
[  294.500000] 
[  294.500000] Disabling lock debugging due to kernel taint
[  294.510000] CPU 0 Unable to handle kernel paging request at virtual address 00100104, epc0
[  294.510000] Oops[#1]:
[  294.510000] CPU: 0 PID: 2059 Comm: dhcpv6.script Tainted: G    B          3.18.29 #23
[  294.510000] task: 82cf4000 ti: 82d56000 task.ti: 82d56000
[  294.510000] $ 0   : 00000000 0041d21c 8108b4bc 00100100
[  294.510000] $ 4   : 00000000 8108b4b8 00000134 00000024
[  294.510000] $ 8   : 00000002 00000000 00000000 80320be8
[  294.510000] $12   : 00000001 77b5c068 00000000 000033e5
[  294.510000] $16   : 80312100 00000141 00000000 00000001
[  294.510000] $20   : 81059da0 8108b4b0 000200d0 0045da30
[  294.510000] $24   : 00000000 77abb8f0

初步怀疑可能固件有问题，刷

Ver:0.1.8-20180813 openwrt-ramips-mt7688-WIDORA3264-squashfs-sysupgrade.bin 后进行测试，默认不配置情况下连续五次aac，未出现问题。

随后配置上sta，再进行aac，重试5次，未崩溃，但有一次一直获取不到ssid和key。

刷wiki中的固件Ver:0.1.8-20180430 by WIDORA

默认在无配置sta，和配置sta之后，aac各进行5次，没出现崩溃。

将wiki固件的network配置也按照root@Rise来改，测试：

出现了两次崩溃，随后又死活不复现了，还没找到规律

mangogeek

初步感觉和
config interface 'lan'
option ifname 'eth0.1'
option force_link '1'
option macaddr '0c:ef:af:d1:dc:07'
option type 'bstatic'
option proto 'dhcp'
中的dhcp有关系，这部分改成dhcp的确是没有任何道理

jansin_shaw

af7bd18a-72ee-4838-8155-fbe0a4c28b8f-图片.png

我只是把lan改了dhcp

即使改成了静态ip也会出异常

不过我觉得即使这些配置有误就引起内核都异常崩溃是不应该的！

且之前我发现把WIFI关掉就很长时间没出现报错！

mangogeek

@jansin_shaw OK，下午我继续测试

jansin_shaw

有新进展吗？

mangogeek

@jansin_shaw 还没找到明显规律

jansin_shaw

解决了吗？

mangogeek

@jansin_shaw 到目前为止，的确还没找到规律。
暂定认为联发科私有驱动在将底层数据包dump到应用层时，容易不稳定（因为这是我们自己添加进代码实现的这种方式，联发科并没提供这方面的支持）
有没有考虑过这种方式，就是使用Openwrt18.06配合开源驱动MT76

以前我测试过开源驱动是可以直接打开monitor接口来空中抓包的
另外MT76-master的稳定性已经很不错：详见： https://widora.io/topic/533/openwrt18-06-mt76-master-driver
涉及到修改airkiss抓包部分程序，由以前的iwpriv接口修改为标准的monitor网卡抓包接口。
Openwrt18.06目前在7688上的音频部分我们还没调试通，如果你们不需要音频部分，那其他都差不多，并且有完美的LUCI界面支持。

jansin_shaw

@mangogeek
音频我们目前倒是没用到，
还请在那问题板上跑一下Openwrt18.06，看下运行的情况会不会异常！

另外：
我们后来又买了2块同型号BIT5板，前面那系统跑很长时间都没出现同样异常！

mangogeek

@jansin_shaw
等等，我一直在测试的都是你们寄回的那个板子？！？

jansin_shaw

@mangogeek

除了把问题板寄给你实验，我这又多买了几块板实验，前后只在寄给你的那块问题板上发现崩溃异常，其它几块目前没发现同类现象！

mangogeek

@jansin_shaw 今晚我回去后整理整理思路后对比测试！
我可能也掉坑里了