All users were logged out of Bugzilla on October 13th, 2018

Aries - WiFi doesn't work: can't connect to any AP

RESOLVED FIXED in FxOS-S2 (10Jul)

Status

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: snowmantw, Assigned: gerard-majax)

Tracking

unspecified
FxOS-S2 (10Jul)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bzlite])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(lissyx+mozillians)
Duplicate of this bug: 1177555
Status: UNCONFIRMED → NEW
Ever confirmed: true
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)
Thanks! That made it work.
Flags: needinfo?(martijn.martijn)
(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

3 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)
(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)

Updated

3 years ago
Duplicate of this bug: 1178333
(Assignee)

Comment 9

3 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

3 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

3 years ago
Component: Gaia::Feedback → GonkIntegration
(Assignee)

Comment 11

3 years ago
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.
(Assignee)

Comment 12

3 years ago
Created attachment 8627649 [details]
95-configured diff
(Assignee)

Comment 13

3 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

3 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

3 years ago
Assignee: nobody → lissyx+mozillians
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Target Milestone: --- → FxOS-S2 (10Jul)
Duplicate of this bug: 1179309
(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

3 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

3 years ago
Yeah, I'd love to have time to do a proper investigation on a better fix ...
(Assignee)

Comment 19

3 years ago
https://github.com/mozilla-b2g/device-shinano-common/commit/e9ef670a15d56ea312e70d4b11c4aaeac404f9d2
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.