First this is a patch and not a fix for real mac address.
I have added new cmdline parameter 'wifi.mac_address' which enables you to set any mac address of the wifi interface. So to set a different mac address you need to add new parameter to your startup.txt:
Code:
[STRIKE]set cmdline "wifi.mac_address=00:11:22:33:44:55"[/STRIKE]
I have attached zip file with new zImage and wifi modules for testing purposes. Kernel is based on hastarin sources from Mon Oct 18 17:30:15 2010.
Backup your settings before you test the new zimage and modules.
To discover your mac address in windows look in the following thread:
h__p://forum.xda-developers.com/showthread.php?t=587705&highlight=mac+address
UPDATE: I have made a new patch for the same problem (new files attached). New kernel is based on hastarin sources from Tue Oct 26 22:18:43 2010.
Thanks to clio94 for showing me anther way to change mac address.
UPDATE2: Thanks to OSM for sharing his code for changing bluetooth mac address i have made new patch (and zImage for testing). I have added new parameter "bt.mac" for changing the bt mac address and renamed parameter for changing wifi mac address to "wif.mac" (because is simpler and parameter with the same name is used in michyprima r11 kernel). So for changing the mac address of wifi and bt cmdline looks like this:
Code:
set cmdline "bt.mac=00:11:22:33:44:55 wifi.mac=00:12:23:34:45:56"
If you are using desire HD builds and the patch it's not working you can try method described in:
http://forum.xda-developers.com/showpost.php?p=9806811&postcount=17
mdebeljuh said:
First this is a patch and not a fix for real mac address.
I have added new cmdline parameter 'wifi.mac_address' which enables you to set any mac address of the wifi interface. So to set a different mac address you need to add new parameter to your startup.txt:
Code:
set cmdline "wifi.mac_address=00:11:22:33:44:55"
I have attached zip file with new zImage and wifi modules for testing purposes. Kernel is based on hastarin sources from Mon Oct 18 17:30:15 2010.
Backup your settings before you test the new zimage and modules.
To discover your mac address in windows look in the following thread:
h__p://forum.xda-developers.com/showthread.php?t=587705&highlight=mac+address
Click to expand...
Click to collapse
Nice one, I hope they merge this into the master.
Thanks!
Until they get the NAND code working to read the real MAC address this will do nicely. I'll add it to my next kernel.
Virtual Dynamic MAC Address
this is awesome , i love it .
Virtual Dynamic MAC Address , this is exactly what i was looking for
greaaaaaaaaaaaaaaaaaat job
Long time waiting this feature.
Now hastarin r7.7 also add this feature.
Do you know michyprima R11 used "wifi.mac"
now hastarin r7.7 use "wifi.mac_address"
differenent property name.
Simply awsome !!!!! Been waiting for a fix for the mac issue
setting up
thanks very much. it solved a big problem.
Great job
Help
Ho do you patch the 'patch file' within the zip file?
Thank you in advance.
You need to have kernel sources.You copy the patch in to kernel folder and you give
patch -p1 < /path_to_patch/0001-Patch-for-wifi-mac-address-and-bt-mac-address.patch
Thanks. This is now included in my r8 kernel.
In desire hd build works only the first patch with "wifi.mac_address=00:11:22:33:44:55"
Τhe second version for some reason cannot change the wifi mac address.
Good tip
I have spend hours to understand why i could not connect anymore on my wifi supplier and the solution was just there I put my original winmo mac on the command line and it connects. Thanks a lot.
Thanks a lot for this patch, I have been using it in kernels that it is compiled with. I am going to learn to compile my own kernel soon and will be using it
Just a quick note that for some reason this isn't working in the build I'm now using.
I see that it gets executed but the driver doesn't use it:
Code:
<5>[ 0.000000] Kernel command line: rel_path=desire_hd2 nand_boot=0 wifi.mac=00:23:76:AF:B4:7F
<4>[ 0.000000] htcleo_macaddress_setup: cmdline mac config=00:23:76:AF:B4:7F | arch/arm/mach-msm/board-htcleo-wifi-nvs.c
<4>[ 0.000000] htcleo_macaddress_setup parsed macaddr=macaddr=00:23:76:AF:B4:7F
<4>[ 0.000000] | arch/arm/mach-msm/board-htcleo-wifi-nvs.c
<4>[ 0.000000] htcleo_macaddress_setup parsed mac_address= 0:23:76:af:b4:7f | arch/arm/mach-msm/board-htcleo-wifi-nvs.c
<4>[ 130.232330] wlan: eth0: Broadcom Dongle Host Driver mac=00:11:22:33:44:55
I even changed the default in the code (board-htcleo-wifi-nvs) but it's presumably not getting it from there now. :S
I doesn't get this working, have MDJ FroYo HD v.4.4 KERNEL: hastarin r8.5.3
RADIO: 2.15.50.14, how do i get my wifi working?!
UPDATE, replaced the *.ko files and wifi is working like a charm! Thx for fix.
Bartjuh_4 said:
I doesn't get this working, have MDJ FroYo HD v.4.4 KERNEL: hastarin r8.5.3
RADIO: 2.15.50.14, how do i get my wifi working?!
UPDATE, replaced the *.ko files and wifi is working like a charm! Thx for fix.
Click to expand...
Click to collapse
What ko files did you change?
thanks
Desire HD Builds workaround
Hi,
it seems that the Desire HD builds are using /etc/calibration instead of /proc/calibration file to get its params.
It could be that the module is loaded with module param nvram_path = /etc/calibration
in addition each time the wifi device is turned off/on, the calibration file is copied from /system/etc/calibration to /etc/calibration.
In case the MAC address param is fixed in the /system/etc/calibration every thing will work fine.
Possible fixes (as I see it, but not sure yet how to do it):
1. during system init, delete /system/etc/calibration and create a link to /proc/calibration.
1. during system init, edit the /system/etc/calibration and change the MAC address based on the cmdline.
hope this is helpful.
OSM said:
Hi,
it seems that the Desire HD builds are using /etc/calibration instead of /proc/calibration file to get its params.
Click to expand...
Click to collapse
Thanks. I'd hit the button but on my phone atm
That will be very handy. I can modify my init.kernel.sh to also update /etc/calibration from /proc/calibration or the update script to delete the file and create a symlink.
I'll definitely sort something out before releasing my next kernel update.
Sent from my HTC HD2
hastarin said:
Thanks. I'd hit the button but on my phone atm
That will be very handy. I can modify my init.kernel.sh to also update /etc/calibration from /proc/calibration or the update script to delete the file and create a symlink.
I'll definitely sort something out before releasing my next kernel update.
Sent from my HTC HD2
Click to expand...
Click to collapse
I think you should update the /system/etc/calibration, and not the /etc/calibration.
it seems that each time the wifi is enabled, the /system/etc/calibration is copied to the /etc/calibration.
ofcource you can simple copy the /proc/calibration to the /system/etc/calibration
OSM said:
I think you should update the /system/etc/calibration, and not the /etc/calibration.
it seems that each time the wifi is enabled, the /system/etc/calibration is copied to the /etc/calibration.
ofcource you can simple copy the /proc/calibration to the /system/etc/calibration
Click to expand...
Click to collapse
Thanks I've had a quick look and there are various differences between the proc and etc files, so I may start out by just updating the macaddr via the init script.
Related
Hi, guys.
You can see that they are porting Android OS for others device using HaRET. I want that it will be for our devices too.
I read about HaRET and tried run HaRET with haretconsole on my device. But I found out that HaRET don't support our device yet. If you have HaRET source code, open file mach-types.h under folder include, you can see there many supported device but not Iolite or open the page
I sent an email to ask about support but nothing isn't now. If someone know how to do please tell me what i have to do?
Hope that Android OS will be ported for our device in the recent day.
Best regard!
woooow let's hope...
HaRET works on my Iolite. But I' a new user and not allowed to post links.
1u21 said:
HaRET works on my Iolite. But I' a new user and not allowed to post links.
Click to expand...
Click to collapse
How do it work?
Yeah, it run but we can't deploy device with it. For example when you run command watch GPIOS (through haretconsole), nothing will be appear
It works, but not really stable. Sometimes ist freezes and some functions don't work like bluetooth. You can send and receive SMS, make some phone calls and go online via WLAN. I don't know, if UMTS is running.
I'm still waiting for a Mod to unlock my account.
But it uses a huge amount of energy.
1u21 said:
It works, but not really stable. Sometimes ist freezes and some functions don't work like bluetooth. You can send and receive SMS, make some phone calls and go online via WLAN. I don't know, if UMTS is running.
I'm still waiting for a Mod to unlock my account.
But it uses a huge amount of energy.
Click to expand...
Click to collapse
Can you send me link via email [email protected], please?
Thanks in advance.
It could be this - kandroid dot org
No. I'm using not the korean version.
Android 2.0 is running on the Iolite, but too unstable. You can't use is it in anyway.
Did you have try it ?
Yes. It fills the whole 256 data.img with software. But the bigger problem is the necessary of a fast CPU. Everything runs slow and is more unstable. The Tattoo is not a similar phone to the Iolite.
I just found my problem. You should use HaRET version 0.5.1 (newest version is 0.5.2).
But I still can't make Android boot. Some changes in zImage are needed?
Android started with an unmodified zImage on my Iolite. But I have some new problems with Android and no time for solving.
Maybe the CPU is to slow for Android.
Can we have a link for the file?
dancer_69 said:
Can we have a link for the file?
Click to expand...
Click to collapse
Here is all versions of HaRET
http://www.handhelds.org/~koconnor/haret/
Click to expand...
Click to collapse
Sorry, I mean a link for android image, and the parameters of default.txt to be able to boot it with haret.
I already know where to find haret
I need it too, please, can you post the link?
Here is it:
http://www.androidonhtc.com/polaris/install
Well, we still need the contents of the "Default.txt" to boot the android image....
Use the normal default.txt and make some changes. Here is my default.txt
set RAMSIZE 0x07000000
set RAMADDR 0x10000000
set FBDURINGBOOT 0
set MTYPE 1723
set KERNEL zImage3
set initrd initrd.gz
#
# The following kernel parameters are useful
# ppp.username - The username used to connect to the network when dialing #777
# ppp.password - The password used to connect to the network when dialing #777
# msm_sdcc.msmsdcc_fmax - The maximum frequency (in Hz) used by the SD controller
# pm.sleep_mode - The mode used when the phone is off
# 0=Power Collapse Suspend, 1=Power Collapse, 2=Apps Sleep,
# 3=Slow Clock and Wait for Interrupt 4=Wait for Interrupt
# Default is 3, use 0 for best power savings
# board-htcvogue.panel_type - Panel type used to power the panel off and on
# 0=Don't power off the panel (Default)
# 1=Hitachi 2=Topoly 3=Samsung
# mddi_client_vogue.vsync - Use hardware vsync, default is 1 but should be 0 if
# panel_type is 0
#
set cmdline "board-htckaiser.panel_type=2 ppp.nostart=0 pm.sleep_mode=1 mddi.width=240 mddi.height=320 lcd.density=120 no_console_suspend clock-7x00.mddi=0xa51 clock-7x00.ahb_div=2 clock-7x00.slow=1 clock-7x00.voltage=1 "
boot
Click to expand...
Click to collapse
I'm also using the new version of Android, which you can find on the same page. It works better, but you can feel the difference between 400Mhz and 528Mhz.
I have been following the Android scene here pretty regularly but the os I have always really wanted is a full fledged Linux. I heard about, and wanted a N900 because of Maemo but I'm too poor to buy one . I then heard about the Mer project https://wiki.maemo.org/Mer to port Maemo to other devices and saw it booted on the kaiser http://forum.xda-developers.com/showthread.php?t=565480. On page two of that thread it is stated that someone (Mdrobnak) got it up and running pretty well on his Fuze with a couple tweaks to Xorg.conf, the kernel, and to the splash screen (resized to 640x480). I've been working over the past few days on getting it to start on my fuze but haret keeps giving errors about pc_clk_disable. I resized the splash, changed Xorg.conf to be 640x480 and did the rest of the directions on the Kaiser thread, but no luck. I would love to get a port of this going, as being able to use ~95% of Ubuntu packages working on my phone would be awesome. I wasn't quite sure how to patch the kernel; that would be the zImage, right? Any suggestions?
I'm going to be on #mer and #htc-linux irc on freenode quite a bit until we get this working well if anyone wants to discuss things, not that I can contribute much.
Would it be possible to create a rootfs.img file similar to how XDANDROID does it for people too lazy to partition their card or just plain suck like me?
Sounds interesting! Keep us updated!
Oh god! Ill be in 7th heaven if it's going to be done!
I think you can use the zImage of xdandroid, maybe it'll work
I tried the xdandroid zImage but it didn't work. This is really a call for help. I really don't know what I am doing, lol. I'm not even close to being a dev. Try out the steps on the Kaiser thread but use the stable 0.16 distribution as the testing links don't work. See if you can figure anything out.
Maemo on the Raph ? that would be great! maybe we could run it in dual boot with android and abandon WM for ever !
To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)
phhusson said:
To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)
Click to expand...
Click to collapse
Thanks, phh. Will try it when I get home.
that's the old and ugly msm_fb refresh hack.
I will update here once I have xorg working on kovsky and kaiser.
Man, I actually feel like this is getting places. Got Phhusson from XDANDROID and dcordes from the original Android on Diamond thread. Quite the star power.
@dcordes: What needs to be edited to use VGA; just the first screen resolution dimensions in Xorg.conf?
what image are you using?
I'm using the Smartq5 from here: http://wiki.maemo.org/Mer/Releases/0.16. My main problem is with the kernel though I think; haret hangs after about 15 seconds; I'm gonna create a log of it.
On my Raph300 I can login on the terminal using the Q5 image. I was using the latest zimage from gelmsom. But kernel is screaming some stuff a bout a clock not having an ena bit and something about an rpcrouter being blocked. When I try to start X, I get an error loading libpicacces.so.0
I get that same error, but Haret hangs when I get it. Please share what you did: e.g. editing xorg, exact zImage used, what you used to partition, your default.txt, whether you edited the splash screen image etc. I'd like to get a database of sorts of people's configurations. Good to know though. Did you add Phhusson's tip to default.txt?
"To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)"
Yes i added the msm_fb.fix_x=1 to the cmdline. Unfortunatly it is not the solution for this problem. We have got some trouble with the libraries. Maybe something is missing.
LordKiwi said:
Yes i added the msm_fb.fix_x=1 to the cmdline. Unfortunatly it is not the solution for this problem. We have got some trouble with the libraries. Maybe something is missing.
Click to expand...
Click to collapse
Last time I tried it worked automatically (I mean for X video output.) with msm_fb.fix_x=1
Sorry it works. JesusFreak and I extracted the tar file the wrong way.
I should have type tar -pxvf. I forgot the p which is very important.
Now it stops with a different error.
Code:
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
compiled for 1.6.0, module version = 1.1.0
ABI class: X.Org ANSI C Emulation, version 0.4
(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed
Fatal server error:
AddScreen/ScreenInit failed for driver 0
Dang it; I just can't get it to work. I'm the thread starter and I can't do it, lol. Here's what I did:
1. Downloaded 0.16 stable smartq5 rootfs.
2. Extracted the tar to my home folder. (Now that I think of it; I did it with archive manager not the command line, so no -p setting or anything. That could be the problem.)
3. Edited the xorg.conf file to change the resolution to 640x480.
4. Changed the splash screen size to 640x480.
5. Formatted my sd card to ext2 for 1.5 gb and fat32 for .5 gb using command line following these directions for ext2: http://wiki.maemo.org/Mer/Documentation/SmartQ_Installation_for_the_Windows_user and gparted for fat32.
6. I then used the directions on the same pagee as before to copy the file, except using cp instead of mv.
7. I copied haret, a zImage, and the startup.txt that I renamed to default.txt and edited to the fat32 partition.
8. I started Haret.
I attached my default.txt.
The formatting is done correct. You should try to use the tar command line wich you can find on the same page. It should solve the problem of loading the library.
•Type sudo tar -pxzvf *.gz and press return. This will now untar the entire 'rootfs' to the card. (Install Mer).
LordKiwi said:
Sorry it works. JesusFreak and I extracted the tar file the wrong way.
I should have type tar -pxvf. I forgot the p which is very important.
Now it stops with a different error.
Code:
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
compiled for 1.6.0, module version = 1.1.0
ABI class: X.Org ANSI C Emulation, version 0.4
(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed
Fatal server error:
AddScreen/ScreenInit failed for driver 0
Click to expand...
Click to collapse
I'm an idiot....... I saved my startup.txt as startup.doc. That's why X didn't start.
0.17 release
Is possible run the 0.17 realease in raphael more fast than in N810?
kaiser ubuntu port based on zubuntu by Omegamoon for Sharp Zaurus was successfully launched on HTC Nike!
Instructions:
1. download kernel
http://84.23.71.227/kerneloftheday/zImageUbuntu
2. download ubuntu basefiles and rootfs
3. place ubuntu.img, haret, initrd.gz and zImageUbuntu to Storage Card/ubuntu/
4. place this default.txt there too
Code:
set RAMADDR 0x10000000
set MTYPE 1724
set KERNEL zImageUbuntu
set initrd initrd.gz
set cmdline "pm.sleep_mode=1 mddi.width=320 mddi.height=480 lcd.density=160 board-htcnike-keypad.keypadlayout=1 board-htcnike-keypad.sticky_timer_time_ms=350 no_console_suspend"
boot
5. change board-htcnike-keypad.keypadlayout=1 to 0 if you have 20key nike.
6. run haret and press "Run", ubuntu & kernel will be loaded to login prompt, login with username root and no password, you will get root shell.
7. write
Code:
export TSLIB_TSDEVICE=/dev/input/event0
ts_calibrate
and calibrate your screen.
8. write startx and see LXDE running on your nike! you've got real linux box in pocket!
Note, rootfs for ubuntu needs 1GB of free space on your sdcard!
For now, you cannot work with screen, we have some difference from kaiser panel's, i.e. ubuntu gui is completely unusable, this thread were started to find out why.
based on this thread from kaiser forum.
Credits: dzo, Omegamoon, domy007, mblaster and guys from Rhodubuntu thread.
I dont get any response when i try to calibrate screen on niki 200
thats strange, it must work.
I will debug on touchscreen problems, but ubuntu running and that is great, now we have only input-devices problems, and this is more better than nothing.
Sounds great, but wouldn't it be better to try something smaller like puppylinux or Feather linux ?
zubuntu is only we have compiled for ARM and working with our hardware that starts X and tested on other htc's devices.
rzk333 said:
zubuntu is only we have compiled for ARM and working with our hardware that starts X and tested on other htc's devices.
Click to expand...
Click to collapse
Ok thanks for the information, did some reading before and was always wondering why they use ubuntu but this answer set things straight.
Greetz,
Great to see a full linux distro around for htc devices. I will fix the '_' tomorrow... Any other missing characters?
How is the speed of ubuntu? Is it very sluggish or usable?
'=' character maybe, for export line.
zImageUbuntu is updated (your link is still valid).
'=' and '-'are on '*'-button, '_' is Alt-
I have included the msm_fb_refresh and the keypad changes into my auto-updated-kernel, so you should be able to use the fresh kernels from my thread with ubuntu if you want recent updates (zImageUbuntu is not automatically updated).
got some progress,
1) msm refresh thread seems to disable sleep mode in android, thread polls framebuffer many times in second and drains battery.
2) linux logo on bootup must be disabled - logo gets over ts_calibrate's first crosshair point.
2) still trying to make touchscreen and tslib friends - i2c bus debug messages logs saying that touchscreen is connected and recieves data correctly.
found some data:
/dev/input/event0 - htcnike-kbd
/dev/input/event1 - htcnike-ts
but still no data from touchscreen...
rzk333 said:
got some progress,
1) msm refresh thread seems to disable sleep mode in android, thread polls framebuffer many times in second and drains battery.
2) linux logo on bootup must be disabled - logo gets over ts_calibrate's first crosshair point.
2) still trying to make touchscreen and tslib friends - i2c bus debug messages logs saying that touchscreen is connected and recieves data correctly.
found some data:
/dev/input/event0 - htcnike-kbd
/dev/input/event1 - htcnike-ts
but still no data from touchscreen...
Click to expand...
Click to collapse
Disabled msm refresh thread from the android kernels again. The kernel you linked in your first post is now automatically updated with anything new in the repository. Bootlogo is disabled, too. Good luck with tslib, let me know if when you need something else to be hacked into the kernel.
mblaster
I've just test the usb ether function in the zImage from the post
showthread.php?p=6675397
and it works just fine.
(Just when I had managed to make adbd works... but ssh is more reliable)
Thanks gTan64.
wow, that is good, now I can dump system state without hours of keyboard typing
I've managed to get internet by usb (cdc only) thanks to gTan64: just apply the patch from is post ("Debian on the vogue"), you can extract it from the download links.
And the TOUCHSCREEN WORK!!!!!!!
But you need to compile tslib from the tslib git (github.com/kergoth/tslib.git), the one in the rootfs from this post doesn't work.
Will make a more complete post later, I think.
Bye.
Ubuntu always shows me a black screen when I try to startup it!
What can I do make it work?
omg, I knew that something is wrong with tslib in this rootfs!
thanks for r&d, if you will make some packages & mans, I'll add them to first post.
Maybe you can upload some pics ?
But you need to compile tslib from the tslib git
Click to expand...
Click to collapse
I tried to compile - but no luck, autoconf fails to make configure...
I also uploaded debian rootfs and posted links in gTan's Debian on Vogue thread.
nothing happened last month?
Hello, every SD build users,
Savan told me a method about how to get the real WiFi MAC address from the kernel (i.e. the same MAC address you see on WM6.5).
However, we need to get the memory dump of HSPL running WM6.5 and your real MAC address, so Savan can find out the MAC offset and write it to kernel for getting the real WiFi MAC address.
I'm running NAND ROM now and I'm lazy (have no free time) to flash back to WM6.5 just for dumping HSPL and then flash back to MAGLDR later.
Thus, I would like to request helps from you, the SD build users running WM6.5.
If you can help, please use the following steps to dump the HSPL. Thanks.
Backup your original "startup.txt" in Android folder.
Place the following command in "startup.txt".
Code:
pwf hspl.dump 0x0 0x100000
Start HaRET and it will automatically run the above command.
Check if file hspl.dump exists in your SD card.
Send me hspl.dump and your real WiFi MAC address you see on WM6.5.
Reference: http://htc-linux.org/wiki/index.php?title=HaRET_Documentation#HaRET_commands
Update:
We can get the real WiFi MAC address from SPL/HSPL when using SD builds on WM. (Please use r12 kernel if you want to try it.)
However, we cannot get the real WiFi MAC when using MAGLDR and cLK bootloaders.
here you are:
MAC
00-23-76-8e-23-dc
let us know... thank
Marco
Real MAC:
38: E7: D8: 8E: 27: 6D
Thank you very much to marco.palumbi and kajos.
The correct command is 'pwf hspl.dump 0x0 0x100000'.
Hello marco.palumbi and kajos,
Thanks for your help.
Which version of HSPL do you use?
Is it SPL 2.08.HSPL?
I can find 0023768E23DC at 0xFC028 when HEX editing marco.palumbi's hspl.dump. (Nothing at 0x90028.)
But I can find 38E7D88E276D at 0x90028 and 0xFC028 when HEX editing kajos' hspl.dump.
These two memory dumps seem to be different in terms of format.
When I add 0x90028 or 0xFC028 to kernel source code, I still cannot read MAC address from kernel.
Maybe Savan and I miss something.
I'm trying different possible methods.
tytung said:
Hello marco.palumbi and kajos,
Thanks for your help.
Which version of HSPL do you use?
Is it SPL 2.08.HSPL?
Click to expand...
Click to collapse
My Bootloader shows SPL-3.03.0000
I don't use HSPL
R 2.15.50.14
G 15.42.50.11U
D 3.14.04666
is HSPL necessary for this?
Hi tytung,
I have the latest official HTC rom installed on my Italian EU device.
booting the device with vol- pressed I read:
PB81100 HX-BC
SPL-3.03.0000 XE
MicroP(LED) 0x05
MicroP(TOUCH) 0x30
let me know if you need more information
Thanks to both of you.
I'm not sure whether SPL and HSPL have different format.
I changed my HD2 to HSPL 2.08 in order to install MAGLDR and flash NAND ROM.
And the new kernel with real MAC fix doesn't work for me on my NAND ROM.
WiFi MAC = ff:ff:ff:ff:ff:ff and bootloop.
Savan, the kernel developer of HTC Photon (HD Mini, another WM6.5 phone), told me that his real MAC fix may only work with SD build.
...but you've detected the realMAC at 0xFC028.
May be there a different way for implementing this?
Hi!
My MAC: 7C-61-93-33-F1-CF
With Power and Vol- i get:
PB81100 HX-BC
SPL-2.08.HSPL 8G XE
0x50
CotullaHSPL 0x50
hi
I am not expert on the HD2 device but I have some experience with embedded systems.
just to better understand and give some help.
the problem can be splitted in two steps:
1) find from somwhere in the device the assigned MAC addres. this seems to be at memory phisycal address 0xFC028 on kajos and mine device.
2) modify the kernel driver in order to use the address retrived from the prvious step.
tytung, which step is failing in your implementation?
to debug you can try
a) to printk() the phisical addres at 0xFC028 (so you can see it on dmesg)
b) modify the ETH kerrnel driver to use a string passed as kernel command line.
the last could be a easy solution for SD users becouse this way they can put the MAC on startup.txt...
zboq said:
Hi!
My MAC: 7C-61-93-33-F1-CF
With Power and Vol- i get:
PB81100 HX-BC
SPL-2.08.HSPL 8G XE
0x50
CotullaHSPL 0x50
Click to expand...
Click to collapse
Thank you.
I can find 7C619333F1CF at 0x90028 and 0xFC028 when HEX editing your hspl.dump.
marco.palumbi said:
hi
I am not expert on the HD2 device but I have some experience with embedded systems.
just to better understand and give some help.
the problem can be splitted in two steps:
1) find from somwhere in the device the assigned MAC addres. this seems to be at memory phisycal address 0xFC028 on kajos and mine device.
2) modify the kernel driver in order to use the address retrived from the prvious step.
tytung, which step is failing in your implementation?
to debug you can try
a) to printk() the phisical addres at 0xFC028 (so you can see it on dmesg)
b) modify the ETH kerrnel driver to use a string passed as kernel command line.
the last could be a easy solution for SD users becouse this way they can put the MAC on startup.txt...
Click to expand...
Click to collapse
I am not expert on the HD2 device either.
Here is my kernel diff. http://pastebin.com/HeSUAd5Y
What I cannot ensure is values of MSM_SPLHOOD_BASE and id_base.
According to your three spl.dump files, I think id_base = 0xFC028.
I don't know how to determine MSM_SPLHOOD_BASE.
Savan used IOMEM(0xF9500000) in his kernel, but he let me try IOMEM(0xF9200000).
I tried both and had the same result.
dmesg
Code:
<6>[ 3.489532] wifi_nvs_init
<4>[ 3.489562] id1 = 0xffffffff
<4>[ 3.489593] id2 = 0xffffffff
<4>[ 3.489593] id3 = 0xffffffff
<6>[ 3.489624] Device Wifi Mac Address by cardsharing-x: macaddr=ff:ff:ff:ff:ff:ff
I can boot into Android, but it reboots itself later. (I always enable WiFi.)
Update:
Doesn't the original kernel support set cmdline "rel_path=Android wifi.mac=00:11:22:33:44:55" in startup.txt?
kajos said:
...but you've detected the realMAC at 0xFC028.
May be there a different way for implementing this?
Click to expand...
Click to collapse
Maybe the real MAC patch only works for SD build because we get memory dump when running WinMo 6.5.
I tested new kernel on NAND with MAGLDR installed.
And the kernel cannot read SPL or have different address offset.
Here is my r12 beta2 kernel including the above real MAC patch.
You can try it on SD build.
I'm testing your new kernel and all i can say now is that i have my real mac address.
Edit:
I'm getting 60mA on standby so i'm going back to hastarin 8.6
No thanks left today
I'll do it tomorrow
I'm using MccMBoxmaX GS V9
http://forum.xda-developers.com/showthread.php?t=1038694
...and I'm getting no WIFI with r12beta2, but no wifi-error - it only can find no network
Is there a (universal) way, using this AutoMAC?
I can confirm that the MAC works for me too with r12beta2.
I get the correct one.
tytung,
I made some tests.
I am able to read the mac address from android in user space.
from the shell I issue this command:
devmem 0xFC028 64
the result for me is :
0x0000DC238E762300
that is my MAC.
devmem is part of busybox and read (and writes) phisycal memory using the /dev/mem device
can please try what is the results on your device?
regarding "wifi.mac=00:11:22:33:44:55" in startup.txt i think that it is not supported by the kernel itself.
in some android ROM this command line parameter is used by an userspace application somwhere during android boot to change values in /proc/calibration.
can you please point me to your latests kernel sources (the r11)?
i would like to give a look to them.
tytung said:
Maybe the real MAC patch only works for SD build because we get memory dump when running WinMo 6.5.
I tested new kernel on NAND with MAGLDR installed.
And the kernel cannot read SPL or have different address offset.
Here is my r12 beta2 kernel including the above real MAC patch.
You can try it on SD build.
Click to expand...
Click to collapse
Thank tytung for looking after the SD build user we need more stable kernel .. seems now u are the one that really focus on it !
Sent from my HD2 Bliss using XDA App
kajos said:
No thanks left today
I'll do it tomorrow
I'm using MccMBoxmaX GS V9
http://forum.xda-developers.com/showthread.php?t=1038694
...and I'm getting no WIFI with r12beta2, but no wifi-error - it only can find no network
Is there a (universal) way, using this AutoMAC?
Click to expand...
Click to collapse
My kernel needs a new /system/bin/wpa_supplicant.
You can get it from http://nexus-hd2.googlecode.com/files/kernel_tytung_r12_beta1_update.zip
And remember to set the permissions.
Code:
adb shell chown 0:2000 /system/bin/wpa_supplicant
adb shell chmod 755 /system/bin/wpa_supplicant
marco.palumbi said:
I can confirm that the MAC works for me too with r12beta2.
I get the correct one.
tytung,
I made some tests.
I am able to read the mac address from android in user space.
from the shell I issue this command:
devmem 0xFC028 64
the result for me is :
0x0000DC238E762300
that is my MAC.
devmem is part of busybox and read (and writes) phisycal memory using the /dev/mem device
can please try what is the results on your device?
regarding "wifi.mac=00:11:22:33:44:55" in startup.txt i think that it is not supported by the kernel itself.
in some android ROM this command line parameter is used by an userspace application somwhere during android boot to change values in /proc/calibration.
can you please point me to your latests kernel sources (the r11)?
i would like to give a look to them.
Click to expand...
Click to collapse
In r12 beta1:
# devmem 0xFC028 64
devmem 0xFC028 64
0xFFFF7FFFFFFFFFFF
Cotulla said "MAGLDR doesn't replace OSPL/HSPL. It runs in the chain after."
http://forum.xda-developers.com/showthread.php?t=893618
Not sure what he means exactly.
I think the kernel cannot access SPL when using MAGLDR and NAND ROM.
Maybe the memory space is overwritten by MAGLDR after HSPL's task is done.
My r11 kernel info: http://forum.xda-developers.com/showpost.php?p=10429937&postcount=3
Git: http://gitorious.org/~tytung/linux-on-wince-htc/tytungs-hastarins-linux_on_wince_htc
************ UPDATE *****************
update.zip flashable for DSC and DSC PDroid can be found at
openssl 1.0.1e update for DSC/407
*****************************************
Hello,
you may have heard of the badly choosen default ssl ciphers (1) in gingerbread.
Gingerbread devices use outdated encryption algorithms for ssl communication.
That problem effects also gingerbread based roms like 407 or dsc. You can check this by sending
your default browser (or for example nakedbrowser) to a ssl browser test-server (2)
You will get a result like in attachment 1 ciphers_original: We are using the RC4-SHA without perfect forward secrecy. That is problematic cause of the Lucky 13 attack agains this encryption (3)
With some patch in core.jar in our framework (attachment ciphers_reorder.patch) I got DHE-RSA-AES128-SHA which is considered more secure and also supports perfect forward secrecy. (attachment ciphers_pfs)
You can get my core.jar from http://ge.tt/api/1/files/1MKLbUv/0/blob?download. Install it into /system/framework and rebuild your dalvik-cache.
I can't support TLSv1.1 or TLSv1.2 yet, because it would need to recompile a more recent version of libssl.so.
Users of Opera get even DHE-RSA-AES256-SHA in their connection (attachment ciphers_opera) which is considered state-of-the art cryptography. But even than, other android apps will use the badly choosen systems default. So it is a good idea even for opera
users, to update core.jar.
Can please someone confirm my findings, and install core.jar in a 407 or dsc rom and check your browser on (2)
(1) http://op-co.de/blog/posts/android_ssl_downgrade/
(2) https://cc.dcsec.uni-hannover.de/
(3) http://www.isg.rhul.ac.uk/tls/Lucky13.html
@hunderteins,
Thanks for the post.
I am on currently BB407, PCM ROM. Should I do this too?
How is it, which one to choose? Copy your given "core.jar" and paste to "/system/framework" and rebuild your dalvik-cache... OR flash " ciphers_reorder.patch" ?
Ops, sorry I don't know how to handle file.patch... how is it?
Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.
Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM
Razak RK said:
I am on currently BB407, PCM ROM. Should I do this too?
Click to expand...
Click to collapse
don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example
Code:
$ sha1sum /system/framework/core.jar
126bad1df158f1af179d353ecd9e781501a30c73 /system/framework/core.jar
$ md5sum /system/framework/core.jar
1b1c955e837b4413fcbeead0a54cd4b7 /system/framework/core.jar
If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).
If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.
Razak RK said:
Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.
Click to expand...
Click to collapse
Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.
There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'
Good luck,
hunderteins
Thank you Hunderteins!
How about kernel 3.0?
Are you still working on it?
Regards...
hunderteins said:
don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example
Code:
$ sha1sum /system/framework/core.jar
126bad1df158f1af179d353ecd9e781501a30c73 /system/framework/core.jar
$ md5sum /system/framework/core.jar
1b1c955e837b4413fcbeead0a54cd4b7 /system/framework/core.jar
If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).
If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.
Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.
There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'
Good luck,
hunderteins
Click to expand...
Click to collapse
~•~•~•~•~
@hunderteins,
Thank you for your reply.
Here is the checksum I get when I run in Terminal Emulator:-
$ export PATH=/data/local/bin:$PATH
$sha1sum /system/framework/core.jar
1291fcce44f4be036e2209ccb46d3313b65bdfdc /system/framework/core.jar
$md5sum /system/framework/core.jar
19bd48b8eac1bb123a823d039415a344 /system/framework/core.jar
$
So, they are NOT the same.
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.
As for Firefox mobile on my Streak PCM7, I have check the menu and settings, here is NO option as per you mention.
Reason I'm interested to know is to set my Streak at best.
BTW, I'm currently installing and testing all the Streak Custom ROMs in XDA, trying to find a ROM that would probably best for my daily use = Performance+Save Power+Other Features. I probably end up having to learn to mix some ROMs into my own personal use...if I got the time to do it though...
Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM
Razak RK said:
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.
Click to expand...
Click to collapse
basically you need http://code.google.com/p/smali/downloads/list
a good tutorial how the framework is decompiled/updated can be found at
http://forum.xda-developers.com/showthread.php?t=1084850
for how to apply a patch to a source-file consult the manpage of patch
back to topic. I updated core.jar http://ge.tt/api/1/files/7F3UKbv/0/blob?download
Now DHE-RSA-AES256-SHA is included in the list of useable ciphers.
This way in stockbrowser/nakedbrowser the same encrpytion is used as in opera/firefox
look into attached image.
Patch is also included for thoose who find it useful.
Have a nice weekend,
hunderteins
sinan33 said:
How about kernel 3.0?
Are you still working on it?
Click to expand...
Click to collapse
didn't post in that thread, did I?
hunderteins said:
didn't post in that thread, did I?
Click to expand...
Click to collapse
Sorry dude; just eagerness
Confirmed working on Traveller DSC. ROM updates will be coming shortly.
Flashable zip for core.jar patch suitable for DSC and Traveller DSC: MediaFire | Mega
Elliptic curve Diffie–Hellman Key exchange
Hello,
the libssl 1.0.0a on the streak supports elliptic curve Diffie–Hellman key exchange.
With the right server, this speeds up https compared to normal Diffie–Hellman key exchange.
So I had to change the core.jar again to support these cyphers.
With this update I removed the know weak ciphers (export, 56bit etc)
I attached a openssl command for the commandline, to check libssl.so for features. It might
be useful elsewhere.
Have fun,
hunderteins
TLSv1.1 and TLSv1.2 protocol
Hello,
SSLv3/TLSv1.0 are known to be problematic with stream ciphers (the cbc ones) and
as mentioned before, I had to compiled a more recent version of libssl to support
the modern TLS variants.
Attached are the openssl binary and the libssl.so and libcrypto.so of openssl 1.0.1e.
They work on my streak and I get a clean https TLSv1.2 connection to the testserver.
Next step is, to modify core.jar again to get the modern GCM streaming methods
and SHA384 hashes.
Have a nice evening,
hunderteins
GCM streaming, sha384 hashes and server name indication (SNI)
Hello,
as mentioned before, I modified core.jar to match the ciphers from libssl 1.01e. So we get modern ciphers like ECDHE-RSA-AES256-GCM-SHA384 which are considered strong cryptographie. That's even more recent than Android 4.4 KitKat.
But Android Gingerbread has another serious flaw: SNI (server name indication) is not supported with Apache Http Client. Google fixed this *tada* in Honeycomb.
I looked into that problem, but we have to change framework.jar for that, too.
I attached the patches against the backsmalied core.jar and framework.jar. Together with openssl 1.0.1e I get a very beautiful https connection to the testservers (attached screenshots): ECDHE-RSA-AES256-GCM-SHA384 with TLS V1.2 and SNI - in stock android 2.3 browser.
Please confirm my findings. I'll try to make an streakmod compatible update.zip to spread that little security to the masses. If you point me to your core.jar/framework.jar I will consider to integrate your rom into that update.zip.
Have fun,
hunderteins
So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?
BTW, the PDroid version is working perfectly.
Strephon Alkhalikoi said:
So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?
BTW, the PDroid version is working perfectly.
Click to expand...
Click to collapse
Thank you for your feedback.
Update.zip deploys openssl 1.0.1e into /system/lib and /system/bin. It replaces classes.dex inside framework.jar and core.jar when the sha1_check is correct. That is mostly like replacing the files itself, because classes.dex is the main ingredient.
An elegant way would be to baksmali/smali on the device itself, but that didn't work because of memory constraint.
have fun,
hunderteins
openssl 1.0.1g for android 2.3
Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.
Good luck,
hunderteins
[1] http://heartbleed.com/
hunderteins said:
Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.
Good luck,
hunderteins
[1] http://heartbleed.com/
Click to expand...
Click to collapse
I'll make a flashable zip for this shortly as well as release an update to Traveller DSC.
hunderteins said:
you may have heard of the heartbleed bug before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected.
Click to expand...
Click to collapse
I stand corrected. The 1.0.1e version was build with -DOPENSSL_NO_HEARTBEATS. So it was not affected at all. Tested it with the stock browser and naked browser against pacemaker [1].
Anyway, 1.0.1g is not affected, too.
warning: Stock browser on Android 4.1.1 is affected.
[1] https://github.com/Lekensteyn/pacemaker
Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?
Strephon Alkhalikoi said:
Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?
Click to expand...
Click to collapse
I don't think so. As of today in 1.0.1-versions of openssl there are only bugfixes. New, improved features are in 1.0.2. [1]
The changelog between 1.0.1e and 1.0.1g shows detailed bugfixes:
Code:
Changes between 1.0.1f and 1.0.1g [7 Apr 2014]
*) A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64k of memory to a connected client or
server.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <[email protected]> and Bodo Moeller <[email protected]> for
preparing the fix (CVE-2014-0160)
[Adam Langley, Bodo Moeller]
*) Fix for the attack described in the paper "Recovering OpenSSL
ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
by Yuval Yarom and Naomi Benger. Details can be obtained from:
http://eprint.iacr.org/2014/140
Thanks to Yuval Yarom and Naomi Benger for discovering this
flaw and to Yuval Yarom for supplying a fix (CVE-2014-0076)
[Yuval Yarom and Naomi Benger]
*) TLS pad extension: draft-agl-tls-padding-03
Workaround for the "TLS hang bug" (see FAQ and PR#2771): if the
TLS client Hello record length value would otherwise be > 255 and
less that 512 pad with a dummy extension containing zeroes so it
is at least 512 bytes long.
[Adam Langley, Steve Henson]
Changes between 1.0.1e and 1.0.1f [6 Jan 2014]
*) Fix for TLS record tampering bug. A carefully crafted invalid
handshake could crash OpenSSL with a NULL pointer exception.
Thanks to Anton Johansson for reporting this issues.
(CVE-2013-4353)
*) Keep original DTLS digest and encryption contexts in retransmission
structures so we can use the previous session parameters if they need
to be resent. (CVE-2013-6450)
[Steve Henson]
*) Add option SSL_OP_SAFARI_ECDHE_ECDSA_BUG (part of SSL_OP_ALL) which
avoids preferring ECDHE-ECDSA ciphers when the client appears to be
Safari on OS X. Safari on OS X 10.8..10.8.3 advertises support for
several ECDHE-ECDSA ciphers, but fails to negotiate them. The bug
is fixed in OS X 10.8.4, but Apple have ruled out both hot fixing
10.8..10.8.3 and forcing users to upgrade to 10.8.4 or newer.
[Rob Stradling, Adam Langley]
It is sad, that on regular android devices, these bugfixes never see the light. Basically you can take these known bugs and rig most of the android 4.x devices.
reg. hunderteins
[1] http://www.openssl.org/news/changelog.html
Regardless, it's not a bad thing to have the latest version.