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

Status: RESOLVED FIXED

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[snowmantw]

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.

Comment 2

[Martijn Wargers (dead)]

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.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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.

Comment 4

[Martijn Wargers (dead)]

Thanks! That made it work.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

(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.

Comment 6

[:gerard-majax]

I have been hitting this also. This so looks like the bug 1154690 which I reported months ago and nobody seriously investigated.

Comment 7

[Henry Chang [: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.

Comment 9

[:gerard-majax]

Yeah so,
> # showlease wlan0

On a device that exposes the issue will show a IPv4 link local address (within 169.254.0.0/16).

Comment 10

[:gerard-majax]

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.

Comment 11

[:gerard-majax]

Attachment: 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.

Comment 12

[:gerard-majax]

Attachment: 95-configured diff

Comment 13

[:gerard-majax]

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 14

[:gerard-majax]

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.

Comment 16

[Henry Chang [:hchang]]

(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 17

[Michael Wu [:mwu]]

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.

Comment 18

[:gerard-majax]

Yeah, I'd love to have time to do a proper investigation on a better fix ...

Comment 19

[:gerard-majax]

https://github.com/mozilla-b2g/device-shinano-common/commit/e9ef670a15d56ea312e70d4b11c4aaeac404f9d2

Comment 20

[Henry Chang [:hchang]]

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.