[mrg666]

Update-
I turned on bluetooth on the donor phone, and the bluetooth settings screen updated immediately. I checked the about phone screen again, and the bluetooth mac address was filled in. Turned bluetooth off, and the about phone screen again read Unknown. Turned bluetooth back on, and it read the same mac address again. Rebooted, and same behavior, same mac address.

So stock is not reading at init or boot, but from the module at each activation.
We need to discover the api request.

This is what we see in IHO as well. Just that the last three pairs are all zeros. Do you have the /data/bdaddr file? Can you please check that?

[RyanJKremer]

@mrg666: I am sorry, I know l should keep quiet and let you guys work, but listen: that simply doesn't look to me as the kind of code that would read the hardware MAC. Even if that property file was somehow mapped to firmware or EEPROM, why would they store it as formatted ASCII only to parse it again first time they read it?

I think there's got to be some lower level code in the kernel which reads the hardware MAC, then formats and saves it by setting the property being read in the code you posted.

OK, now tell me to shut up. I can take it. Seriously!

Just taking out my "backside" here. I'm guessing if it uses 0-F it might be hexadecimal code. WAY more fun than binary code...

Sent from my LG-VM670 using Android Central Forums

[Dannemand]

Just taking out my "backside" here. I'm guessing if it uses 0-F it might be hexadecimal code. WAY more fun than binary code...

LOL Yeah, yeah, you knew what I meant

It's actually reading a string of colon separated hex digits as represented in ASCII. Even if they wanted to store it in a readable format (as in the build.prop), then why the colons? Of course that doesn't prove anything. But it just doesn't look like the kind of low level code that reads a hardware MAC.

Anyways, you were joking, I know

Edit: BTW every time I see your Avatar... damn!

[Dannemand]

I am not that rude to tell you that. Besides, it is puzzling to me too. I am looking at Broadcom's own code (brcm_patchram_plus.c) that I quoted the relevant part of it above. It requries a file in the file system for reading the value of bdaddr. There is another program (bdaddr_read.c) that reads another system property in build.prop and writes the value of bdaddr to that file (/data/bdaddr). Binaries of both codes are called in the same init script. And I didn't design this, I just followed the code. If there is a phone around with stock ROM, maybe someone can check this out.

On the other hand it is not a sin to assign a randomized bluetooth MAC. It is not an ethernet card in a WAN to cause catastrophic collisions. Why would you use bluetooth for networking while you have 3G and WiFi? As long as you don't use it for networking, only your car stereo or your headphone will see it. If you are too concerned about a "real" MAC, you can just flash a stock ROM and get the number from there. But with the mechanism I have seen, I will not be surprised if the bluetooth MAC is different every time you wipe clean and reflash the stock ROM. Now, that would be be very interesting.

I am tired .... nite nite.

I'll try tonight and restore my original 2.2.1 stock and compare its BT address with the one I got from the ZV9 stock. I have a feeling they're going to be the same and that they're reading a "real" hardware MAC stored deep some place where it's not easily flashed over (what I referred to as EEPROM because that's what it would have been in the old days).

That said, I agree 100% not to obsess over a "real" MAC for Bluetooth. As I said in a previous post, even the solution you already posted is a great leap forward and would be fine for me (assuming audio actually works in the car when I test it - I saw your post about a newer fix on its way).

I already did as you suggested, and used ZV9 stock ROM to get my "real" BT address, which is what I put in my build.prop. And it's what shows up in my About-Status screen.

Thanks again for everything you do!

[mrg666]

Okay, here is my final solution. This should fix the sound problems in calls as well.

No editing of build.prop is necessary anymore. You can just revert build.prop to original. Boot process will create a MAC number with B0:89:91:XX:XX:XX where XX are randomly generated, i.e. 16 million possibilities. If the number has been created before it will not be changed in the subsequent boots, i.e. the MAC number will be persistent. If you want to change the MAC number by yourself, you can edit the file /data/rnd_bdaddress or just restore from your backup after a complete wipe.

You can flash this zip file which will replace /system/bin/bdaddr_read and /system/bin/brcm_patchram_plus. I am confident that the bluetooth will work as before with the new MAC number. You will only need to re-pair your connections.

For anyone who wants to see what has been changed, the source files are below for download. I have revised both C files. You should know where they go.
brcm_patchram_plus.c
bdaddr_read.c

[Tejer]

Okay, here is my final solution. This should fix the sound problems in calls as well.

No editing of build.prop is necessary anymore. You can just revert build.prop to original. Boot process will create a MAC number with B0:89:91:XX:XX:XX where XX are randomly generated, i.e. 16 million possibilities. If the number has been created before it will not be changed, i.e. the MAC number is persistent. If you want to change the MAC number by yourself, you can edit the file /data/rnd_bdaddress or just restore from your backup after a complete wipe.

You can flash this zip file which will replace /system/bin/bdaddr_read and /system/bin/brcm_patchram_plus. I am confident that the bluetooth will work as before with the new MAC number. You will only need to re-pair your connections.

For anyone who wants to see what has been changed, the source files are below for download. I have revised both C files. You should know where they go.
brcm_patchram_plus.c
bdaddr_read.c

Awesome work! So just to double check, this can be flashed on any IHO rom or just Mirage? Also, is the in call fix for regular speaker in cal volume, or for Bluetooth headsets?

[mrg666]

Awesome work! So just to double check, this can be flashed on any IHO rom or just Mirage? Also, is the in call fix for regular speaker in cal volume, or for Bluetooth headsets?

You can flash on any IHO ROM if they have the same IHO boot scripts. The call fix is about the complaints for the blueooth connection on phone calls after my first iteration discussed in the previous and this page.

[Schlidel]

You can flash on any IHO ROM if they have the same IHO boot scripts. The call fix is about the complaints for the blueooth connection on phone calls after my first iteration discussed in the previous and this page.

I've clean installed your latest rom + fix.

Successful Bluetooth address change.

I'll be able to test in car later tonight.

Edit: I just tested. Perfect. You're the man.

Sent from my LG-VM670 using Android Central Forums

[ulmeck]

I have also updated the data indicators in the status bar (made myself). The bluetooth indicator icon was plain ugly and 3G/1X indicators had always the arrows in wrong directions. Nobody noticed since the up/down arrows were so tiny that the direction they point was not easy to see.

BTW, I like the new indicators, along with the changed BT icon. It's a subtle change but nice.

Thanks,

jf

[mrg666]

Edit: I just tested. Perfect. You're the man.

Sent from my LG-VM670 using Android Central Forums

This means that we are done with the same-MAC problem of Bluetooth. Now everybody (who wants) has a different bluetooth MAC address. This is transparent to the user and implementation in IHO is extremely simple. Thanks to everyone who helped with testing and ideas. This will be integrated in the next MiRaGe build.

Just to clarify, you can still update your ROM without changing the Bluetooth address as long as you don't do a complete wipe (i.e. wipe /data as well). In that case, you can edit /data/rnd_bdaddr file or just restore that file from backup to keep using the same Bluetooth address.

[EarthnFire78]

This means that we are done with the same-MAC problem of Bluetooth. Now everybody (who wants) has a different bluetooth MAC address. This is transparent to the user and implementation in IHO is extremely simple. Thanks to everyone who helped with testing and ideas. This will be integrated in the next MiRaGe build.

Just to clarify, you can still update your ROM without changing the Bluetooth address as long as you don't do a complete wipe (i.e. wipe /data as well). In that case, you can edit /data/rnd_bdaddr file or just restore that file from backup to keep using the same Bluetooth address.

With my rom because of the ad2sdx script I use everything needs to be wiped and since my rom wiped's everything (but sd-ext) at install, I will include a script that will backup the file and restored after install is finished.

[MrJedi]

So I just updated to the current build from the 12162011 build. I had stayed at that build for a while because the next build I tried (02122012) gave me issues. I decided at that time not to try to fix something that wasn't broken and went back to the 12162011 build.

After I flashed the most recent build and recovery I have gone from 65MB of user available storage to 15MB of user available storage and my phone is much slower. I tried clearing cache, rebooting, nothing did much than give me a few extra megs. I restored the back-up of my old build and everything is as it should be. Running smooth with 65MB available for user storage. Was there a bug in older builds that under reported usage?

[EarthnFire78]

You need to clarify what rom you are using.

[Schlidel]

MrG666, I'm curious.

What did you figure out was causing the garbled phone audio? Not that important for me to know but I was wondering.

Sent from my LG-VM670 using Android Central Forums

[Dannemand]

@mrg666: Way late too the party again today. But I finally flashed your latest Bluetooth patch, it randomized my BT address, I was able to pair with my car, and I had a phone conversation there no problem. I have yet to pair my wife's phone and see that that works, but I see no reason why not.

I actually did have an odd glitch about an hour after flashing, where suddenly I FC'ed on two different apps. I NEVER have FCs and was quite surprised. Tonight I restored my latest nandroid and flashed your patch again. (I re-downloaded the patch.zip, but they they were identical.) Everything is working, must've been some odd glitch after messing around yesterday.

Do note that the patch.zip isn't signed.

I am truly impressed with how you just hit these curveballs out of the park whenever I throw them at you Seriously, thanks a lot. I cannot think of anything else in MiRaGe now that isn't pretty much perfect.

[mrg666]

MrG666, I'm curious.

What did you figure out was causing the garbled phone audio? Not that important for me to know but I was wondering.

Sent from my LG-VM670 using Android Central Forums

Remember the first brcm...c code I linked? I had checked only a small part of it. That new code was actually passing the kernel driver's API some different parameters than the original. Instead of using the new one, I went back to the original and patched it with useful part of the new version.

[kwknott]

Anyone else having issues downloading from mediafire. Trying to get mrg's patch and just getting blank page. Tried some other files too.

Sent from my LG-VM670 using Tapatalk 2

[mrg666]

@mrg666: Way late too the party again today. But I finally flashed your latest Bluetooth patch, it randomized my BT address, I was able to pair with my car, and I had a phone conversation there no problem. I have yet to pair my wife's phone and see that that works, but I see no reason why not.

I actually did have an odd glitch about an hour after flashing, where suddenly I FC'ed on two different apps. I NEVER have FCs and was quite surprised. Tonight I restored my latest nandroid and flashed your patch again. (I re-downloaded the patch.zip, but they they were identical.) Everything is working, must've been some odd glitch after messing around yesterday.

Do note that the patch.zip isn't signed.

I am truly impressed with how you just hit these curveballs out of the park whenever I throw them at you Seriously, thanks a lot. I cannot think of anything else in MiRaGe now that isn't pretty much perfect.

Thanks for the appreciation. It has been another good team work.

I have not seen or heard any problems about the latest build. It was probably an isolated problem. Yeah the patch was not signed. Since the content were not Android apps but just binaries, I didn't bother.

[RT78]

Anyone else having issues downloading from mediafire. Trying to get mrg's patch and just getting blank page. Tried some other files too.

Sent from my LG-VM670 using Tapatalk 2

If you are trying from your phone (as your signature states), make sure your browser is in desktop view. I had problems like this with mediafire but after switching from mobile to desktop it works everytime.

[braxton355]

I downloaded and flashed this today, and I've had this rom freeze on me like 5 times. I'm not overclocked my phone wont do that. Is there any solutions to this problem?

Sent from my LG-VM670 using Android Central Forums

[anthonycr]

I downloaded and flashed this today, and I've had this rom freeze on me like 5 times. I'm not overclocked my phone wont do that. Is there any solutions to this problem?

Sent from my LG-VM670 using Android Central Forums

You need to specify which rom you flashed. This thread encompasses all the iho roms.

HOWEVER, I bet your problem is the ics rotation animations. Go into settings>>cm settings>>display and unselect ics rotation animations, then reboot. It should fix your problem.

Sent from my LG-VM670 using Tapatalk 2

[braxton355]

I did that thank you! And I didn't realize it was all IHO roms, btw I'm using backside!

Sent from my LG-VM670 using Android Central Forums

[droiddekka]

excellent ROM...i'm still using the 2-29-12 build because the builds after that had the obnoxious blue clock in the status bar that you cant get rid of.


all in all good work..although i do need to say that the name you chose for it is very unfortunate. you might as well have called it the "BUTT CHEEKS ROM"

thank you, that is all.

[Schlidel]

Remember the first brcm...c code I linked? I had checked only a small part of it. That new code was actually passing the kernel driver's API some different parameters than the original. Instead of using the new one, I went back to the original and patched it with useful part of the new version.

Mrg666 are there any other possibilities for differences leaking through, causing audio problems?

I swear I notice a slight persistent stuttering even though the audio quality is vastly improved and usable vs. first iteration fix. It's a stuttering I've never heard before and I consistently hear it with the fix applied vs. not. (most noticeable during ringing)

I've flashed clean rom, made test calls and notice only normal occasional audio glitches probably from cell signal quality. I apply the fix and notice a distinctly different slight stuttering sound. Reversible by reflashing rom without applying fix. (I went through several cycles of that)

Of course, placebo and egg on my face is a possibility since its so slight a difference. I'm about to do a side by side with both our OVs connected to the head unit, tomorrow.

Anyway, it is definitely usable I'd just hate to see people have slightly degraded phone audio for the sake of our unique bt addresses (if I'm not imagining it, since I'm listening to it so "hard").

Sent from my LG-VM670 using Android Central Forums

[tdm]

Update-
I turned on bluetooth on the donor phone, and the bluetooth settings screen updated immediately. I checked the about phone screen again, and the bluetooth mac address was filled in. Turned bluetooth off, and the about phone screen again read Unknown. Turned bluetooth back on, and it read the same mac address again. Rebooted, and same behavior, same mac address.

So stock is not reading at init or boot, but from the module at each activation.
We need to discover the api request.

It is likely done in /system/bin/btld.

Note this comment in init.thunderc.rc:

# Make sure we startup btld before bluetoothd

And here are some strings out of the btld binary:

Setting local bd addr to %02X:%02X:%02X:%02X:%02X:%02X
  bd_addr:%02x-%02x-%02x-%02x-%02x-%02x
local bdaddr %02x:%02x:%02x:%02x:%02x:%02x

Also note there are a few other interesting strings in btld.

Here's one:

/data/data/com.broadcom.bt.app.system/0.vcf

Hmm, what's in that file?

BEGIN:VCARD
VERSION:2.1
N;CHARSET=UTF-8:My Number
FN;CHARSET=UTF-8:My Number
TEL;CELL:206xxxxxxx
END:VCARD

It appears that btld is writing a vcard with the device's phone number. I would be interested in finding out why, and how it got that information...