Related
This guide is based heavily on the one found here: http://i-miss-erin.blogspot.com/2009/09/connect-bluetooth-keyboard-in-android.html
In fact, all information was gleaned from Erin's blog (super props to Erin). This guide is just slightly simplified, with a flashable zip instead of a few ADB steps/
Step 1.) Download the MIUI_Bluetooth_HID.zip from the Download page
Step 2.) Turn Bluetooth ON from Setting UI and click 'Scan for devices'
Step 3.) Select your bluetooth keyboard and pair it.
Step 4.) Under your keyboard android will state "Paired but not connected"
Step 5.) Open up a command prompt/terminal. I am working on a script to automate this part, but for now, you need to use ADB).
Note: Some of the following commands will output text.
adb shell
hcitool scan
(All bluetooth devices in range will be listed here. Look for your bluetooth keyboard, and copy down it's MAC Address)
hidd --connect xx:xx:xx:xx:xx:xx
(Replace xx:xx:xx:xx:xx:xx with your bluetooth keyboard's MAC Address)
hcitool con
(This command shows all connected HID devices, and should list the MAC Address of your bluetooth keyboard)
And that should be it - try typing and see if it works.
If anyone knows how to do the following in a bash script, I'd be grateful if you could tell me.
- Search for a text string in a text file, and replace it with a different text string.
The idea here:
- Script1 runs the scan
- The user copies down the keyboard's MAC Address
- The user enters the MAC Address and it is stored as a variable (is it possible for this to happen automatically?)
- The Script1 then duplicates a second script file called Script2
- The Script1 replaces a preset string (eg xx:xx:xx:xx:xx:xx) inside Script2 with the correct MAC Address of the bluetooth keyboard.
- Script1 runs Script2
- Script2 completes the HID control command
anyway, Thank Erin if it works for you - it worked for me.
Josh
Sense Integration
Can someone PLEASE integrate this into a Sense ROM? IE: Currently using PAYS 2.2...
I tried forcing the files in to /system/xbin but I get the following:
# hcitool scan
Device is not available: No such device
I just got an Rii mini BT Keyboard because it said it was Android compatible, but the drivers won't validate... apparently there's a licensing issue with the OEM or something (found this info on a Google search).
Can someone help?
bdusmc said:
Can someone PLEASE integrate this into a Sense ROM? IE: Currently using PAYS 2.2...
I tried forcing the files in to /system/xbin but I get the following:
# hcitool scan
Device is not available: No such device
I just got an Rii mini BT Keyboard because it said it was Android compatible, but the drivers won't validate... apparently there's a licensing issue with the OEM or something (found this info on a Google search).
Can someone help?
Click to expand...
Click to collapse
Not possible.
Sent from my HTC Desire using XDA App
hi
hi
can u please help me to connect desire hd to rii mini blue tooth keyboard
it is detected but not pairing. Please help me
Hate to bump an old thread like this, but I've been trying to get this type of support on my phone and keep getting pointed to the Desire thread.
On that note, on the Download page the file we are told to download (MIUI_Bluetooth_HID.zip) isn't there. Any idea where it went?
Thanks!
any progress on this dude? i mean automating the connections?
I know this is a thread about HTC Desire, and I beg your apologies in advance for the intrusion, but...this solution is expected to work also in a Motorola Defy, or it will not work?
(just wondering if can be applies in other phones too...)
I hope all this is just a little bit interesting for some developers because I can't do any further investigations on ANDROID because my device is broken. At the moment it's on the way and I hope I will get a change of my broken HD2. I have summarized some more or less insteresting facts and I hope someone of you will think about all this informations and can work with them.
First at all: I'm not a developer but I have done some search on ANDROID and logged and logged and logged it again. All this is just a collection of facts and results of compare log files.
When you disassemble some Files within Android, you will see that something will not work because it can't. Let me start with the init.rc what is missing or might be wrong:
1. MISSING FOR BLUETOOTH:
Code:
# create mountpoints
mkdir /mnt_data/download 0777 root system
2. WRONG?
Code:
chmod 0666 /dev/ttyHS1
chown root radio /proc/cmdline
chmod 666 /proc/cmdline
There is no ttyHS1 device within the ANDROID. Can't find it.
3. NOT SURE
rfkill is seems not working. Recommendation on the website:
http://www.gitorious.org/openaos-te...5f360fec4c21c1e06d145a5fe?diffmode=sidebyside
Code:
chmod 0666 /sys/devices/platform/wifi_bt/bt_enable 0
write /sys/devices/platform/wifi_bt/bt_enable 1
but based on ANDROID Developer FAQ it should be:
Code:
chmod 0666 /sys/modules/board_[platform]/parameters/bluetooth_power_on
write /sys/modules/board_[platform]/parameters/bluetooth_power_on 1
and this MUST also done after the change:
Code:
on property:persist.service.bluetoothd.enable=0
write /sys/modules/board_htcleo/parameters/bluetooth_power_on 0
...depend of the settings it also could be:
Code:
write /sys/devices/platform/wifi_bt/bt_enable 0
on property:persist.service.bluetoothd.enable=1
write /sys/modules/board_htcleo/parameters/bluetooth_power_on 1
...depend of the settings it also could be:
Code:
write /sys/devices/platform/wifi_bt/bt_enable 1
Also interesting is the command write which is used a lot of times by the init.rc. I don't know where this command is located. But if you open a SHELL on Android and try to "write" something you will see that this command is not available. Can someone explain how this will work when this command is not available????
4. WRONG!
Code:
chmod 666 /dev/uinput
chmod 666 /etc/bluez/audio.conf
chmod 666 /etc/bluez/hcid.conf
chmod 666 /etc/bluez/input.conf
On the one hand this path is not existing and on the second hand the hcid.conf is also not existing. If you take a look only within /etc you will see that /etc/bluetooth is only existing.
5. BT INITIALIZATION
Code:
service hciattach /system/bin/brcm_patchram_plus --enable_hci –enable_lpm --baudrate 3000000 --patchram /etc/firmware/bcm4329.hcd /dev/ttyHS0
user bluetooth
group bluetooth net_bt_admin
disabled
This is also not working at all. If you try to run this command via the shell nothing will happens. And if you need to load the firmware into the device you need also setup this device by nvram.txt which you can see within the bluetooth.c file. The nvram.txt is important to get a valid MAC Address from the hardware. If you take a look into the source code of the BCM4329 you will see additional informations about this.
The second problem is the value of 3000000. This is to small. If you want to work with head set than a value of 4000000 is minimum required. From my point of view this initialization should be:
Code:
service hciattach /system/bin/logwrapper /system/bin/hciattach -s 57600 /dev/ttyHS0 any 4000000 flow
The value 57600 is the minimum value for initialize bluetooth and it could be that this value will downsize the standby drain. Not sure, just an idea.
Why? Lets take a look into the main.conf or hcid.conf:
Code:
# What value should be assumed for the adapter Powered property when
# SetProperty(Powered, ...) hasn't been called yet. Defaults to true
InitiallyPowered = true
# Remember the previously stored Powered state when initializing adapters
RememberPowered = true
This was the reason why I think the initialization speed "...-s 57000 /dev..." should be lowerd down which might also solve the battery drain issue. Again, not sure - just an idea.
Btw, if you open the ADB shell and try hciconfig, hciattach or hcitools non of this are working because there is no Bluetooth Adapter even if you have BT enabled. This tools are requried for BT analyse, test and command options. You can call each of the files within the Shell but whatever you try to do you it will fail because BT is not enabled. Try to run rfkill which could initiate a reset on the BT device. If you try to rfkill ttyHS0 which is the BT adapter on HD2 device this will not work. From my point of view all this problems are not only related to the kernel.
6. TAKE A LOOK INTO THE init.htcleo.rc
Code:
# Make sure we startup btld before hcid
# Set target address to emulator host loopback IF
# Limit baudrate to 460800 to ensure reliable uart operation
service btld /system/bin/logwrapper /system/bin/btld -hwtun 10.0.2.2 -hb 460800 3000000 -lpm 1
# service btld /system/bin/logwrapper /system/bin/btld -lpm 1 -hb 3000000
Not sure what will run first. The init.rc or the init.htcleo.rc. If the init.rc will run first this could be also a problem. Btw, the first value is 460800. From my point of view this is too much for initialization.
7. WiFi INITIALIZATION
Just an example but if you do a Google search for "BCM4329 nvram.txt" you will get more than 3 links. Let me show here an example:
http://android-wifi-tether.googlecode.com/svn-history/r465/trunk/res/raw/tether_edify
Search for Value 4329 and you will see SAMSUNG Device bla, bla – don't know from top of my head:
Code:
!file_exists("/sdcard/android.tether/bcm4329.bin") && ( module_loaded("dhd") || log(insmod("/lib/modules/dhd.ko", "firmware_path=/system/etc/wifi/bcm4329_mfg.bin nvram_path=/system/etc/wifi/nvram_mfg.txt"), "Loading dhd.ko module<br>(bcm4329_mfg.bin from /system/etc/wifi/)"); );
Hmm... That was the reason why I grabbed the SAMSUNG i9000 from a friend of me and double checked the device. If you take a look into the /etc/wifi you will see the nvram.txt. I'm not sure how this will be loaded into the device but the i9000 has the same BCM4329 Chipset.
Now let us take a look into the wifi.c for QUALCOMM devices which is also valid for the HD2:
http://gitorious.org/linux-on-qualc...f8dffe668c0448/libhardware_legacy/wifi/wifi.c
Code:
Line 61: Take a look. Nothing of this is existing on the HD2
Line 71: there is no wlan.ko on the HD2
But now, where the hell the MAC Address is stored for the WIFI Adapter? Just take a look at this location:
Code:
sys/module/board_htcleo/parameters/bdaddress
or use this:
Code:
/system/sysroot/module/board_htcleo/parameters/bdaddress
If you check this file you will see there your current MAC Address of the WIFI device. The stupid MAC for the BT device seems not stored on the device. And this is the point where I guess to need the fu***ing nvram.txt.
I have done a search for some BCM files and found something interesting which is attached as "Broadcom Files.7z." There are some (!) more or less firmware files within (?) and also the famous nvram.txt
For additional informations about WiFi and more just open the wifi_suplicant within the /system/bin directory with a simple text editor and browse down to the end. There you will see also a lot of interesting settings for the WiFi environment.
8. W.t.F. IS THIS STUPID NVRAM.TXT?
Download attached Broadcom.7z and check the txt file within. If you open the file you will see the nearly same content as within the
Code:
/etc/calibration
file.
But this file you can ignore on your HD2 device. Delete it, rename it – do whatever you want and you will see no changes on the device. The more interesting thing is within
Code:
/sys/calibration
Huhhhh...! The same file but less values. But where does it come from??? Currently I don't know.
It seems that the nvram.txt is as same as like a BIOS for the device. The BCM4329 is a BT AND WiFi Chip within one CHIP. It might be wrong but I guess this is the easy explanation for this.
And because of this the thing can't work. First it needs to load the BIOS (nvram.txt) and then it needs the OS for it (BCM4329 Firmware).
Okay here is something by reading and following your examples:
sys/module/board_htcleo/parameters/bdaddress
That lines exists in the current NAND Android roms, but this line:
/system/sysroot/module/board_htcleo/parameters/bdaddress
doesnt exist, not in Rafs rom or in imilka's 0.1 GB sense rom.
But here is my key interest: "bdaddress" is where the BLUETOOTH MAC Address is!
Another interesting thing, in imilka's 0.1 GB Sense rom, I can change this to whatever I want and it Sticks till I reboot, but in Rafs it does not.
Key Question, How do we make this file KEEP the changes we make to it??? I know its a dirty fix but none the less its a FIX!! So anyone got a clue?!??
First of all there is a WRONG that is big like an house
the init.rc "syntax" is not shell syntax.
so as example, command "write" will not work in shell... but only in init.rc
I see also a lot of confusions about stock froyo/gingerbread stuff and sense stuff.
Example: Sense uses it's own stuff for BT so a clean init.rc for sense is really different from the one for a non-sense build.
Also some stuff/commands needs to be changed/replaced to have them working with our hd2 kernel.
I have no time now but really this posts is about 30 different things that cannot be explained all togheter.
My suggestion is to google for "android init syntax" and start from there understanding all the android boot process and the android init syntax.
About the wifi mac address.
The wifi mac address is "read" from the libhardware_legacy.so
normmaly this lib reads the mac address in /etc/calibration
this file is a "kernel" file so you are not able to change it.
You can use a modified libhardware_legacy.so that reads the mac address in /system/etc/calibration so you can change it, as I did on my builds where you can change the wifi mac address.
Unfortunately the modified libs causes other issues like gps not working.
---------------------------------------------------------------------------
About the problem that you cannot write permanetly the changes on stuff inside the folders
/
/etc
/proc
/sys
and so on.. this is because those folders are the "kernel" that normally is read-only
you can make it write enabled but it's not a safe way to proceed...
so is there a chance to fix the issue with the bluetooth mac?!
would be important for me
(can't use my parrot car kit with my wifes hd2 because of the same mac adress )
rafpigna said:
First of all there is a WRONG that is big like an house
the init.rc "syntax" is not shell syntax.
so as example, command "write" will not work in shell... but only in init.rc
I see also a lot of confusions about stock froyo/gingerbread stuff and sense stuff.
Example: Sense uses it's own stuff for BT so a clean init.rc for sense is really different from the one for a non-sense build.
Also some stuff/commands needs to be changed/replaced to have them working with our hd2 kernel.
I have no time now but really this posts is about 30 different things that cannot be explained all togheter.
My suggestion is to google for "android init syntax" and start from there understanding all the android boot process and the android init syntax.
Click to expand...
Click to collapse
Thanks mate! The problem is that I have no clue how to do it but I hope someone outside who has more experience with all this knows what to do.
Btw, I have had also tried to do a simple test with this "write" command by fill a line within /etc/test and also /proc/test which fails. Usually I added some lines into the init.rc to see if this will work.
But I'm not sure if I have had something wrong.
rafpigna said:
About the wifi mac address.
The wifi mac address is "read" from the libhardware_legacy.so
normmaly this lib reads the mac address in /etc/calibration
Click to expand...
Click to collapse
Sorry, but this is not true. Check this:
http://developer.android.com/reference/android/net/wifi/WifiInfo.html
If you check this from Android SDK you will see that the wpa_supplicant is responsible for this. And this would be O.K. if you also check the BCM4329 source code.
First the CHIPSET will be initiated and prepared by the firmware and the nvram.txt and after that the wpa_supplicant do the rest.
How this exactly will work - sorry, too less coding knowledge
A good thing is it to compare the MAC & BT issue with the i9000 devices and Sony X10. The Sony X10 has the same QUALCOM chipset as the HD2.
Here are the files from the original Desire HD 1.8x.
The initrd.zip contains is the original file and the initrd~.7z is the extracted who is interested to read and compare.
see this http://gitorious.org/linux-on-wince...mmit/ce69804632e64b397758c1c9835f06efd0c8cb54
in file arch/arm/mach-msm/board-htcleo.c i see from markinus some changes to file bdaddress.but it is not in the main git tree we use for hd2 kernel
maybe someone kernel developer can see it and make a kernel for testing;
clio94 said:
see this http://gitorious.org/linux-on-wince...mmit/ce69804632e64b397758c1c9835f06efd0c8cb54
in file arch/arm/mach-msm/board-htcleo.c i see from markinus some changes to file bdaddress.but it is not in the main git tree we use for hd2 kernel
maybe someone kernel developer can see it and make a kernel for testing;
Click to expand...
Click to collapse
Looks good, but this is not valid for HD2. This is HTC Tattoo. If you check this code you will see "akm8973".
Damn!
http://nagaraj-embedded.blogspot.com/2011/02/guide-on-adding-wifi-drivers-on-android.html
and
http://www.jetdroid.org/forum/viewtopic.php?f=78&t=456&start=20#p4502
Can someone double check this???? From my point of view this looks quite good...
MrT69 said:
Sorry, but this is not true. Check this:
http://developer.android.com/reference/android/net/wifi/WifiInfo.html
If you check this from Android SDK you will see that the wpa_supplicant is responsible for this. And this would be O.K. if you also check the BCM4329 source code.
First the CHIPSET will be initiated and prepared by the firmware and the nvram.txt and after that the wpa_supplicant do the rest.
How this exactly will work - sorry, too less coding knowledge
A good thing is it to compare the MAC & BT issue with the i9000 devices and Sony X10. The Sony X10 has the same QUALCOM chipset as the HD2.
Click to expand...
Click to collapse
I'm wrong?
Sorry to say, I'm not an andorid guru but maybe I have a little bit more knoledge and trust me in our case, at least with our builds, the mac address is read from the calibration file.
So how is possible that in my builds you can change the wifi mac?
I just take yor desired wifi mac, write it in the /system/etc/calibration file and replace the libhardware_legacy.so that will read from that instead of /etc/calibration
MrT69 said:
Thanks mate! The problem is that I have no clue how to do it but I hope someone outside who has more experience with all this knows what to do.
Btw, I have had also tried to do a simple test with this "write" command by fill a line within /etc/test and also /proc/test which fails. Usually I added some lines into the init.rc to see if this will work.
But I'm not sure if I have had something wrong.
Click to expand...
Click to collapse
Already said... init.rc syntax is not shell syntax!!!
Anyway.. I still miss the purpose of this thread....
Just the first two google search links appearing with a simple "android init.rc" search
http://www.androidenea.com/2009/08/init-process-and-initrc.html
http://elinux.org/Android_Booting
Read that and something will be clearer.
rafpigna said:
I'm wrong?
Sorry to say, I'm not an andorid guru but maybe I have a little bit more knoledge and trust me in our case, at least with our builds, the mac address is read from the calibration file.
Click to expand...
Click to collapse
It might be that I have had something missunterstand but I only want to say by default (!) the MAC Address is not read from the calibration file by ANDROID. Of cause I have had tested your solution and it's working.
So how is possible that in my builds you can change the wifi mac?
I just take yor desired wifi mac, write it in the /system/etc/calibration file and replace the libhardware_legacy.so that will read from that instead of /etc/calibration
Click to expand...
Click to collapse
I know that the MAC Address could be changed within this way. I hope you don't understand it within the wrong way but from my point of view this is only a patch solution. Because of the fact that the BT & WiFi Chip is ONE (!) chip within HD2 there must be an other solution to read and get the MAC address for WiFi AND BT.
Already said... init.rc syntax is not shell syntax!!!
Click to expand...
Click to collapse
I only was asking why and where it was not working. In the mentime I know it because of your feedback. But I have add some lines into the init.rc and the files and changes was not written to the device. That was the reason why I was asking.
Anyway.. I still miss the purpose of this thread....
Click to expand...
Click to collapse
Hope to find some people who will help to fix all this issues and on the second hand I hope to find a solution for the BT and WiFi MAC to get it from the device.
It is proper time to make an open discussion about the 2.2.1 rom and more tweaks closer to HD2 reveal in the community.
MrT69 said:
I know that the MAC Address could be changed within this way. I hope you don't understand it within the wrong way but from my point of view this is only a patch solution. Because of the fact that the BT & WiFi Chip is ONE (!) chip within HD2 there must be an other solution to read and get the MAC address for WiFi AND BT.
Click to expand...
Click to collapse
maybe this is wrong but it is extremely good that in sense roms,you can change at any time wifi mac address.in my city municipality have free wifi hotspot but after sometime reads your wifi mac address and cut the connection for a time.so with dynamic wifi address i can be almost all time everywhere online and this saves me from a slow (because i live in a small greek city and 3g connection is not everywhere) data edge connection.
June 1:
Release tytung_HWA_r2.5 which supports the real WiFi and Bluetooth MAC addresses (i.e. the same MAC you see on WinMo) for all MAGLDR, cLK, and WinMo SD users.
(Credits go to Franck78, Rick_1995 and Marc1706)
May 26:
Please visit the Tytung UNIMAC kernel debugging thread for more developments.
May 22:
Bring back the real WiFi MAC address for WinMo users using Clrcad & Haret to boot SD build.
Now WinMo SD users get the real WiFi MAC address (i.e. the same WiFi MAC address you see on WinMo).
NAND (MAGLDR and cLK) and MAGLDR SD boot users get the new unique WiFi MAC address to avoid the collisions.
Download HTCLEO-Kernel_2.6.32-ics_tytung_HWA_r2.4-uniMAC-update.zip
P.S.: r2.4 also fixes the USB Tethering.
May 9:
A new kernel with unique WiFi MAC address patch which solves an old bug: WiFi MAC address collisions.
Full credit to Franck78 for the fix.
With this tytung_HWA_r2.1-uniMAC kernel, WiFi/Bluetooth MAC address is really unique now.
Since the WiFi MAC address changes, you may need to modify the white list (filter) of your wireless router after flashing this kernel.
Download HTCLEO-Kernel_2.6.32-ics_tytung_HWA_r2.1-uniMAC-update.zip
its ok for my
WiFi/Bluetooth MAC address is really unique now.
edit : 2 days test : everything ok
great
thanks ... you always great
rashidkn said:
thanks ... you always great
Click to expand...
Click to collapse
This thread is a development thread.
Please, do only give feedbacks (bug reports etc.) and stay on-topic. If you appreciate the developers work, use the thanks button.
YZ.
Wifi works not on CyanogenMod 9 Nightly ROMS.....Fix it
everything fine on tytung v2
I have clk 1.5 and this kernel work ok in aokp milestone 5 se. Thank you
Works fine tytung ! great work once again
jamal2367 said:
Wifi works not on CyanogenMod 9 Nightly ROMS.....Fix it
Click to expand...
Click to collapse
Fix it yourself... You should at least insert the ramdisk (initrd.gz) of the CM9 nightly rom since they have changed the name of the wlan interface..
Working well
Keep it up Tytung
tytung said:
A new kernel with unique WiFi MAC address patch which solves an old bug: WiFi MAC address collisions.
Full credit to Franck78 for the fix.
With this tytung_HWA_r2.1-uniMAC kernel, WiFi/Bluetooth MAC address is really unique now.
Since the WiFi MAC address changes, you may need to modify the white list (filter) of your wireless router after flashing this kernel.
Download HTCLEO-Kernel_2.6.32-ics_tytung_HWA_r2.1-uniMAC-update.zip
Please help test it.
If this kernel doesn't cause any problem, I will include this patch into next kernel release.
Click to expand...
Click to collapse
Thanks Tytung. From the little I understand of code, this does not use the phone's original MAC address (the one we get with Windows) but randomizes the sid1, sid2, sid3 parts using the IMEI and the mobile operator's CID. So the MAC address will change if I use a different operator's SIM card, am I correct?
ph03n!x said:
Thanks Tytung. From the little I understand of code, this does not use the phone's original MAC address (the one we get with Windows) but randomizes the sid1, sid2, sid3 parts using the IMEI and the mobile operator's CID. So the MAC address will change if I use a different operator's SIM card, am I correct?
Click to expand...
Click to collapse
Yes, we can only get the phone's original MAC address when using haret.exe on WM.
IMEI is unique in every phone.
Is CID related to the phone or the SIM card?
I need to do some studies.
In GSM, CID usually denotes the Cell ID - a unique ID given to each cellular base station (signal tower, if I may) of a GSM service provider. Needless to say, this value will change based on the service provider and the phone's location. The same location can have more than one CID, as the service provider may have multiple base stations covering densely populated areas to handle the capacity, or on areas that falls in the coverage of more than one base station.
Other codes that are tied to SIM card are MCC and MNC - Mobile Country Code (Unique code to identify the country of the service provider) and Mobile Network Code (Unique code to identify the service provider itself). MCC will not change unless you go to different company and roam on a different network. MNC will change within the country as the same service provider may have more than one MNC (maybe for capacity or because of takeovers/ acquisitions of other service providers), and will change if there is a possibility of roaming within the country.
manual entry?
just curious, is there any way we, as users, could enter our original MAC address manually if we already know what it is, so that we wouldnt have to constantly change our white lists?
and on a side note(pls dont yell at me), can our phone numbers be entered into sys info manually also to be able to use apps that try to pull that info but cant find it, such as PTT apps?
alienclone said:
just curious, is there any way we, as users, could enter our original MAC address manually if we already know what it is, so that we wouldnt have to constantly change our white lists?
and on a side note(pls dont yell at me), can our phone numbers be entered into sys info manually also to be able to use apps that try to pull that info but cant find it, such as PTT apps?
Click to expand...
Click to collapse
i guess it would be even possible to include it in the aroma setup (read a config-file on sd or enter it manually). that would be a great option and if nothing is enter the imei+cid calculation should be done.
ph03n!x said:
In GSM, CID usually denotes the Cell ID - a unique ID given to each cellular base station (signal tower, if I may) of a GSM service provider. Needless to say, this value will change based on the service provider and the phone's location. The same location can have more than one CID, as the service provider may have multiple base stations covering densely populated areas to handle the capacity, or on areas that falls in the coverage of more than one base station.
Other codes that are tied to SIM card are MCC and MNC - Mobile Country Code (Unique code to identify the country of the service provider) and Mobile Network Code (Unique code to identify the service provider itself). MCC will not change unless you go to different company and roam on a different network. MNC will change within the country as the same service provider may have more than one MNC (maybe for capacity or because of takeovers/ acquisitions of other service providers), and will change if there is a possibility of roaming within the country.
Click to expand...
Click to collapse
OK. This CID is not what you said.
According to the email that Franck78 sent me when we discussed the new unique MAC address, CID is Customer ID.
http://forum.xda-developers.com/showthread.php?t=1459270
alienclone said:
just curious, is there any way we, as users, could enter our original MAC address manually if we already know what it is, so that we wouldnt have to constantly change our white lists?
and on a side note(pls dont yell at me), can our phone numbers be entered into sys info manually also to be able to use apps that try to pull that info but cant find it, such as PTT apps?
Click to expand...
Click to collapse
You don't need to constantly change the white list because WiFi MAC address will be a fixed value.
AFAIK, some SIM card stores the phone number, and others don't.
That is why someone cannot see the phone number in "About phone" -> "Status" -> "My phone number".
Maybe you could try My Phone Number app to set the correct phone number into your SIM card.
In some sense roms wifi mac address is stored in /system/etc/calibration file so you can put any wifi mac address you want easily.In non sense roms the value is stored in /proc/calibration so we cant edit this file but there is a way to have our original wifi mac address or any wifi mac address we want. it re-directs /proc/calibration file in /system/etc/calibration so we can put our wifi mac address
look here http://forum.xda-developers.com/showthread.php?p=22799467#post22799467 post 38 and 39
i didnt try it in newer kernels but i think it will work because wifi mac in newer kernels it is also stored in /proc/calibration
Edit
It works for tytung kernel r2.1 unimac and ics rom aokp 35 installed via clk 1.5.this time i gave the command cat /proc/calibration > /system/etc/calibration from the rom with a terminal emulator and then i edited /system/etc/calibration and 13modules file instead of 01modules with solid explorer
tytung said:
OK. This CID is not what you said.
According to the email that Franck78 sent me when we discussed the new unique MAC address, CID is Customer ID.
http://forum.xda-developers.com/showthread.php?t=1459270
Click to expand...
Click to collapse
Ok.. so here is what I did. I doubted if the CID is something related to (or is) the IMSI. Hence I used a SIM from a different service provider to see if the MAC changes - it didn't. So looks like the CID is not dependent on the SIM card or the service provider or the current Cellular Base Station . That clears my initial question, and looks like it doesn't expand to Customer ID after all (blind guess, as it has nothing to do with me - the customer )
I then tried to get into cLK (1.5) and see if "fastboot getvar cid" works - it didn't, all I am getting is a blank response. So not sure if CID is actually being looked up and cLK does not have the ability to display it, or not looked up at all. I did not want to try writing a CID in my phone, as I am not sure if that is a part of how cLK/ HD2 works. I dont think fastboot commands work in Magldr (too long since I used it!), so not sure if this can even be tried there.
I remember reading somewhere that HSPL unlocks the CID in our devices - does that mean they do not exist, I dont know. But as long as we have enough Unique MAC addresses there is nothing to bother, I guess
---------- Post added at 12:22 AM ---------- Previous post was at 12:05 AM ----------
clio94 said:
In some sense roms wifi mac address is stored in /system/etc/calibration file so you can put any wifi mac address you want easily.In non sense roms the value is stored in /proc/calibration so we cant edit this file but there is a way to have our original wifi mac address or any wifi mac address we want. it re-directs /proc/calibration file in /system/etc/calibration so we can put our wifi mac address
look here http://forum.xda-developers.com/showthread.php?p=22799467#post22799467 post 38 and 39
i didnt try it in newer kernels but i think it will work because wifi mac in newer kernels it is also stored in /proc/calibration
Edit
It works for tytung kernel r2.1 unimac and ics rom aokp 35 installed via clk 1.5.this time i gave the command cat /proc/calibration > /system/etc/calibration from the rom with a terminal emulator and then i edited /system/etc/calibration and 13modules file instead of 01modules with solid explorer
Click to expand...
Click to collapse
That's awesome! Do you happen to know if there is something similar for Bluetooth MAC too?
Ι searched for it and found out that bt address is stored in /sys/module/board_htcleo/parameters/bdaddr
so i tried in terminal emulator
cat /sys/module/board_htcleo/parameters/bdaddr > /system/etc/bdaddr
then i go to /system/etc and found bdaddr file.I open it and changed to my bt address
Then in /system/etc/init.d/13modules file i add the line
mount -o bind /system/etc/bdaddr /sys/module/board_htcleo/parameters/bdaddr and then save and reboot
and it work
Just to be safe and sure what should i use to flash this kernel?
Sent from my HTC HD2 ICS 4.04 on XDA Premium
Guys please help me to change my device (Redmi 1S) mac address i am unable to change it using Terminal Emulator (busybox installed ) currently using CM12.1 ROM .
You can't change mac address as it is wifi chip integrated.
but you can spoof mac address. google for mac spoofing.
basically spoofing is like a mask which hides your original mac address.
press thanks if I helped.
peace
Have flashed RC 5 onto my Jiayu s3. All seems to be good.
But want to write my IEMI numbers into the phone. My problem is when using SN write tool it asks for MD1_DB and AP_DB files. Apprently they are with my phones firmware. I can't find on my computer or the internet.
Can anyone cast some light on this please.
Ken
Dutchie1608 said:
Have flashed RC 5 onto my Jiayu s3. All seems to be good.
But want to write my IEMI numbers into the phone. My problem is when using SN write tool it asks for MD1_DB and AP_DB files. Apprently they are with my phones firmware. I can't find on my computer or the internet.
Can anyone cast some light on this please.
Ken
Click to expand...
Click to collapse
Ken, each time people explain how to manipulate IMEI some moderator kicks in and closes thread. Once it was argued such is illegal. Of course the law differs from country to country.
Perhaps you were lucky to have a typo so the moderator tools did not spot your request.
Maybe it is not forbidden to PM you instructions. I will do so now and others may do same.