• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Help Corrupted WiFi MAC Address

F

faragalla

Newbie
I have a Nexus 5 which was running 5.1 . I wanted to change my mac address and did some research and it seemed that it was very difficult on 5.1 so I downgraded to 4.4, rooted the device and ran these groups of commands (11:22:33:44:55:66 wasn't actually used, I used the actual MAC address I was trying to replicate):

busybox ifconfig wlan0 hw ether 11:22:33:44:55:66

ip link set wlan0 address 11:22:33:44:55:66
ip link set wlan0 broadcast 11:22:33:44:55:66

echo -n "112233445566" > /persist/wifi/.macaddr

After all this stuff, my mac address changed, but kept changing on its own whenever I reboot the phone; 00:90:4C:XX:XX:XX the first 3 sets always the same with the last 3 sets always changing. I tried this to fix the problem and get my mac address to it's original state.

echo -ne '\x11\x22\x33\x44\x55\x66' > /persist/wifi/.macaddr
chown root:root /persist/wifi
chmod 755 /persist/wifi
chown wifi:wifi /persist/wifi/.macaddr
chmod 660 /persist/wifi/.macaddr

While that seemed to have fixed the problem, as soon as I upgraded back to 5.1, the bad mac address started appearing again. I've factory reset and flashed stock firmware several times without success.
 
Last edited:
I can see what stack exchange article (or similar quoted at XDA and reddit) that you followed.

I'm not sure why you want to substitute an IP address for a MAC address.

Were you root when you tried it?

Did you verify whether Lollipop used a 6 byte binary file or an ACSII file?
 
I am sorry, I meant MAC address, not IP. I edited my original post.

Yes, I was rooted.

I used a hex editor to edit persist/wifi/.macaddr everything else that I tried was is in ASCII

The ever changing MAC address is 00:90:4c:xx:xx:xx with the last three sets always coming up random. How could the MAC address not be hard wired into the wireless chip?
 
http://forums.androidcentral.com/ve...57-wifi-mac-address-changes-every-reboot.html

The most plausible explanation goes - when the MAC address is read in reverse order, evidently a popular bug, the kernel takes the fallback position of using the chip manufacturer prefix code (00:90:4c is Broadcom, pretty popular part) and randomizing the final 3 octets.

It must be a firmware issue as others reporting that they regressed to a previous system version without the problem still get the post-upgrade behavior.

You could test that by entering the octets in reverse order, I guess - no promises though.

Editorial comment - I agree with others that using the MAC address from security isn't that great.

Otoh, if you're trying to keep your arp table clean, the reverse thing is maybe worth a shot.
 
First off, thank you very much for your help. You are spot on with your diagnosis. I did what you recommended, putting the values in reverse. The mac address showed up correctly, at which point I did a firmware restore from 4.4 to 4.4, but after the restore, the MAC address regressed to the dreaded 00:90:4c:xx:xx:xx.

The only places I see the MAC address referenced is in
/persist/wifi/.macaddr
/system/etc/wifi/bcmdhd.cal
/sys/devices/msm_sdcc.2/mmc_host/mmc0/mmc0:0001/mmc0:0001:2/net/wlan0/address

I just don't understand how a full firmware restore does not fix this issue and how the MAC address is not hard wired into the chip.
 
Because you're thinking in terms of a NIC, and from there, a NIC on a chip architecture - where on a pc, the primary signaling mechanism is all going through that single point.

Here the architecture requirements are the same but the allocations are different due to the nature of the beast - including multiple radios and modems as part of the architecture, unlike a pc.

Freaked me out the first time I was required to sideload a MAC address to a real-time communication controller as part of its initialization procedure, so I can relate to how screwy this looks as you peel the onion.

Remember - the MAC address is a zone-coded string. The first 24 bits indicated the known Organizationally Unique Identifier (OUI), in this case for a Broadcom transceiver component, and as I had to look up the first part again and I'm bushed lol, I'm going to ask for faith that the rest of the string contains another packet or two in the identification hierarchy before you get to the final bits identifying what you might want to think about as the serial number within that hierarchy.

Because everything doesn't go down to a plug in card or an equivalent chip, I think that the hierarchy isn't completed until the final board is assembled for your phone.

Which are getting cranked out like matchsticks all over Asia.

Easier to adopt the model of a soft MAC address, and that discipline is pretty well established.

I imagine (imagine mind you lol) that part of the validating string may be allocated elsewhere in the firmware below the rom (or beside, say in a secure storage partition (like a /mnt/asec or something) that got updated when the version number increased), and some change there along the way is why you can't regress roms and get the prior behavior.

As for the multiple storage locations, someone else here or on stackexchage may know. I haven't kept up on this in some time.

Just tell me that you're not doing this for local router security. :D

Hope that helps even though it's not really an answer.
 
Actually that makes perfect sense. But prior to upgrading from 4.4 to 5.1, the real MAC address was sticking, but that still does not mean that there was no corruption as you suspect. I thank you again for all your help and if you can think of anything I can do, file to erase or check, which may be able to "reset" this issue, I will try anything.

I am not trying to fix this issue for any particular reason other than it is really pissing me off :)
 
So, unless you can get to the routine where it's being read out in reverse and fix that, then probably your best option is to jimmy the file.

faragalla said:
I am not trying to fix this issue for any particular reason other than it is really pissing me off :)
Click to expand...

I understand *perfectly*.

It's always nice to meet someone else with the proper motivation for fixing an issue.
 
Well, I would be willing to try anything even if it ruins the phone, so if you have any recommendations on which file(s) to Jimmy, I am all ears :)
 
Get kernel source, fix problem. :)

Or add init.d scripting if the stock Nexus doesn't have it.

You'll have to search for both methods, I've been away from it for too long to guide by memory.
 
After MUCH research, I built the kernel, but have still not been able to unpack the old kernel from the boot.img file and repack my new kernel. In any case, I am not sure how this will help me as I will still be doing a regular firmware restore with the new kernel, but will still only be rewriting the same files I have been rewriting with previous firmware restores. Meaning, the corrupt file that I am trying to fix, will still be untouched.

Am I even doing the right thing here? Am I even understanding things correctly?
 
Yep, you're on to the right start.

Next, find and correct the kernel error, then package up your own boot image.

PS - I'm mobile and can't search right now but in the last month, I posted some information on packing the boot image.

Google -

site:androidforums.com EarlyMon boot image kernel build

That sort of thing.
 
I'm a bit confused. If all I am doing is replacing the kernel in the boot image and restoring the firmware, the same as I have been doing, then how will that change anything? It's not like the kernel in the stock firmware I downloaded is corrupted or anything.
 
Because the point is not to just build and replace what you have with the same thing.

The objective is -

EarlyMon said:
Get kernel source, fix problem. :)
Click to expand...

That means finding the place where it becomes unhappy with the MAC address fed to it in reverse order -

- and instead of just generating a random replacement address

- you change that code to un-reverse the actual address and use that.
 
You must log in or register to reply here.
Back
Top Bottom