Hi all,
I've been tinkering around trying to get mtpfs to work properly and get mtp services working in Ubuntu for my Xperia ZL (Bell C6506 4.2.2 android)
Here's where I'm at so far:
Linux can recognize the device and automatically mounts it now.
Rhythmbox can detect it, but I haven't tested sync features, but I did notice it couldn't automatically detect my music libraries. It obviously doesn't autodetect their locations and is possibly only looking for them in a certain place.
I'm also worried if I try to sync with rhythmbox, that it will erase data on the SD or worse, the internal.
Don't give me credit for any of this, I pulled all my info from various sources online, mostly from webupd8.
My steps:
Create a directory that we can mount the device to. Open up a terminal and type:
Code:
sudo mkdir /media/xperiazl
I never had to use chmod, but if you wanna make sure permissions are right, do a quick google search on how to set permissions with chmod. I think it's more important if you have multiple users on the one computer, but I'm the only user on my PC.
Next, install go-mtpfs through the ppa provided by webupd8
go-mtpfs is a Ddebian package that manages the filesystem used by the mtp protocols. It should work on any Debian distro, but I only work in Ubuntu 13.04 so I haven't tested anything else.
Code:
sudo add-apt-repository ppa:webupd8team/unstable
sudo apt-get update
sudo apt-get install go-mtpfs
But go-mtpfs isn't enough on it's own, because it doesn't autmoatically detect the Xperia ZL (it is supposed to detect nexus devices, etc. automatically though)
Next you need to edit a script file in the udev folders, to tell linux how to recognize the phone; or theoretically any other MTP devices.
If you want to know about udev and the files you're editing, go to /etc/udev/rules.d/ and look for the readme document inside.
Code:
sudo gedit /etc/udev/rules.d/51-android.rules
I use the code below to set the parameters for recognizing the Xperia ZL, specifically while it's in MTP, with USB debugging enabled.
With debugging disabled you have a different product ID (labelled "ID_VENDOR_ID" in the code below). You could just duplicate the code and have two entries then, one for usb debugging on, one for when it's off.
FOR NON C6506 / Xperia ZL device users:
When looking at the below code, notice the idVendor tag and the idProduct tag in the first unhashed line of code. These numbers are specific for the Xperia ZL (possibly specific to the C6506, I never looked into it). If you're setting up auto-mount for another device, use the following function in the terminal:
lsusb
lsusb gives you a readout of all the usb devices attached to your computer (that linux can detect). The readout looks kind of like this:
Bus 002 Device 055: ID 0fce:5189 Sony Ericsson Mobile Communications AB
That's the readout at this time for my Xperia ZL. The 0fce is meant to be handled by idVendor or ID_VENDOR. The 5189 is meant to be handled by idProduct or ID_VENDOR_ID. Again, remember that your idProduct or ID_VENDOR_ID is different when usb debugging is off / on.
Ok, we're almost there! C6506 users, just copy the code below and replace YOUR_USERNAME with... well, your username.
All other users must replace the product ID and Vendor ID with their own device's values.
Code:
# Sony XperiaZL idProduct="0189" for usb debug off, and idProduct="5189" for usb debug on
SUBSYSTEM=="usb", SYSFS{idVendor}=="0fce", ATTR{idProduct}=="5189", MODE="0777" #MTP media, USB debug on
# Xperia ZL MTP mode under JB 4.2+ : automatic mount & unmount whel plugged (usb debug on & off)
SUBSYSTEM=="usb", ENV{ID_VENDOR}=="0fce", ENV{ID_VENDOR_ID}=="5189", ACTION=="add", RUN+="/usr/bin/sudo -b -u YOUR_USERNAME /usr/bin/go-mtpfs -allow-other=true /media/xperia"
You will often run into errors and other random problems if you try to mount with the screen off (or at lockscreen). If you're gonna do lots of file transfers, I suggest jumping into your phone's developer options and turning on "stay awake" so the screen stays on while it's charging. That'll prevent loss of permissions in the middle of a file sync.
If there are any linux experts, could you help point out any faults in my code? I'm pretty sure its all good actually and that all the rough edges are linux issues with mtp, since it's not supported as well as it could be.
Anyways, thanks for reading, I know I'm not the best at teaching this but hopefully this helps someone else out who's been struggling with linux and MTP protocol.
EasyAI said:
Hi all,
I've been tinkering around trying to get mtpfs to work properly and get mtp services working in Ubuntu for my Xperia ZL (Bell C6506 4.2.2 android)
Here's where I'm at so far:
Linux can recognize the device and automatically mounts it now.
Rhythmbox can detect it, but I haven't tested sync features, but I did notice it couldn't automatically detect my music libraries. It obviously doesn't autodetect their locations and is possibly only looking for them in a certain place.
I'm also worried if I try to sync with rhythmbox, that it will erase data on the SD or worse, the internal.
Don't give me credit for any of this, I pulled all my info from various sources online, mostly from webupd8.
My steps:
Create a directory that we can mount the device to. Open up a terminal and type:
Code:
sudo mkdir /media/xperiazl
I never had to use chmod, but if you wanna make sure permissions are right, do a quick google search on how to set permissions with chmod. I think it's more important if you have multiple users on the one computer, but I'm the only user on my PC.
Next, install go-mtpfs through the ppa provided by webupd8
go-mtpfs is a Ddebian package that manages the filesystem used by the mtp protocols. It should work on any Debian distro, but I only work in Ubuntu 13.04 so I haven't tested anything else.
Code:
sudo add-apt-repository ppa:webupd8team/unstable
sudo apt-get update
sudo apt-get install go-mtpfs
But go-mtpfs isn't enough on it's own, because it doesn't autmoatically detect the Xperia ZL (it is supposed to detect nexus devices, etc. automatically though)
Next you need to edit a script file in the udev folders, to tell linux how to recognize the phone; or theoretically any other MTP devices.
If you want to know about udev and the files you're editing, go to /etc/udev/rules.d/ and look for the readme document inside.
Code:
sudo gedit /etc/udev/rules.d/51-android.rules
I use the code below to set the parameters for recognizing the Xperia ZL, specifically while it's in MTP, with USB debugging enabled.
With debugging disabled you have a different product ID (labelled "ID_VENDOR_ID" in the code below). You could just duplicate the code and have two entries then, one for usb debugging on, one for when it's off.
FOR NON C6506 / Xperia ZL device users:
When looking at the below code, notice the idVendor tag and the idProduct tag in the first unhashed line of code. These numbers are specific for the Xperia ZL (possibly specific to the C6506, I never looked into it). If you're setting up auto-mount for another device, use the following function in the terminal:
lsusb
lsusb gives you a readout of all the usb devices attached to your computer (that linux can detect). The readout looks kind of like this:
Bus 002 Device 055: ID 0fce:5189 Sony Ericsson Mobile Communications AB
That's the readout at this time for my Xperia ZL. The 0fce is meant to be handled by idVendor or ID_VENDOR. The 5189 is meant to be handled by idProduct or ID_VENDOR_ID. Again, remember that your idProduct or ID_VENDOR_ID is different when usb debugging is off / on.
Ok, we're almost there! C6506 users, just copy the code below and replace YOUR_USERNAME with... well, your username.
All other users must replace the product ID and Vendor ID with their own device's values.
Code:
# Sony XperiaZL idProduct="0189" for usb debug off, and idProduct="5189" for usb debug on
SUBSYSTEM=="usb", SYSFS{idVendor}=="0fce", ATTR{idProduct}=="5189", MODE="0777" #MTP media, USB debug on
# Xperia ZL MTP mode under JB 4.2+ : automatic mount & unmount whel plugged (usb debug on & off)
SUBSYSTEM=="usb", ENV{ID_VENDOR}=="0fce", ENV{ID_VENDOR_ID}=="5189", ACTION=="add", RUN+="/usr/bin/sudo -b -u YOUR_USERNAME /usr/bin/go-mtpfs -allow-other=true /media/xperia"
You will often run into errors and other random problems if you try to mount with the screen off (or at lockscreen). If you're gonna do lots of file transfers, I suggest jumping into your phone's developer options and turning on "stay awake" so the screen stays on while it's charging. That'll prevent loss of permissions in the middle of a file sync.
If there are any linux experts, could you help point out any faults in my code? I'm pretty sure its all good actually and that all the rough edges are linux issues with mtp, since it's not supported as well as it could be.
Anyways, thanks for reading, I know I'm not the best at teaching this but hopefully this helps someone else out who's been struggling with linux and MTP protocol.
Click to expand...
Click to collapse
Hey i did everything as you said, but still cannot mount my ZL C 6502...is there anything else that i could do?
Related
First, I didn't know if this should go in development or general since most of the people who are going to be on Ubuntu will be devs, but hopefully this will be useful for everyone.
Honeycomb changed a lot of things. Most of the changes are awesome (as we know) but some of them have made certain things frustrating. Honeycomb marked the move from USB Mass Storage to MTP (media transfer protocol). Although for Windows users it actually works pretty well, for Linux users it doesn't...at least at first.
If anyone has hooked up their Xoom to a Ubuntu box then they know at first nothing happens. There is no selection on the tab to "mount" USB Mass Storage because it is not supported (which I thought Honeycomb was supposed to support both so this may change) It's like the computer doesn't even recognize anything is plugged in.
So this was very frustrating but I have put together a solution. Previously I was using a GUI interface called gMTP to connect to the Xoom and transfer files. This was an ok solution and it worked but I would still rather just use it in Nautilus like every other drive I use. Ok so starting here I will just post the commands and then explain after so no code gets lost.
Start with installing a needed program for all of this to work
Code:
sudo apt-get install mtpfs
Next we will create the device rules, so Ubuntu recognizes it as a USB device.
Code:
sudo gedit /etc/udev/rules.d/51-android.rules
NOTE: Some of you may have already added the Vendor ID. If you don't this file will start off blank and then you need to add this next line. If it does not come up blank, then make sure you have a line with Vendor ID 22b8 and 18d1 (for bootloader which uses a different VendorId) and you are all set.
Code:
SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666"
You might need to start a new terminal for this change to take effect for adb and bootloader access.
make the mount point and take ownership:
Code:
sudo mkdir /media/xoom
sudo chown user:user /media/xoom
NOTE: "user" in the above code is literally your user name for your box.
ANOTHER NOTE: if you stopped here you could mount by typing mtpfs /media/xoom -o allow_other and unmount by typing fusermount -u /media/xoom...but that's no fun
add the mount point to your fstab:
Code:
sudo gedit /etc/fstab
In the first unused line available you might want to type a comment like:
Code:
# mount point for moto xoom
then add this line after it:
Code:
mtpfs /media/xoom fuse user,noauto,allow_other 0 0
Next modify fuse.conf to allow_other:
Code:
sudo gedit /etc/fuse.conf
uncomment the last line which should read:
Code:
#user_allow_other
uncomment this line by removing the '#' symbol.
add your user to the fuse group:
Code:
sudo gedit /etc/group
a long file will open, press CTRL+F to bring up the find dialog and type
Code:
fuse
close the dialog and fuse should be selected and visible.
At the end of that line with no space add your user name.
Save that file. Close it.
Lastly reboot your computer.
Now when your computer restarts, if you look at your "Places" menu you will see a Drive marked with 'xoom'
Plug in your xoom, and click on xoom in Places.
Nautilus should open with all your files that you have on your device. It will also place a mounted drive icon on your desktop. If you would like to unmount, right click on that icon and click unmount.
As you can see this was a pain for me, but hopefully this solution will work for everybody. I know the instructions are really long but follow it and you will feel old school mounting your storage in your file browser.
NOTE: THIS WAS TESTED ON UBUNTU 10.10 ONLY, IF THIS WORKS FOR ANYONE ELSE PLEASE POST YOUR FINDINGS.
Also, I am fairly new to Linux actually, so if there is an easier way to mount the storage in nautilus let me know. This works for me and I just want to help out so please no flames.
Couple things I have also noticed with MTP, when you have the internal storage "mounted" you still actually have access to the files on the device. Plus the file transfer is a lot faster. Usually I had been getting about 4 Mb/s and now I get about 15. Of course this speed difference from what I am used to might be the internal storage vs. SDCard transfer rate diffs.
Last thing, is this might need to modified when the sdcard access comes since there is only one mount point specified.
not trying the artificial bump.
I guess no comments on 228 views means this is working?
Can someone chime'in if this worked for them so I can know'if it works'as is or needs to be tweaked.
Thanks
I got mount up and running last night. Works like a champ. Great work. I was tired of pushing and FTP.
Thanks for the reply. Glad it worked for you too. One thing I need to add tonight to it is the fact that the xoom uses a different vendor'id when it's in the bootloader. The one vendor id if used alone will not recognize the xoom to use fastboot but ill update it when I get home.
FWIW, the "mtpfs" package in 10.04 was broken when using the Xoom, and causing segfaults. I found the source and rebuilt that and now it's working OK.
kcrudup said:
FWIW, the "mtpfs" package in 10.04 was broken when using the Xoom, and causing segfaults. I found the source and rebuilt that and now it's working OK.
Click to expand...
Click to collapse
So, I'm on 10.04 and not getting segfaults, but after pugging in (xoom is in usb debug mode) and click on xoom in places, ubuntu gives me the error "could not open location file:///media/xoom. Error stating file '/media/xoom': Permission denied"
Would love to get a copy of your recompiled 10.04 mtpfs package as a deb file...
I found this deb package for mtpfs 0.9-1 that you can try
mtpfs_0.9-1_amd64.deb
roberj13 said:
I found this deb package for mtpfs 0.9-1 that you can try
mtpfs_0.9-1_amd64.deb
Click to expand...
Click to collapse
Unfortunately, that's not gonna work for me. I'm 32-bit.
Ill keep looking, for some reason the 64-bit was the only one there.
roberj13 said:
Ill keep looking, for some reason the 64-bit was the only one there.
Click to expand...
Click to collapse
Thanks! If i could ge this to work, it would totally be awesome!
--Q
Most excellent guide!! Thanks you for taking the time to figure this out. I'm on 10.10 so I have nothing else to add.
Works flawless on Ubuntu 10.10 running on an older Mac Pro
Thank you for posting the easy to follow guide.
This is semi-working for me in that I can successfully mount and browse the device, but there are a few problems. One, it locks up Nautilus for 30-60 seconds (grayed out and unresponsive) though it does come back. Two, file transfer speeds are very poor.
I'm trying to load two movies totaling 1 GB right now and the copy dialog says 2hrs 56 min to transfer w/ a speed of 99.7 kb / sec. This is unreliable, however, as the copy dialog is frozen on those metrics.
Build is AMD64, distro is 10.10 upgraded from 10.4.
I appreciate the effort to document this, in spite of my issues. Let me know if anyone has suggestions for a fix and I'll try them.
One day later and this solution is now working for me. The Xoom filesystem behaves oddly in Nautilus, with some files not appearing that have in fact been transferred to the device, but otherwise this is the best solution I've found.
sogrady said:
One day later and this solution is now working for me. The Xoom filesystem behaves oddly in Nautilus, with some files not appearing that have in fact been transferred to the device, but otherwise this is the best solution I've found.
Click to expand...
Click to collapse
I find it odd that Android dosn't play nicely with *nix.. considering they are cousins in the OS family. That it works sooo well with Windows instead offensive IMO
sogrady said:
One day later and this solution is now working for me. The Xoom filesystem behaves oddly in Nautilus, with some files not appearing that have in fact been transferred to the device, but otherwise this is the best solution I've found.
Click to expand...
Click to collapse
I've seen the same thing. Usually an unmount then mount will clear it up.
this did not work for me. i'm getting no application is registered as handling this file
i told nautilus to open it and its saying /media/xoom is not a folder
Using this guide I'm able to mount fine, but I'm seeing a couple issues:
I have my music organized like this:
Artist
-----Artist - Album
----------Music files
When I copy over the top 'Artist' directory to the Xoom's Music folder it works, but, all of the music files have been directly placed in the Xoom's Music folder and the Artist and Artist - Album folders are empty, seems pretty weird?
EDIT: It looks like the Xoom (or MTP?) forces all music files into the root of the Music directory. Even if I try copying the artist folder to the root of the device the mp3 files end up in the Music folder.
EDIT take 2: Nevermind...the Android docs say nested directories are supported for music, and Windows preserves the directory structures fine.
I'm totally unable to copy over movies. I've transcoded a file into mp4 and it seems to copy over but, once the copy is finished the file doesn't show up on the Xoom.
EDIT bonanza: Looks like I'm also able to copy over movies fine through windows...so I guess all my problems are Linux related.
I keep gettting a "Transport endpoint is not connected" error when I try this. I am using 10.04 64-bit. Does anyone know how to resolve this?
For a while now I have been wanting to run aircrack on my galaxy nexus so as to have a mobile pentesting device.
So, I finally got it working and thought I would post how. This is not a task for the terminally challenged.
Install Backtrack 5 ARM. The latter is a linux environment designed for pentesting. On a mobile device the easiest way to install it is by chrooting to the mounted img, running on top of the mobile devices kernel.
Since most people seem to think aircrack is unusable on a mobile arm device, it is not included in the BackTrack 5 linux distro above, so you will need to download it manually once you have BackTrack up and running.
Here are the commands to do so:
#!/bin/bash
# Aircrack-ng installer for BackTrack 5 on Android
# By Justin Barrick aka th3p4tri0t
# install dependency for libssl-dev
apt-get install zlib1g-dev
# install libssl-dev
wget http://launchpadlibrarian.net/64412492/libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
dpkg --install libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
rm libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
# get and install aircrack-ng
apt-get install source-aircrack-ng
cd /var/backtrack/sources/aircrack-ng/1.1/bt9/upstream-sources/
tar -xzf aircrack-ng.tar.gz
cd aircrack-ng/
make
make install
# set path variable
echo "export PATH=$PATH:/usr/local/sbin" >> ~/.bashrc
export PATH=$PATH:/usr/local/sbin
Now, the hard part. Or at least the part that took me forever to discover. You need the drivers for the AWUS036H to be insmod'ed into the kernel. You can accomplish this by obtaining your kernel source and the driver source, which is part of the compat-wireless package, more specifically the AWUS036H uses the rtl8187 chipset. Then, you cross compile those two sources to obtain rtl8187.ko, eeprom_93cx6.ko, and mac80211.ko. Then insmod those kernel modules into your kernel (insmod rtl8187.ko). The process is explained here. One can also recompile the enitre kernel, instead, and include the modules as built-in drivers. However, compiling kernel drivers can be difficult (toolchains, kernel source, etc), so luckily, I found a Galaxy Nexus kernel that already has the modules built-in, it is franco.Kernel R140 with modules added.
***Update:farcno.Kernel R200 with RTL8187 modules added, and R248 for JellyBean 4.1.1 with RTL8187 drivers
, so Aircrack-ng is now compatible with JellyBean! Also, R140 is no longer available but R200 is and has the modules needed
Beware, the kernel R200 needs ICS 4.0.4 installed to work properly, and R248 is built for JB 4.1.1.
***Update 04/11/2013:
I couldn't find any kernels with the RTL8187 drivers for JB 4.2.2, so, I built one my self. The kernel is a modified franco.Kernel R370. I didn't package it into a flashable zip, because I find it just as easy to hook my phone to my computer and use fastboot (fastboot flash boot bootJB422-RTL8187.img). The kernel image is attached below. I have been running it for about 4 days now without issue. I actually find it is the stablest version yet. I was able to play N64oid, while running airodump-ng and aireplay-ng. File attached below.
***Update 04/15/2013:
I looked into getting more of the aireplay-ng attacks to work proper with the RTL8187 drivers. There had been some complaints about fragementation attack not working and negative one always being returned as the channel for mon0. So, I found two patches for those issues on the aircrack-ng site and applied them to the franco.Kernl r370 with RTL8187 and recompiled. Now, we have fully functional aircrack-ng RTL8187 driver.
Once you flash the kernel, using the flashable zip and cwm or fastboot flash, then backtrack will be able to recognize the attached wifi adapter.... once you mount the usb bus in BackTrack. And, of course, this needs a OTG USB host cable.
The final step before learning how to use aircrack-ng is:
1. Open a terminal and load BT5, you can load the 'ui' and use an vnc to connect the the xserver desktop if you want. But, I have found it is easier to just use the chroot shell in the android terminal emulator.
2. open another android terminal window, and type:
su
mkdir -p /data/local/bt/dev/bus/usb
mount -o bind /dev/bus/usb /data/local/bt/dev/bus/usb
3. In the new android terminal window, start the BT5 shell (startbt), then type:
lsusb
You should see atleast one device, the usb root, and whatever device you have plugged in to the otg cable, if any.
A note to remember: I re-performed this guide after formatting my phone and got stuck here. lsusb didn't list anything. I rebooted my phone and tried to start BT5 and mount the usb again and it worked. I rebooted, started BT5, tried lsusb without binding usb and was blank as should be, bound usb back in another terminal window, returned to BT5, tried lsusb and root hub displayed.
Now, plug in the AWUS036H and type: airmon-ng
And you should see the device listed.
Read here for how to run aircrack, or view here.
Essentially the commands are:
lshw -disable dmi
(this should list the attached wifi card under NETWORK, my RTL8187 was wlan1)
ifconfig
(you should see wlan1 listed, if not the type "ifconfig wlan1 up" and retype "ifconfig")
airmon-ng start wlan1
airodump-ng mon0
copy BSSID and CHANNEL
New android terminal with BT5 shell (startbt): airodump-ng -w wep -c CHANNEL --bssid BSSID mon0
New android terminal with BT5 shell (startbt): aireplay-ng -1 0 -a BSSID mon0
New android terminal with BT5 shell (startbt): aireplay-ng -3 -b BSSID mon0
After ~50,000 packets collected:
New android terminal with BT5 shell (startbt): aircrack-ng wep-01.cap
To the purpose, with this, if your friend or mom or just some complete stranger forgets their wep key to their network, all they need to do is call you and you can just drive by, plug your wifi adapter into your phone, chroot to BT5 and aircrack their password for them, in a matter of 5 to 10 minutes.
WARNING!!!: In my intial aircrack run on my galaxy nexus, I cracked a wep key in about 5-10 minutes. I was happy, happy, happy. Then, a ruinous moment occurred. Almost the very second aircrack-ng finished cracking the key, my phone came up with a low battery warning, I was using a awus036h wifi adapter and it was draining my battery fast, I had about 50% to begin and had the 14% warning hit me about 10 minutes in, funny thing is the warning is usually 14%, but this time was 13%, go figure? Anyway seconds after the warning my phone just blanks, turns off. I plug it in and reboot and the battery is at 0% and stuck there, so a word of warning:
An external wifi adapter my require more usb host juice then the battery can safely supply. I have seen people using powered hubs to circumvent draining the phone battery, I would defintiely recommend the practice.
UPDATE: I plugged the phone into an AC charger and the battery finally charged (phew). For some reason, it wouldn't recharge on the USB cable after being so drained.
Is there a compatible wifi device that has the same chip set but with its own power supply (cord or battery)? If so that should help. I'm interested if someone can find one.
Sent from my Galaxy Nexus using xda premium
This is amazing work. I used to do some network pen testing as part of my old job and there's a lot of work that goes into making a mobile setup even with a laptop involved. The fact you got this all working coherently on a phone is mind blowing to me. Huge props.
I have no experience with this manufacturer or ebay seller but through some googling I did find this product:
http://www.ebay.com/itm/Solar-Power...970998?pt=PDA_Accessories&hash=item20b72a86b6
USB hubs in theory do not identify as normal USB devices and allow for pass through communication between connected devices. This one supplies external power as well. In other words, you may be able to connect both devices to this as it provides external power, and they can communicate without you having to rewrite any drivers.
However, be careful because some USB chipsets get confused if you try to use them as USB host but supply external power at the same time. So you may want to verify that is safe on the GNEX USB chipset.
Anyone willing to order that hub and test it?
Sent from my Galaxy Nexus using xda premium
Wow just found that and will be testing it at home tonight.
I flashed the V140 kernel via recovery and I can't locate rtl8187.ko anywhere to move it to /data/local/modules
Where is it located once the kernel flashed?
Thanks!
Once you install the R140 kernel mentioned, there is no need to insmod rtl8187.ko. The rtl8187 chipset support is compiled into the kernel boot.img.
I use this external battery pack, and I spliced a spare USB cord with the cord from my wifi adapter, so it only draws juice from the battery pack.
When you cut open a usb cord there are four wires: red, black, green, and white.
Green and white are data, connect them to the cord going to the galaxy nexus.
Red is +5V, connect it to the +5 V or red cord going to the battery pack.
Black is common, connect it to both usb cords.
So, on the cord going to the battery pack, green and white are loose, and on the cord going to the gnex, red is loose.
Or, you could use the solar powered hub mentioned above. You will still need the modified kernel, as the hub will show up as an attached device, but so will whatever is connected to it. You can't communicate with a device, without the appropriate drivers.
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
bigrushdog, to be honest, during my trek to get this working, I nearly gave up and bought a XOOM, after seeing how well developed it was.
bigrushdog said:
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
Click to expand...
Click to collapse
Of course I would be interested!!!
Aircrack is working now with my rtl8187!
Great job. However I noticed that this kernel is draining the battery much quicker than the latest Franciscofranco kernel in Android with a normal everyday usage.
You could download the franco.Kernel updater, it lets you set options in the franco.Kernel, like the "Generic Hotplug" option which saves battery by turning off one cpu core when the phone screen is off and allows you to set undervolt settings. It also has a Power Mode setting with Full Power, Balanced, and Power Save options. Full Power is default, which makes your phone faster, but at the expense of battery power.
Be sure not to upgrade the kernel to the current nightly though. The franco.Kernel I listed is specially modified, the rtl8187 drivers aren't normally found in the franco.Kernel.
bigrushdog said:
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
Click to expand...
Click to collapse
Yes, please! I'd be interested.
Sent from my Galaxy Nexus using xda premium
michaelmotes said:
You could download the franco.Kernel updater, it lets you set options in the franco.Kernel, like the "Generic Hotplug" option which saves battery by turning off one cpu core when the phone screen is off and allows you to set undervolt settings. It also has a Power Mode setting with Full Power, Balanced, and Power Save options. Full Power is default, which makes your phone faster, but at the expense of battery power.
Be sure not to upgrade the kernel to the current nightly though. The franco.Kernel I listed is specially modified, the rtl8187 drivers aren't normally found in the franco.Kernel.
Click to expand...
Click to collapse
I will try the settings as I already have the app! Huge thanks!
Wow I tried to get rtl8187 working since 2 weeks, but never was able to crosscompile the kernel modules.. And you found a kernel, that has these modules already intergrated thank you very very much
It was brought to my attention that the patches for the compat wireless drivers from aircrack-ng haven't been applied to the driver in the kernel I provided. Nonetheless, aircrack-ng, aireplay-ng, airmon-ng, and airodump-ng still work. The only one that might give you a problem is aireplay-ng because it uses the patches to get the channel of the bssid from the driver, which without the patch just returns -1. I was able to get around it by using the command line option --ignore-negative-one when using aireplay and the ARP request replay attack (attack 3) and fake authentication (attack 1) still worked.
Also, a word to the wise, I overheated my cpu while running airodump, aireplay ARP request replay, and aircrack all at once and caused a kernel panic and emergency shutdown. So, I would advise only running airodump and aireplay, then waiting until you have lots of packets, stopping airepaly and airodump, and then running aircrack. Or, maybe even underclocking the cpu while running in backtrack.
michaelmotes said:
It was brought to my attention that the patches for the compat wireless drivers from aircrack-ng haven't been applied to the driver in the kernel I provided. Nonetheless, aircrack-ng, aireplay-ng, airmon-ng, and airodump-ng still work. The only one that might give you a problem is aireplay-ng because it uses the patches to get the channel of the bssid from the driver, which without the patch just returns -1. I was able to get around it by using the command line option --ignore-negative-one when using aireplay and the ARP request replay attack (attack 3) and fake authentication (attack 1) still worked.
Also, a word to the wise, I overheated my cpu while running airodump, aireplay ARP request replay, and aircrack all at once and caused a kernel panic and emergency shutdown. So, I would advise only running airodump and aireplay, then waiting until you have lots of packets, stopping airepaly and airodump, and then running aircrack. Or, maybe even underclocking the cpu while running in backtrack.
Click to expand...
Click to collapse
Could we patch it manually? We would need to download the kernel source somewhere in the chroot session and modify the makefile then?
You can patch it manually. But, like I said, I'm happy with it, I can crack wep keys and that is what I wanted to do, still as an academic exercise, or academic triathlon, you can patch it manually. To start, I would try getting the kernel source for the gnex, or maybe from Kernel-XP I linked. He might give it to you if you asked. Then, I would recompile the kernel with not changes.
The kernel must be recompiled using the arm gcc toolchain, you can get it like:
$ git clone https://android.googlesource.com/platform/prebuilt
$ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
I would install all the necessaries on a regular desktop and follow the instructions for building kernels here: http://source.android.com/source/building-kernels.html.
Once you get the kernel rebuilt and it works, look into patching the compat-wireless source here: http://www.aircrack-ng.org/doku.php?id=compat-wireless
And then take a look here: http://stackoverflow.com/questions/4849063/cross-compile-lkm-module-for-android-platform. It says how to setup a makefile in the driver source directory to make it cross-compile with the android kernel source.
Nice!
Cool and thanks for all the steps. Last link was the key I was missing for many weeks!
So right now WPA2 won't be working right?
What do you mean "WPA2 wont be working"?
I believe you can still caputre handshakes, and try to brute force the password. All you need is to run airodump to capture the handshake on the wpa router and run aireplay with attack 0 (deauthication) to cause a client to handshake.WPA cracking is slow though, and only possible if the router has password less then or equal to 7 characters, I think after that the odds of cracking it become worse then hitting the lottery after that. There is no way to recover a WPA key without guessing it.
Capturing the handshake just allows one to guess rapidly without the router knowing or being able to ban your mac for repeated auth attempts.
---
DISCLAIMER: THIS IS A REALLY GOOD WAY TO EFF UP YOUR KINDLE IF YOU DON'T KNOW WHAT YOU ARE DOING!!!
IF YOU DON'T KNOW WHAT ADB, PARTED, OR WHAT LINUX IS, YOU MIGHT WANT TO JUST CLICK THE BACK BUTTON!
---
Most that know Android, knows that it's just fancy UI and API on top of Linux, but it's still not quite Linux... But what if you want to run real Linux on your tablet?
Well, it's actually not that hard to do, but certainly not for n00bs...
Need to know: Linux, fastboot, adb, parted, etc.
You will also need the mkbootimg program, fastboot, working ADB, etc.
And a USB OTG adapter and working USB keyboard.
(this is assuming you already have modded your kindle with the usual FFF+TWRP 2.1+CM9)
The first step is to do a little repartitioning, so boot the Kindle into recovery, and run an 'adb shell'.
Then run 'parted'.
The idea here is to basically maintain the stock layout, while making room for linux...
Which can be done a few ways, the easy way would to just delete 'media', then recreate it much smaller (I did 1GB).
Then make one more new partition, using the remaining flash memory (should be a little over 4GB).
Making sure to reassign the name 'media' to partition 12, you can also name the new linux partition 'linux' or whatever, if you like.
After that, quit parted, and create the new FS on the new linux partition (mke2fs -Text4 /dev/block/mmcblk0p13, but you should know that already ).
Then reboot the tablet, get back into Android, it may or may not complain about the 'SDCARD' needing to be formatted, which should be done anyway, since it changed in size.
Do another 'adb shell', mount the new linux partition to a useful place, you can just mount over '/mnt' if you like, it won't hurt anything. Exit out of the shell.
Download this pre-built Debian rootfs I found:
http://rcn-ee.net/deb/rootfs/wheezy/
Unpack that file on your host machine, then use 'adb push' to copy the armel-rootfs tar to the Kindle's '/mnt'.
'adb shell' back into the kindle, and change to '/mnt' and untar the armel rootfs tar file... Maybe go to the bathroom, get a drink, get some fresh air or something, it'll take a little time to do it's thing.
After that's done, download my rc.local and 'adb push' that to '/mnt/etc' and make sure to ungzip it, and chmod is 0777 (or is it 0766, either should work lol).
http://www.mediafire.com/?gx46xxb4813n5ob
Then you can delete the rootfs tar file if you like, get out of '/mnt', and unmount it.
Linux is now installed, easy eh?
Now, download my kernel (acutally it's Hashcode's kernel, but with needed changes):
http://www.mediafire.com/?2lqex9j5bgws0b1 (Updated 6/11/2012)
Using mkbootimg:
'mkbootimg --kernel zImage --ramdisk /dev/zero --cmdline "root=179:XX" --base 0x80000000 -o boot.img'
Where XX is the partition that you put linux on (if following this exactly, should be 13), you should now be able to use /dev/mmcblk0pXX as well, if that doesn't work just use 179:XX.
Then using fastboot, boot the kernel package:
'fastboot boot boot.img'
While it says 'waiting for device...", reboot the Kindle and wait for it to download and boot the package.
Then wait for the linux login!
Plug in your favorite USB keyboard, a USB 1.1 one works best I've found.
The root password for that rootfs package is just 'root'.
-------------
Now, the fun part: Internet access, the hard way.
I'm still working out getting the WIFI modules working, so you'll have to use it tethered via USB... Which means no keyboard, but you can still log in by SSH.
In my kernel, instead of being an 'android' USB devices, it's a multifunction USB gadget with ethernet, serial port, and mass storage.
Mass storage works, but a little buggy sometimes.
Serial port seems broken for some reason.
Ethernet is what we're after.
Now the rc.local I made, in addition to enabling the video overlay (so there's a framebuffer console on the LCD), it also sets up the ethernet USB gadget.
I set the IP address to 192.168.5.1, which really should be out of the common IP range that most people use, but if it conflicts, then you can edit rc.local before you push it over above.
On your Linux host, with the Kindle plugged in, bring up the USB ethernet interface:
'ifconfig usb0 192.168.5.2 netmask 255.255.255.0'
After that, maybe try pinging the kindle (192.168.5.1), to make sure everything is working... If it is, you should have no problems connecting with SSH and logging in.
Once you can connect/login by SSH, you'll need to add your host machine as the default gateway ('route add default gw 192.168.5.2'), then edit '/etc/resolve.conf' and add a DNS server (add your ISP's DNS, or use 4.2.2.1).
After that, you should have internet access on the kindle side via SSH, and should be able to download/install your favorite Debian packages.
Oh, did I mention that you'll need a IP forwarding/NAT service running on your linux host too? I'll have to refer to linux manuals on how to do that, but if you can do all this, you should have no problems doing that.
I should also say that this CAN technically be done in windows as well, since all the needed programs are available in WIN32 bins, but you won't be able to get tethered network access working, because Microsoft doesn't support CDC ethernet devices.
Have fun!
OH! And X works fairly well with the omap3 video driver, just so long as you DON'T touch the screen, the touch screen driver currently crashes X on input.
So fair warning, make sure you know how to navigate X with just a keyboard, unless you have a OTG working hub and can use a keyboard and mouse, or have a wireless keyboard/mouse combo of some kind.
Update 6/11/2012:
Uploaded new kernel (link above), touch screen is now working, though no multitouch.
I have a boot loader with multiple boot options, http://www.mediafire.com/?l6aaqgsdkiksfw0
To use it, make a partition named "linuxboot", and flash your linux's boot.img created with the above instructions.
Still working on wifi.
Update 6/11/2012:
Ok, WIFI is working... Not sure why it wasn't before.
Here are the modules: http://www.mediafire.com/?139hold2a2l9vbl
Don't forget to run depmod.
You'll also have to copy the firmware from android system partition in /etc/firmware and copy it to Linux /lib/firmware
In case no one believes me, here's a console dump (typing blind of course, this was an early attempt with no LCD):
Code:
d.
.
Starting periodic command scheduler: crond.
FATAL: Could not load /lib/modules/3.0.21+/modules.dep: No such file or directory
Debian GNU/Linux 5.0 carrier tty1
carrier login: usb 1-1: new low speed USB device number 2 using musb-hdrc
usb 1-1: device v0b38 p0010 is not supported
input: HID 0b38:0010 as /devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-1/1-1:1.0/input/input4
generic-usb 0003:0B38:0010.0001: input: USB HID v1.10 Keyboard [HID 0b38:0010] on usb-musb-hdrc-1/input0
input: HID 0b38:0010 as /devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-1/1-1:1.1/input/input5
generic-usb 0003:0B38:0010.0002: input: USB HID v1.10 Device [HID 0b38:0010] on usb-musb-hdrc-1/input1
root
Password:
Last login: Sun May 27 21:55:28 UTC 2012 on tty1
Linux carrier 3.0.21+ #40 SMP PREEMPT Sun May 27 16:59:27 CDT 2012 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
carrier:~# echo skdjfhnsdkjfshdsummit_bat_notifier_call val=41
summit_smb347 4-0006: summit_fsm_stateTransform:state : suspend(0) -> suspend(0) ; event : EVENT_BATTERY_NTC_NORMAL
kfjshdkjfshdfkjshdfkjsdhfkjsdhfkjsdhfkjshksdjfhskjdhfskjdhfsdkjfhsdkjfh > /dev/fb0
carrier:~# echo skdjfhnsdkjfshdkfjshdkjfshdfkjshdfkjsdhfkjsdhfkjsdhfkjshksdjfhskjdhfskjdhfsdkjfhsdkjfh > /dev/fb1
-bash: echo: write error: No such device
carrier:~# omap-rproc omap-rproc.1: rproc_loader_cont: failed to load ducati-m3.bin
cat /dev/vcs1 > /dumpp.txt
I was trying to get something to come up on the framebuffer, to no avail of course.
The backlight comes on, and it seems like it want to work, but there's nothing.
Are you talking about a true Debian dual-boot on our tablet? That could be really awesome .
Envoyé depuis mon Amazon Kindle Fire avec Tapatalk
Actually, yes.
It's mostly a matter of having a proper framebuffer console and telling the kernel to use a root instead of using the initrd to setup android.
If we could get a scripted bootloader, one that would give a customizable boot menu, you could easily boot whatever you wanted.
And what about it : http://thomaspolasek.blogspot.fr/2012/04/arch-linux-lxde-w-xorg-mouse-keyboard_16.html?m=1 ?
Envoyé depuis mon Amazon Kindle Fire avec Tapatalk
Well, I already got most of that working, chroot environment is easy.
I got the full Linux init going, no android at all... just no display.
seishuku said:
Well, I already got most of that working, chroot environment is easy.
I got the full Linux init going, no android at all... just no display.
Click to expand...
Click to collapse
Display might be tricky, as we are currently using the very latest graphics modules from TI. I'm not sure if you can use those in our current build.
That being said you could send a cat /proc/msg to a file during boot and that might contain your error.
Sent from my Amazon Kindle Fire using Tapatalk 2
Well I already have a working fbcon in android, but it seems the display just isn't being enabled in Linux.
I've tried "echo 1 > /sys/devices/omapdss/display0/enabled" to force it on, but nothing.
The back light is already on though...
I thought EXT2 was for really old linux distros.
Sent from my Kindle Fire using XDA
Not really, its just more compatible.
I could have made pretty much anything...
I read somewhere that SSDs should use EXT4.
i am really anxios to see this even though is only cmd line.
will the steps to get this going available even for SSH commands?
I really should hack together a wifi script to get some kind of network connection, would make working on it a little (lot) easier.
The idea here though is to basically have a full linux, to operate exactly like it would on a PC.
With a working framebuffer console, an X.org config can be made and X should work just fine with the touch screen too.
The end result, with just keyboard, should be a full blown linux system.
The real question is how long it would take to compile android for.. itself.
Sent from my Amazon Kindle Fire using Tapatalk 2
Hashcode said:
The real question is how long it would take to compile android for.. itself.
Sent from my Amazon Kindle Fire using Tapatalk 2
Click to expand...
Click to collapse
They can start reproducing them selves, isn't this how terminator started?
Sent from my LG-VM670 using Tapatalk
Hashcode said:
The real question is how long it would take to compile android for.. itself.
Sent from my Amazon Kindle Fire using Tapatalk 2
Click to expand...
Click to collapse
pbailey212 said:
They can start reproducing them selves, isn't this how terminator started?
Sent from my LG-VM670 using Tapatalk
Click to expand...
Click to collapse
This is really off topic but Hashcode's comment and pbaileys phone reminded me of a test project Drew (of Team Hydro) did where he chrooted ubuntu onto an LG-LS670 and compiled a kernel for it natively, took just under 3 hours.
I'm at a bit of a loss here... if I disable surfaceflinger, so I keep my android fb console, then if I disable the display and reenable it, I lose the console.
Also, in my initrd, I can remove everything except ueventd and still keep the console... so something ueventd (init) is doing to enable the console.
In Linux I can play with enabling/disabling the display, but nothing seems to provoke Linux to give me an actual console.
Sblood86 said:
This is really off topic but Hashcode's comment and pbaileys phone reminded me of a test project Drew (of Team Hydro) did where he chrooted ubuntu onto an LG-LS670 and compiled a kernel for it natively, took just under 3 hours.
Click to expand...
Click to collapse
On the vm670 legend has it, people have compliled whole roms in 30 minutes, with an optimus v, and Leslie Ann's build server
sent from my Nokia 5110
Aha! Got it!
http://www.youtube.com/watch?v=PXhnVP3lWLU
For whatever reason sysfs wasn't taking my commands.
Now I can work out some bugs and get X working.
I also switched the USB gadget from android to an Ethernet CDC, so I can SSH via USB while I get wifi working.
Edit-
Sorry about the super blurry video, my phone's camera is having "issues".
Ok, I've switched to the official Debian armel wheezy distro (basically just formatting my linux partition and untaring the distro), seems to have fixed a lot of problems... One being aptitude not working correctly (seen in the video).
I need to enable some kind of ip forwarding on my local linux install, so I can get a temp internet connection on the kindle via USB gadget ethernet cdc (ssh and http already works).
Probably not breaking any ground here (since in hindsight it was blatantly obvious), but I thought I would share anyways...
I own several Android devices, and I'm always playing. well, tonight I was tweaking a few things over adb and got to wondering if I could use adb to connect from one Android device to another. Well, turns out it's pretty easy, if you're rooted...
Both devices need to be connected to the same wireless network.
Install adbWireless from the Playground (sorry, Play Store): https://play.google.com/store/apps/...251bGwsMSwyLDEsInNpaXIuZXMuYWRiV2lyZWxlc3MiXQ..
You only really need it on the receiving device, but I have it on everything anyway.
Copy the Linux adb binary into /system/xbin/ and set the permissions to 755 (rwxr_xr_x), and reboot.
You only really need to do this on the controlling device, but may as well do it on all.
Fire up adbWireless on the receiving device, grant root privileges, and note the IP address
Fire up a Terminal Emulator on the other device, and enter: adb connect <IP address from other device> (you typically don't need to add the :5555 on the end.
Job done! Pretty handy when working from a slate!
I also run dd-wrt firmware on my router, which let's me assign static IPs by MAC address, so the IP for the devices are always the same.
Regards - dr
adb binary is already built in, /system/bin/adb.
besides that, all that's left is get adbd running, and that can be achieved either by an app (like you suggest) or edit init.rc to have adbd as one shot service to allow manual start (doesn't boot with the system). cyanogenmod also has adbd over wireless done like this.
also, one could use an OTG cable to connect devices directly, while i agree adb over wireless is good, adb over ssh would be best.
Valid points.
The adb in /system/bin is a less functional version than the standard Linux binary (94kb versus 156kb); kinda similar to the chown binary, where the recursive function doesn't work...
I'll concede to the rest though...
danger-rat said:
Valid points.
The adb in /system/bin is a less functional version than the standard Linux binary (94kb versus 156kb); kinda similar to the chown binary, where the recursive function doesn't work...
I'll concede to the rest though...
Click to expand...
Click to collapse
Agreed.
Sent from my i9250
edit: checkout this commit @aosp-master: https://android-review.googlesource.com/#/c/41846/
i'll be cherry-picking this one today
danger-rat said:
Valid points.
The adb in /system/bin is a less functional version than the standard Linux binary (94kb versus 156kb); kinda similar to the chown binary, where the recursive function doesn't work...
I'll concede to the rest though...
Click to expand...
Click to collapse
Hi - Where can I get this more functional binary that's half the size of a standard linux binary? I've tried two, they are both around 330Kb, and they fail to run with error "non executable: magic 7F45" because they were not compiled for my ARMV71 processor. I ran chmod 755 on it and when I check the permissions it is executable (-rwxr-xr-x). Can you post a link to the one that's 156kb - I can't find it.
elfaure said:
Hi - Where can I get this more functional binary that's half the size of a standard linux binary? I've tried two, they are both around 330Kb, and they fail to run with error "non executable: magic 7F45" because they were not compiled for my ARMV71 processor. I ran chmod 755 on it and when I check the permissions it is executable (-rwxr-xr-x). Can you post a link to the one that's 156kb - I can't find it.
Click to expand...
Click to collapse
Bumb. Anyone home? Shoot me a link please.
Hey guys,
Now, I have a tablet (running android) and is rooted already (so, I'm ready to get any needed binary on my device). It supports OTG. When I plug in my phone (rooted) using OTG to my tablet, my phone says 'Android debugging enabled' in notifications, is also charging. When I go to TE (Terminal Emulator) of my tab and type: 'adb devices', it displays no device in the list of attached devices (obvious).
And yes, my tab has got OTG host modules in kernel because when I turn on USB mass storage on (in my phone), my tab detects it and I can use it.
Now, my question:
Can I actually do this? i.e., using adb in my tablet (for my phone) via OTG?
Can we run adb from the device to detect itself?
I'm sure you can see why this would be amazing and powerful.. possibly giving root to apps on non-rooted devices with adb's run-as com.package.apk and such?
Is this possible? To have adb run on the Android device and connect to itself? If it is, can you guide me to where to learn it?
Dave :cyclops:
I'm trying to get my system back to where it was before I lost everything. My files, notes, tools, etc. were gone but I've managed to get about 80% of it up again. In order to get my computer to talk to my VK815, I'm pretty sure I need a good udev rule. I think there's also a modeswitch script that needs to run when it's plugged in but that info was lost in the disaster. I have the linux development setup back to where I can compile AOSP and I get the tools like adb and fastboot as compilation products, but can't get the VK815 and computer to talk to each other. Any and all help is most welcome.
Thanks,
Jim
I guess there's some good news here. I was able to reconstruct two udev rules; one to modeswitch (which may or may not be necessary) and the other to symlink to ttyUSB0. With the phone in the normal (not download) mode, dmesg shows it initially as idProduct 6292 (where it attempts to feed the Micro$oft drivers) and then it changes to 6293 and symlinks ttyUSB0. After this completes, 'adb devices' shows a blank list. I'm in the developer mode on the tablet with USB Debugging enabled and the Build Version is LRX22G.
Ideas anyone?
edit: Be sure to turn on USB tethering in Wireless Networks -> More
Turns out that the usb_modeswitch rule wasn't needed. Here's the rule I put into /lib/udev/rules.d/51-vk815.rules
# LG G-Pad 8.3
SUBSYSTEM=="usb", ATTR{idVendor}=="1004", MODE="0666", GROUP="plugdev"
After adding this rule, restart udev the way your version of linux wants you to.
Plug in the USB cable and wait for the VK815 to finish loading the Windoze drivers and change idProduct to 6293.
Now, adb devices "should" show you the device ID. It did on mine.
This can easily be made harder than it should be.
Still can't get the VK815 to become a ttyUSB device when it's in the download mode. Tried adding SYMLINK+="ttyUSB%n" to the udev rule without success. Gotta have this to squirt and image.
When this is done and working, I plan on making a step-by-step for future reference.
Jim