All users were logged out of Bugzilla on October 13th, 2018
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
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]
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.
Thanks! That made it work.
(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.
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)
(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.
Yeah so, > # showlease wlan0 On a device that exposes the issue will show a IPv4 link local address (within 169.254.0.0/16).
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.
Component: Gaia::Feedback → GonkIntegration
Created attachment 8627647 [details] [review] Shinano common PR So this does help as far as I could test, but it's unclear to me why. This needs more investigation, IMHO.
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.
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: nobody → lissyx+mozillians
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Target Milestone: --- → FxOS-S2 (10Jul)
(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.
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+
Yeah, I'd love to have time to do a proper investigation on a better fix ...
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
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.