Closed
Bug 1177411
Opened 9 years ago
Closed 9 years ago
Aries - WiFi doesn't work: can't connect to any AP
Categories
(Firefox OS Graveyard :: GonkIntegration, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
FxOS-S2 (10Jul)
People
(Reporter: snowmantw, Assigned: gerard-majax)
References
Details
(Whiteboard: [bzlite])
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 After I successfully connect to WiFi, it got stuck and can't connect to any new AP, after I launched the FxOS studio and got a fully reset. The error just shows "key error, try to reset the key" or something like that. According to out WiFi team, this is because this build is with some old driver and it doesn't clear the "/data/misc/dhcp/dhcpcd-wlan0.lease". After I manually clear it via adb, it works again However I think it's totally unacceptable for any ordinary users.
Depends on: 1144623
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(lissyx+mozillians)
Updated•9 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•9 years ago
|
||
How do I clear the /data/misc/dhcp/dhcpcd-wlan0.lease file? When I do adb shell rm /data/misc/dhcp/dhcpcd-wlan0.lease , I get a permission denied.
QA Whiteboard: [top-dogfood]
Flags: needinfo?(nhirata.bugzilla)
Be sure to do an "adb root" as the dogfood devices are using userdebug builds, and you would need to do that before you run the remove command.
Flags: needinfo?(martijn.martijn)
Comment 5•9 years ago
|
||
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #3) > Be sure to do an "adb root" as the dogfood devices are using userdebug > builds, and you would need to do that before you run the remove command. "adb shell" and then "su" also worked for me.
Assignee | ||
Comment 6•9 years ago
|
||
I have been hitting this also. This so looks like the bug 1154690 which I reported months ago and nobody seriously investigated.
Flags: needinfo?(lissyx+mozillians) → needinfo?(hchang)
Comment 7•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #6) > I have been hitting this also. This so looks like the bug 1154690 which I > reported months ago and nobody seriously investigated. I don't think we didn't seriously investigate but you can definitely blame that we are not good enough to find the root cause. By the way, I am not sure if all the wifi issues have the same cause (even though they "look" the same). We have been seeing different kind of errors and there is no reason to treat them as the same one in mind.
Flags: needinfo?(hchang)
Assignee | ||
Comment 9•9 years ago
|
||
Yeah so,
> # showlease wlan0
On a device that exposes the issue will show a IPv4 link local address (within 169.254.0.0/16).
Assignee | ||
Comment 10•9 years ago
|
||
Pushing backup-aries/system/etc/dhcpcd/dhcpcd-hooks/95-configured to /system/etc/dhcpcd/dhcpcd-hooks/95-configured seems to mitigate/fix the issue for me.
Flags: needinfo?(hchang)
Assignee | ||
Updated•9 years ago
|
Component: Gaia::Feedback → GonkIntegration
Assignee | ||
Comment 11•9 years ago
|
||
So this does help as far as I could test, but it's unclear to me why. This needs more investigation, IMHO.
Assignee | ||
Comment 12•9 years ago
|
||
Assignee | ||
Comment 13•9 years ago
|
||
Right so, let's compare dhcpcd service definition on Z3 Compact and Flame ... Z3 Compact: > $ grep 'dhcpcd_wlan0' out/target/product/aries/root/init.qcom.rc > service dhcpcd_wlan0 /system/bin/dhcpcd -B -d -t 30 Flame: > $ grep 'dhcpcd_wlan0' out/target/product/flame/root/init.qcom.rc > service dhcpcd_wlan0 /system/bin/dhcpcd -ABKLG And, as documented in dhcpcd(8): > > Local Link configuration > If dhcpcd failed to obtain a lease, it probes for a valid IPv4LL address (aka ZeroConf, aka APIPA). Once obtained it restarts the process of looking for a DHCP server to get a proper address. > > When using IPv4LL, dhcpcd nearly always succeeds and returns an exit code of 0. In the rare case it fails, it normally means that there is a reverse ARP proxy installed which always defeats IPv4LL probing. To disable this behaviour, > you can use the -L, --noipv4ll option. > Hence it means on Flame we can never get a link local address because of the '-L' flag in dhcpcd command line.
Assignee | ||
Comment 14•9 years ago
|
||
Comment on attachment 8627647 [details] [review] Shinano common PR This seems to be enough. I don't see a simpler way to fix this right now.
Attachment #8627647 -
Flags: review?(mwu)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → lissyx+mozillians
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Target Milestone: --- → FxOS-S2 (10Jul)
Comment 16•9 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #10) > Pushing backup-aries/system/etc/dhcpcd/dhcpcd-hooks/95-configured to > /system/etc/dhcpcd/dhcpcd-hooks/95-configured seems to mitigate/fix the > issue for me. This is interesting. The hook is to propagate the dhcpcd internal request result to property. The modified hook treats IPv4ALL to 'success' whereas the current hook in use treats IPv4ALL 'failed'. The interesting point is how come the hook file could affect the subsequent DHCP request.
Flags: needinfo?(hchang)
Comment 17•9 years ago
|
||
Comment on attachment 8627647 [details] [review] Shinano common PR This.. seems odd, but ok. I think I would slightly prefer passing -L to dhcpcd if it's simple enough to do, but I'm ok with this too.
Attachment #8627647 -
Flags: review?(mwu) → review+
Assignee | ||
Comment 18•9 years ago
|
||
Yeah, I'd love to have time to do a proper investigation on a better fix ...
Assignee | ||
Comment 19•9 years ago
|
||
https://github.com/mozilla-b2g/device-shinano-common/commit/e9ef670a15d56ea312e70d4b11c4aaeac404f9d2
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 20•9 years ago
|
||
Are we going to add '-L' to the dhcpcd args? I checked the args that cm12 uses is 'service dhcpcd_wlan0 /system/bin/dhcpcd -aABDKL' and what we current use is same as the vender.
You need to log in
before you can comment on or make changes to this bug.
Description
•