Related
This is a program I wrote a while back that allows transparent tethering over USB without requiring root access. It works by simulating an unencrypted OpenVPN server and then internally running everything through a Java-based NAT. I get decent speeds off it, but your mileage may vary. It's a bit beta! Might explode! Wear eye protection!
It has a really basic website at http://lfx.org/azilink/, but to spare your eyes I'll just paste the instructions below:
Required files:
- ADB from the 1.1 SDK or from http://lfx.org/azilink/adb.zip
- OpenVPN 2.1 (not 2.0) from http://openvpn.net/index.php/downloads.html
- AziLink.apk from http://lfx.org/azilink/azilink.apk
- AziLink.ovpn from http://lfx.org/azilink/azilink.ovpn
Installation:
1) Install OpenVPN on the host. I use version 2.1_rc15, but any version should work. Apparently if you use version 2.0 you'll need to remove the NO_DELAY option from the AziLink.ovpn configuration file. You can find OpenVPN at:
http://openvpn.net/index.php/downloads.html
2) Enable USB debugging on the phone. From the home screen, this is under
Settings>Applications>Development>USB debugging.
3) Install the Android USB driver (if you don't already have one installed).
See http://code.google.com/android/intro/develop-and-debug.html#developingondevicehardware
4) Install the program. You can either use ADB to install by typing
"adb install azilink.apk" with the file in the current directory, or you can browse (on the phone!) to: http://lfx.org/azilink/azilink.apk
Either way you might need to allow installation from unknown sources
under Settings>Applications>Unknown Sources.
Configuration steps:
1) On the host, run "adb forward tcp:41927 tcp:41927" to set up port forwarding. Be sure to use adb from the Android 1.1 SDK! The version from 1.0 will lock up under heavy load. If you don't want to download the entire SDK, you can get a copy of ADB+drivers from http://lfx.org/azilink/adb.zip
2) On the phone, run AziLink and make sure "Service active" is checked.
3) Right click AziLink.ovpn on the host (not in the web browser!) and select "Start OpenVPN on this configuration file." You can find this file at: http://lfx.org/azilink/azilink.ovpn. If you're using Linux or, god forbid, MacOS, you'll also need to manually set the nameserver to 192.168.56.1 (the phone's NAT IP address).
Nice work around.
Wow, amazing work! I'll definitely have to mess around with this tomorrow...
OpenVPN 2.0.9
Thnx for the manual..!! Took me something to get it working, i'll find out, that it isn't working with OpenVPN version 2.0.9
OpenVPN 2.0.9 doesn't recognize the following rule in azilink.ovpn:
socket-flags TCP_NODELAY
And it worked with version 2.1rc15...
So no more Internet Sharing on Windows Mobile...
OpenVPN 2.0.9
Thnx for the manual..!! Took me sometime to get it working, i'll find out, that it isn't working with OpenVPN version 2.0.9
OpenVPN 2.0.9 doesn't recognize the following rule in azilink.ovpn:
socket-flags TCP_NODELAY
And it worked with version 2.1rc15...
So no more Internet Sharing on Windows Mobile...
help
Ok I'm a complete noob and I've played about with this but can't get it to work. How do I run adb? As in the very first step? Where do I type that. Do I need to install adb and how do I do it?
Thanks
Got it working
Man this is awesome.
I realised i needed to run the adb from cmd. see when i tried to open adb.exe it just kept closing.
thanks alot. this rocks
ps im writing this off my tethered pc
zecbmo said:
Ok I'm a complete noob and I've played about with this but can't get it to work. How do I run adb? As in the very first step? Where do I type that. Do I need to install adb and how do I do it?
Thanks
Click to expand...
Click to collapse
Nah, you can just unzip adb and run it directly from that folder. It's a command line program, so you'd need to run it from a command prompt (cmd.exe). I'm not sure whether adb needs to run as an administrator or not (I disable all that UAC garbage in Vista). If you have the proper driver installed, then the ADB command should return immediately without saying anything. If it says "waiting for device..." that means it wasn't able to find the Android debug driver.
I know this is all a bit hacky, but now that we've got root and wifi tethering I figured that there wouldn't be too much interest.
cheers
its working great like. im using this cus i havent rooted my phone yet. tethering was the only reason why i wanted to root it but this is a great alternative
Works Great. Thanks for the easy instructions.
Here is translation of post on Russian with images http://androidteam.ru/faq/azilink-tethering-with-android-usb.html
I have repacked all in one zip, and make some command files to make process a little easy.
another trick that may help on XP machines, probably other versions as well.
Create a shortcut to adb.exe on your windows desktop (mine is located in C:\and\tools)
Modify the 'target' (right-click,properties) of the shortcut to read C:\and\tools\adb.exe forward tcp:41927 tcp:41927 <I think this is the right code, I'm still using tetherbot on 1080>
That's it. Once everything's set up connecting is easy. one click on the computer, no cmds required
does this allow for media such as flash on web site to play on the laptop?
clevetbs said:
does this allow for media such as flash on web site to play on the laptop?
Click to expand...
Click to collapse
If you've got enough bandwidth. I'm not really sure what bitrate flash video runs at though.
Many thanks for this, aziwoqpd. I've not had the time to root, but have been looking for an easy way to tether. A usb connection is great, since the battery drains so quickly anyway it's nice to keep a charge going.
sonikamd - thanks for the suggestion, it's a great idea. Unfortunately my XP doesn't want to accept your syntax. I wish I could offer something else, but my skills (ha!) are nonexistant. I'm embarassed to say that I had to refresh my memory on how to maneuver around command lines...
Got any other suggestions?
Thanks again for all your work!
the AziLink.ovpn file wont download for me.
works fine for me, GREAT WORK!
Okay, so I'm trying this out on a mac. I've successfully built openvpn and have my tunneling device (/dev/tun0, /dev/tun1, etc.). I run the adb forward command and it starts the daemon successfully, I fire up azilink on the phone and it says it's waiting for the connection, I fire up openvpn and the phone changes to stating that it's connected. Openvpn does not exit out - it starts the tunnel - BUT in the logging it reports " ROUTE: problem writing to routing socket" twice (which oddly appears to be a non-fatal error to the application), and traffic is unable to flow. I'm guessing it's something about openvpn not correctly manipulating the darwin routing tables, but I've been unsuccessful thus far in figuring out the nature of the problem so I thought I'd check here.
I'm running the straight azilink openvpn config file, which means if I need any syntactical changes for darwin I haven't applied them. The openvpn documentation is not terribly good and I was unable to find any documentation of routing command differences for MacOS (if that's even the problem, of course).
Edit: I forgot to mention, I've been trying to ping known-good IPs by address to test the routing - after my first attempt at loading a web page failed I figured it best to remove name services from the possible list of problems. The bytes sent count was slowly incrementing (up to about 23K bytes in ten minutes of diagnosis), and the inbound count got up to about 900 bytes in the same period, so clearly *something* was getting through - unless those counters are counting all traffic into and out of the phone and just going over the cable - but I got no ping responses, no websites could load, and by all appearances from the terminal, no data was moving.
lindsayt said:
I'm running the straight azilink openvpn config file, which means if I need any syntactical changes for darwin I haven't applied them. The openvpn documentation is not terribly good and I was unable to find any documentation of routing command differences for MacOS (if that's even the problem, of course).
Edit: I forgot to mention, I've been trying to ping known-good IPs by address to test the routing - after my first attempt at loading a web page failed I figured it best to remove name services from the possible list of problems. The bytes sent count was slowly incrementing (up to about 23K bytes in ten minutes of diagnosis), and the inbound count got up to about 900 bytes in the same period, so clearly *something* was getting through - unless those counters are counting all traffic into and out of the phone and just going over the cable - but I got no ping responses, no websites could load, and by all appearances from the terminal, no data was moving.
Click to expand...
Click to collapse
The byte counters only include traffic that OpenVPN is forwarding, so something is making it over. Did you try changing the DNS server to either 192.168.56.1 or an external address like 4.2.2.2? OpenVPN on MacOS and Linux won't set the nameserver automatically.
Also, there's a bit of a problem with pinging. The app on the phone can't generate ICMP ping packets since it isn't running as root. When you send an ICMP ping, the phone translates it to a UDP ping, sends it, and translates the reply back to a ICMP ping. Unfortunately, probably about 50% of hosts don't reply to UDP pings. Some that I've tested with that do work are lfx.org and he.net.
I'll see if I can give it a quick test on a Mac sometime tomorrow.
EDIT: I managed to get it working, although T-Mobile's so-called "transparent" web proxy is barely working today so I was having trouble accessing websites without getting errors. SSH was working fine, though. Anyway, here's what I did:
1- Installed a MacOS port of OpenVPN called Tunnelblick (didn't have XCode handy to compile my own and it's got a pretty GUI)
2- Copied azilink.ovpn to /users/azi/library/openvpn or whatever it is
3- Click the Tunnelblick icon in the upper-right, go to details, click "set nameserver"
4- Remove the TCP_NODELAY line because it was complaining that my kernel didn't support it (and would cause my connection to timeout after about 30 seconds).
5- Clicked connect
If you want to see what traffic's going over openvpn, you can just run "sudo tcpdump -n -i tun0"
wow ... this works great ... tested using a german G1 under linux (arch 686), win vista (x64) & win xp (x86) ... pretty good speed and low latency (actually i can't notice any latency at all - no mather if using wlan or 3g)!
GREAT WORK!!!
How i got it working..
You may've seen me nagging around the forums for a sense-ui 2.2 rom with the cifs module in it. It looked like only the non-HTC roms have this module currently, that is, roms with a non-HTC custom compiled kernel.
This got me curious as to why, since people have compiled ext4 and tun modules for it just fine, they're in plenty of HTC kernel based roms.
So i got a cross-compile toolkit last night, and went looking for the closest kernel source i could find, and that turned out to be the msm branch of 2.6.32.9. I haven't even compiled a linux kernel in about 2 years, the last time i worked on kernel code was about 4 years ago, and i've never tried to make a module for a kernel that i don't have the source for. Meaning i got caught out with magic differences due to localversion appends etc, but eventually i built a cifs.ko that'd insmod.
I imagine that's how people made their ext4 and tuns (vpn) modules for the HTC built 2.6.32.15 too. So why no cifs module floating around for it already? Inserting the module fails with missing symbol errors for slow_work functions.
A patch was added after 2.6.31 called slow_work, that essentially stops certain filesystem activities blocking excessively. If you enable cifs in 2.6.32, even as a module, it requires slow_work to be enabled on your kernel. Likewise if you don't enable CIFS then slow_work isn't built into your kernel. Curiously the only two filesystems are cifs and gfs2 that require a slow_work enabled kernel.
HTC made the kernel, they didn't include cifs, it doesn't have slow_work enabled, so you can't fudge a module for it. Well, unless you edit out the slow_work code from the cifs filesystem in 2.6.32. As luck would have it, slow_work provided additional functionality, but didn't replace any.
So i edited out the slow_work code from the cifs headers and source files. Get the module for HTC's 2.6.32.15 below.
Edit: Changed the source from android git 2.6.32.9 to HTC's 2.6.32.15. Updated to remove debug symbols and tidied up the oplock code just in case anyone is writing many files to heavy traffic shared drives. UTF8 module included now also for non-ASCII filenames. Full credit to snq- for the tip on debug symbol stripping, the idea of including unicode support, and making me consider people might use this for writes on busy shares.
http://rapidshare.com/files/413103029/cifs.zip
For anyone interested i cross-compiled this using Sourcery G++ Lite 2010q1-188 for ARM EABI on ubuntu x86 installed to a virtualbox VM, with the 2.6.32.15 kernel source from the HTC incredible.
What's so good about CIFS anyway?
Support for CIFS lets you log into windows network shares from a linux OS and mount them as part of the linux filesystem. How's that any different to the SMB aware file managers like Astro or estrong file explorer? Transparent file streaming.
With a software client you can list and copy files from your windows share to your phone. If you instead mount the windows share into your filesystem, you can use files that're on the server as if they're already on the phone.
For example i'm connected to my home network right now over wifi and just opened a 700MB avi file instantly, as if it were already on my sdcard, instead of waiting 5-10 minutes for it to copy over usb, or half the movie's actual duration for it to copy over wifi.
Combine it with VPN and that's like having your entire movie/music collection on your phone anywhere you can get a broadband connection. No copying, no waiting, no ugly transcoding or streaming media servers, just use the files as if you already put them on the SD card.
The only real limiting factor is when the file's encoded bitrate exceeds your connection bitrate, eg. playing a 320kbit mp3 on a 200kbit EDGE connection.
How do i use this CIFS module?
You need a rooted phone with the official OTA 2.6.32.15 kernel, and possibly busybox too (for a mount binary with cifs support).
Quick and ugly instructions are to download the file above, copy it somewhere on your phone, eg. /sdcard/cifs.ko, and do the following as su in a terminal...
Code:
mkdir /sdcard/share
insmod /sdcard/cifs.ko
busybox mount -t cifs //192.168.0.1/sharedfolder /sdcard/share -o username=user,password=pass
Replace //192.168.0.1/sharedfolder with your windows share server name or ip and the folder you wish to access. Replace user and pass with your username and password, naturally.
For more detailed instructions on automating the mount and umount etc, there's an excellent thread here...
http://forum.xda-developers.com/showthread.php?t=733490
and also..
http://forum.xda-developers.com/showthread.php?t=740695
Note to ROM authors
Any rom authors using 2.6.32.15 who would like to include this module in their rom, you're quite welcome to. You don't need to credit me either, although it would be nice.
Nice work buddy, I will test this out when I get back home.
Nice! Thanks for the module!
FYI: HTC just released the HTC EVO 4G - MR release - 2.6.32 kernel source and
Droid Incredible by HTC (Verizon) - MR release - 2.6.32 kernel source code.
It's working flawlessly!! Thanks you very much for this. And as you looks skilled, now pls try to find a way, how to connect bluetooth keyboard in Sense ROM and you are definitely my hero
insmod /sdcard/cifs.ko -> exec format error
busybox insmod /sdcard/cifs.ko ->invalid module format...
Why is that? Using nextsense with 2.6.32.15 kernel
Thanks
Sent from my HTC Desire using XDA App
maslinar said:
insmod /sdcard/cifs.ko -> exec format error
busybox insmod /sdcard/cifs.ko ->invalid module format...
Why is that? Using nextsense with 2.6.32.15 kernel
Thanks
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
Go to software information on the phone, is your kernel listed as Linux-2.6.32.15-gf9c0527? This module is built for the specific HTC OTA build of the 2.6.32.15 kernel only.
ranwej said:
It's working flawlessly!! Thanks you very much for this. And as you looks skilled, now pls try to find a way, how to connect bluetooth keyboard in Sense ROM and you are definitely my hero
Click to expand...
Click to collapse
It's pretty much impossible to get bluetooth keyboards working on the HTC kernel without it's source code, since it'd require a full kernel recompile to enable it. Although the current HTC kernel has bluetooth HID support enabled, it doesn't have keyboard support enabled in the input devices section. Keyboard support can't be built as a module, only built into a kernel. Sorry!
If anyone is using gscript to automate their cifs mount/umount, i made up a little script to toggle the mount, for use as a gscript homescreen shortcut.
Code:
if test -f /sdcard/sharefolder/mounted.txt
then
busybox umount /sdcard/sharefolder
else
insmod /path/to/cifs.ko
busybox mount -t cifs //192.168.0.2/sharename /sdcard/sharefolder -o username=user,password=pass
fi
busybox df -h
Create a file called mounted.txt in the root of your shared drive, this is used to detect if the share is currently mounted.
replace /sdcard/sharefolder with the name of the directory you're mounting the share on.
replace /path/to/cifs.ko with your path to the cifs.ko module.
replace //192.168.0.2/sharename with your server ip and share name.
replace user and pass with your username and password.
Lastly the df -h is there for visual confirmation whether the share is mounted or not, it'll always be the last line of df -h when it's mounted, the bottom of the gscript window.
Thanks Myshkinbob,
It works
Just one problem.
I add my music as a share, I can play all songs but just a song at a time cannot have a playlist.
Is a way to do this with the default music player? or do I need another player?
Once more thanks Myshkinbob for this.
JoseF
Found solution using Astroplayer
excellent worked great for me
After loading the module and typing this:
Code:
busybox mount -t cifs //192.168.1.5/Shows /sdcard/share/shows -o username=XXX,password=XXX
I'm getting this error:
Code:
mount: mounting //192.168.1.5/Shows on /sdcard/share/shows failed: Cannot allocate memory
Any thoughts?
Demp said:
After loading the module and typing this:
Code:
busybox mount -t cifs //192.168.1.5/Shows /sdcard/share/shows -o username=XXX,password=XXX
I'm getting this error:
Code:
mount: mounting //192.168.1.5/Shows on /sdcard/share/shows failed: Cannot allocate memory
Any thoughts?
Click to expand...
Click to collapse
I had the same error connecting to one computer, if you try to connect using estrongs file manager (free version), that will fail also? Switch estrongs to LAN, hit menu, click new, click scan, then select the PC you're trying to get cifs to connect to. I wouldn't use Astro SMB, it seems a little buggy in 2.2, for me at least.
Just to elaborate, i did all my testing on my desktop pc, windows 7 ultimate x64, and that connected fine. When it came to connecting to my media center pc, windows 7 ultimate x86, i got the same memory allocation error you're seeing.
Estrongs file manager failed to connect also, so i knew it wasn't a cifs module bug. Both machines are on the same network, same firewall settings, it was a real puzzle why the desktop was reachable, and the media pc wasn't.
Does your computer have a long name by any chance? It's a bit bizarre, but my desktop has a very short name, bob-pc, and my mediacenter had a long name, mediacenter-pc. I changed the mediacenter-pc name to media-pc which then required a reboot, and restarted my desire to clear the DNS cache. When i tried now, estrongs file manager could connect, and my cifs mount no longer gave a memory allocation error.
So i'd try pinging 192.168.1.5 from your phone first, then check sharing settings on the pc and that your firewall considers the phone trusted or in a trusted ip range, then if that's all good, try giving the computer a shorter name if it has a long one, and rebooting everything.
I'd recommend you do the connectivity testing with estrongs file manager's LAN - menu - New - Scan, since it rules out any serious user error such as typos in the mount command or mounting to a non-existent directory.
Myshkinbob said:
I had the same error connecting to one computer, if you try to connect using estrongs file manager (free version), that will fail also? Switch estrongs to LAN, hit menu, click new, click scan, then select the PC you're trying to get cifs to connect to. I wouldn't use Astro SMB, it seems a little buggy in 2.2, for me at least.
Just to elaborate, i did all my testing on my desktop pc, windows 7 ultimate x64, and that connected fine. When it came to connecting to my media center pc, windows 7 ultimate x86, i got the same memory allocation error you're seeing.
Estrongs file manager failed to connect also, so i knew it wasn't a cifs module bug. Both machines are on the same network, same firewall settings, it was a real puzzle why the desktop was reachable, and the media pc wasn't.
Does your computer have a long name by any chance? It's a bit bizarre, but my desktop has a very short name, bob-pc, and my mediacenter had a long name, mediacenter-pc. I changed the mediacenter-pc name to media-pc which then required a reboot, and restarted my desire to clear the DNS cache. When i tried now, estrongs file manager could connect, and my cifs mount no longer gave a memory allocation error.
So i'd try pinging 192.168.1.5 from your phone first, then check sharing settings on the pc and that your firewall considers the phone trusted or in a trusted ip range, then if that's all good, try giving the computer a shorter name if it has a long one, and rebooting everything.
I'd recommend you do the connectivity testing with estrongs file manager's LAN - menu - New - Scan, since it rules out any serious user error such as typos in the mount command or mounting to a non-existent directory.
Click to expand...
Click to collapse
I tried connecting to my other PC last night, and it worked fine, so its a problem with my PC.. I fiddled with my sharing settings so many times that I must have screwed up something in the process sometime.
I'm at work now so I'll do those tests when I get home, but I'm positive it'll work
Great work, really useful for streaming music and video. Maybe I'll create an application to make it easier to mount and unmount during the weekend. It would be really nice to see this module implemented on ROMs, and custom kernels.
Btw, any point in unloading the module? (to conserve battery or any other reason?).
unloading the module i don't think so....but i think that unmounting the share is going to save resources....not sure though
Oh one thing i can think of, disabling media sharing might fix it too. My media center has several accounts on it, all providing an individual share for the accounts media, i got rid of those at some point.
I'm not sure that using modprobe -r to remove the module would make any difference to battery usage, since unless you're actively browsing a cifs mount, the module isn't doing any work. It's probably best to unmount when you're done with your share tho, since i'm not sure how well cifs behaves when the network connection isn't available to a mounted share. It might just keep re-enabling wifi to get access to it.
I've since come across a nasty issue btw, video streaming is fine since it keeps the screen alive, but music streaming has a huge problem; when the screen turns off, the phone drops into sleep mode, and the wifi chipset drops down to keep-alive low power mode.
This destroys wifi bandwidth, a typical VBR 160kbps mp3 stutters like mad, so i'm guessing it leaves wifi at around 60kbps, certainly sub-100kbps.
There are 3 solutions i know of...
1) leave the usb cable plugged into either the charger or the computer, the trickle charge from a usb connection allows the wifi chipset to stay out of low power mode when the screen is in standby.
2) an app called WiFi Fixer, that was made for the nexus one. It was made to prevent wifi dropping completely during sleep mode, which isn't my problem exactly. However, in the options menu there's an advanced option called standby fix 2, or words to that effect, and it's meant to prevent the wifi chipset going to sleep. It's kind of buggy, and so far as i can tell it works by disabling/re-enabling wifi once the phone is in standby, to wake the wifi chipset out of low power mode. Like i said tho, it's far from perfect, and if you're using something like msn talk at the same time, you'll lose your connection to it while it switches wifi on and off.
3) Tinker with the broadcom wifi kernel driver. I -think- this is a module so it might be possible to remove low-power mode from it with the HTC kernel. Certainly this fix is used in some of the custom built kernels available.
I went with option 3, just hacked up the bcm4329 wifi kernel module to prevent it entering full standby mode.
mp3 streaming seems to work okay with the screen turned off now, just going to find some 320kbit to test it properly, or dare i say, some FLAC encodings.
Edit:
Just used http://www.appbrain.com/app/net.avs234 to test and even the mighty FLAC plays cleanly in standby over wifi now. Result!
kernel module posted - http://forum.xda-developers.com/showthread.php?p=7638714#post7638714
Myshkinbob said:
How i got it working..
You may've seen me nagging around the forums for a sense-ui 2.2 rom with the cifs module in it. It looked like only the non-HTC roms have this module currently, that is, roms with a non-HTC custom compiled kernel.
This got me curious as to why, since people have compiled ext4 and tun modules for it just fine, they're in plenty of HTC kernel based roms.
So i got a cross-compile toolkit last night, and went looking for the closest kernel source i could find, and that turned out to be the msm branch of 2.6.32.9. I haven't even compiled a linux kernel in about 2 years, the last time i worked on kernel code was about 4 years ago, and i've never tried to make a module for a kernel that i don't have the source for. Meaning i got caught out with magic differences due to localversion appends etc, but eventually i built a cifs.ko that'd insmod.
I imagine that's how people made their ext4 and tuns (vpn) modules for the HTC built 2.6.32.15 too. So why no cifs module floating around for it already? Inserting the module fails with missing symbol errors for slow_work functions.
A patch was added after 2.6.31 called slow_work, that essentially stops certain filesystem activities blocking excessively. If you enable cifs in 2.6.32, even as a module, it requires slow_work to be enabled on your kernel. Likewise if you don't enable CIFS then slow_work isn't built into your kernel. Curiously the only two filesystems are cifs and gfs2 that require a slow_work enabled kernel.
HTC made the kernel, they didn't include cifs, it doesn't have slow_work enabled, so you can't fudge a module for it. Well, unless you edit out the slow_work code from the cifs filesystem in 2.6.32. As luck would have it, slow_work provided additional functionality, but didn't replace any.
So i edited out the slow_work code from the cifs headers and source files. Get the module for HTC's 2.6.32.15 below.
http://rapidshare.com/files/412285213/cifs.zip
For anyone interested i cross-compiled this using Sourcery G++ Lite 2010q1-188 for ARM EABI on ubuntu x86 installed to a virtualbox VM, with the kernel source taken from the android kernel git.
What's so good about CIFS anyway?
Support for CIFS lets you log into windows network shares from a linux OS and mount them as part of the linux filesystem. How's that any different to the SMB aware file managers like Astro or estrong file explorer? Transparent file streaming.
With a software client you can list and copy files from your windows share to your phone. If you instead mount the windows share into your filesystem, you can use files that're on the server as if they're already on the phone.
For example i'm connected to my home network right now over wifi and just opened a 700MB avi file instantly, as if it were already on my sdcard, instead of waiting 5-10 minutes for it to copy over usb, or half the movie's actual duration for it to copy over wifi.
Combine it with VPN and that's like having your entire movie/music collection on your phone anywhere you can get a broadband connection. No copying, no waiting, no ugly transcoding or streaming media servers, just use the files as if you already put them on the SD card.
The only real limiting factor is when the file's encoded bitrate exceeds your connection bitrate, eg. playing a 320kbit mp3 on a 200kbit EDGE connection.
How do i use this CIFS module?
You need a rooted phone with the official OTA 2.6.32.15 kernel, and possibly busybox too (for a mount binary with cifs support).
Quick and ugly instructions are to download the file above, copy it somewhere on your phone, eg. /sdcard/cifs.ko, and do the following as su in a terminal...
Code:
mkdir /sdcard/share
insmod /sdcard/cifs.ko
busybox mount -t cifs //192.168.0.1/sharedfolder /sdcard/share -o username=user,password=pass
Replace //192.168.0.1/sharedfolder with your windows share server name or ip and the folder you wish to access. Replace user and pass with your username and password, naturally.
For more detailed instructions on automating the mount and umount etc, there's an excellent thread here...
http://forum.xda-developers.com/showthread.php?t=733490
and also..
http://forum.xda-developers.com/showthread.php?t=740695
Note to ROM authors
Any rom authors using 2.6.32.15 who would like to include this module in their rom, you're quite welcome to. You don't need to credit me either, although it would be nice.
Click to expand...
Click to collapse
Combine it with VPN and that's like having your entire movie/music collection on your phone anywhere you can get a broadband connection. No copying, no waiting, no ugly transcoding or streaming media servers, just use the files as if you already put them on the SD card
Please could you please explaine how to do that?
Regards
JoseF
Hi! i got the share mounted but its not unmounting now, i have tried to force unmount also but its not working, i am getting operation not permitted. initially i was getting resource busy. Any ideas?
lept0n said:
Hi! i got the share mounted but its not unmounting now, i have tried to force unmount also but its not working, i am getting operation not permitted. initially i was getting resource busy. Any ideas?
Click to expand...
Click to collapse
I get this occasionally, usually it's some background task that was using the share, such as a file explorer, music or movie player. Even though they weren't currently in the shared directory, they still prevented me unmounting. Killing all media/file explorer apps should let you unmount.
you seem to have compiled your module with debugging options, that's why it's size is about 3MB
you might want to strip debugging symbols and sections (just them) with arm-eabi-strip --strip-debug (or arm-none-eabi-stip in your case)
Myshkinbob said:
As luck would have it, slow_work provided additional functionality, but didn't replace any.
Click to expand...
Click to collapse
except for the whole oplock break handling
i took a slightly different approach (patch provided):
h**p://forum.xda-developers.com/showthread.php?t=754793
(sorry, beeing a new user i am not yet permitted to post links)
tried this last night and works great
Found the stock movie player lags a bit but rockplayer works fine.
How do you set up an VPN SSL conection in Windows 7?
I've tryed but didn't works
DISCLAIMER:
It is extremely illegal to use this app against networks you don't own or don't have a permission to attack. I am not responsible for how you use it and any damage you may cause. Consider yourself warned.
Hijacker is a Graphical User Interface for the wireless auditing tools airodump-ng, aireplay-ng and mdk3. It offers a simple and easy UI to use these tools without typing commands in a console and copy&pasting MAC addresses.
This application requires an android device with a wireless adapter that supports Monitor Mode. A few android devices do, but none of them natively. This means that you will need a custom firmware. Nexus 5 and any other device that uses the BCM4339 (and BCM4358 (although injection is not yet supported so no aireplay or mdk)) chipset will work with Nexmon. Also, devices that use BCM4330 can use bcmon.
The required tools are included in the app. To install them go to Settings and click "Install Tools". This will install everything in the directory you select. If you have already installed them, you don't have to do anything. You can also have them at any directory you want and set the directories in Settings, though this might cause the wireless tools not being found. The Nexmon driver and management utility is also included.
Root is also necessary, as these tools need root to work. If you don't grant root permissions to it, it hangs... for some reason... don't know why...
Features:
View a list of access points and stations (clients) around you (even hidden ones)
View the activity of a network (by measuring beacons and data packets) and its clients
Deauthenticate all the clients of a network
Deauthenticate a specific client from the network it's connected
MDK3 Beacon Flooding
MDK3 Authentication DoS for a specific network or to everyone
Try to get a WPA handshake or gather IVs to crack a WEP network
Statistics about access points (only encryption for now)
See the manufacturer of a device (AP or station) from a OUI database (pulled from IEEE)
See the signal power of devices and filter the ones that are closer to you
Leave the app running in the background, optionally with a notification
Copy commands or MAC addresses to clipboard, so you can run them in a terminal if something goes wrong
Include the tools
Reaver WPS cracking (pixie-dust attack using NetHunter chroot)
.cap files cracking with custom wordlist
Let the user create custom commands to be ran on an access point or a client with one click.
Installation:
Make sure:
you are on Android 5+
you are rooted. SuperSU is required. If you are on CM, install SuperSU
have installed busybox (opened and installed the tools)
have a firmware to support Monitor Mode on your wireless interface
Download the latest version here.
When you run Hijacker for the first time, you will be asked whether you want to set up the tools or go to home screen. If you have installed your firmware and all the tools, you can just go to the home screen. Otherwise, click set up to install the tools. You can change the directories in which they will be installed, but I recommend that you leave them unchanged. The app will check what directories are available and select the best for you. Keep in mind that on some devices, installing files in /system might trigger an Android security feature and your system partition will be restored when you reboot. After installing the tools and the firmware (only Nexmon) you will land on the home screen and airodump will start. If you don't see any networks, make sure you have enabled your WiFi and it's in monitor mode. If you have a problem, go to settings and click "Test Tools". If they all pass, you probably don't have monitor mode enabled. If something fails, click "Copy test command" and select the tool that fails. A sample command will be copied to your clipboard so you can open a terminal, run it, and see what's wrong.
Keep in mind that Hijacker is just a GUI for these tools. The way it runs the tools is fairly simple, and if all the tests pass and you are in monitor mode, then you should be getting the results you want. But also keep in mind that these are AUDITING tools. This means that they are used to TEST the integrity of your network, so there is a chance (and you should hope for it) that the attacks don't work on a network. It's not the app's fault, it's actually something to be happy about (given that this means that your network is safe). However, if an attack works when you type a command in a terminal, but not with the app, feel free to post here to resolve the issue. This app is still under development so bugs are to be expected.
Troubleshooting:
First of all, if the app happens to crash at a random time, run it again and close it properly. This is to make sure that there are not any tools still running in the background, as this can cause battery drain. If it crashes during startup or exiting, open a terminal, run `ps | busybox grep -e air -e mdk` and kill the processes you see.
Most of the problems arise from the binaries not being installed (correctly or at all). If that's the case, go to settings, click "install tools", choose directories for binaries and the lib (libfakeioctl.so) and click install. If the directory for your binaries is included in PATH, then you don't have to do anything else. If it's not, the you need to adjust the absolute paths of the binaries, right below the "install tools" option. This might also cause problems (especially with mdk) since these programs require the wireless tools to be installed, and they won't find them if you install them anywhere other than the paths included in your PATH variable. If you don't know what the PATH variable is, then you probably shouldn't be using any of these programs.
If you are certain that there is problem with the app itself and not the tools installation, open an issue here so I can fix it. Make sure to include precise steps to reproduce the problem and a logcat (having the logcat messages options enabled in settings). If the app happens to crash, a new activity should start which will generate a report in /sdcard and give you the option to email it to me directly. I suggest you do that, and if you are worried about what will be sent you can check it out yourself, it's just a txt file and it will be sent as an email attachment to me.
XDA:DevDB Information
Hijacker, App for all devices (see above for details)
Contributors
chrisk44
Source Code: https://github.com/chrisk44/Hijacker
Version Information
Status: Testing
Current Stable Version: v1-RC.4
Stable Release Date: 2016-12-23
Created 2016-11-14
Last Updated 2016-12-26
Reserved
thank you
works great on my nexus 5 and note 3
not working on s6 edge problem i dont know i already installed in my device correctly and also hijacker airdump shows networks for attacking but not do real attack
Hi All,
My first post here, I am not sure I am posting in the correct section.
I need to update the wpa_supplicant conf of my Andorid 9 phone (an Asus Zenfore Max Pro M1) in order to allow it to connect to a MFP (managed frame protected) network.
I managed to configure my home linux machines to do so but with my Android phone it is a disaster.
From what I know the device needs to be rooted...for this I am just proceding with the proper steps but...I am not sure that the wpa_supplicant.conf to be modified is the one settled in the /etc directory as I ve read that on Android the conf file for the wpa_supplicant service may be different.
Is there any way to understand which configuration files a binary executable is bound with?
What I am trying to do is to set the pmf option in the correct wpa_supplicant.conf file in orded to let the device connect to a MFP network.
Any help will be so much appreciated.
Thanks!
Well...it is nice to discover that Android 9 is not using wpa_supplicant any more and that it will be a nightmare to crosscompile it and configure it as a daemon
This is my last android shxt phone.
A quick search reveals that WifiConfigStore.xml should be the file you want. requirePMF might help, from source for WifiConfiguration.java. I can't find any more documentation than that (opening source files kills my phone browser) but that should be a good start.
Thanks Efreak2004 but have tried that way as well.
Have modified the WifiConfigStore.xml by setting to true the requirePMF option but it did nothing.
My suspect is that the java wrapping useless stuff is not doing anything more than trying to "steer/drive" the native processes preposed to do the job. It has always be this way since the invention of java which was wrapping lib C in any aspect.
I am almost convinced that without the wap_supplicant binary/daemon there is no way to let the java fancy wifi manager do the job by its own.
Is there an updated XDA tutorial yet on setting up adb COMPLETELY wirelessly as of Android 11?
Why do I ask?
Using adb is a critical developer/hacking/user tool
As of Android 11, adb has been fundamentally changed for Wi-Fi
As of Android 12, adb was further improved for Wi-Fi
The existing XDA Developers' tutorial doesn't contain that info
I figured it out on my own (see below)...
(Which meant a LOT of new questions popped up that had to be solved that could have been answered in a tutorial)
Unfortunately, almost everything out there that I can find about adb is (wrong / inaccurate / incomplete [choose one]) in terms of how to set up a wi-fi connection as of Android 11 & 12.
The problem is there are important questions to be solved that are MISSING from that old tutorial
(These problems revolve around connection completely from the PC side only)
Where I would think EVERYONE would have the SAME questions as I do about the new setup
(And for which an updated XDA Developers' adb tutorial would be very useful!)
Mostly these new Android 11+ Developer options Wireless debugging features eliminate the USB cable.
But that then instantly brings up the non-intuitively fundamental question of ESTABLISHING the connection solely from the PC...
(which - let's never forget - is how the older, well documented USB-cable-first-then-Wi-FI adb connection had always been done)
Hence my question of:
Is there an updated XDA tutorial yet on setting up adb COMPLETELY wirelessly as of Android 11+ & 12+?
DETAILS:
Spoiler: Short summary of steps which should be in a tutorial
Given how important adb is to Android software development and hacking, I searched for an XDA Developers writeup on how the newly added Android 11+ Developer options Wireless debugging works and which incorporates a few of the even more newly added Android 12+ Developer options Wireless debugging tiles (which are CRITICAL but it's not obvious to those who haven't done it why those new Android 12 tiles have to be used every day all day!) & Android 12's separate ability to randomize the phone's MAC address for every Wi-Fi connection for added privacy (not just for every Wi-Fi SSID as Android 11 did it) which itself has further implications for reserving IP addresses (usually erroneously referred to as "static IP addresses" in the router and on the phone) for those daily random-port connections using adb over Wi-Fi only. You can no longer connect "from" the PC until after you physically "look" (using live human eyeballs!) to locate either the random port assignment (for "adb connect") or a different random port assignment plus a random pin assignment (for the new Android 11+ encrypted "adb pair" command). Now you can connect via adb over Wi-FI from the PC. But bear in mind the catch! Frequently (upon reboot for example), the Android 12+ tile turns off, as does the Developer options:Wireless debugging toggle, as does the Wi-Fi connection (in my case for privacy, as I have Wi-Fi toggle off when I leave the range of the LAN - which then turns off Wireless-debugging in an unintended cascade) but more importantly, frequently the random port assignment changes as does the random pin assignment. So you have to perform the all-important human-eyeball LOOK frequently - which you would rather not need to do if you could help it
Whew! I said what "should" be in a tutorial so others don't have to figure all of that out on their own just to set up adb completely wirelessly (without first establishing a USB connection on the PC).
I figured it all out, of course, but that XDA Developers writeup didn't help (in fact it hurts)... because it contained completely outdated information (which is why I wrote that long paragraph above, to summarize what's completely missing).
Here's what needs to be done on the phone:
Enable Wi-Fi (mine is set up to NOT auto-reconnect, for privacy)
Establish a connection over Wi-Fi to an SSID on your LAN
Enable Developer options:Wireless debugging (Android 11+)
Enable Developer options:Wireless debugging Tile (Android 12+)
Enable random MAC address per SSID (Android 11) or per connection (Android 12+)
Enable the (so-called) static IP address of the phone
Physically eyeball the random Wireless debugging port assignment (&/or random port + random PIN)
Note all the questions are related to the fact everyone wants to eliminate that last step above!
On the PC:
Simply assure yourself that the phone is on the LAN (e.g., ping 192.168.0.2) (duh)
Remember - it's using a RANDOM MAC address so the router has to be configured for that
Then connect from the PC adb to the phone completely over Wi-Fi (encrypted or not)
Remember - there's no initial establishment via USB - which means you need to know random ports!
adb connect 192.168.0.2:12345 (or) adb pair 192.168.0.2:12345 123456
Remember - everyone's goal is to obtain those random ports 100% from the PC side of things
You may have to accept an encryption dialog on your phone if this is the first time using that PC
At this point, adb over Wi-Fi works the same as adb has always worked (over USB first, then over Wi-Fi).
Until, of course, Android randomly resets the port assignment - which it does frequently!
Then you're back to having to look at the phone for the random port assignment
Notice that most of the issues people are having (see reference list below) are related to the fact that the random port assignement, as far as we know, can ONLY be obtained from a visual inspection of the Android phone - but also notice that nobody used to need to do that in the olden days (when we connected via USB cable first!).
My observation is nobody wants to do that visual inspection of the phone every time, all day, every day, whenever Android re-randomizes the MAC address (which, for me, happens frequently but my phone is set up specifically for Wi-FI privacy).
In summary, this thread asks if there is an XDA Developers' writeup for connecting adb on the PC completely wirelessly to Android 11 and Android 12 and up.
The REASON I believe that XDA Developers' updated adb tutorial is needed by hackers/developers/users is:
a. The way adb works over Wi-Fi is COMPLETELY DIFFERENT as of Android 11 (this is why finding an updated tutorial is needed!)
b. I had to figure all this out on my own, so that means everyone else does too (unless I missed the XDA Developers' tutorial), and,
c. There are still a ton of open unanswered questions that everyone also has.
REFERENCES: (in no specific order, these are attempts to make it work the way everyone wants it to work!)
(PSA) Using the new Android 12 TILE for 'Developer options' 'Wireless debugging' to establish adb connection over Wi-Fi without USB
What's the difference between Windows/Android adb "connect" versus adb "pair" when mirroring Android 12 over Wi-Fi onto a Windows PC?
Android 12 Developer options adb "Wireless debugging" option keeps turning off
[adb,scrcpy,vysor] What ports does Android 12 randomly set when Wi-Fi connecting via Wireless debugging adb "pair" or "connect" commands?
[adb] What is the adb syntax to connect wirelessly to Android by unique serial number (instead of by Wi-Fi LAN IP address & random port assignment)?
Note that none of those threads would be needed if we could have found a comprehensive tutorial that was updated to Android 11 and 12 new connect-adb-over-Wi-Fi-without-USB functionality that answers those basic obvious questions to ask. (See illustrative screenshots below).
Is an updated XDA Developers' writeup extant for connecting adb on the PC completely wirelessly to Android?
I simply use ladb - it's an app that makes the whole process a breeze
See a big xda write up about it here ..
How to debloat your phone (and more) without connecting to a PC
LADB is an app that lets you run ADB shell commands from your phone, no root and no PC needed! Use it to debloat your phone and more!
www.xda-developers.com
CFKod said:
I simply use ladb
Click to expand...
Click to collapse
Thanks for that advice to use Local ADB which "leverages Android’s built-in support for ADB over WiFi to provide a GUI for sending shell commands straight from the Android device."
The great news is that was the first XDA Developers' tutorial that I've seen that showed cognizance of the new Android 11 features of setting up adb completely wirelessly (without need for USB first).
* GitHub: LADB (A local ADB shell for Android!)
The bad news is that, at least upon initial inspection, ladb doesn't do anything you can't do inside of Termux as far as I can tell (is that correct though - maybe the ladb apk can do more privileged actions?).
Spoiler: Example of doing in Termux what would often be done in adb
1. Install F-droid <https://f-droid.org/>
<https://f-droid.org/F-Droid.apk>
2. Install F-Droid Termux <https://f-droid.org/en/packages/com.termux/>
<https://f-droid.org/repo/com.termux_117.apk>
3. Add F-Droid Termux Widget <https://f-droid.org/en/packages/com.termux.widget/>
<https://f-droid.org/repo/com.termux.widget_12.apk>
4. Run the F-Droid Termux & create an alias we'll name "rad" for reset ad id.
$ rad
(This should report: No command rad found)
$ alias rad 'am start -n com.google.android.gms/.ads.settings.AdsSettingsActivity'
$ rad
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programmatically close it later)
$ cat ~/.bashrc
cat /data/data/com.termux/files/home/.bashrc
No such file or directory
$ alias > ~/.bashrc
$ cat !$
alias rad='am start -n com.google.android.gms/.ads.settings.AdsSettingsActivity'
$ unalias rad
$ rad
(This should report: No command rad found)
$ source ~/.bashrc
$ rad
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programatically close it later)
5. Run the F-Droid Termux and create two directories for the shortcut widget
$ mkdir -p $HOME/.shortcuts (we will put our shell script here)
$ mkdir -p $HOME/.shortcuts/tasks (we didn't use this directory yet)
6. Create a shell script to open up the reset ad id Activity.
$ cd $HOME/.shortcuts
$ nano ./rad.sh
Edit the result to look like this:
#!/data/data/com.termux/files/usr/bin/bash
am start -n com.google.android.gms/.ads.settings.AdsSettingsActivity
$ chmod +x ./rad.sh
$ ./rad.sh
(nothing will happen)
7. Modify termux to be able to execute user shell scripts on Android.
$ pkg install termux-exec
8. Test your shell script.
$ ./rad.sh
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programmatically close it later)
9. Add the Termux Widget to your homescreen.
Long press your Android homescreen.
Select "Widgets" & then "Termux:Widget" & place it on your Android homescreen.
It will ask: Create widget and allow access? to which you press "Yes"
Then press the "rad.sh" entry showing up in that Termux Widget.
"Termux requires "Display over other apps" permission
to start terminal sessions from background on Android >=10."
"Grants it from Settings -> Apps -> Termux -> Advanced"
10. Grant Termux permission to display over other apps:
Android11:Settings > Apps > Your apps > Termux > Appear on top = (change off to on)
11. Now press the Termux Widget entry named "rad.sh"
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programmatically close it later)
12. Reboot the phone & ensure everything is persistent.
Tap the new homescreen icon after rebooting
& the "reset ad id" Activity should pop up.
But worse, the LocalADB instructions clearly say to do the same manual (aurgh!) steps we've been doing all along.
That is, even with LADB, they're still NOT obtaining the random port address programatically; they're getting it manually - just like I've been doing all along without LADB.
So ladb doesn't change anything... as far as I can tell (but maybe I'm wrong?).
"Copy the 6 digit “Wi-Fi pairing code” and paste it into the “pairing code” box in LADB. Copy the 5 digit port number from the IP address (the 5 numbers after the colon) and paste it into the “Port” box in LADB."
Click to expand...
Click to collapse
If I were to "guess" wildly - then that means what everyone wants is perhaps impossible to accomplish; but I'm still hoping that's not the case - but - the point is to find an updated XDA Developers' tutorial that shows an awareness of the stated problem set.
EDIT: I have an idea. I installed LADB on Android, and now I'm trying to see if I can query that LADB from the PC using adb commands where the goal is maybe the PC adb can query the Android ladb to figure out what the current random port assignment is???
GalaxyA325G said:
So ladb doesn't change anything... as far as I can tell (but maybe I'm wrong?).
If I were to "guess" wildly - then that means what everyone wants is perhaps impossible to accomplish; but I'm still hoping that's not the case - but - the point is to find an updated XDA Developers' tutorial that shows an awareness of the stated problem set.
EDIT: I have an idea. I installed LADB on Android, and now I'm trying to see if I can query that LADB from the PC using adb commands where the goal is maybe the PC adb can query the Android ladb to figure out what the current random port assignment is???
Click to expand...
Click to collapse
Yes .. everything you have said is correct
I wouldn't say it has any special privileges. It just guides you through the connection process.
You end up with a blank canvas in terminal - just as you would using termux
Not sure what the app costs, I purchased pre release so cost barely a thing
either way , it cuts out some of the faff and i'd certainly recommend for a less tech savvy person...
Then again.. why wouldn't anyone with no clue, use adb?
If I can assist in any way. Feel free to give me a shout on telegram
CFKod said:
Yes .. everything you have said is correct
Click to expand...
Click to collapse
I must again thank you for letting me know about local adb.
I installed ladb the instant you informed me about it.
Yesterday and today I started to test it out.
CFKod said:
It just guides you through the connection process.
Click to expand...
Click to collapse
I'm hoping maybe this ladb running on the Android device "might" give it something special that the PC doesn't have in terms of access to the information of the random port assignment on Android.
There are multiple levels of this problem set, the top level being the almost complete lack of XDA Developers' tutorials that have any cognizance of what's new in Android 11 and up with respect to adb wireless connections - where - again - I thank you for finding the one and only XDA Developers' tutorial that shows that awareness.
However, the more important level of this problem set is to find a way to connect adb wirelessly to Android WITHOUT manually grepping the random port with our eyeballs.
CFKod said:
You end up with a blank canvas in terminal - just as you would using termux
Click to expand...
Click to collapse
It may very well be that the Android developers made that impossible (e.g., for security reasons); but in the absence of any information or tutorial stating that as a fact, I'm not going to assume it's impossible (yet).
AFAICT, the way to solve the problem is to find a way to either:
a. Keep the port assignment static, or,
b. Set the port to a specific assignment (as we did with USB), or,
c. Determine the random port assignment programatically
It "may" be that local adb can help in that latter method... dunno yet... but I didn't even know ladb existed until you mentioned it so I'm starting from scratch without a tutorial (for this part of the problem set).
CFKod said:
I wouldn't say it has any special privileges.
Click to expand...
Click to collapse
Actually, after looking it up since yesterday, I think local adb DOES have more privileges than does Termux; so I was wrong in that assumption.
The ladb developer, @tytydraco said so himself on Dec 18, 2020 when he announced the existence of the ladb APK on XDA Developers.
tytydraco said:
for those of you who have used or encountered ADB in the past, you know that you usually need a PC to shell into your phone. While yes, apps such as Termux exist, they don't have elevated privileges as ADB does.
Click to expand...
Click to collapse
So we can safely assume ladb has "elevated privileges" which Termux doesn't have (which is a good thing as we may need them!).
CFKod said:
Then again.. why wouldn't anyone with no clue, use adb?
Click to expand...
Click to collapse
Well.... just as "mock location" GPS spoofing is a "Developer option" that has gone mainstream, I suspect we're at an inflection point where with screen mirroring of scrcpy and vysor, that adb usb/wireless debugging has gone mainstream too!
In summary, here's the status so far (which may change over time)...
a. Unfortunately, nobody knows of an updated XDA adb tutorial
b. But there is an updated XDA ladb tutorial
c. But even that ladb tutorial REQUIRES an eyeball grep of the random port assignment (aurgh!)
Note with the brand new Android 12 tile that it's not in the least difficult to do that eyeball grep of the current random port assignment (although you have to get up from your computer to find the phone in order to do so) - but the whole point of computers is they are supposed to do that stuff for you (are they not?).
While it may be designed that way by Google, I'm hoping I can figure out a programatic way to obtain that random port assignment from the PC, where the suggestion of perhaps implementing ladb as a middleman "might" solve that problem (if I can figure out the method).
Thanks for your help and advice, as everyone has the same adb random port assignment problem who wants to mirror their phone onto the PC completely wirelessly - and for which there is no known XDA tutorial to help them (yet).
BTW, I've noticed only recently since I started testing out ladb that the serial numbers are different where I wonder if anyone can explain why there is both a long and a short serial number when using adb completely wirelessly.
Note the question matters because "maybe" we can omit the random port if we can connect via the static serial numbers...
Adb source changes a lot, with the adb wifi stuff being added in, you could probably compile a modified adb binary to use via an apk like ladb that could use a static serial number connection method.
In source, there's a lot of testing binaries you can compile, iirc in maybe 11-dev branch there was some code commented out to allow for more insecure connections.
Hey I have noticed that shizuku also uses wireless adb...
I may have time to test it later.
Surge1223 said:
you could probably compile a modified adb binary to use via an apk like ladb that could use a static serial number connection method.
Click to expand...
Click to collapse
Thank you for that suggestion, because if it was easy to connect purely over Wi-Fi (sans USB) between adb on the PC and the Android 11+ phone (WITHOUT eyeballing the randomly assigned port address), it would have been documented already (since it's what EVERYONE wants to do).
So we're breaking new ground...
And, while I definitely harbor the optimism that there (almost always) is a way, I do agree that nobody on the Internet (that I can find) has found THAT way.
Still... as you suggested, ladb does have some extra "hooks" on the phone itself which may allow ladb to REPORT back to the PC over Wi-Fi what our EYEBALLS have to see for themselves today (of the random port address).
This report back to the PC (of the random port address) over Wi-FI has to be done in some OTHER protocol than adb itself, I suspect... as it's a chicken-and-the-egg scenario otherwise.
BTW, we "might" be able to use the Android serial number to good effect, but probably not as my tests using the Android serial number only work AFTER the adb connection has been prior established.
Code:
C:\> adb devices
*daemon not running; starting now at tcp:5555
*daemon started successfully
List of devices attached
C:\> adb devices
List of devices attached
C:\> adb devices
adb-YFVR80V7YFY-yF7kj8._adb-tls-connect._tcp. device
C:\> scrcpy -s adb-YFVR80V7YFY-yF7kj8._adb-tls-connect._tcp.
C:\> adb connect -s adb-YFVR80V7YFY-yF7kj8._adb-tls-connect._tcp.
C:\> adb connect -s 192.168.0.2
CFKod said:
Hey I have noticed that shizuku also uses wireless adb...
I may have time to test it later.
Click to expand...
Click to collapse
Thank you for that pointer to Shizuku which, like ladb, I had never heard of until you mentioned it as a possible solution.
What's nice is Shizuku has its own updated tutorial on XDA Developers which, at least, is aware of the new Android 11+ Developer options:Wireless debugging toggle, as it says...
"On Android 11 or above, you can enable Wireless debugging and start Shizuku directly from your device, without connecting to a computer."
Click to expand...
Click to collapse
By which they really mean:
"On Android 11 or above, you can enable Wireless debugging and start Shizuku directly from your device, without first needing to connect by USB to a computer."
Click to expand...
Click to collapse
I'm not rooted; but, since Shizuku can be started on the Android device, maybe it can be used to tell the computer over Wi-Fi what the current random port address assignment is (or the unencrypted adb connect command) or the random port and pin assignment (for the encrypted adb connect command).
MOD EDIT: ENGLISH TRANSLATION ADDED
I want to apply this program, Yasser, as much as possible
---------------------------------
ااريدتطبيق هذا البرنامح ياسر مايمكن
MOD EDIT: ENGLISH TRANSLATION ADDED
and not google
-----------
وغير قوقل
زين said:
MOD EDIT: ENGLISH TRANSLATION ADDED
I want to apply this program, Yasser, as much as possible
---------------------------------
ااريدتطبيق هذا البرنامح ياسر مايمكن
Click to expand...
Click to collapse
زين said:
MOD EDIT: ENGLISH TRANSLATION ADDED
and not google
-----------
وغير قوقل
Click to expand...
Click to collapse
1. This thread is a question (mostly) about a missing XDA tutorial.
2. The NEED for the tutorial is embedded in the details
Essentially...
a. We need an updated adb TUTORIAL for Android 11+ new features
b. Specifically, how to connect COMPLETELY via Wi-Fi (no USB)
Keeping in mind...
i. The OLD USE model used adb over USB first
ii. And then, after USB connection, adb could move to Wi-Fi
What we want is...
A. The Android 11+ use model is to eliminate the need for USB
B. But STILL connect using adb over Wi-Fi from the PC
Where...
A. The OLD use model was done COMPLETELY from the PC
B. And we're simply trying to REPLICATE that old use model
However... the problem is...
1. So far, we MUST first ascertain VISUALLY the random port (& PIN)
2. Which means we can no longer connect FROM the PC
That's the problem exposed by this thread, in a nutshell...
But... I do NOT understand what the two posts above are asking us to answer...
a. "I want to apply this program, Yasser, as much as possible"
b. "And not google"
Huh?
A. Which program? (adb? ladb? shizuku?)
B. Who (or what?) is Yasser?
C. And what does "not Google" have to do with it?
D. What does that poster want as an "answer"?
I want to help the guy (just as I'd want to help anyone).
But I don't understand what the heck the guy is even asking.
Can someone translate that English translation to something that makes sense in English that can be answered in English?