|
|
本帖最后由 翌阳 于 2017-10-1 12:41 编辑
2017.10.1
以前的基本上也都是是白费力了，经过多次试验，终于大致确定了问题所在：bluetooth。蓝牙。开了蓝牙，甚至开过然后关掉，都会有几率导致WIFI联系网络的时候死机。再追下去，应该是驱动的问题了，没有源码，基本上没可能修复。被厂家放弃了的手机，也只能放弃了。这个问题的引发也是由于买个小米蓝牙音箱产生的。等过段时间，看看哪家手机先上android 8吧，准备换机。目前只有先不用蓝牙了。
!!!2017.9.28: 发现下面这些努力都是白费力的，BUG仍然存在！事实证明，无端的猜测是靠不住的。不甘心，尝试了很多，怀疑到其它的地方，试着换些SO库文件，结果失败，甚至开不了机。想看看到底发生了什么，终于下决心联机调试，其实这个也没啥难的，原来是把内容存到一个文件里，再传出来读，怀疑似乎出错时有关键的内容没存上。连机ADB调试，logcat输出。发现有一堆P2P的东西。又研究了一下源程序，发现它竟然是默认开P2P模式的，即使不用它，也开着。也许在其它系统中，frame会发指令关掉它，可能我这系统并没有关掉它。于是改代码，直接disable=1，然后，试了一段时间，没发现有错出现。可能找对了？？？？？过几天再看吧。。。。。
Android 5.1.1(MOKEE51.1)NUBA Z5S mini wpa_supplicant 在某些情况下引发崩溃问题的解决。
这个可能没什么大用了，android 8.0都出来了，还弄这个5.1的？还得弄啊，我的手机 nubia z5s mini 就是那个小牛2，厂家不再更新ROM了，放弃了，最后版本是android4.4，慢，乱，和存在的BUG无人维护了。幸好MOKEE推出了这个手机的基于android5.1的系统，刷 上了，速度上去了，可是BUG有一堆。刷来刷去，实在没好用的，只好对付这个，然后就是DEBUG。JAVA部分好解决，MOKEE有源码可以下载，可以查看分析，开源就是好啊，没厂家可以自己维护了。
但实在不想弄编译环境，太麻烦，都是小改只在SMALI下改就好。经过一段时间的努力，终于算是可用了。
但几个月前发现过几次崩溃，手机熄屏死机，在某一处连续发生两三次。由于是在外地，没办法分析问题所在。回到家又没发现问题，但考虑到当时是拍照和录像时发生的，把怀疑对象弄到了相机应用上了，改了一堆，去掉了地址信息的记录（这是无端猜想，后来事实也证明确是如此，因为又发生崩溃了）。
再次连续发生崩溃现象是自买了小米蓝牙音箱开始的。在室外，有WIFI的地方，蓝牙播放歌曲时，特别是播放“萌萌哒”这首歌的时候，在某个地点会频发崩溃。回到家里，放一天都没事。
怀疑了很多，都怀疑到FLAC文件（因为这首歌是FLAC的）解码的问题，与蓝牙冲突。换了格式，仍发现存在问题。
后来才怀疑到蓝牙和WIFI上，因为它们都是用2.4G频率的。网上一查，确实如此，蓝牙会干扰2.4G的WIFI。于是在家里尝试一连蓝牙播放萌萌哒，连续不断重连WIFI，果然发生崩溃。打开终端，看logcat。发现死机时logcat的记录，初步定位到 wpa_supplicant上。由于有一段时间没找到这个版本（2.3）的源码，进展基本停下了。都在准备换手机了，看了很多，都是大屏，小屏的都比我这个大，虽然5英寸不比4.7大多少，但整体性能还不如我这手机呢。可恶的厂家，以后再也不买它的手机了，出了新的就不管老用户了。纠结了好久。最终还在决定尝试自己来解决这个问题，毕竟以前的BUG也都给消灭了。不过好在用BING国际版搜索到了wpa_supplicant2.3的源码，百度在这方面能力是0，GOOGLE连不上。得到了源码，就方便过多了，但看源码看得头大也没理清，这东西，太复杂了，竟然还是用C来写的，面向对象都没有用，注释也不多，太难读了。
尝试解决吧，不断地猜测，改代码，测试。前两天终于试对了。今天对比了android里的和2.3及2.6的代码，发现可能的原因。
下面把我的修改记录发上来：
不频繁存wpa_supplicant.conf，只在选择“WPS PIN码输入”时保存。
fc /b wpa_supplicant wpa_supplicant.old
正在比较文件 wpa_supplicant 和 WPA_SUPPLICANT.OLD
00080146: 00 92
00080147: 46 F7
00080148: 00 2D
00080149: 20 FE
00080E8E: 00 91
00080E8F: 46 F7
00080E90: 00 89
00080E91: 20 FF
--------------
2017?年?9?月?8?日：
0008833A: 05 D4
0008833B: B0 F8
0008833C: BD C8
0008833D: E8 60
0008833E: F0 20
0008833F: 8F 46
试了一段时间，发现前面的修改已经起了作用，暂时还没有CRASH。这回就直接把不需的都去掉了。
经过两天的测试，看来问题似乎解决了。又分析了一下代码，发现这个用的是2.3版的，而ANDROID5.1带的那个android_external_wpa_supplicant_8-jb-mr1_mkt里没有这个调用：wpas_connect_work_done(wpa_s); 2.6版的增加了一个直接返回的判断：
if (wpa_s->own_disconnect_req) {
wpa_s->own_disconnect_req = 0;
wpa_dbg(wpa_s, MSG_DEBUG,
"Ignore connection failure due to local request to disconnect");
return;
}
2.3版里没有这个，似乎问题是由此引发的。在某种状态下，是不应该走下面的代码的。我直接去掉了后面的代码，实测也没有太大的影响，可能会影响到重连的速度吧？？？？？？这是猜想。实际上也感觉不到，因为在蓝牙干扰下，说不好重连的速度，没的干扰的时候，也没感觉到重连。可能会慢些吧。这样吧，出错重连慢点也总比崩溃来得好啊。
void wpas_connection_failed(struct wpa_supplicant *wpa_s, const u8 *bssid)
{
int timeout;
int count;
int *freqs = NULL;
wpas_connect_work_done(wpa_s);
/*
* Remove possible authentication timeout since the connection failed.
*/
eloop_cancel_timeout(wpa_supplicant_timeout, wpa_s, NULL);
//下面的都去掉了.....
}
.text:00088320 sub_88320 ; CODE XREF: sub_82908+68p
.text:00088320 ; .text:00082FAAp ...
.text:00088320 PUSH.W {R4-R11,LR}
.text:00088324 SUB SP, SP, #0x14
.text:00088326 MOV R4, R0
.text:00088328 MOV R8, R1
.text:0008832A BL sub_87B30
.text:0008832E LDR R0, =(sub_87258+1 - 0x88338)
.text:00088330 MOV R1, R4
.text:00088332 MOVS R2, #0
.text:00088334 ADD R0, PC ; sub_87258
.text:00088336 BL sub_120D8
.text:0008833A ADD SP, SP, #0x14
.text:0008833C POP.W {R4-R11,PC}
.text:0008833C ; End of function sub_88320
.text:0008833C
2017?年?9?月7日
===============================
00080146: 00 92
00080147: 46 F7
00080148: 00 2D
00080149: 20 FE
00080E8E: 00 91
00080E8F: 46 F7
00080E90: 00 89
00080E91: 20 FF
-------------------
00088354: 00 04
00088355: 00 F0
00088356: 00 88
00088357: 00 FF
又发现CRASH现象了，这回把wpa_blacklist_add函数调用去掉了，初步测试没再发现CRASH。然后再看看。
-------------------
00088358: 05 01
00088359: B0 28
0008835A: BD 81
0008835B: E8 46
0008835C: F0 3C
0008835D: 8F D1
但确实没有找到问题所在，只是尝试，发现此处修改会减少CRASH出现的几率。
倒叙了，下面是更早的记录，最新的写上面了。下面是更早以前的记录。
C:\Users\Thinkpad>fc /b wpa_supplicant wpa_supplicant.old"
正在比较文件 wpa_supplicant 和 WPA_SUPPLICANT.OLD
00080146: 00 92
00080147: 46 F7
00080148: 00 2D
00080149: 20 FE
00080E8E: 00 91
00080E8F: 46 F7
00080E90: 00 89
00080E91: 20 FF
-------------------
00088358: 05 01
00088359: B0 28
0008835A: BD 81
0008835B: E8 46
0008835C: F0 3C
0008835D: 8F D1
分隔线下面的是用来解决蓝牙播放（萌萌哒）时，WLAN切换时系统会崩溃死机的问题。这回似乎解决了问题。猜想应该是timeout和清除timeout引发的，或者是什么什么释放了，又被用上了，也没有精力去追踪了。总之，去掉了一大部分的东西，竟然好使了。会有会引发别的问题，那就得用着看了。
void wpas_connection_failed(struct wpa_supplicant *wpa_s, const u8 *bssid)
{
int timeout;
int count;
int *freqs = NULL;
wpas_connect_work_done(wpa_s);
/*
* Remove possible authentication timeout since the connection failed.
*/
eloop_cancel_timeout(wpa_supplicant_timeout, wpa_s, NULL);
if (wpa_s->disconnected) {
/*
* There is no point in blacklisting the AP if this event is
* generated based on local request to disconnect.
*/
wpa_dbg(wpa_s, MSG_DEBUG, "Ignore connection failure "
"indication since interface has been put into "
"disconnected state");
return;
}
/*
* Add the failed BSSID into the blacklist and speed up next scan
* attempt if there could be other APs that could accept association.
* The current blacklist count indicates how many times we have tried
* connecting to this AP and multiple attempts mean that other APs are
* either not available or has already been tried, so that we can start
* increasing the delay here to avoid constant scanning.
*/
count = wpa_blacklist_add(wpa_s, bssid);
//下面的都删除了。然后就似乎好了。
}
下面是不成功的一个寻找这个CRASH的尝试过程：
以下这部分是用来解决用蓝牙播放（萌萌哒）时，WLAN切换时系统会崩溃死机的问题。其实在某些WLAN信号不好或者什么特别干扰的环境下，也会偶然崩溃，但很少见。蓝牙信号干扰WLAN？查一下，确实会干扰！！
下面这些只是在接收recvfrom时，抛弃小于6的数据（是一个尝试，因为小于6的在程序判定中是没用的数据，留着向下走也不会判定是正常的数据，但却会引发崩溃。由于没有找到这个版本的源码，所以仅是猜测。究竟是何处引发的崩溃，不得而知了，但这么尝试修改后，测试一段时间，没发现崩溃现象，似乎解决了问题。
00081250: 00 06
00081C84: 00 06
00082296: 00 06
仍然不是这个问题，DEBUG失败。。。。。。没道理的猜测是不对的。
再次尝试结果：
C:\Users\Thinkpad>fc /b wpa_supplicant wpa_supplicant.old"
正在比较文件 wpa_supplicant 和 WPA_SUPPLICANT.OLD
00080146: 00 92
00080147: 46 F7
00080148: 00 2D
00080149: 20 FE
00080E8E: 00 91
00080E8F: 46 F7
00080E90: 00 89
00080E91: 20 FF
000883FA: 00 FF
000883FB: 00 F7
000883FC: 00 1F
000883FD: 00 FF
000883FE: 64 09
000883FF: 27 F1
00088400: 08 FF
00088401: E0 36
似乎解决问题了，但感觉非常奇怪，没找到原因，但这么改以后，试了好久都没有CRASH。开始是怀疑black_list的问题，看源码却没有发现问题，但add_black_list返回值却影响很大，如果是3或者更大的数，就会引CRASH。问题应该在后面。
去掉了wpas_auth_failed(wpa_s, "CONN_FAILED");就没的问题了！！！
对比android_extend_wpa_supplicant_8中的源码，发现这里竟然没有这段：
if (count > 3 && wpa_s->current_ssid) {
wpa_printf(MSG_DEBUG, "Continuous association failures - "
"consider temporary network disabling");
wpas_auth_failed(wpa_s, "CONN_FAILED");
}
可是我的mokee51中的却有这个！会是这个引发的问题吗？单独去掉这块，竟然也没有用。下面的所有情况的timeout全改成100ms，这才稳定下来。引发问题的原因没找到，不知道会在其它什么情况下还会引发这个BUG。
000883FA: 00 FF
000883FB: 00 F7
000883FC: 00 1F
000883FD: 00 FF
000883FE: 64 09
000883FF: 27 F1
00088400: 08 FF
00088401: E0 36
00088436 ADD SP, SP, #0x14 (05 B0)
00088438 POP.W {R4-R11,PC} (BD E8 F0 8F)
|
|
IP卡
狗仔卡
发表于 2017-9-10 21:13:43
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2017-9-11 09:09:50
