Created an attachment (id=429820) picture AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.127 Firefox os v1.0.1 Mozilla build ID:20130602070207 DEFECT DESCRIPTION: MAC address display undefined REPRODUCING PROCEDURES: 1 disable wifi, restart the phone, the macaddress shows "undefined" in settings 2 then enable wifi and connect to a ap, the macaddress still show "undefined" in settings 3 if we restart the settings app, the mac address shows correctly EXPECTED BEHAVIOUR: 1.MAC address should show correctly after we enable the wifi 2.Generaly speaking, undefined means something wrong. If we don't get mac address from low level, we should say not available or something else. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE:5/5 For FT PR, Please list reference mobile's behavior:
Clone from brother
Dear Blake, Could you have a look at this bug? Thanks.
blocking-b2g: --- → tef?
Daniel, please make a blocking call here. Thanks.
In general, Vincent is the guy to go to for wifi questions. For the two bugs pointed out here: * When wifi is off and we don't have a MAC address, we should replace undefined with "not available": this should be a simple fix in gaia (and can be fixed anywhere). * The settings app doesn't update the MAC address when wifi is turned on for the first time when the settings app is open: this should be pretty easy to fix except on the b2g18 branch because the WifiEnabled event now contains the MAC address (again this should be a simple fix in gaia against m-c).
Component: Wifi → Gaia::Settings
Depends on: 845211
This is not a 1.0.1 blocker for me
per comment 6,let's try leo?
blocking-b2g: tef? → leo?
Is someone working on this? If not, I will be taking it for tomorrow (Friday).
Hi Mihai, please take it and feel free to r? me.
It seems that wifiManager.macAddress returns the string "undefined" when the MAC address is not available, thus setting 'deviceinfo.mac' with 'undefined' in mozSettings. Not sure if this behavior is intentional, so I asked about this on the depending bug 845211.
did not block for 1.0.1 and based on the STR in step 3 the mac address is shown correctly on restart.Not a blocker.
blocking-b2g: leo? → -
1.1 is affected. Cannot turn wifi on at all; restarting settings does not reset the wifi mac address. Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/08cb0fc1e205 Gaia 6e43018fe137779997211f5dcdfa2ffa7ea5ac8b BuildID 20130619070213 Version 18.0
blocking-b2g: - → leo?
status-b2g18: --- → affected
status-b2g18-v1.0.1: --- → affected
This is not reproduced on leo device. So this is not a blocker for leo device.
Duplicate of this bug: 869246
Master/MC is also affected. Build ID : 2013-06-24-03-12-23 I believe this is with the mozilla gonk/fw on buri. If you flash a partner build and flash gecko/gaia on top, this issue is not seen (tested on both v-train and master/M-C). Can someone please take a look into this on Mozilla end?
Created attachment 768445 [details] Pull Request #10676 - Properly set/display MAC addr Set the MAC address only once (since it is hardware specific and does not change) and not every time the Wi-Fi status changes and add extra checks for the case when it is undefined. Please check my note in the pull request regarding the need of displaying 'Not available' when the MAC address is not defined.
Attachment #768445 - Flags: review?(kaze)
Comment on attachment 768445 [details] Pull Request #10676 - Properly set/display MAC addr Thanks for your good work, Mihai! Please address my nitpick (see my comment on GH) and let me know if you need me to merge your patch.
Attachment #768445 - Flags: review?(kaze) → review+
Thanks for the review, Fabien! Updated the patch with your suggestion and landed on master: https://github.com/mozilla-b2g/gaia/commit/9e70675f17e450920090ccc8e58c076d3760771e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Uplifted 9e70675f17e450920090ccc8e58c076d3760771e to: v1-train: 88bf50695767e766fef03775b5650f316538ff43
status-b2g18: affected → fixed
status-b2g-v1.1hd: --- → fixed
Dear Mihai, I don't think your patch can solve this bug without the patch of bug #845211. And IMO, we should update the macAddress after we enable the wifi.
The patch for this bug makes use of the changes brought by bug 845211, otherwise I guess 'wifiManger.macAddress' would not work at all. Since the MAC address is hardware dependent and does not change upon reboot/change of Wi-Fi network, it is more efficient to only store it once (i.e. when the Wi-Fi is enabled the first time) and then only get the stored value (from mozSettings: 'deviceinfo.mac') and not ask the wifiManager about it.
(In reply to Mihai Cirlanaru [:mihai][:mcirlanaru] from comment #22) > The patch for this bug makes use of the changes brought by bug 845211, > otherwise I guess 'wifiManger.macAddress' would not work at all. > > Since the MAC address is hardware dependent and does not change upon > reboot/change of Wi-Fi network, it is more efficient to only store it once > (i.e. when the Wi-Fi is enabled the first time) and then only get the stored > value (from mozSettings: 'deviceinfo.mac') and not ask the wifiManager about > it. As I know, after add the 845211 patch, the wifiManager.macAddress is undefined when the wifi disabled, and wifiManager.macAddress will be the real address. That is to say, we cant get macAddress when the wifi is disabled, so displays undefined. But after we enable the wifi, the wifiManager.macAddress will be the real address, and we should show the right macAddress to user but not undefine. Have look at the STR and contrast with Android and Iphone, you will find the problem.
(In reply to xiaokang.chen from comment #23) > As I know, after add the 845211 patch, the wifiManager.macAddress is > undefined when the wifi disabled, and wifiManager.macAddress will be the > real address. That is to say, we cant get macAddress when the wifi is > disabled, so displays undefined. But after we enable the wifi, the > wifiManager.macAddress will be the real address, and we should show the > right macAddress to user but not undefine. That is exactly what my fix does. > > Have look at the STR and contrast with Android and Iphone, you will find the > problem. I don't think I understand what you mean here, you might be confusing the MAC address (hardware specific, doesn't change with switching networks, rebooting) with the IP address (network/session specific, changes with switching networks, might change upon reboot when connecting to the same network).
I mean that after I add your patch in my code. The wifi macAddress always show "not available" even though I connected to an AP. Just like the attachments below.
issue No longer reproduces in the Leo. Build ID: 20130717070237 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/582e3a7018b Gaia: c506c50adaaebcf729ac3c27887ba2931ab79040 Platform Version: 18.1 MAC address does not display undefined anymore.
status-b2g18: fixed → verified
(In reply to sbogati from comment #28) > issue No longer reproduces in the Leo. > Build ID: 20130717070237 > Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/582e3a7018b > Gaia: c506c50adaaebcf729ac3c27887ba2931ab79040 > Platform Version: 18.1 > MAC address does not display undefined anymore. but the mac address still shows not available while we connected to an AP, just like the attachment shows. Is that ok???
(In reply to xiaokang.chen from comment #25) > I mean that after I add your patch in my code. The wifi macAddress always > show "not available" even though I connected to an AP. Just like the > attachments below. Hey xiaokang.chen, double checking your claims with a freshly flashed unagi on latest master (1cf9c6c) and I could reproduce the always "not available" MAC address. Apparently this is a regression caused by previous invalid stored setting for "deviceinfo.mac" in mozSettings and just noticed that the script to build Gaia for flashing on a phone sets this setting to "". Because the value was stored for the MAC address entry in mozSettings, my patch assumes that it is the correct value and doesn't update it (it only updates if such a setting is not set which worked fine at the time I submitted the patch). I have filed bug 895739 to take care of this regression.
You need to log in before you can comment on or make changes to this bug.