[ROM+Kernel] Inferior Human Organs unofficial CM7.1

[EarthnFire78]

Yeah I was just thanking about that, would it be possible to have script run at install that sets the Mac, that way the script does not have to be installed?

Sent from my LG-VM670 using Android Central Forums

 

[tdm]

Now that we can change the BT MAC address, the next problem is again the same. If I set a MAC number in build.prop and release the ROM, all of the phones will have the same value again. The user can change this now but it is not an elegant solution. I am looking into giving each phone a different MAC address and keep it persistent between the ROM updates. Well, I can't help with a clean wipe though

How does the vendor ROM get its mac?

 

[Schlidel]

@mrg666: I have to give it to you, that simply worked first try after updating brcm_patchram_plus and my build.prop. Bingo, just like that

Even without an Academy Award for Most Elegance in Bluetooth MAC Randomizing, this would already be a GREAT solution for me, just as it is. Having to do this when I update ROM is still nothing, considering that my wife I can both use our car now

Thanks a lot, man. Again!

Have you tried making a phone call yet? I can't hear any call audio. Pandora works though.

Also, when I press the voice dial on my cars head unit I get a terrible sound instead of "Please say a command".

Dunno, what's going on. Is it just me I hope?

Edit: Tried making a call again and I get terrible sounds like the voice command button gave. If no one else is getting this I'll just reflash.

Sent from my LG-VM670 using Android Central Forums

 

[mrg666]

Have you tried making a phone call yet? I can't hear any call audio. Pandora works though.

Also, when I press the voice dial on my cars head unit I get a terrible sound instead of "Please say a command".

Dunno, what's going on. Is it just me I hope?

Edit: Tried making a call again and I get terrible sounds like the voice command button gave. If no one else is getting this I'll just reflash.

Sent from my LG-VM670 using Android Central Forums

I just tried with a bluetooth headphone. Sound is crystal clear. We only set the MAC number without changing anything else.

How does the vendor ROM get its mac?

I am not sure. They probably get the first part (first three ?) and they assign the rest. I said first three because the phone only knows the first three. The followings are just zero if we don't set them.

 

[Dannemand]

Have you tried making a phone call yet? I can't hear any call audio. Pandora works though.

Also, when I press the voice dial on my cars head unit I get a terrible sound instead of "Please say a command".

Dunno, what's going on. Is it just me I hope?

Edit: Tried making a call again and I get terrible sounds like the voice command button gave. If no one else is getting this I'll just reflash.

I just tried making a phone call, no problems there. Haven't actually tried the car yet, it will only be tomorrow. You may have gotten a bad download of that broadcom file -- or maybe it didn't transfer properly to your phone.

That said, it was bad form of me (as tester) to declare everything dandy, without testing other tasks that might be affected by the updated broadcom file. I'll test a bit more thoroughly tomorrow. Only tomorrow night, though, very busy day.

 

[Schlidel]

Ok, well if its good for you guys its just something on my end.

Ill get it sorted.

Sent from my LG-VM670 using Android Central Forums

 

[mrg666]

Yeah I was just thanking about that, would it be possible to have script run at install that sets the Mac, that way the script does not have to be installed?

Sent from my LG-VM670 using Android Central Forums

This is a very good idea.

 

[tdm]

I just tried with a bluetooth headphone. Sound is crystal clear. We only set the MAC number without changing anything else.



I am not sure. They probably get the first part (first three ?) and they assign the rest. I said first three because the phone only knows the first three. The followings are just zero if we don't set them.

Macs are not just assigned at random, they are retrieved from somewhere. We just need to find out how and where.

 

[mrg666]

Macs are not just assigned at random, they are retrieved from somewhere. We just need to find out how and where.

I agree. They are generally set in the firmware of the device. However, Broadcom's own code is below. It intends to read the address from a file (ro.bt.bdaddr_path) in the file system.

#ifdef ANDROID
void
read_default_bdaddr()
{
        int sz;
        int fd;

        char path[PROPERTY_VALUE_MAX];

        char bdaddr[18];
        int len = 17;
        memset(bdaddr, 0, (len + 1) * sizeof(char));

        property_get("ro.bt.bdaddr_path", path, "");
        if (path[0] == 0)
                return;

        fd = open(path, O_RDONLY);
        if (fd < 0) {
                fprintf(stderr, "open(%s) failed: %s (%d)", path, strerror(errno),
                                errno);
                return;
        }

        sz = read(fd, bdaddr, len);
        if (sz < 0) {
                fprintf(stderr, "read(%s) failed: %s (%d)", path, strerror(errno),
                                errno);
                close(fd);
                return;
        } else if (sz != len) {
                fprintf(stderr, "read(%s) unexpected size %d", path, sz);
                close(fd);
                return;
        }

        if (debug) {
                printf("Read default bdaddr of %s\n", bdaddr);
        }

        parse_bdaddr(bdaddr);
}
#endif

 

[Dannemand]

Macs are not just assigned at random, they are retrieved from somewhere. We just need to find out how and where.

That's what I keep thinking: if stock kernel can read the hardware MAC from somewhere and feed it to stock ROM, you'd think IHO kernel (which is based on stock kernel) should be able to the same with IHO ROM.

But still, even if we have to set these addresses manually, it's still a huge leap forward.

 

[Schlidel]

Ok, so I reflashed and applied the fix again no problem. This time I just left the line with the XX:XX:XX 's in instead of making something up.(accidentally).

I got a new address as wished anyway. Or was that the way intended?

However, phone calls were still horribly garbled. Pandora sounded beautiful. A2DP vs some other protocol?

Anyway, I was able to fix the problem by removing the fix.

The fix must be doing something other than change the address, I suppose.

Sent from my LG-VM670 using Android Central Forums

 

[Dannemand]

@Schlidel: I used my hardware MAC in build.prop (I saved it when I was testing BT on stock recently). It's completely different from the IHO standard addr (B0:89:91:21:F4:CB).

I'll test more thoroughly tomorrow night with different BT devices.

 

[mrg666]

Ok, so I reflashed and applied the fix again no problem. This time I just left the line with the XX:XX:XX 's in instead of making something up.(accidentally).

I got a new address as wished anyway. Or was that the way intended?

However, phone calls were still horribly garbled. Pandora sounded beautiful. A2DP vs some other protocol?

Anyway, I was able to fix the problem by removing the fix.

The fix must be doing something other than change the address, I suppose.

Sent from my LG-VM670 using Android Central Forums

No colons or X's. The string must be 12 character long and each character is from 0 to F. See the example here

 

[Dannemand]

@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!

 

[mrg666]

@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!

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.

 

[JerryScript]

FYI- on the donor phone I have, running the VM Security Update and CWM-Green recovery, the BT address is unavailable.

 

[Schlidel]

No colons or X's. The string must be 12 character long and each character is from 0 to F. See the example here

I've succesfully changed my Bluetooth address three times as different ones, but each time phone call audio is terrible but Pandora is fine.

As soon as I remove the fix it's fine.

Just a warning before you push this out. Maybe it something I'm doing, I dunno.

I last did a clean install of your latest and greatest rom, applied the fix, tried phone call, sounds garbled, tried Pandora, sounds fine, removed fix, rebooted and all was good again as far as bt audio quality.

Only voice calls and voice commands are garbled, a2dp is fine.

I don't understand what is happening if only MAC is changing.

Sent from my LG-VM670 using Android Central Forums

 

[mrg666]

I will test it in the car tomorrow as well. Thanks for the feedback.

Edit: Also, I think I found the reason for your trouble. I will test it out and put a new binary of brcm_patchram_plus. I have removed the current one for now.

 

[HurrrDurrrDURP]

I've succesfully changed my Bluetooth address three times as different ones, but each time phone call audio is terrible but Pandora is fine.

As soon as I remove the fix it's fine.

Just a warning before you push this out. Maybe it something I'm doing, I dunno.

I last did a clean install of your latest and greatest rom, applied the fix, tried phone call, sounds garbled, tried Pandora, sounds fine, removed fix, rebooted and all was good again as far as bt audio quality.

Only voice calls and voice commands are garbled, a2dp is fine.

I don't understand what is happening if only MAC is changing.

Sent from my LG-VM670 using Android Central Forums

Is it possible the radio needs a specific MAC address before it can enable a clear connection? Maybe the radio is only using bluetooth 1.0 with an unidentified MAC address?

New at system development, and reverse engineering. Be nice? :3

 

[JerryScript]

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.