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.
This is a PSA for those who mirror their Android phone onto Windows each day that there is a wonderfully convenient new TILE for Wireless debugging.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Android Wireless-debugging tile
That new Wireless-Debugging tile replaces this sequence of commands:
Settings > Developer options > Wireless debugging = on
But a lot of things turn that 'Wireless debugging' switch off on you!
Boot turns W/L debug off
It's not easy to find that new TILE though, where I found it here.
Settings > Developer options > Quick settings developer tiles
Wireless debugging = on
Which gets automatically turned off whenever your Wi-Fi is turned off
(so you're constantly turning it back on if you have Wi-Fi not set to turn on automatically & if auto-reconnect is also off for privacy reasons).
Allow wireless debugging
In summary, this new "developer options tile" for 'wireless debugging" is a great time saver as it's required to mirror Android over Wi-Fi without USB.
ScrCpy vs Vysor PC mirror
--
The background is for privacy I have my home router set to not broadcast the SSID (so as to keep it out of databases which don't respect the "_nomap" opt-out naming conventions and to prevent most phones from uploading it even to the servers that do respect the opt out naming conventions) and therefore, it's required for privacy to also set my Android Wi-Fi radio to not broadcast that SSID when I'm away from that home router (i.e., Android Wi-Fi setting for that specific SSID is set to not auto-reconnect).
Because of those two privacy options (one on the router, the other on the phone), whenever my phone disconnects from Wi-Fi (e.g., if I drive down the driveway away from my home router), the Wi-Fi on the phone also turns off, which is exactly what I want to happen.
However, when I return home, the Wi-Fi on the phone has to be manually turned on, and so does 'Wireless debugging' in 'Developer options' because you need to be connected to a Wi-Fi access point and you need to have Wi-Fi Debugging turned on in order to establish a Wi-Fi adb connection over Windows to mirror the phone display, keyboard, mouse, and clipboard onto the PC (without ever needing to use a USB cable, even only momentarily).
Given that background, I was seeking a simpler way to turn on Androiud 'Wireless debugging', which turns out to be adding this 'Wireless debuggon = on/off' goggle tile to your Android swipe-down menu.
The use model is when you reboot the PC or when you return home, you swipe down on Android 12 to tap both the Wi-Fi and 'Wireless debugging' toggling tiles, and then you can mirror your phone onto your PC using the following adb commands on the phone and PC (listed in step-by-step order although there are many ways to accomplish the same task - this is only one of them)
(Phone) Swipe down & manually turn on Wi-Fi via the "Wi-Fi" TILE
(Phone) Longpress on that 'Wi-Fi' TILE to connect to a previously saved AP
(Phone) Tap to toggle the 'Wireless debugging' Android TILE on.
(PC) C:\> adb kill-server (optional, to set a known starting point)
(PC) C:\> ping 192.168.0.2 (optional, to check if you're on the LAN)
(PC) C:\> adb devices
(PC) C:\> vysor.exe (this will bring up the Vysor GUI to mirror Android)
Note prior to Android 11, to establish that adb connection over Wi-Fi, you first had to use a USB cable to set up tcpip on port 5555 and _then_ after establishing a link to adb, you could disconnect USB to use it on Wi-Fi.
C:\> ping 192.168.0.2 (optional to test you're on the LAN over Wi-Fi)
C:\> adb kill-server (optional to start at a known starting point)
C:\> adb tcpip 5555
C:\> adb connect 192.168.0.2:5555 (port is optional)
C:\> adb devices (optional to see what devices are connected over adb)
But the situation I'm describing does _not_ need to use that USB cable.
Great explanation THANKS!!!
One silly issue, where you can have a lead for me:
every time Wireless Debug reconnects it will change randomly IPort number
I use SCRCPY which is similar to VYSOR... but completely free...
it will not be able to reconnect not knowing what port to call, and having lost the previous one.
Using SCRCPY I'm mirroring two static androids on USB and that's fine,
but the issue is with the other two mobile androids ( main & backup ) that I have to connect wireless because they are moving with me.
This is part of the .BAT for my main cell> POCO F3
::Go wireless instead
:Wireless
ADB connect 10.0.1.103:38277
scrcpy.exe --window-x 1500 --window-y 45 -s 10.0.1.103:38277
Click to expand...
Click to collapse
This is POCO F3 W. D. screen with the ver changing port number
.... BAT results are the same with the wrong port and without a port number
By default without a Port Number,
it will try only the standard port:55555 and as per the previous Port:38227 it will not be authorized to use it !!!
Is there a way to set fixed that Port number?
I have to manually look at it and then change it in my .BAT.
Even a simpler roundabout that allows me to get back my androids automatically on the PC will be fine !!!
AlainCh2 said:
every time Wireless Debug reconnects it will change randomly IP port number
Click to expand...
Click to collapse
I know. I know. It happens to me also.
It's even worse in some ways in that BOTH ports change.
That is, every once in a while the random port changes for the adb "connect" command:
C:\> adb connect 192.168.0.2:12345
And, at the same time, the random port (which is a DIFFERENT port!) also changes for the adb "pair" command (as does the 6-digit PIN).
C:\> adb pair 192.168.0.2:54321 123456
Sometimes the port stays the same for days, sometimes it changes. I haven't tested yet what circumstances change that port, but I agree with you that it happens a lot.
AlainCh2 said:
I use SCRCPY which is similar to VYSOR... but completely free...
it will not be able to reconnect not knowing what port to call, and having lost the previous one.
Click to expand...
Click to collapse
I use both scrcpy and vysor (both of which are free, but vysor has some non-free stuff that I don't need).
Interestingly Vysor "says" it won't do pure wireless without paying for it but that isn't true - both scrcpy & vysor work completely wirelessly.
Vysor won't give you the good resolution without paying for it while scrcpy will give you better resolution all the time.
They're essentially the same (as far as I can tell anyway)... where I had to write a script to make scrcpy work without the console though (whereas vysor works without the console without modification).
Certainly Vysor is SLOWER than scrcpy on startup, where scrcpy is almost immediate and nothing needs to be put onto Android, but with Vysor, it MUST install some temporary vysor.apk each time you run it, but once they're both up and running, the speed is indistinguishable (as far as I can tell).
The one thing Vysor seems to do better than scrcpy is it seems to figure out better what port adb is currently on - but I don't know how Vysor does it - and - worse - Vysor doesn't do it correctly every time.
It's frustrating - which is why I AGREE with you that if we could somehow lock the port down on Android - that would solve the problem - or - if we could figure out using a Windows command what the current port is on Android - that would also solve the problem.
We need help from Windows/Android experts!
AlainCh2 said:
By default without a Port Number,
it will try only the standard port:55555 and as per the previous Port:38227 it will not be authorized to use it !!!
Click to expand...
Click to collapse
I'm with you about the port number having to be put into the batch file, where I have a batch file for scrcpy that no longer requires the port but I have to establish the adb connection first unfortunately.
AlainCh2 said:
Is there a way to set fixed that Port number?
I have to manually look at it and then change it in my .BAT.
Click to expand...
Click to collapse
I have the same problem that the port keeps changing.
I have the same question as you do, but I was approaching it from the OTHER angle.
That is, the batch file can ascertain what the port number is.
That's possible - but I don't know Windows well enough to be successful all the time. Sigh.
AlainCh2 said:
Even a simpler roundabout that allows me to get back my androids automatically on the PC will be fine !!!
Click to expand...
Click to collapse
I think there are two approaches to a solution.
1. Try to keep the port static, or,
2. Try to figure out the port (after the fact) in the batch file.
I've been working on the latter using these Windows commands.
C:\> netstat -ano -p tcp | findstr "192.168.0.2"
C:\> adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
C:\> adb mdns services
C:\> nmap 192.168.0.2
But I need help in how to figure out the port from Windows.
Once we figure out the port, we can feed it to the batch files.
Wow, interesting!
Would I've been in my glorious years my brain would have helped a, lot.
Now I'll try to do my best.
Differences in our network management:
Cell side
>All my cell's IP are static by router
>All my cell have USB Debugging enabled
>All my cell have Wireless enabled :: Unless the phone disable it
LAN side
>My LAN is always on > All home is covered but 2mt of south balcony
>I lose Wireless When I leave Home :: When I go on South Balcony
__________________________________
My full script is quite simple and contain REM'd the debug instructions
Code:
::@echo on
@echo off
powershell -window hidden -command ""
:: Poco F3 - PF3s - M2012K11AG
:: --serial a7ff2388
:: --serial 10.0.1.103:38277 37751 39685 37293
cd /d "D:\D_\ScrCpy - ScreenCopy\"
:Top
::Start "trying a go on USB - WIRED"
scrcpy.exe --window-x 1500 --window-y 45 -s a7ff2388
:: Check if the wire is connected
:: if the exit code is >= 1, no phone on wire
if errorlevel 1 TimeOut /t 4 /nobreak
::Goto Top
::Go wireless instead
:Wireless
ADB connect 10.0.1.103:37293
scrcpy.exe --window-x 1500 --window-y 45 -s 10.0.1.103:37293
::::: I Must use as -SERIAL the IP and not the ADB serial "a7ff2388" >no reason given
::Exit
::Pause
::Back on Wire
Goto Top
Let's see what I've got so far:
#Port number
the number change every time :: IP Reconnect :: Wifi Reconnect :: no other reason
From you I get that ...
We can in some way divine the port number
With netstat / ipconfig using the fixed cell Ip
But so far it seems No cells are connected to the LAN
103 = PocoF3
109 = P9 Lite
110 = HonorW10
105 = N5T
065 = T365
for sure I'm doing something wrong using this command: "netstat -ano -p tcp"
I checked as well "netstat -ano -q"
For sure PF3s is now connected on USB to the PC, but also sure it should appear on LAN as well
The router see all of them
When I come back home, it seems that the cell have not reset the Wireless debugging
but that's not true !!!
When I enable it, it will assign a new port...
... will it announce on the network as "port OPEN xyyyzxx"
... or it will be used just LISTENING to check the connect request??
BTW : I never used the pairing method you use.
While I know that you can look at all the TCP connections related to your IP
I have a big doubt that W10 would see the full Lan IP_Ports from its own interface.
...
..... digging down on that.
.... Mumble ... mumble .. mumble...
YEEEESSSSSS!!!
My brain became sluggish but it still work - in a way
Netstat and IPConfig works only from inside to any outward connection/adapter,
and they cannot go looking out.
You have to use a different command "PORTQRY" to be downloaded from Microsoft itself:
"To view the TCP/UDP open port state of a remote host, type “portqry.exe –n [hostname/IP]” where [hostname/IP] is replaced with the hostname or IP address of the remote host. You can also specify to scan for a particular port using the “-e [port_number]” parameter, a particular range of ports using the “-r [start_range:end_range]” parameter, or a group of ports in a particular order using the “-o [port1, port2, port3]” parameter."
Last thing to do:
Learn how to use "portqry.exe"
____________________________________________
Here we go from my observations:
Assuming the random port being in the range 30k-44k, I need to check who's listening.
I get the identification string response > using the known port I checked in Android's PF3s settings.
But the process takes several minutes up to half an hour...
NP this is the first screenshot... just in case you read it before I'm back online.
#@#!!!!!
ok, it took 12 minutes to check 138 ports !!!
I tested that on a shorter range_
Seems I cannot delimit correctly the FINDSTR "xxxxxxxxxx"
It's a good night for me !!!
<2022-08-02 01:23:41>this post took 3hours 11minutes 33seconds - using a very large amount of my BRAIN<
:-D
Wow. That's a lot to digest. You did great work!
Really great work!
Thanks for all that work on behalf of me and you and everyone!
I will have to take HOURS to go through all the wonderful work you did, particularly in finding that "portqry.exe" command that maybe can tell us what port the Android phone recently switched to (since that's the root of the problem!).
BTW, regarding the "adb connect" versus "adb pair", I think the difference is just in encryption (connect apparently isn't encrypted), where if that's the case, it doesn't matter which you use otherwise.
However, I could be wrong, so I had asked a while ago here, but nobody answered the question unfortunately.
What's the difference between Windows/Android adb "connect" versus adb "pair" when mirroring Android 12 over Wi-Fi onto a Windows PC?
Since you posted your script, here is my scrcpy script which gets rid of the console (but adb has to already be connected for it to work without the port number - which is how I use it most myself).
Code:
@echo off
REM C:\app\editor\android\scrcpy\showwin.bat
REM adb mdns services
REM List of discovered mdns services
REM netstat -ano -p tcp | findstr "192.168.1.10"
REM TCP 192.168.1.27:15919 192.168.1.10:41913 ESTABLISHED 7904
REM
cd /d "c:\app\editor\android\scrcpy"
certutil -f -decode %~f0 showwin.exe>nul
REM Port 5555 was needed when you established adb connections over USB
REM And then you disconnected the USB cable to subsequently work on Wi-Fi
REM But as of Android 11 or 12, you can establish the connection over Wi-Fi
REM But that "Developer option" "Wireless debugging" port is assigned by Android!
REM So you have to get it on Android or on Windows to know what it is
REM adb connect 192.168.1.10:5555
REM You can get the current port from the following command
REM c:\> netstat -ano -p tcp | findstr "192.168.1.10"
REM
REM maybe we do NOT need this command after all???
REM adb connect 192.168.1.10:41913
:: now we hide console window
showwin.exe 0
REM scrcpy --always-on-top --tcpip=192.168.1.10:5555
REM Maybe we can then remove the IP:PORT after all???
REM scrcpy --always-on-top --tcpip=192.168.1.10:41913
REM We don't really need --always-on-top after all???
REM scrcpy --always-on-top
scrcpy
:: after scrcpy is closed we show console window again
showwin.exe 5
del showwin.exe
goto :eof
-----BEGIN CERTIFICATE-----
TVpgAQEAAAAEAAAA//8AAGABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAoAAAAA4fug4AtAnNIbgBTM0hTmljZSB0byBtZWV0IHNvbWVi
b2R5IHdobyBpcyBzdGlsbCB1c2luZyBET1MsDQpidXQgdGhpcyBwcm9ncmFtIHJl
cXVpcmVzIFdpbjMyLg0KJFBFAABMAQEAUHmlNgAAAAAAAAAA4AAPAQsBBQwAAgAA
AAAAAAAAAADIEAAAABAAAAAgAAAAAEAAABAAAAACAAAFAAAAAAAAAAQAAAAAAAAA
ACAAAAACAAAAAAAAAwAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA
GBAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAAAmAQAAABAAAAACAAAAAgAA
AAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoEAAAAAAAAJQQAACmEAAA
uhAAAAAAAABgEAAAAAAAAAAAAABUEAAAABAAAIQQAAAAAAAAAAAAAHYQAAAIEAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVU0VSMzIuZGxsAABoEAAAAAAAAAAAU2hvd1dp
bmRvdwAAS0VSTkVMMzIuZGxsAACUEAAAphAAALoQAAAAAAAAAABHZXRDb21tYW5k
TGluZUEAAABHZXRDb25zb2xlV2luZG93AAAAAEV4aXRQcm9jZXNzAP8VCBBAADHS
SECAOAB0EYA4InUC99IJ0nXvgDggdepAMfa9BQAAAA+2EEAI0nQTgOowcvOA+gl3
7mv2CgHWMe3r5QntdAKJ7v8VDBBAAFZQ/xUAEEAAagD/FRAQQAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
-----END CERTIFICATE-----
In addition, if you run any free WebDAV server, you can mount your entire Android phone (even most of the read-only root partition!) as a drive letter onto Windows without having to use FTPUse to do it.
C:\> net use Z: \\[email protected]\DavWWWRoot /USER:foo bar & net use Y: \\[email protected]\DavWWWRoot /USER:foo bar
I had to use TWO free webdav servers though... one for the internal sdcard and one for the external sdcard - each on a different port - as nobody solved the problem I posed a while ago over here asking how to do it with just one webdav server.
Can you mount BOTH Android internal & external storage onto Windows as a drive letter over Wi-Fi using a SINGLE WebDAV server?
AlainCh2 said:
Last thing to do:
Learn how to use "portqry.exe"
Click to expand...
Click to collapse
This morning I downloaded the Microsoft PortQry command where I place what I did below to help save time for others who can read this instead of doing it to get an idea of what it is & how it installs.
1. Googling, I found the canonical location of the Microsoft command.
PortQry Command Line Port Scanner Version 2.0<https://www.microsoft.com/en-us/download/details.aspx?id=17148>
2. I downloaded it (where I'm not sure if this URL is static or dynamic):
<https://download.microsoft.com/download/0/d/9/0d9d81cf-4ef2-4aa5-8cea-95a935ee09c9/PortQryV2.exe>Date: 20220802Name: PortQryV2.exeSize: 151112 bytes (147 KiB)SHA256: 6471C5190A99E3D1F337FCFEF1FC410E8D487B66E093F924700E186CBD398DC0
Doubleclicking on the file above asks to unzip it.
It wants to go by default into c:\PortQryV2Instead I put it where it belongs at c:\app\network\portqry (Note that I decide where things belong... not a billion different developers who don't have a common vision.)
Resulting in:
Date: 20220802Name: PortQry.exeSize: 143360 bytes (140 KiB)SHA256: FB6CEBADD49D202C8C7B5CDD641BD16AAC8258429E8FACE365A94BD32E253B00
Then I downloaded the port query user interface.
PortQryUI - User Interface for the PortQry Command Line Port Scanner<https://www.microsoft.com/en-us/download/details.aspx?id=24009><https://download.microsoft.com/download/3/f/4/3f4c6a54-65f0-4164-bdec-a3411ba24d3a/PortQryUI.exe>
Resulting in:
Date: 20220802Name: PortQryUI.exeSize: 217160 bytes (212 KiB)SHA256: D462DD1AD77B37E9E681F9A779550B3918AF4925EC6F3D0014E6880B69B98126
Doubleclicking on the file above asks to unzip it.
It wants to go by default into C:\PortQryUIInstead I put it where it belongs at C:\app\network\portqry (Note that I decide where things belong... not a billion different developers who don't have a common vision.)
Date: 20220802Name: portqueryui.exeSize: 70656 bytes (69 KiB)SHA256: DCD38075F8D594763A498FE884A85394DB66BB604A0A1E6E6AC823923ADD910D
I doubleclick portqueryui.exe and a GUI comes up & I type the IP address of the phone (sans port) and then the MS Port Query GUI runs a scan of the phone's IP address, which, let's face it, takes a very long time to complete (at least with the defaults it does).
BTW, I've noticed the ports used by adb seem to always be in the same range of 3#### and 4#### so maybe we can save some time by scanning only those ports as explained here.
How To: Mastering PortQry.exe<https://techgenix.com/portqry-howto/>Specifically:C:\> portqry -n 192.168.0.2 -r 30000:40000And, well, um, er... it takes FOREVER and reports a lot of "NOT LISTENING" lines which are useless to us for our purpose... so I see (belatedly) now why you needed the "find string" syntax to find just the ports that adb is using!If we knew more about adb, maybe we could query more specifically the type of ports adb uses (e.g., mdns services)?
AlainCh2 said:
Differences in our network management:
Cell side
>All my cell's IP are static by router
>All my cell have USB Debugging enabled
>All my cell have Wireless enabled :: Unless the phone disable it
LAN side
>My LAN is always on > All home is covered but 2mt of south balcony
>I lose Wireless When I leave Home :: When I go on South Balcony
Click to expand...
Click to collapse
As I explained over here a while ago, most of us do a bunch of things that provide us Wi-Fi privacy that we have to keep in mind, where what I do is somewhat similar to what you do, as shown below.
My home SSID/passphrase do not contain identifying words
So as to keep out of WPA2/PSK butterfly/rainbow hash tables
While at the same time they are as unique as I can make them
And I change them every once in a while for obvious reasons
Where the SSID has "_nomap" (it used to also have "_optout_")
But that doesn't stop WiGle/NetStumbler/Kismet/etc. uploads
And that doesn't stop passwerby from uploading to Google/Mozilla servers either!
Even as these well-behaved servers "say" they scrub this information
So that Google/Mozilla get it - but they don't publish it
Because you can be tracked if anyone knows your phone SSID
Simply by querying the public servers with any other known SSID
So I also turn off the broadcast of that SSID on my home router
Which means the cell phone has to remember the SSID
But the phone would "shout out" that SSID with AutoConnect
So I turn "AutoConnect=off" on the cell phone
So now, when I go down my driveway, it doesn't shout it out
In addition, I used to randomize the MAC by each SSID
Which meant that random BSSID was "reserved" on my router
And that the IP address was set to "static" on the phone
New in Android 12 Developer options, I can now randomize the phone's Wi-Fi MAC address on each and every connection
While still reserving the IP address on the home router
And, like you, every phone I get, the first thing I do is enable USB debugging (so I can recover from a smashed screen), yet, with Android 12, there's never a need for a USB cable anymore as everything it did is now rendered obsolete nowadays...
a. Many phones charge wirelessly nowadaysb. My phone is mirrored (sound/screen/keyboard/clipboard) over Wi-Fi to my PC (sndcpy,scrcpy,visor)c. My unrooted phone is mounted as a drive letter onto Windows (Z: for the internal sdcard and Y: for the external sdcard)And, of course, there are a few things which are forbidden on my phone:
a. There will never be a mothership tracking account (not Google, not Samsung, not my Bank, nothing)b. There will never be a way to pay for anything or to get money from anywherec. There will never be a log in to a mothership account (except, perhaps, email, when necessary)
And, most radios are turned off by default, and only turned on when necessary and then turned off again...
a. Uploads of other people's Wi-Fi to Google servers are always permanently turned off
b. The GPS radio is off by default & location accuracy is always off
c. The NFC radio is turned off by default
d. The Bluetooth radio is turned off by default
e. Developer options Wireless debugging is on by default (but it turns off when the AP is no longer connected when I leave my driveway)
The only radios left on, by default are:
a. The cellular radio
b. The cellular data radio
And I have a few cellular and cellular data aps monitoring when I'm out of cellular calling/data range (but this isn't a privacy thing per se).
GalaxyA325G said:
BTW, I've noticed the ports used by adb seem to always be in the same range of 3#### and 4#### so maybe we can save some time by scanning only those ports as explained here.
How To: Mastering PortQry.exe<https://techgenix.com/portqry-howto/>Specifically:C:\> portqry -n 192.168.0.2 -r 30000:40000And, well, um, er... it takes FOREVER and reports a lot of "NOT LISTENING" lines which are useless to us for our purpose... so I see (belatedly) now why you needed the "find string" syntax to find just the ports that adb is using!If we knew more about adb, maybe we could query more specifically the type of ports adb uses (e.g., mdns services)?
Click to expand...
Click to collapse
I suppose you missed the last part of my message after "learn how to use" it
Range:
I checked it from the past reconnections: ports 30xxx to 44xxx
TIME:
It took me 20 minutes to do 138 ports
>>>but maybe ... sending to log instead of using cache... can be faster
SEARCH:
I showed the found string as well
_______________________
I've got the string to look at >> "e): LIST"
_______________________
°-°
The most difficult task is now up to you:
How to pass the found record to ADB & SCRCPY
String found = VAR1
>> ADB CONNECT IP:"VAR1"
>> SCRCPY ..... -s IP:"VAR1"
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Big issue is the time needed to connect the cell to the PC
> for the first time after you get home
For me, reconnecting it's twice a week in a normal situation, 'cause I'm normally locked in bed...
...but I imagine you and other people are in a different situation.
For me, it would be no problem at all, if under 1 hour,
provided that the .Bat will wait for the PocoF3
> xxx.103 to appear in LAN, before starting to look for the port.
This is why:
After a foraging boot, I enter the LAN while I'm parking the car downstairs.
Both Car and Cell connect nearly at the same time.
It will take some time ....
to climb 19 steps and getting upstairs, enter the home, arrange all the goods, then do the chores at hand
.... as much as 20 to 40 minutes or more will pass before I finally go to the PC and lay back onto the bed.
(usually forgetting somewhere the phone till it will ring - or I need for an SMS confirmation code, for instance)
I would have to rise and search - no matter how I feel
>>> that's the reason it's so useful for me to have it wireless on PC <<<<<
Even if it takes a long time I wouldn't probably even notice it,
if I'm not going straight to the PC, and in that case, I plug the cell in USB.
It's after that I may forget again, rise and search. So now I maniacally do Port's manually.
( unless I forget to do it the first time - start again from tiles zero )
I just came home and connected to scrcpy via adb over port 41703
(which I knew was the port from looking at the phone, but I WISH I could figure out that port from Windows!)
C:\> adb connect 192.168.0.2:41703 && scrcpy
Click to expand...
Click to collapse
And then I ran the Microsoft port query command (which is as slow as a lazy dog), but at least portqry.exe listed that port as "listening"...
c:\app\network\portqry\portqry -n 192.168.0.2 -e 41703
Querying target system called:
192.168.0.2
Attempting to resolve IP address to a name...
Failed to resolve IP address to name
querying...
TCP port 41703 (unknown service): LISTENING
Click to expand...
Click to collapse
Of course, I cheated as I already knew the port was 41703 by looking at the phone by longpressing on the new Android 12 "Developer options Wireless debugging tile" (which saves a bunch of steps digging into Android Settings and then Developer options).
But assuming I didn't know the port, but only knew the range, this would work (but it's horribly slow).
c:\app\network\portqry\portqry -n 192.168.0.2 -r 41700:41705
TCP port 41700 (unknown service): NOT LISTENING
TCP port 41701 (unknown service): NOT LISTENING
TCP port 41702 (unknown service): NOT LISTENING
TCP port 41703 (unknown service): LISTENING
TCP port 41704 (unknown service): NOT LISTENING
TCP port 41705 (unknown service): NOT LISTENING
Click to expand...
Click to collapse
Of course, I cheated by giving the slow portqry command a small range, as it would have taken forever to give it the range of 30000 to 40000 which is, so far, the range that I've seen being used.
Hindsight is so 20/20 in that once you've cheated such that you know the "static" IP & "random" port that Android set the new Android 12 Developer options Wireless debugging to, many basic network commands will quickly tell you that specific IP address is being used.
This will instantly report the "static" IP address of the adb-connected phone on my Windows 10 PC:
C:\> adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
192.168.0.2
Click to expand...
Click to collapse
And, more to the point, the basic networking commands can tell you the random port - if - for example - if you had connected to it using adb yesterday or a week ago and that random port assignment had not changed in the interim...
This will tell you the "static" IP address and the "random" port:
C:\> netstat -ano -p tcp | findstr "192.168.0.2"
TCP 192.168.0.2:2392 192.168.0.2:41703 ESTABLISHED 1928
Note I left in the extraneous report of another port (2392) which was in use for reasons unknown to me...
Click to expand...
Click to collapse
What we need, of course, is a way to narrow down the range of ports that adb will use, which, to that end, I opened this thread about:
[adb,scrcpy,vysor] What ports does Android 12 randomly set when Wi-Fi connecting via Wireless debugging adb "pair" or "connect" commands?
GalaxyA325G said:
Of course, I already knew the port was 41703 by looking at the phone by longpressing on the new Android 12 "Developer options Wireless debugging tile" (which saves a bunch of steps digging into Android Settings and then Developer options).
Click to expand...
Click to collapse
TILE:
If I tap it, I can enable the option.
If I long press it, nothing happens and the tiles disappear immediately
> strange, isn't it ?
GalaxyA325G said:
I think there are two approaches to a solution.
1. Try to keep the port static, or,
2. Try to figure out the port (after the fact) in the batch file.
Click to expand...
Click to collapse
I think we have another option here:
3. Set IN ANDROID ADB the port we want.
That can be done using an Android.Bat activated by the wifi connection event
..... and HERE WE GO with the android terminal string for the standard port:
>> adb -d shell setprop service.adb.tcp.port 55555
Referring to:
Is it possible to adb connect android via wifi without configuring port on android?
I can connect via wifi by typing these codes in android terminal - setprop service.adb.tcp.port 5555 stop adbd start adbd and connect ip:port on PC adb .. it is connected .. Is there any possibi...
android.stackexchange.com
____________________________________________________________________
The following under bash:
$ export ANDROID_ADB_SERVER_PORT=12345
$ adb start-server
* daemon not running. starting it now on port 12345 *
* daemon started successfully *
$ adb devices
List of devices attached
TA2070M5O6 device
$ ANDROID_ADB_SERVER_PORT=6789 adb devices
* daemon not running. starting it now on port 6789 *
* daemon started successfully *
List of devices attached
Refering to:
How to make adb listen to tcpip 5555 after reboot
I have to use adb over ssh. now, everything works fine but after a reboot i have to connect my device again over usb and set adb to listen to tcpip instead of usb. is ther a way to save those settings? This is how it works for now. After a...
forum.xda-developers.com
________________________Start testing ______________________
Poor results >> I don't know Linux or Android enough
>> Please Step-In
___________________Waiting you ______________
I'm reading this:
Android Debug Bridge (adb) | Android Studio | Android Developers
Find out about the Android Debug Bridge, a versatile command-line tool that lets you communicate with a device.
developer.android.com
And we got a hit on the first 20 lines !!!
>>>>>> I take a break... see you in 7-9 hours
AlainCh2 said:
TILE:
If I tap it, I can enable the option.
If I long press it, nothing happens and the tiles disappear immediately
strange, isn't it ?
Click to expand...
Click to collapse
That is strange indeed.
The reason it matters is that this brand new Android 12 Developer options Wireless debugging tile saves a LOT of time daily digging into the Android settings (because it takes you exactly where you need to be to find out what the current random port assignment is).
I guess we need a third person to test it as when I tap the new tile, it toggles from on to off and from off to on... but when I longpress it, I end up deep inside the Developer options Wireless debugging Activity (whether or not the tile was blue or white at the time that I longpressed it).
I even just now tested it for you with the Wi-Fi radio turned off, and again with the Wi-Fi radio turned on but with no access point being connected.
In summary, even though the Developer option for Wireless debugging won't work without BOTH the Wi-Fi radio being turned on AND the Wi-Fi being connected to an access point (mine being set to NOT auto-reconnect, for privacy reasons), longpressing on the Developer options Wireless debugging tile brought me, every time, to the Developer options Wireless debugging screen.
I'm on a Samsung Galaxy A32-5G, Android 12, non rooted.
Would someone else kindly test it for us to break the tie?
AlainCh2 said:
I think we have another option here:
3. Set IN ANDROID ADB the port we want.
Click to expand...
Click to collapse
I love the way you think!
Here are the possible solutions (thanks to you):
1. Keep the random port assignment static between adb connections
Or...
2. Determine the current random port assignment from the PC
Or...
3. Manually set the port assignment from the PC!
(Which is much like we used to do in the days of USB cable connections (where we would set it to 5555 and then disconnect once we set it to that static port).
I love how you think as you're trying to solve the same problem we all have, but you're using more tools to do it as you think outside the box by using all the methods available.
I will have to try this on the PC on the MSDOS command line (which is outside of Bash as I don't have Linux inside of the PC set up yet).
AlainCh2 said:
>> adb -d shell setprop service.adb.tcp.port 55555
Click to expand...
Click to collapse
I'll try to follow in your footsteps on the Windows 10 MSDOS command line (which requires a different style of environment variables)...
AlainCh2 said:
$ export ANDROID_ADB_SERVER_PORT=12345
Click to expand...
Click to collapse
This seems to be how to set Win10 user-specific environment variables...
C:\> setx [variable_name] "[variable_value]"
And this is how to set Win10 system-wide environment variables:
Win+R > cmd {Ctrl+Shift+Enter} <-- admin windowsetx [variable_name] "[variable_value]" /M
Which means I can use this in the MSDOS admin cmd window:
Win+R > cmd {Ctrl+Shift+Enter}setx ANDROID_ADB_SERVER_PORT "55555" /M
AlainCh2 said:
$ adb start-server
* daemon not running. starting it now on port 12345 *
* daemon started successfully *
$ adb devices
List of devices attached
TA2070M5O6 device
Click to expand...
Click to collapse
I think I'm with you only up to this point... starting with...
a. Android has Wi-Fi turned on
c. Android has the Wi-Fi connected to an access point
d. Android has Developer options Wireless debugging = on
e. Which reports a static IP & random port of 192.168.0.2:41269
And then running these commands in your footsteps...
1. Win+R > cmd {Ctrl+Shift+Enter}
2. adb kill-server
3. setx ANDROID_ADB_SERVER_PORT "55555" /M
SUCCESS: Specified value was saved.
4. adb start-server
* daemon not running; starting now at tcp:5037
* daemon started successfully
5. adb devices
List of devices attached
adb-SERIALNUMBER._adb-tls-connect._tcp. offline
6. set ANDROID_ADB_SERVER_PORT
Environment variable ANDROID_ADB_SERVER_PORT not defined
(funny... I thought I had already defined it, system wide... oh well... )
7. set ANDROID_ADB_SERVER_PORT=55555
8. set ANDROID_ADB_SERVER_PORT
ANDROID_ADB_SERVER_PORT=55555
Notice I'm with you up to this point so far...
AlainCh2 said:
$ ANDROID_ADB_SERVER_PORT=6789 adb devices
* daemon not running. starting it now on port 6789 *
* daemon started successfully *
List of devices attached
Click to expand...
Click to collapse
I don't (yet) understand what that command is doing so I can't even figure out how to reproduce it in the Windows 10 MSDOS batch command line.
AlainCh2 said:
View attachment 5676681
Click to expand...
Click to collapse
I remember seeing "setprop" stuff for adb when I had googled this, so we both need to look up what it does and what's the syntax.
AlainCh2 said:
>>>>>> I take a break... see you in 7-9 hours
Click to expand...
Click to collapse
I like how you think, which is that we "should" be able to set the port from WIndows that adb will connect to Android... but....
Remember all that "old" stuff predates Android 11 Developer options Wireless debugging (which is designed to use a random port assignment).
All that "old" stuff assumed a USB cable connection to the Android phone... which we aren't using....
... so what we have to do is figure out how to change that old stuff to get around the fact we can't talk to the phone unless we can figure out what port the phone is listening on...
This is the best I can do (but it's cheating)
a. Android has Wi-Fi turned on
c. Android has the Wi-Fi connected to an access point
d. Android has Developer options Wireless debugging = on
e. Which reports a static IP & random port of 192.168.0.2:41269
These commands ALWAYS work (but I had to cheat!)...
1. Win+R > cmd
2. adb kill-server
3. adb connect 192.168.0.2:41269
4. scrcpy --tcpip=192.168.0.2:41269
5. up pops the mirror of Android in the scrcpy GUI
While that works perfectly, the problem is that I have to KNOW the port before any of that works.
Hi,
as adb announces the service via MDNS, you can use the value of "persist.adb.wifi.guid" to connect.
output of avahi-discover under Ubuntu 20.04:
Code:
Service Type: _adb-tls-connect._tcp
Service Name: "value of persist.adb.wifi.guid"
Domain Name: local
Interface: eth0 IPv6
Address: Android.local/192.168.1.223:41465
TXT v = ADB_SECURE_SERVICE_VERSION
Or you can use "adb mdns services" to show all found devices in the network, see https://source.android.com/devices/automotive/virtualization/tools
Regards,
meiser
meiser said:
as adb announces the service via MDNS, you can use the value of "persist.adb.wifi.guid" to connect.
Click to expand...
Click to collapse
I don't know if I'm supposed to openly admit I have no clue what "mdns" even means, but I did use the "adb mdns services" command in post #3 above because I found it on the net when I had googled for how to tell which port adb is using.
C:\> netstat -ano -p tcp | findstr "192.168.0.2"
C:\> adb shell "ifconfig|grep -A 1 wlan0|tail -n 1|cut -f2 -d:|cut -f1 -d' '"
C:\> adb mdns services
C:\> nmap 192.168.0.2
Click to expand...
Click to collapse
The problem I had with using 'mdns' was that it sometimes gave me good port information and it sometimes did not (more often than not, it reported absolutely nothing useful) - yet - I haven't been able to figure out why - so I simply gave up on it a while ago.
Maybe I need to re-visit mdns because sometimes it gave what I wanted.
Googling, I find it's actually labeled mDNS, which now I only need to figure out what the "m" stands for since we're all familiar with DNS name-to-ipaddress lookups.
Googling some more, I find the "m" stands for "multicast" which still doesn't tell me a thing about what it is yet...
If you aren’t familiar, mDNS is a protocol defined by the Internet Engineering Task Force (IETF), the organization that oversees the technical standards that comprise the Internet. It stands for multicast domain name system, and it’s how hostnames are resolved on local networks without their own DNS server. The mDNS protocol is defined in full in the IETF’s RFC 6762 document, but the most relevant part is Section 5.1 – One-Shot Multicast DNS Queries, as it’s what Android’s DNS resolver implements.
Without getting too technical, mDNS basically makes it possible to connect to devices on a local network using human readable names, similar to how DNS makes it possible to connect to servers over the Internet using a human readable name.
Click to expand...
Click to collapse
What I'm guessing (at this point) is that Android will "announce" itself with a hostname of sorts using this "multicast DNS" protocol for the LAN, am I right?
Android, meanwhile, has offered support for mDNS service discovery since Android 4.1 Jelly Bean … but only for apps that implement the network service discovery (NSD) API. This means that Android users, for years now, haven’t been able to simply enter a hostname followed by .local into a web browser and have it be resolved to the IP address of a local device.
Click to expand...
Click to collapse
You mentioned "avahi" below... (which I also never heard of)...
meiser said:
output of avahi-discover under Ubuntu 20.04:
Code:
Service Type: _adb-tls-connect._tcp
Service Name: "value of persist.adb.wifi.guid"
Domain Name: local
Interface: eth0 IPv6
Address: Android.local/192.168.1.223:41465
TXT v = ADB_SECURE_SERVICE_VERSION
Click to expand...
Click to collapse
Now I see why you brought up "avahi" discover services...
Microsoft brought native support for mDNS to Windows with Windows 10 1703 in 2016, but prior to that, users could install Apple’s Bonjour Print Services tool to use the feature. Many Linux distros implement mDNS through the Avahi daemon. Apple, as the author of the protocol, of course has a native implementation in iOS and macOS.
Click to expand...
Click to collapse
The problem I've had with "adb mdns services" is sometimes it reports good information but other times it reports nothing.
meiser said:
Or you can use "adb mdns services" to show all found devices in the network, see https://source.android.com/devices/automotive/virtualization/tools
Click to expand...
Click to collapse
If we can figure out the circumstances as shown below where mDNS are in service, then the "adb mdns services" command might actually be useful to us to determine the Android 12 random port assignment.
1. Start with Android 12 & desktop PC connected to the LAN
2. Turn on Android Developer options Wireless debugging
3. Query Android for the wireless debugging port
The problem to resolve is...
a. When adb hasn't been run, mdns doesn't report anything
b. Even with adb connected, often mdns doesn't report anything
Yet...
c. Sometimes mdns DOES report the port address we seek
Why?
Screenshot: Notice we've been using "adb mdns services" for a while now but it rarely reports anything at all, let alone the random port assignment (but sometimes it does!).
GalaxyA325G said:
I love how you think as you're trying to solve the same problem we all have, but you're using more tools to do it as you think outside the box by using all the methods available.
Click to expand...
Click to collapse
That's what I did for a living in small companies like Olivetti, SIP/TelecomItalia, MCIWorldcom.
I'm a strange human being: I learned to program Assembler and PL1 in IBM, Gwbasic and COBOL on Mainframes, Honeywell OS, Digital PDP OS., and at last on Cisco routers
.... all by myself - and never worked programming ( but to better understand what was happening to my people)
______________________________________________
Sorry to say: you didn't got my lead correctly.
3: >android side
IF > we can run the equivalent of a ".BAT" file every time wifi connect
we can try setting the ADB port variable Android side,
making no assumptions on PC
But I don't know enough on that side,
nor do I know enough on Linux that's the Android base.
( I'm still curious - but brain is not agile anymore to learn fast to my liking)
AlainCh2 said:
That's what I did for a living in small companies like Olivetti, SIP/TelecomItalia, MCIWorldcom.
Click to expand...
Click to collapse
Yea, me too, where I worked in Silicon Valley startups for decades before retiring about 20 years ago...
AlainCh2 said:
I learned to program Assembler and PL1 in IBM, Gwbasic and COBOL on Mainframes, Honeywell OS, Digital PDP OS., and at last on Cisco routers
.... all by myself - and never worked programming ( but to better understand what was happening to my people)
Click to expand...
Click to collapse
Yup. I took Fortran (before there was a Fortran 77) on the IBM 1130 (as I recall) with tickertape just being phased out in favor of modern punch cards, and then moved on to PL/C (before there was a PL/1) and IBM Assembly Language and COBOL (which are just about the most divergent languages on the planet). Then the PDP 11, VAX/VMS, Masscomp, SunOS, Solaris, etc., until the PC grew up and I dropped all that 'nix stuff for Windows (and moved into management so I never did coding professionally - and I hate it - so I won't be doing it anytime soon).
But, like you, I do what I have to do in order to get the job done.
AlainCh2 said:
______________________________________________
Sorry to say: you didn't got my lead correctly.
Click to expand...
Click to collapse
Yeah. I'm Aspergers. I don't get anybody's jokes. Not just yours. But everyone's. Ask my wife and kids and grandkids.
On this thread I'm just trying to do what I am sure can be done, which is:
a. Run a PC command that queries the Android phone on the LAN
b. To spit out the random port Wireless debugging is set to
c. WITHOUT having initially connected USING that port in the first place!
It may not even be possible (since Android developers may have made it impossible for security reasons perhaps).
But until I find out that it's impossible - I'm assuming it's possible.
1. Sometimes we don't know which commands to use, and,
2. Sometimes we don't have the command syntax just yet... and,
3. Sometimes it is impossible (but that's rare, is it not?)
We just have to figure out which commands/syntax give us that missing port information.
GalaxyA325G said:
We just have to figure out which commands/syntax give us that missing port information.
Click to expand...
Click to collapse
Hehehe !! A parallel story, I'm younger but beaten bad by life: at 66, I'm pretty locked in a bed from 2017.
Had to stop working in 2015, and finally got anticipated retirement in 2019.
Asperger too.
( oh, and I mean we are not brother for sure - but magnetic communication exists)
3) >>I proposed a closed command program continuously running in Android.
It was not a Joke!
But maybe we can reach the same result from PC,
if we can access telnet console on android
AlainCh2 said:
I proposed a closed command program continuously running in Android.
It was not a Joke!
But maybe we can reach the same result from PC,
if we can access telnet console on android
Click to expand...
Click to collapse
I do very much like how you think... as you don't give up when encountering a technical hurdle - and - better yet - and nearer to my heart and soul - you - like I - assume naturally there will be a solution.
Maybe there is... hmmmmmmmm......
Along the line of your "closed command program" running on Android, I am testing this option I just found out of the open source local android debug bridge (ladb APK) which is designed to run adb on the Android phone in order to mimic the PC.
I'm hoping I can get the PC to communicate with that free open source ladb app which is said to have more privileges than does Termix on Android.
is there any app like LADB which can command phone through my phone with wireless debugging android 12 .I don't have any pc and LADB price is too high to afford.