Closed Bug 890974 Opened 12 years ago Closed 11 years ago

ZTE Open does not keep Wifi on consistently

Categories

(Firefox OS Graveyard :: Wifi, defect)

Product:
Firefox OS Graveyard
Component:
Wifi
Platform:
Other
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:-)

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-b2g -

People

(Reporter: cww, Assigned: chucklee)

Details

Attachments

(8 files)

logcat captured during wifi testing
182.66 KB, text/plain
Details
logcat
191.54 KB, text/plain
Details
logcat.txt
313.09 KB, text/plain
Details
dmesg.txt
1.20 KB, text/plain
Details
logcat_prod.txt
240.85 KB, text/plain
Details
logcat_wifi_logging.txt
165.50 KB, text/plain
Details
Wifi Network disabled Log
188.38 KB, text/x-log
Details
logcat (see previous comment)
262.34 KB, text/plain
Details
We're seeing some reports about WiFi not working after the first time on the ZTE Open. "Zte open: Wifi worked only once. It does not connect anymore to our home wifi. How am i supposed to run 'adb shell rm /data/misc/wifi/wpa_supplicant.conf' while adb gives 'permission denied'!!!! " "The wifi connection worked only once!! Yesterday, I could connect to our home wifi (wep secured). Then I enabled the data connection from Movistar (carrier). I do not know if it is the cause. I only know that today, it only does "connection failed" when I want to connect to our wifi. Moreover, I have to fill in the wifi password all the time (I've tried stuff like rebooting, dis/enabling options...), it is definetely a pain in the ass. Right now, the ZTE Open sucks! "
Let's leave this on the leo? list until we better understand the issue.
blocking-b2g: --- → leo?
Keywords: qawanted
I've asked marcia if she can grab the posted build that went to production in the FTP server ,and try flashing this on the Open. Cc'ing kevin, since he mentioned he could reproduce.
I just hit this problem with my phone from Taiwan (which is a black ZTE open, so might not be the same thing.) Here's what happened. I got the phone, set it up to use Mozilla Guest (no password), made sure internet was working. Plugged it in to a power adapter. Went to meetings (~ 2 hours). When I came back, the screen was still on and wifi indicator was gone, but settings still had wifi on. I turned wifi on again and I'm going to try again to reproduce.
Here are my specs: Model: ZTE OPEN Software: OPEN_FFOS_V1.0.0B03_MOVISTAR OS Version: 1.0.1.0-prerelease Firmware revision: V1.01.00.01.019.120 Hardware revision P752D04B02 Platform version: 18.0 Build identifier: 20130530053909 Update channel: nightly
There are 3 bugs that were open in regards to bad wifi on inari: bug 844968 bug 860972 bug 888227 Could we possibly get a logcat of the issue? I recall that in one of the builds we had issues with the wpa_supplicant causing a disconnect; the resolution was to kill that process. Having said that, since the phone is locked down from root access, one cannot kill that process out of the box. It would be good to get the logcat so we can determine if it's the wpa_supplicant issue.
I found the read/write permission of the file /data/misc/wifi/wpa_supplicant.conf is incorrect. The permission of this file should be "system:wifi". But I found that it is set to "root:root" in a wifi broken ZTE open. Not sure if it is the root cause of this bug, and also why the file privilege is modified to root. If your ZTE open have root privilege, you can try to delete the wpa_supplicant.conf and recovery your wifi. This method works well on my ZTE open right now.
Side note : This also may be the root cause of bug 881388.
We are waiting for a production ZTE device to be handed over to QA to further investigate the issue by getting the logcat.
QA Contact: mozillamarcia.knous
I have the prod build, but one blocker to testing one of the scenarios is that I cannot get data to work on this phone since the phone is locked. One of the input reports mentions switching from wifi to data and then seeing the issue. I can still test some different scenarios to see what happens but I need a SIM card in order to test that path.
I was able to get a Movistar card to use temporarily to try to do some testing. However, testing with the Mozilla Guest network may not be the best Here is what I did in Scenario 1: 1. Connected to Mozilla Guest Network (no password) 2. Turned off wifi and then turned on Data connection. Data connection remained on. 3. Tried to connect to wifi again. 4. Captured the attached log. Result: I was not able to successfully connect to Mozilla Guest network. In the Second scenario I tried this: 1. Turned off wifi and then turned on Data connection. Turned data connection off 2. Tried to connect to wifi again. Result: I was finally able to connect to Mozilla Guest, but it took repeated attempts. Many times when I selected the network nothing happened. I am not getting the connection failures reported by the individual in input. More testing will follow tonight on different networks.
Testing on my home WPA/WPA2 Personal Network with the production device, I cannot reproduce any issues with wifi following the same STR in Comment 10. Each time the device connects to wifi fine, and I don't have issues with connection failures or having to re-enter the network password.
Leaving this as QA is still trying to get devices.
From the user with the initial problem: Thank you for your attention, here is the information: Build Identifier 20130531232151 More information OS version 1.0.1.0-prerelease Firmware revision v1.01.00.01.019.120 Hardware revision P752D04B02 Platform version 18.0 Git commit info 2013-05-31 15:09:15 1c43bed98b2bba2388f4b869dda52d3... What happened I bought the device in an official Movistar shop in Valladolid (Spain). I was connected to the carrier's data. I went "home" (== vacation's home), then I connected to the Wifi's home. Later I plugged in the battery charger. Then, I went out, so I got back to the carrier's data. The day after, I wanted to get back on the wifi's home but it could not connect: The Wifi function is turned on, it detects wifis but when I give the password, it tries three time to connect but ends up with 'connection failed'. Since then, always this same behaviour. Now, I came back from vacations, and I tried to connect our Wifi's home (== true home :-) and it worked. As I am afraid of having the same behaviour, I'm not trying to disconnect and connect again.. Also, while in vacation, I tried 'adb rm /data/wifi/.. wifi file' but it does not work as: 1) I do not have roots permission on /data ('Permission denied') 2) I can not use adb as root ('adb can not run as root on production version' or something like that) :-( Thanks for your attention, Regards,
Attached file logcat —
I got a device from Michelle as well. I was able to reproduce the issue. This phone was not updated since the package has been opened. all I did was connect to the wifi after reboot and then let it sit idle. I had to let it sit idle for a couple of hours. Side note: I have an issue with the alarm as well being stuck on a screen. I will try to get STRs and report that as a separate issue.
I tried reproducing this again on Friday with the production device I have in the office, and even after several hours the wifi was still connected to the Mozilla Guest network.
removing qawanted based on comment 14. who can Dev can take a look at the attached logcat?
Keywords: qawanted
I see this as a blocker (WiFi is critical esp if we can repro) and we should try to get an assignee asap. Thanks.
blocking-b2g: leo? → leo+
Hi kevin, can we also get a production device here ?
Flags: needinfo?(khu)
We don't have the production devices, but we have the same devices and we can download the final builds from the partner. So, we should be able to have the same environment. Is it okay?
Flags: needinfo?(khu)
For test case in comment 10, I think 1. wifi works normally. Because the connection is rejected by AP, per log I/wpa_supplicant(420): wlan0: CTRL-EVENT-ASSOC-REJECT status_code=1 2. ZTE Open uses incorrect way to connect to AP after disconnected. ZTE Open uses "reassociation". per log I/Gecko(116): -*- WifiWorker component: Event coming in: Re-associate with 00:1a:1e:15:3b:02 Based on 802.11 spec, Reassociation is used for AP-to-AP roaming, not for reconnection. I think its not proper to use Reassociation when STA is already disconnected, because previous connection information might already be removed in AP. Standard doesn't describe the behavior in detail, so it's up to AP to determine what to do on such case. 3. For the second senario, lack of log and source code. I guess it's maybe because the "disable wifi -> enable 3G -> disable 3G -> enable wifi" flow takes longer time than "disable wifi -> enable 3G -> enable wifi", which is just is long enough to age out local AP record, while later doesn't. So ZTE Open uses association instead of reassociation. If this guess is correct, then "disable wifi -> enable 3G -> wait a while -> enable wifi" might also make the connection success.
(In reply to Chuck Lee [:chucklee] from comment #20) > If this guess is correct, then "disable wifi -> enable 3G -> wait a while > -> enable wifi" might also make the connection success. Update this line, "disable wifi -> no wait -> enable wifi" will make the connection fail, and "disable wifi -> wait a while -> enable wifi" will make the connection success.
Do we have a sense for how long that "while" is?
(In reply to [:Cww] from comment #22) > Do we have a sense for how long that "while" is? It's just a guess, I tried STR in comment 10 but can't reproduce the problem with firmware build 20130531051008 and 20130530053909. So that assumption might be wrong. I can't get firmware version 20130531232151 per comment 13, so I can't test that. After talking to QA, they They suspect the black ZTE Open mentioned in comment 3 is Inari, while I am using Ikaru here. Because there are two types of device might be both called "ZTE Open" - Ikaru and Inari. Difference between these two device is Inari has four buttons at bottom, and Ikaru has only one and more similar to ZTE Open. Inari is much unstable then Ikaru, and not fully compatible with ZTE Open rom in their experience. Lastly, they suggest to provide the MAC address in device information while this bug shows.
Assignee: nobody → chulee
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #14) > Created attachment 774755 [details] > logcat > > I got a device from Michelle as well. I was able to reproduce the issue. > This phone was not updated since the package has been opened. > > all I did was connect to the wifi after reboot and then let it sit idle. I > had to let it sit idle for a couple of hours. > I also observes "REASSOCIATE" in the log, like it also use that command to connect to AP. 07-12 09:59:58.357: E/WifiHW(113): 'DISCONNECT' 07-12 09:59:58.567: E/WifiHW(113): 'DISCONNECT' 07-12 09:59:58.777: E/WifiHW(113): 'REASSOCIATE' 07-12 09:59:58.987: E/WifiHW(113): 'REASSOCIATE' 07-12 09:59:59.007: E/WifiHW(113): 'REASSOCIATE' Per comment 20, the wpa_supplicant of ZTE Open uses reassociation on some unknown condition, and might have compatibility issue with some AP. I have tried mentioned STR but can't reproduce on Ikaru with partner build 20130530053909 (Software version OPEN_FFOS_V1.0.0B03_MOVISTAR).
I would like to mark this bug WORKSFORME for two reasons: 1. I can't reproduce this bug by mentioned STR in both Unagi and Ikura. 2. The "Reassociation" issue observed in logs indicates the root cause should be inside wpa_supplicant, but wpa_supplicant uses in B2G repo doesn't have such behavior. And we can't do further investigation because ZTE OPEN uses proprietary wpa_supplicant. So I think it's better inform this bug to ZTE.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
For Vincent's observation on comment 6, I think it shouldn't be considered to be resolved in this bug. It is not the cause of this bug(I didn't get the same issue during my tests), and it didn't have a STR. We should file another bug for that after we know exactly how to reproduce it.
STR: 1. launch FTU 2. setup wifi through FTU 3. leave the device to sleep for 2 hrs(?) ie so that wifi is disconnected 4. wake the device up and try to use wifi This is on the ikura device.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
And what build are you using? (inari on central, inari on b2g18, or partner build?)
Michael, I remembered that's something was fixed in the chipset side. Can I get your feedback and/or confirmation? Thanks.
Flags: needinfo?(mvines)
Unfortunately my memory doesn't seem to be as good as yours, I can't recall. Please use SR system when chipset support is requested though. Thanks!
Flags: needinfo?(mvines)
I need a production phone in order to answer the questions. I no longer have the production phone because I was borrowing it from a different department and had to give it back.
Base on comment 24, this bug is related to wpa_supplicant. Can partner look into this bug?
Flags: needinfo?(khu)
I will check with Partner for them to take a look the bug.
Flags: needinfo?(khu)
Hi Ivan, Any feedback from the partner? DId they say they would pick up the bug?
Flags: needinfo?(itsay)
Please renominate if still a blocker.
blocking-b2g: leo+ → -
In informed ZTE to look at this bug on 8/8. But it seems that they are busy on the v1.1 due to tight v1.1 schedule now. I will ask again for the help.
Flags: needinfo?(itsay)
The log "logcat captured during wifi testing" shows that the supplicant meets some trouble on reading the profile. I think you'd better do not modify the conf file in all your programs, just leaving it to the wpa_supplicant. From the second log "logcat" we can see the commands "DISCONNECT", "REASSOCIATE" are alternately send to the wpa_supplicant. The wpa_supplicant seemly do not response to the two commands. And I don't think the wpa_supplicant can response to the commands correctly, either.
Hi Ken, Please help to provide the adb log for Baisheng to do the further investigation. Thank you!
Flags: needinfo?(kchang)
Vincent, I and Chuck are not in Taipei now. Can you please help this?
Flags: needinfo?(kchang) → needinfo?(vchang)
Hi Naoki, can you provide the logcat log using the STR in Comment 27 ? In the attached "logcat" file you posted before, zhangbaisheng found that Wifi commands "DISCONNECT" and "REASSOCIATE" are sent to wpa_supplicant continuously in a very short time which might be the reason why wifi can't work. I am wondering if you can reproduce the same issue using the STR in Comment 27 right now ? If you can, please let us know which software version and device should we use to reproduce the problem.
Flags: needinfo?(vchang)
Flags: needinfo?(nhirata.bugzilla)
This bug has been brought up as one of our highest "support calls". For that reason I'm placing this on the koi? list again (for possible inclusion in a ZTE 1.1 or 1.1.0.1)
blocking-b2g: - → koi?
Attached file logcat.txt —
09-03 11:55:17.040: I/wpa_supplicant(411): wlan0: CTRL-EVENT-DISCONNECTED bssid=58:6d:8f:a2:e7:5f reason=3 It doesn't give a specific reason. This occurs after ~ 30 minutes of the device falling asleep (black screen) and no other activity.
Attached file dmesg.txt —
Corresponding adb shell dmesg log. Note: time is 7 hrs ahead in the dmesg; I think it's using GMT.
Flags: needinfo?(nhirata.bugzilla)
So I hacked using the exploit on the production version (B2G_P752D04V1.0.0B09_TME) which I used to replicate the issue : drwxr-x--- wifi wifi 2013-09-03 12:17 wpa_supplicant -rw-rw---- system wifi 143 2013-09-03 12:17 wpa_supplicant.conf I read on some forums where people were having issues with the wpa_supplicant on various linux/android systems. One mentioned : "Is your wireless network broadcasting your SSID? If not, you'll need to add scan_ssid=1 within your network {...} definition within your wpa_supplicant.conf file"
[To note, I used the ZTE's build and on a nonproduction phone]
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #43) > Created attachment 799032 [details] > logcat.txt > > 09-03 11:55:17.040: I/wpa_supplicant(411): wlan0: CTRL-EVENT-DISCONNECTED > bssid=58:6d:8f:a2:e7:5f reason=3 > > It doesn't give a specific reason. This occurs after ~ 30 minutes of the > device falling asleep (black screen) and no other activity. The frequently "DISCONNECT" and "REASSOCIATE" doesn't show up in this log. Also, although we don't know why AP sends the deauth, the STA reconnect to AP right after it is disconnected. The wifi should be still connected. The state looks normal to me in this log. baisheng, do you find something abnormal?
Flags: needinfo?(zhang.baisheng)
I'm not sure what you're looking for Chucklee, can you clarify? There are disconnects at the following times: 09-03 11:54:29.484 09-03 11:55:17.040 09-03 11:56:43.995 09-03 11:57:03.194 09-03 11:57:53.162 09-03 11:58:07.146 The device was left alone after going to sleep.
Attached file logcat_prod.txt —
Here is the logcat from the production device.
(In reply to nhirata from comment #48) > I'm not sure what you're looking for Chucklee, can you clarify? There are > disconnects at the following times: > > 09-03 11:54:29.484 > 09-03 11:55:17.040 > 09-03 11:56:43.995 > 09-03 11:57:03.194 > 09-03 11:57:53.162 > 09-03 11:58:07.146 > > The device was left alone after going to sleep. These disconnects are always followed by a connect right away, so the connection should be working after wake up. And this log doesn't show continuous "DISCONNECT" and "REASSOCIATE" commands as previous log. The cause of disconnect here should be different from others, but I have no other data to find it out.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #49) > Created attachment 799867 [details] > logcat_prod.txt > > Here is the logcat from the production device. Hi Naoki, We noticed the timer is triggered too frequently: the 'SIGNAL_POLL' command should be sent every 5 second after connected, but it is sent contentiously after 16:25:09.661, which is not what we expected. It looks like there are multiple timer running at same time. So We like to check the wifi state. Please provide logact with open wifi debug log, if available, in Settings -> Device Information -> More Information -> Developer -> Wi-Fi output in adb. If possible, please also adding |debug()| message in WifiWorker.js http://mxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js#2258 and http://mxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js#2191. So we can track the source of "DISCONNECT" and "REASSOCIATE" command. Thanks for your help.
Turned on device, set the wifi debug to adb, rebooted device, let the phone sleep. I plugged in/out the phone several times, you can see from the log by filtering on usb. Plugging in the usb will wake the device. It appears that there is no disconnect messages with the logging on the wifi turned on. I did see : 09-05 13:21:47.264: D/wpa_supplicant(399): RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP]) 09-05 13:21:47.264: D/wpa_supplicant(399): RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #52) > Created attachment 800360 [details] > logcat_wifi_logging.txt > > Turned on device, set the wifi debug to adb, rebooted device, let the phone > sleep. I plugged in/out the phone several times, you can see from the log > by filtering on usb. Plugging in the usb will wake the device. > > It appears that there is no disconnect messages with the logging on the wifi > turned on. I did see : > > 09-05 13:21:47.264: D/wpa_supplicant(399): RTM_NEWLINK: operstate=1 > ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP]) > 09-05 13:21:47.264: D/wpa_supplicant(399): RTM_NEWLINK, IFLA_IFNAME: > Interface 'wlan0' added All issues mentioned above didn't show up in this log... :( But From the following log (and also other logs for connectionInfoUpdate), I/Gecko(113): -*- WifiWorker component: Firing connectionInfoUpdate: ({signalStrength:-58, relSignalStrength:93, linkSpeed:39, ipAddress:"10.251.37.0"}) I found another problem here: the device seems gets an incorrect IP. The situation is getting more complex now. Naoki, we both are attending the work week next week, maybe we can find some time work on this together.(I don't have an Ikura) Although I still think this bug should be taken over by ZTE(at least doing the tests), let's try what's we can do.
Hi Baisheng, Please check the new log for the further investigation.
Yes, I agree; let's meet up in Oslo to work on this together. I will bring the production phone in question. Is there anything in the wifi logging code that would cause a difference in behavior?
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #55) > Yes, I agree; let's meet up in Oslo to work on this together. I will bring > the production phone in question. > > Is there anything in the wifi logging code that would cause a difference in > behavior? I think the only difference is the delay caused by logging. And I tested ZTE Open with STR - turn off screen, wait more than 30 minutes, turn on screen - for about 5 times this afternoon. Wifi connection comes back successfully every time...
Observe other situation causes wifi not re-connect. Main cause is SSID is disabled in wpa_supplicant by gecko due to connection fail, although it's setting is correct. Once the SSID is disabled, it can only be enabled again when it is forced to connect by user, device connects to other SSID successfully, or wpa_supplicant restart. We can't avoid connection fail on wifi, maybe we should disable SSID only for a period of time instead of forever, to avoid such dead lock. Analysis of log: [ Connected ] 09-11 00:17:53.012 I/wpa_supplicant( 389): wlan0: CTRL-EVENT-CONNECTED - Connection to f8:4f:57:aa:4d:e1 completed (reauth) [id=0 id_str=] [ Disconnected, reason unknown ] 09-11 00:18:01.482 I/wpa_supplicant( 389): wlan0: CTRL-EVENT-DISCONNECTED bssid=f8:4f:57:aa:4d:e1 reason=0 [ Reconnection failed ] 09-11 00:19:56.001 I/wpa_supplicant( 389): wlan0: CTRL-EVENT-ASSOC-REJECT bssid=f8:4f:57:aa:4d:e1 status_code=1 09-11 00:20:13.001 I/wpa_supplicant( 389): wlan0: CTRL-EVENT-ASSOC-REJECT status_code=1 09-11 00:20:27.001 I/wpa_supplicant( 389): wlan0: CTRL-EVENT-ASSOC-REJECT status_code=1 [Network is disabled due to connection fail] 09-11 00:20:27.081 E/WifiHW ( 113): 'DISABLE_NETWORK 0' [Wifi working, but doesn't attempt to connect anymoe] 09-11 00:29:27.975 E/WifiHW ( 113): 'SCAN_RESULTS' 09-11 00:29:27.975 E/wpa_supplicant( 389): bssid / frequency / signal level / flags / ssid 09-11 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:ab:01:71 2442 -40 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:ab:1d:a1 2467 -47 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:ab:18:51 2427 -47 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:ab:1a:a1 2412 -56 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:aa:fa:41 2467 -59 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:aa:4d:e1 2427 -60 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): 14:10:9f:e7:1b:3a 2447 -63 [WPA2-PSK-CCMP][ESS] Styang mac 09-11 00:29:27.975 E/wpa_supplicant( 389): dc:a5:f4:43:73:81 2412 -65 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): dc:a5:f4:42:05:11 2467 -81 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week [Manual disable-enable wifi] 09-11 00:32:47.499 E/WifiHW ( 113): 'TERMINATE' [Network enabled] 09-11 00:32:57.889 E/WifiHW ( 113): 'ENABLE_NETWORK 0' [Wifi connected] 09-11 00:32:58.450 I/wpa_supplicant( 1470): wlan0: CTRL-EVENT-CONNECTED - Connection to f8:4f:57:ab:1a:a1 completed (auth) [id=0 id_str=]
Side note, above test is performed on ZTE Open, version OPEN_FFOS_V1.0.0B04_MOVISTAR. With same wifi setting, I don't observe same issue on Unagi with same wifi setting.
Adding code that already exists on central [1] to ZTE Open (I suppose it is using b2g-18) might help with the wifi disable issue. I can't test because I can't flash it. [1] http://mxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js#2227
I'll call that's all we can do, and move this bug out of radar until ZTE provides further support. Because 1. It's difficult to get a device, and the bug can't be reproduced on other phones. 2. I think we've collect as much information as we can out of the black box, and point out issues presented in these logs. 3. We can't flash code into device for debugging or confirmation solution. Actually I am willing to change this bug to WONTFIX since we actually can do nothing about it but dumping log.
I just got a ZTE Open today - second round of the US eBay sales. I haven't put a SIM card in it yet, but I did put a 32 GB microSD card in. This morning it connected fine (without the SD card) to WiFi in a coffee shop with WEP security. It had seven updates queued, which it downloaded and installed successfully. Software is now OPEN_US_DEV_FFOS_V1.0.0B02, firmware revision V1.01.00.01.019.144, hardware revision P752D04B02, platform version 18.0, Build identifer 20130906180957, Git commit info 2013-09-06- 09:48:36 Now I'm in another coffee shop with WPA security and it says 'connecting' but never actually connects. I'm going to wait until I get home where I have more troubleshooting options (Wired internet, a Clear hotspot, a Fedora Linux laptop I can turn into a WEP hotspot, etc.). At this point I think it's the coffee shop's problem and not the ZTE Open or the software. I should have a SIM card in it tomorrow.
Ivan, Please check if this is needed in 1.2. Is this a POVB?
Flags: needinfo?(itsay)
(In reply to Chuck Lee [:chucklee] from comment #57) > Created attachment 802923 [details] Wifi Network disabled Log Observe other > situation causes wifi not re-connect. Main cause is SSID is disabled in > wpa_supplicant by gecko due to connection fail, although it's setting is > correct. Once the SSID is disabled, it can only be enabled again when it is > forced to connect by user, device connects to other SSID successfully, or > wpa_supplicant restart. We can't avoid connection fail on wifi, maybe we > should disable SSID only for a period of time instead of forever, to avoid > such dead lock. Analysis of log: [ Connected ] 09-11 00:17:53.012 > I/wpa_supplicant( 389): wlan0: CTRL-EVENT-CONNECTED - Connection to > f8:4f:57:aa:4d:e1 completed (reauth) [id=0 id_str=] [ Disconnected, reason > unknown ] 09-11 00:18:01.482 I/wpa_supplicant( 389): wlan0: > CTRL-EVENT-DISCONNECTED bssid=f8:4f:57:aa:4d:e1 reason=0 [ Reconnection > failed ] 09-11 00:19:56.001 I/wpa_supplicant( 389): wlan0: > CTRL-EVENT-ASSOC-REJECT bssid=f8:4f:57:aa:4d:e1 status_code=1 09-11 > 00:20:13.001 I/wpa_supplicant( 389): wlan0: CTRL-EVENT-ASSOC-REJECT > status_code=1 09-11 00:20:27.001 I/wpa_supplicant( 389): wlan0: > CTRL-EVENT-ASSOC-REJECT status_code=1 [Network is disabled due to > connection fail] 09-11 00:20:27.081 E/WifiHW ( 113): 'DISABLE_NETWORK 0' > [Wifi working, but doesn't attempt to connect anymoe] 09-11 00:29:27.975 > E/WifiHW ( 113): 'SCAN_RESULTS' 09-11 00:29:27.975 E/wpa_supplicant( 389): > bssid / frequency / signal level / flags / ssid 09-11 00:29:27.975 > E/wpa_supplicant( 389): f8:4f:57:ab:01:71 2442 -40 > [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 > 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:ab:1d:a1 2467 -47 > [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 > 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:ab:18:51 2427 -47 > [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 > 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:ab:1a:a1 2412 -56 > [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 > 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:aa:fa:41 2467 -59 > [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 > 00:29:27.975 E/wpa_supplicant( 389): f8:4f:57:aa:4d:e1 2427 -60 > [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] Mozilla Work Week 09-11 > 00:29:27.975 E/wpa_supplicant( 389): 14:10:9f:e7:1b:3a 2447 -63 > [WPA2-PSK-CCMP][ESS] Styang mac 09-11 00:29:27.975 E/wpa_supplicant( 389): > dc:a5:f4:43:73:81 2412 -65 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] > Mozilla Work Week 09-11 00:29:27.975 E/wpa_supplicant( 389): > dc:a5:f4:42:05:11 2467 -81 [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][ESS] > Mozilla Work Week [Manual disable-enable wifi] 09-11 00:32:47.499 E/WifiHW > ( 113): 'TERMINATE' [Network enabled] 09-11 00:32:57.889 E/WifiHW ( 113): > 'ENABLE_NETWORK 0' [Wifi connected] 09-11 00:32:58.450 I/wpa_supplicant( > 1470): wlan0: CTRL-EVENT-CONNECTED - Connection to f8:4f:57:ab:1a:a1 > completed (auth) [id=0 id_str=] From this log, this device is rejected by Hotspot and then this hotspot is added into blacklist of wpa_supplicant. In the android, it will show the status to user: "Disabled", and won't try to connect to this hotspot again until user chooses to connect it in the list or re-turn on wifi, wpa_supplicant will clear it from blacklist and try to connect.
Flags: needinfo?(zhang.baisheng)
Hi, I've been testing this with Ikura device, 1.1 commercial build, and I've been not able to reproduce the issue. However, I plan to test with FTU and sleep mode as described by Naoki in comment #27 (I'll late you know later). Version info: Software: OPEN_FFOS_V1.1.0B01_TME Firmware: 01.01.00.019.215 commit info: 2013-09-26 03:41:00 2d565af4e109580d6810ae5ac0fbada704... Dear Zhang Baisheng, could you please take a look to this issue? Thanks! David
Flags: needinfo?(zhang.baisheng)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #27) > STR: > 1. launch FTU > 2. setup wifi through FTU > 3. leave the device to sleep for 2 hrs(?) ie so that wifi is disconnected > 4. wake the device up and try to use wifi > > This is on the ikura device. Retested with ikura, commercial version 1.1: Version info: Software: OPEN_FFOS_V1.1.0B01_TME Firmware: 01.01.00.019.215 commit info: 2013-09-26 03:41:00 2d565af4e109580d6810ae5ac0fbada704... And it's also happening. I'll attach some logs now... Thks! David
(In reply to Preeti Raghunath(:Preeti) from comment #62) > Ivan, > > Please check if this is needed in 1.2. Is this a POVB? It seems not to be POVB so far but we need ZTE's help on log analysis.
Flags: needinfo?(itsay)
I can't find it is abnormal in the log, is it reproduced?
Flags: needinfo?(zhang.baisheng)
Please renom when more info is available.
blocking-b2g: koi? → -
Feel fee to reopen if you still can reproduce the bug.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: