860972 - [WiFi] Loss of Mac Address on Inari device; Wifi cannot be used.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Wifi, defect)

Description

[Sreenidhi]

Attachment: LogCat for Wifi

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/f83d169babee
Gaia   81cab0e96c0064b03db46a5248047fed617c2f26
BuildID 20130411070205
Version 18.0

While on First Tim Experience on the Inari, V1.0.1, The Wifi screen is blank and there are no Wifi networks detected.

Similarly, the following steps to reproduce do not detect any Wifi networks :

1. Go to Settings
2. Tap on WiFi
3. Make sure that the WiFi is turned on
4. Available networks sub heading displays 'Searching' and does not detect any WiFi networks
5. Go back to Settings->Wifi and check. Thus, WiFi under settings says 'Offline' even if the Wifi is turned on (because there are no available networks to connect to)

Comment 1

[Sreenidhi]

Attachment: No Wifi in Inari detected during FTU

Comment 2

[Sreenidhi]

Attachment: No available networks in Inari to select from for WiFi connectivity

Comment 3

[Sreenidhi]

Attachment: WiFi offline in Settings even when WiFi is turned on(because no networks to select from)

Comment 4

[Daniel Coloma:dcoloma]

This is working for me on Unagi with a build based on latest manifest:

http://stage.mozilla.org/pub/mozilla.org/b2g/manifests/1.0.1/latest/source_unagi_2013-04-11-07.xml

Can you please try to repro in an Unagi?

Comment 5

[Kai-Chih Hu [:khu]]

Nominate it back if it could be reproduced with the target devices.

Comment 6

[Sreenidhi]

Cannot be repro'ed in a unagi. Flashed my Inari on the next day's build and WiFi seemed to work fine. Can someone else reciprocate it on Inari/ Unagi on the build ID specified in Comment 1 ?

Comment 7

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

I can't reproduce on Inari with the commercial RIL build:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/2b44e2c40cc1
Gaia   c79e761bae4d92f329154c64159f4f5c8eb49c9e
BuildID 20130415070202
Version 18.0

Can you try again please?

Comment 8

[Jason Smith [:jsmith]]

Sounds like we've got the QA info needed from the initial request, even though more help here to close it. Leaving needinfo on for final resolution, but pulling qawanted keyword.

Comment 9

[Sreenidhi]

Nhirata, try flashing your phone to 11th April 2013 build (Build ID : 20130411070205) and try again, please; would like to know if this occurred on the 'Inari' on this particular build, for someone else as well.

Comment 10

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

Hi Sreenidhi, 

No this did not occur in that build for me.  
Could you please try again in a more recent build as asked in Comment 7?

Comment 11

[Sreenidhi]

Hi Naoki, Like I said before, WiFi seemed to work normal from the next day's build (12th April 2013). From then on, this WiFi problem did not occur.

Comment 12

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

I'm showing this issue on my device today.

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/5c1d67e0c242
Gaia   11477c127ae9be5051e4cfbcbf3da1d4150f9967
BuildID 20130502070201
Version 18.0
Inari

For some reason the Wifi AP Scan fails to initiate:
05-02 13:49:38.666: W/wpa_supplicant(356): wlan0: Failed to initiate AP scan

Comment 13

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

root@android:/ # busybox ifconfig                                              
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

The ethernet port is up...

Comment 14

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

I just realized.  It has no mac address and that's the problem.

Comment 15

[Daniel Coloma:dcoloma]

I cannot reproduce it with latest build on Unagi:

Gecko-b3d69b5
Gaia-716c192

I'd suggest we tef-

Comment 16

[Lukas Blakk [:lsblakk] use ?needinfo]

Vincent can you investigate and see why this might only occur on Inari devices?

Comment 17

[Dimi Lee [:dimi]]

Hi Sreenidhi,
  After checking the log, i agree with Naoki that no mac address is the problem.
  And i also tried on my platform, this issue cannot be reproduced with build in description.
  So could you help confirm following questions ?

1. Is the reproduce rate is 100% on that inari device.
2. Can all inari device reproduce this issue, or only inari device with no mac address can reproduce ?

  thanks for help

Comment 18

[Vincent Chang[:vchang][changyihsin]]

No Mac address should be the root cause in this case.

Comment 19

[Andrew Overholt [:overholt]]

ni? for comment #17

Comment 20

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

I've been having this issue consistently : 
inari-mozilla-b2g18_v1_0_1-20130507070205-ril01.00.01.019.098

This is after having flashed the partner build, the ics image and then flashing back to the commercial ril build that mozilla produces.

Comment 21

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

Attachment: screenshot

Easiest way to check is if you go to settings -> device info -> more info => there's a mac address section and it's all 00

Comment 22

[Marcia Knous [:marcia]]

Sreenidhi advises that she has not seen this since the initial report.

Comment 23

[Andrew Overholt [:overholt]]

Should we close this or is there some fix to be made?

Comment 24

[Tracy Walker [:tracy]]

I've seen something similar. I am going to investigate further.

Comment 25

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

I think this may be related to bug 869246  It might not be device specific.

Comment 26

[Tracy Walker [:tracy]]

I do not have a inari device, however, I can not reproduce this issue on 1.0.1 with ikura or unagi devices with builds from 0508. Networks are available and can be connected to during FTE.

Works as expected on ikura:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/7d7a5f0ad3e2
Gaia   30ad443fbe5363a7381c19c6bf9d6ca49228fb8b
BuildID 20130508230201
Version 18.0

Works as expected on unagi:
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/7d7a5f0ad3e2
Gaia   30ad443fbe5363a7381c19c6bf9d6ca49228fb8b
BuildID 20130508230201
Version 18.0

When I said I was seeing something similar it was on leo. The MAC address is getting changed on each flash of the device.  That is a different bug which I will file right away.

Comment 27

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

Apparantly a loss of MAC address is common on the inari device.  
I think it might be hardware related?

I tried setting one with busybox, but it wouldn't let me.

nhirata$ adb shell busybox ifconfig wlan0 hw ether 51:3D:DA:35:23:64 
ifconfig: SIOCSIFHWADDR: Operation not supported on transport endpoint

Comment 28

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

Turns out flashing w/ the partner's build, I do have a mac address and can use the wifi just fine.  Some how it's not getting set all the time in our own builds.

Comment 29

[Lukas Blakk [:lsblakk] use ?needinfo]

Not blocking based on comment 28.

Comment 30

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

I think it's an issue with mozilla's gonk layer, because as far as I can tell it's just a pass through with the gecko layer : https://mxr.mozilla.org/mozilla-b2g18/source/dom/wifi/WifiWorker.js#455

The problem with not having this in our gonk is that we cannot test the latest changes as the partner builds tend to have an earlier revision.

Comment 31

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

/proc/WIFI_MAC_ADDR is showing 00:00:00:00:00:00

Comment 32

[Vincent Liu[:vliu]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #30)
> I think it's an issue with mozilla's gonk layer, because as far as I can
> tell it's just a pass through with the gecko layer :
> https://mxr.mozilla.org/mozilla-b2g18/source/dom/wifi/WifiWorker.js#455

AFAIK, burning mac address either hard code in a ROM or a specific memory space. No matter which way to go, it is done in partner side. Base on this, I think there is nothing we should do in Mozilla's gonk layer.

Comment 33

[Ken Chang[:kenkai]]

Can we have partner's MAC update tool to write a new MAC address for this device?

Comment 34

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

I flashed with the partner's image, and flashed gecko/gaia on top.  I have a MAC address now.

I think it's some sort of other issue.

Oddly : adb shell cat /proc/WIFI_MAC_ADDR 
still shows:
00:00:00:00:00:00

Yet I have a MAC Address in the Settings :
00:03:7f:05c0:ca

I think the problem may be it's pointed to the incorrect location or calling a deprecated function?  We're noticing the same thing for Buri and the Leo is showing the wrong IMEI number.

Comment 35

[Askeing Yen[:askeing][:fyen]]

Please ref to Bug 875714.

After flash the partner build(for Ikura) on Inari, the MAC address will always be "00:03:7f:05:c0:ca".
And then flash back to Inari builds, the MAC address will be "00:00:00:00:00:00".

The Wifi fixing tool had been sent to Naoki by William.
And Taipei member can get this tool from fs1's QA folder.

Comment 36

[Mihai Cirlanaru [:mihai][:mcirlanaru]]

Bug 880617 might be relevant to this issue, there is also a follow-up for it: bug 895739.

Comment 37

[Askeing Yen[:askeing][:fyen]]

When trying to flash Inari image into Ikura device, the MAC address always be "Not Available".
The Wifi fixing tool from partner doesn't work in this case.

Ikura Device / Inari v1.0.1 Image without commercial RIL
  Gaia:     054cdc27404e2daca91d3065d9783681032b2151
  Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0
  BuildID   20130812043202
  Version   18.0

Ikura Device / Inari v1.1.0 Image without commercial RIL
  Gaia:     c60e3507d9df160e006d2e25967d26df2dc543cb
  Gecko:    http://hg.mozilla.org/releases/mozilla-b2g18/rev/36bbc5943448
  BuildID   20130812041203
  Version   18.0

If this issue is resolved, then we can flash Inari image into Ikura device.
Mark as blocker of Bug 840849.

Comment 38

[BMO Automation]

Firefox OS is not being worked on