Related
Hi,
I'm getting consistent data corruption when I copy data to my G1 over the USB cable. Every time I copy, say, a 50MB file, the md5sum is different compared to the original. It is different every single time:
Code:
mount android; cp 50mb.bin android/; umount android; mount android; md5sum 50mb.bin android/50mb.bin; umount android;
b3b6bef71e9628dc54833663e93ebdc9 50mb.bin
f0ac977696d8c270b2677457b9fd53d4 android/50mb.bin
mount android; cp 50mb.bin android/; umount android; mount android; md5sum 50mb.bin android/50mb.bin; umount android;
b3b6bef71e9628dc54833663e93ebdc9 50mb.bin
1aaa38e015c469fc2c59eeb99729a631 android/50mb.bin
JesusFreke also reported data corruption issues.
Would you please check if your G1 has data corruption by either doing the same command as above (remember to umount after copying!), or doing something equivalent on windows (perhaps with sfv or whatever)?
I'm wondering what percentage of users suffers data corruption and under what circumstances.
Thanks!
Update:
infernix said:
just a heads up for everyone.
i bought two ferrite cores and put them on each end of the USB cable. no more data corruption. equal md5sums every single time.
so in conclusion:
if you experience data corruption, buy ferrite cores and stick them on your usb cable, or use a cable with integrated ones
Click to expand...
Click to collapse
I'm getting the same behaviour on my laptop. A new G1 with RC28 G1 will arrive in a week or so, let's see if it's only happening on some of the G1s.
infernix said:
Hi,
I'm getting consistent data corruption when I copy data to my G1 over the USB cable. Every time I copy, say, a 50MB file, the md5sum is different compared to the original. It is different every single time:
Code:
mount android; cp 50mb.bin android/; umount android; mount android; md5sum 50mb.bin android/50mb.bin; umount android;
b3b6bef71e9628dc54833663e93ebdc9 50mb.bin
f0ac977696d8c270b2677457b9fd53d4 android/50mb.bin
mount android; cp 50mb.bin android/; umount android; mount android; md5sum 50mb.bin android/50mb.bin; umount android;
b3b6bef71e9628dc54833663e93ebdc9 50mb.bin
1aaa38e015c469fc2c59eeb99729a631 android/50mb.bin
JesusFreke also reported data corruption issues.
Would you please check if your G1 has data corruption by either doing the same command as above (remember to umount after copying!), or doing something equivalent on windows (perhaps with sfv or whatever)?
I'm wondering what percentage of users suffers data corruption and under what circumstances.
Thanks!
Click to expand...
Click to collapse
Unfortunately my datapoint won't be directly relevant to your methodology as I do my data management in xp, but I have experienced no data corruption as of yet (Transferred multiple gigabytes of mp3 through the usb mount and verified against previously generated md5 sums). Have you tried extracting the files back to your PC and finding the difference? It might help to troubleshoot the problem by knowing where the file is differing from the original.
Just did a few tests and I'm not seeing any data corruption issues with my setup:
G1: JesusFreke's modified RC30, 8GB SD card
PC: Fujitsu laptop running Ubuntu Hardy (8.04)
I tried copying a 50MiB zero-filled file, and also tried 50MiB of arbitrary data (actually the first part of a large tar.gz I had lying around) and both checked out fine with md5sum after an umount/mount..
I also spoke with Infernix about my corruption issues. But just to put it "out there", I have occassionally seen some files get corrupted when I copy them to the sd card. I've seen it happen both when the sdcard is mounted via USB, and also when using adb push. So I've gotten in the habit of doing an md5sum of an update before I try to apply it.
I've noticed that USB is practically unusable if I have my BT dongle plugged into my computer near the USB cable, for example if I have them both plugged into the front of the computer. But I have my BT dongle plugged into the back of the computer, and the G1 into the front, it seems to work decent.
Another problematic setup I noticed was if I tried to use a USB extension cord (maybe 3-4, not like a super long one), I seemed to have significantly more USB issues as well.
So I'm guessing the cord is picking up EM interference and causing bits to be corrupted.
I can think of a number of possible workarounds to the issue:
- Modify adb and the adb daemon so that it will detect corrupted "packets" and re-transmit.
- Host whatever files you want to put on your G1 on a webserver with the extension .xxx and download them via the browser instead.
- use some sort of "secure copy" program to copy the files to the sdcard when mounted via usb. There is more than likely something like that out there that would work, I just don't know of anything off the top of my head.
JesusFreke said:
So I'm guessing the cord is picking up EM interference and causing bits to be corrupted.
Click to expand...
Click to collapse
Are you guys using usb cables with ferrite cores on em?
jashsu said:
Are you guys using usb cables with ferrite cores on em?
Click to expand...
Click to collapse
/me checks end of cable.
Yup, pretty good sized one on there.
TBH, the data corruption issues might have just been occuring when I had used another cable I have laying around, that I don't think has one. I don't remember for sure if I have had any data corruption with this one or not.
Code:
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ sudo mount /dev/sdb1 /media/disk
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ sudo cp coa-saw5-r5.avi /media/disk
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ sudo umount /media/disk
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ sudo mount /dev/sdb1 /media/disk
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ md5sum coa-saw5-r5.avi
66ed3515a533885f436768106cdaf6b1 coa-saw5-r5.avi
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ md5sum /media/disk/coa-saw5-r5.avi
fe6c396c9ad3199d1dcaa020023753f3 /media/disk/coa-saw5-r5.avi
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$
That is scary.
Edit:
Code:
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ cp /media/disk/coa-saw5-r5.avi coa-saw5-r5.avi.2
[email protected]:~/qBT_dir/Saw.V.R5.LINE.XviD-COALiTiON$ md5sum coa-saw5-r5.avi /media/disk/coa-saw5-r5.avi coa-saw5-r5.avi.2
66ed3515a533885f436768106cdaf6b1 coa-saw5-r5.avi
fe6c396c9ad3199d1dcaa020023753f3 /media/disk/coa-saw5-r5.avi
fe6c396c9ad3199d1dcaa020023753f3 coa-saw5-r5.avi.2
Copying from USB to PC doesn't seem to do it...?
No wonder all my images get corrupted when i transfer from G1 to PC. I end up with half images and sometimes unreadable ones.
For example....
just a heads up for everyone.
i bought two ferrite cores and put them on each end of the USB cable. no more data corruption. equal md5sums every single time.
so in conclusion:
if you experience data corruption, buy ferrite cores and stick them on your usb cable, or use a cable with integrated ones
infernix said:
i bought two ferrite cores and put them on each end of the USB cable. no more data corruption. equal md5sums every single time.
Click to expand...
Click to collapse
The principal source of the RF is probably the computer, so most data cables for small electronics only have one ferrite core near the terminal end for the computer. One core should be sufficient.
I'm glad someone else was having this problem I felt baffled by it. I was looking forward to using phone as storage medium but kept getting errors durring large transfers. Do you think the RF from the phone itself may be the problems since I can use longer cables for eternal drive copy, or is it simply a power vs signal fragility problem?
Hey folks. I put some instructions up that state how to make a G1 Serial to USB adapter. This could be handy for kernel hackers and could be modified too for other purposes which I plan to explore...
http://www.instructables.com/id/Android_G1_Serial_Cable/
Enjoy, and please leave comments on the instructables website if you see something wrong or confusing!
CMOS vs TTL levels can mean the difference between a functional device and a dead UART.
anyone know if it's actually 5v tolerant or does in fact require CMOS voltage level?
I can tell you the G1's pins output 2.8v. I think I would stick close to that. The only reason I used the 3.3v cable is because I have seen pictures of a cable an actual android dev has allegedly used 3.3v levels.
Did you find the instructions confusing since I claimed CMOS-TTL? I actually switched it to just say 2.8v levels now to be safe. I guess saying TTL was a bad word choice since it can go up to 5v although I do specify you need a 2.8 or 3.3v serial to usb adapter in the required materials section.
Nice.
Next step is to disconnect the console and allow control of rs232 devices from the phone.
Working on it You need to disable H2W and PIQ AFIK.
ya it was the TTL that made me second guess.
I have several TTL level uarts that will smoke CMOS level inputs. I wasn't about to try one of them unless you had said you did with no problems.
2.8 is odd, but i imagine it's still some form of low voltage MOS and can handle 3.3v without problems.
macpod said:
Working on it You need to disable H2W and PIQ AFIK.
Click to expand...
Click to collapse
Thanks for the great tutorial !
I've compiled a kernel with CONFIG_TROUT_H2W, CONFIG_MSM_FIQ_SUPPORT and CONFIG_MSM_SERIAL_DEBUGGER unset
I understand that the UART port appears as /dev/ttyMSM2, however I can't measure anything on the TX pin when sending data from the Dream, i.e :
echo "Hello" > /dev/ttyMSM2
Have you succeeded in transmitting data in any direction ?
What are you using to measure? A multimeter isn't going to work.. you would need a scope.. or serial device of compatible voltage levels able to run at the g1's baud rate.
I didn't have a build env setup on my computer and I only got everything setup/compiled last night because of the cupcake merge into master (I might post instructions on how to build everything before the march 18th merge if there is interest).. so I haven't had a chance to disable the debug console/etc and test yet. I plan to work on that tonight and tommorow.
Some interesting things I have found sofar and questions if you guys happen to be researching this stuff:
-Booted normally you get a "debug>" prompt. ps works.. but I haven't researched what other commands are possible. What have you guys found?
-With the phone powered off, if you plug the serial cable in and read it, it tells you the charging mode and some other characteristics/etc.
-The engineering spl has a serial console you can send commands to. I haven't research what commands are possible yet.. again, what have you folks found?
edit: I bet if you attached a piezoelectric speaker between the tx and gnd pins.. then piped /dev/urandom to /dev/ttyMSM2, you could test that way too.. but that's unconfirmed.
Thanks for your answer, I was measuring with a scope.
I'll try again with a default msm_defconfig'd kernel and see if I get a console.
Looking forward to hearing of your tests !
macpod said:
-The engineering spl has a serial console you can send commands to. I haven't research what commands are possible yet.. again, what have you folks found?
Click to expand...
Click to collapse
Not only the engineering spl has that. You can use either usb or serial to talk to the interface. What is more interesting : Serial lets you talk to the radio directly (oemsbl) and outputs debug info. Access to all commands is only given using engineering spl and security unlocked device. The commands however are already in the wiki.
macpod said:
edit: I bet if you attached a piezoelectric speaker between the tx and gnd pins.. then piped /dev/urandom to /dev/ttyMSM2, you could test that way too.. but that's unconfirmed.
Click to expand...
Click to collapse
Totally confirmed. Sounds just like a good old modem
Cya,
Viper BJK
Ok, taxes put me on hold.. but I'm back and have it working. Here is the config file I used to compile the kernel.
Speed is set to 9600 8N1, the G1 serial device is /dev/ttyMSM2. If you were curious, /dev/ttyMSM0 is bluetooth related.
I'll post up instructions later on how to compile and install it as well as a boot.img for convenience if folks are interested.
macpod said:
Ok, taxes put me on hold.. but I'm back and have it working. Here is the config file I used to compile the kernel.
Speed is set to 9600 8N1, the G1 serial device is /dev/ttyMSM2. If you were curious, /dev/ttyMSM0 is bluetooth related.
I'll post up instructions later on how to compile and install it as well as a boot.img for convenience if folks are interested.
Click to expand...
Click to collapse
Great, thanks a lot for all your contributions! I am looking forward to your instructions.
Hi all xda users ,
Thank you for your work macpod.
I am looking forward to your instructions also.
TIA
regards,
Maciej
I would love to get a boot.img as well, I'm not very skilled with all that and only want the serial console to interface the G1 with my Arduino.
Just ordered the parts for this. Thanks.
Okay, I got it working! Instructions are for Ubuntu only, sorry. I believe you need a rooted phone with engineering (or hardspl or comparable fastboot-enabled) bootloader and macpods serial to usb cable (or something comparable).
1) Compile Android source with Dream-specifics as described by this. You probably only need prebuilt and kernel, but I'm not very familiar with git and just got everything.
2) cd into the kernel directory, copy macpods serial9600config from above as .config there
3) "make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi- oldconfig" I don't remember if this asks for anything at all, if it does, go with the suggested answers
4) "make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-" - You now have a kernel image for Android 1.0 (I think), but for me it works with JFv1.51 as well
5) You can now compile fastboot in $ANDROIDSOURCE/system/core/fastboot or grab the precompiled binary from http://android-dls.com/files/linux/fastboot
6) Hook up your phone, power off, start with camera+power. Press back when the skating androids appear to switch to fastboot mode.
6) Do ./fastboot boot $ANDROIDSOURCE/kernel/arch/arm/boot/zImage and wait. This takes a moment, then it should start.
You know should have /dev/ttyMSM2 which you can echo into (echo "hello world" > /dev/ttyMSM2) or listen to (cat /dev/ttyMSM2). For instance, I'm building an Android app that passes GPS coordinates over the console to an ArduPilot board and will provide telemetry to a ground station. Testing it with "Serial port terminal" from the Ubuntu repository works as well (remember to choose 9600 bauds and the right port).
Thanks to to macpod for his excellent work and help with building the cable, Google for providing such a kick-ass (somewhat) open phone and all the kernel hackers and rooters for their work.
I just wrote this from the top of my head, just post if you have trouble getting this to work.
edit: I attached my kernel image, which should allow you to skip steps 1 - 4 if you're so inclined.
do you guys think this will help all the bricked devices? just a question i don't have a bricked device to test but would be nice if did
So let me get this straight? The cable allows direct access to the motherboard and all the hard were in it? Sorry i am a complete noob
Well, I don't know nothing about bricked devices, but if you can still get them into fastboot mode, you can flash every partition on the phone, so you should be able to resurrect it.
The cable normally allows you access to a debug console (you see kernel outputs while booting, then get a console). I don't know what that is for (maybe USB debugging for developing apps, dunno. I read somewhere that you can directly access the GSM chip, issue AT commands and the like). You'd need to look into that. And with a custom kernel you get a regular serial console trough that extended USB port on your phone, just like telnet'ing into your phone or whatever. Normal unix stuff. And this console can be accessed from Android apps as well.
do we know what config options/boot options should be used, so we can receive the kernel output while it loads from serial?
2/22/11 Update: Froyo kernels include tethering support, so this patch is no longer necessary. A Froyo-compatible Wired Tether client is available here.
12/20/10 Update: Added patch to wired-tether client to clamp MSS. Fixes stalled connections when the network breaks fragmentation support.
10/18/10 Update: The MixUp-20101024-847 kernel now includes USB tethering (RNDIS) support. If you have this kernel installed, you should be able to USB tether by installing the modified android-wired-tether client attached here.
Troubleshooting Update: If the client force closes on you and you're using a ROM with android-wifi-tether preinstalled, then there is a library conflict. Remove android-wifi-tether from /system, and most importantly, delete (or rename) /system/lib/libnativetask.so, then android-wired-tether should work. If you want both wifi & wired tether, reinstall android-wifi-tether from the market. This will make each application use its own library so there's no more conflicts. See this post for more details.
Attached is a patch to the DI18 kernel sources to enable USB tethering support with android-wired-tether. Kernel developers, please feel free to include this patch in your kernel builds. It requires no configuration changes.
This patch requires use of a modified wired-tether agent (at least, until the change is commited upstream). A modified build of wired-tether is also attached, along with the source patches against upstream v1.4 (SVN r34).
Also attached is a build of the stock DI18 kernel with the kerel patch applied. It's compiled with CodeSourcery Lite 2009q3-68 with stock config options, stock initramfs (so no root, no clockworkmod support). It's intended for folks who want to try this right away, and know how to restore their old kernel if need be.
Directions:
To install the test kernel, look for a copy of redbend_ua in any of the kernel update.zip packages, install with:
Code:
adb push redbend_ua /data/local/tmp
adb push zImage /sdcard
adb shell
su
chmod 755 /data/local/tmp/redbend_ua
/data/local/tmp/redbend_ua restore /sdcard/zImage /dev/block/bml7
Then install the attached wired-tether-1.4-epic-2.apk. Tethering may be used with "USB debugging" enabled or disabled. However, neither mass-storage support nor ADB will be availble while actively tethering. To use:
(Windows only) Install the Samsung USB drivers. No other drivers are needed for Windows 7, and I think Windows XP SP3.
Make sure the USB cable is unplugged before starting the tether client.
Start "Wired Tether" and "Press to start tethering."
Grant the Superuser Request (if your su requires it).
Make sure tethering has started, you should see green/red "Down/Up" numbers at the bottom of the screen.
Attach the USB cable.
Select "Charging" mode if the "Select USB mode" menu comes up (it won't if USB debugging is enabled).
Tether!
When finished:
Detach the USB cable.
"Press to stop tethering."
Grant the Superuser Request (if your su requires it).
Exit the "Wired Tether" program.
Reattach the USB cable if you want to use mass-storage or ADB.
Technical details (for those interested, otherwise ignore):
The Epic kernel already provides RNDIS USB support in the USB gadget driver, however the host-side RNDIS interface is never presented. The kernel patch adds a sysfs variable that, when enabled, configures the host-side USB to exlusively present the RNDIS interfaces, and when disabled, reconfigures the host-side USB back to the previous state, either mass-storage (actually typically "KIES" mode) or ADB. You may toggle this variable manually, for example, if you wanted to use the RNDIS interface for other purposes. Just be sure to toggle when the USB cable is unplugged:
Code:
su
echo -n 1 > /sys/devices/virtual/sec/switch/rndis_enable # Enable RNDIS.
echo -n 0 > /sys/devices/virtual/sec/switch/rndis_enable # Disable RNDIS, reenable UMS or ADB.
The wired-tether patch simply toggles the sysfs varible upon starting and stopping tethering. Since the host-side USB interface will only reconfigure upon cable reinsertion (I think?), this is why the cable must be attached/detached only while tethering is enabled.
Note that the host-side RNDIS interface is exclusively presented--it may not be used simultaneously with mass-storage or ADB. This is a limitation of the Samsung Windows driver and will not be fixed. The previous version of the kernel patch (10/8) did present RNDIS alongside ADB, which is a mode of operation generally supported by Linux. However, the Samsung drivers need to be modified to support this mode (necessitating a reinstall) and as it turns out, driver bugs presents the along-side configuration from actually working. Because of this, and reports from Ubuntu users of losing ADB with the previous version, this patch only uses "blessed" host-side USB configurations.
Nitty grity details:
I'm not precisely sure what "Tethered Mode" is, that shows up in the menu when you plug in a USB cable with debugging disabled. From the USB gadget driver code, it appears to disconnect one (or both) of the 3G/4G modems and presents it over the USB interface directly, not allowing it to be shared with the phone. This may use the RNDIS interface (hence why it's "supported" in the first place), or may expose a serial UART. I've never tried it, and I'm uncertain (from the driver code) that it actually works.
Amusingly enough, it should be possible to enable the RNDIS interface even with the stock kernel. However, the gadget driver code is very buggy, and the existing sysfs interfaces do not operate as advertised. Even if you "game the bugs" to work around them, you'll lose ADB support until the phone is restarted. Since I would have to modify the kernel to fix these bugs, I decided to just present a new interface that mirrors the behavior of ADB mode, to keep the patch simple to maintain.
If you want to follow along though, the two relevant parts of the USB gadget driver are "adb_ums_acm_mtp_rndis.c" and "fsa9480_i2c.c" (in "drivers/usb/gadget"). "adb_ums_acm_mtp_rndis.c" contains host-side USB interface configurations for UMS mode (default), ACM/UMS/ADB (USB debugging), ACM/MTP (disabled), MTP (disabled), RNDIS (basically unused), and ACM only (disabled). The two functions that appear to switch between configurations are enable_adb() and enable_askon().
At first I thought enable_adb() was used by "USB debugging" mode, and enable_askon() by the "Charging/Mass Storage/Tethered Mode" menu, but this isn't the case. Turns out enable_adb() is the only of the two actually used, and enable_askon() is buggy dead code that, for example, doesn't set the current USB configuration status so it's not possible to switch back to the previous configuration.
"fsa9480_i2c.c" contains, among other things, a variety of show/store functions exported as (world-writeable!) sysfs variables in /sys/devices/virtual/sec/switch. I can't tell if these were intended for internal debugging only, or if they were intended to be used by userspace (e.g., the "Select USB mode" menu). The two interesting interfaces here are UsbMenuSel and AskOnMenuSel, which should take a USB device configuration nickname (e.g., "UMS", "KIES", "VTP") and set the host-side USB configuration accordingly. However, the "if/else if/else" lists in both functions are broken, and the "else" clause is often executed when it shouldn't. Interestingly enough, the default host-side USB mode appears to be "KIES", although I'm unsure if that's intentional or due to this bug. But this doesn't matter since the ACM/MTP configuration is disabled and UMS is used in its place.
In other words, the USB gadget driver code is a misleading rats nest of buggy/dead code. It's a wonder it actually works in the first place. I really hope the rest of the device-specific code isn't that bad, but I'm afraid to look.
Mirror links (does not require forum login):
kernel_rndis_enable.diff
kernel_rndis_enable.zip
wired-tether-1.4-epic-2.apk
wired-tether_use_stable_api.diff
wired-tether_clamp_mss.diff
wired-tether_rndis_enable.diff
Great! I was working on a patch for this earlier but didn't have the time! Thanks, t'will be in my next kernel
Sweet. Was waiting for dev to bring this so i can install wired tether
saWeet, can't wait for your updated kernel Genius!
Any ideas?
C:\Users\*****>adb shell
$ su
su
# /data/local/tmp/redbend_ua restore /sdcard/zImage /dev/block/bml7
/data/local/tmp/redbend_ua restore /sdcard/zImage /dev/block/bml7
/data/local/tmp/redbend_ua: permission denied
EDIT: Had to chmod redbend_ua to 777 first!
remount
did you remount the drive into read/write mode?
adb shell remount rw
Has any more testing been done with this? Has it been incorporated in Genius' kernel?
Sent from my SPH-D700
Forcystos said:
Has any more testing been done with this? Has it been incorporated in Genius' kernel?
Sent from my SPH-D700
Click to expand...
Click to collapse
Well, it is incorporated but I haven't released yet. I'm still adding some stuff. See my GitHub if you're curious.
Has the download speed been tested using this method? I currently get 1MB using wireless tether and would like to know if my laptop would be able to surf the net faster through this kernel and a USB cord.
The Google Code FAQ says "The client needs to support RNDIS. Windows Vista/7 comes with RDNIS-support out of the box." However when I plug in my Epic it says it needs drivers for RNDIS, and Windows Update does not find any. Anyone know where to get these drivers?
Edit: I'm on Windows 7 64-bit and Herver's Baked Snack 1.3 kernel.
ragnarokx said:
The Google Code FAQ says "The client needs to support RNDIS. Windows Vista/7 comes with RDNIS-support out of the box." However when I plug in my Epic it says it needs drivers for RNDIS, and Windows Update does not find any. Anyone know where to get these drivers?
Edit: I'm on Windows 7 64-bit and Herver's Baked Snack 1.3 kernel.
Click to expand...
Click to collapse
It's a lie.
http://www.microsoft.com/downloads/...FamilyID=46f72df1-e46a-4a5f-a791-09f07aaa1914
You need WMDC on Vista/7.
Firon said:
It's a lie.
http://www.microsoft.com/downloads/...FamilyID=46f72df1-e46a-4a5f-a791-09f07aaa1914
You need WMDC on Vista/7.
Click to expand...
Click to collapse
I plugged in my Epic via USB (with debugging mode on), ran the file from that link (drvupdate-amd64.exe), and I get an error message pop-up saying "Device driver software was not successfully installed" and under details it says
RNDIS Communications Control X No Driver found
Unidentified Device X Device unplugged
I tried this a few times, unplugging and replugging my Epic in. I also tried running the exe without the phone plugging in.
ragnarokx said:
I plugged in my Epic via USB (with debugging mode on), ran the file from that link (drvupdate-amd64.exe), and I get an error message pop-up saying "Device driver software was not successfully installed" and under details it says
RNDIS Communications Control X No Driver found
Unidentified Device X Device unplugged
I tried this a few times, unplugging and replugging my Epic in. I also tried running the exe without the phone plugging in.
Click to expand...
Click to collapse
Reboot, install the driver, reboot again and try plugging it in? Maybe you need the ADB drivers installed too.
I've updated the OP with a new kernel/patch as well as a modified version of android-wired-tether to support the new patch. I've tested it in Windows 7 with the Samsung USB drivers installed (you don't need WMDC as it turns out) and it works.
If you tried the previous kernel, you may want to uninstall/reinstall the Samsung drivers to wipe out any stale device configuration.
Sorry about that folks, I just assumed the old (simpler) patch would work on Windows, but it's very much not the case. Apparently RNDIS support on USB composite devices is flaky, and the Linux USB documentation was recently updated reflecting this.
mkasick is it possible to get a video tutorial of how to get this to work (noob)
docdg said:
mkasick is it possible to get a video tutorial of how to get this to work (noob)
Click to expand...
Click to collapse
Sorry I don't have a video camera.
Anyways, the latest MixUp kernel has USB tethering support. So if you install that, all you need to do is install wired-tether-1.4-epic-1.apk from the OP and follow the directions for starting tetherig half-way down the post; which, in short is just starting the tethering client, tapping the screen to start tethering, the connect your USB cable.
If you're running Windows, you also need the Samsung USB drivers installed (see OP). But if you're tethering with the same computer you rooted the phone with, that should already be done.
Finally got wired tether to work. When I compare the bandwidth speeds with those of easy-tether the speed seems slower. What is the best FREE tethering solution?
docdg said:
When I compare the bandwidth speeds with those of easy-tether the speed seems slower.
Click to expand...
Click to collapse
I suppose this is possible, particularly if your OS's RNDIS driver isn't very good.
I did some benchmarking. I can send data over RNDIS to my phone at 18.7 MiB/s (157 Mb/s) and receive at 14.5 MiB/s (122 Mb/s). That's a little slow relative to the USB 2.0 maximum (480 Mb/s).
However, it's quite a bit faster than the rate I can transfer over 802.11 directly: 2.2 MiB/s (18 Mb/s) sending, 2.0 MiB/s (16 Mb/s) receiving. Tethering USB <-> 802.11 is bounded to about those speeds as well.
I haven't benchmarked 3G, but my past experience suggests is no faster than 802.11. In which case the RNDIS speed should be plenty sufficient unless there's a driver problem.
First, why:
I own two Coby Kyros tablets that I am using as a part-time car headrest entertainment system. Heck, they are so cheap, buying a dedicated car video just does not make sense.
Tablets work great for that purpose, great resolution (for a car), have games and music. There is only one piece that is missing, simultaneous video playback on both tablets.
Getting this working presents two challenges:
* A fast, stable, always ON connection between the tablets.
* A master/slave video playback software, either streaming or syncing
Glad to report, I've solved the first issue, that I'll describe here. Be warned this is not for the faint of hart and right now is fully manual. If you find it helpful I might work on automating the link.
Tested on Froyo. At least one device has to be rooted and support the USB Host mode.
Now, how:
The idea is simple - use the android debugging bridge to forward TCP ports between two systems over USB. If you do have USB tethering enabled on at least one device (I did not) you could use RNDIS to route all traffic, not just specific ports, over USB.
1. Pick a tablet to be the slave. It must be rooted. Get the adb client compiled for android from here, upload it to the slave /system/xbin ("adb push ...") and make executable (adb shell chmod 755...). Get ConnectBot from the market to access its console.
2. Put the slave into the USB Host mode, disable USB debugging on it. Put the master into the USB device mode and enable USB debugging.
3. Connect the master and the slave using a miniUSB-USBfemale and USBmale-miniUSB combination, a USB hub (make sure it is a high-speed one) or a miniUSBmale-miniUSBmale cord.
4. Now the tough part, typing shell commands on the tablet. You can make it a bit easier by using a USB hub and connecting a keyboard and a mouse together with the other tablet to the slave.
On the slave start ConnectBot for the localhost and type the following
Code:
less /proc/bus/usb/devices
Look for your master's devices BUS# and DEV#. Record both. Note, these numbers change when you re-plug USB.
Now, on the slave:
Code:
su
mkdir -p /dev/bus/usb/001/
ln -sf /proc/bus/usb/[BUS#]/[Dev#] /dev/bus/usb/001/001
5. Test. On the slave run 'adb devices'. It should show your master in the list.
6. Forward slave ports to the master as needed. Run 'adb forward tcp:123 tcp:234'. Now you can use localhost:123 on the slave to reach out to the master port 234 over USB.
If your kernel is RNDIS enabled you could route all network connections over the usb0 interface, essentially creating a one-to-one network. Stock Kyros unfortunately does not support RNDIS so I've not tested it.
The ADB USB speed is not bad, averaging 2.5MB/sec after protocol overhead.
I did some research on the second issue, went several routes (mplayer, VLC and UPNP) and, sadly, found nothing that currently works. If you know of any working video source/sink pair or a sync peer for android, let me know.
sicvolo said:
Tested on Froyo. At least one device has to be rooted and support the USB Host mode.
Click to expand...
Click to collapse
Is there a guide on getting USB Host Mode to work on this device or if there isn't could you write one?
I have two Galaxy S3. I went through steps 1-3, all fine. But in step 4, there is no '/proc/bus/usb/devices'; there are only '/proc/bus/input' and '/proc/bus/input/devices'.
Is there any other method to get dev# and bus#? Thanks.
I need to reassemble the firmware for my tablet (RK2918) with Ethernet service disabled by default because it is hungry for power and starting automatically on every reboot. So I have to disable it via menu manually every time. Android 2.3.2
build.prop >> ro.ethernet.autoEnable=no
doesn't work at all or works from time to time until WiFi interface wouldn't be disabled.
Googled all over the world but unsuccessful
What could one modify to disable it?
Up
weired, nobody knows
Perhaps you could remove the kernel driver, the nameofdriver.ko file.
Thank You, Jason! But there is only one wlan.ko
Indeed, there is no wired ethernet adapter in the tablet but I think that it's for support USB-Ethernet via USB-OTG port.
But it's provide a great power saving been disabled. Strange.
Maybe the driver is somehow included directly in the kernel.
In that case you could try to recompile the kernel which would be the hard way. Or the easy way would be to write a script that runs sometime during boot that runs:
ifconfig eth0 down
or
netcfg eth0 down
Substituting eth0 with whatever the name of your ethernet interface is. I know this will bring down the interface but I am not sure if it will shut it off at a hardware level. It is just a matter of finding the right opportunity at boot to run the script.
Thank You.
Yes, netcfg command works but only at logical level, the hardware didn't down.
that's awesome...keep it good work