Network problem with TC Android Wifi Transfer app on Chromebook

[jacn]

Hi all,

This is regarding a new network issue with Total Commander Wifi Transfer app on Android in Chromebook (modern Chromebooks can run Android apps, particularly TC Android, and with keyboard support!). I believe it's caused by the recent Chrome OS Stable 75 update.

When using TC Android on chromebook to send files via connected wifi, TC Wifi Transfer app can show the QR code but is now assigned an internal IP (100.115.92.2) that is unreachable from outside the Chromebook. I can no longer connect to it from a Windows PC (using TC on Windows with WebDAV plug) or android phone (using TC Android with Wifi Transfer app). I believe this problem also affects other Android apps (like files sync apps) that require incoming network connections.

TC Wifi Transfer app still works the other way round i.e. TC Android on chromebook can connect to files share out from my Windows PC/Android phone, but this way I can't use TC Windows to sync files.

From what I gathered, Chrome OS isolates Android and Linux apps using VM/containers, and assign private IPs (i.e. 100.115.92.x; rfc 6598) to them that can go out via NAT but doesn't permit incoming network connections in general, though the TC Wifi Transfer app somehow still manage to work prior to Chrome OS 75 update.

The workaround that works for me is to use the open source "Connection Forwarder" Chrome web app to forward incoming traffic from the Chrome OS IP (e.g. 192.168.0.2:8081 on wifi LAN) to the particular private IP (100.115.92:8081) assigned to TC Wifi Transfer app. In this case, TC Windows should connect to the Chrome OS IP (e.g. 192.168.0.2:8081/9433) instead.

Sharing here in case somebody runs into the same problem, and maybe somebody has a better solution/insight into the issue.

Jack

[jacn]

Hi all,

To add on to my own post, my files on my Chromebook are kept in Android and I use TC Android on Chromebook (with Connection Forwarder workaround) to share out the files. This way, I can use TC on a Windows machine to sync with my Chromebook files.

For my purpose, a better alternative I found later is to run TC Windows in Crossover. Crossover for ChromeOS (free Beta, requires Intel CPU) is CodeWeaver's commercial version of Wine. (It's somewhat confusing that Chromebook can also run Wine in Linux and also Crossover app in Android.)

In Crossover, I can map my Chromebook's Android folder to a drive letter:
Manage Total Commander -> Launch Wine configuration -> Under "Drives" tab -> map a drive to "/storage/emulated/0/_some_android_directory_"

Then I can run TC Windows directly on my Chromebook to sync files with my phone / Windows machine like this:
Mapped drive of Android folder on Chromebook <--> TC Win in Crossover + WebDAV plugin <--> TC Android on phone or TC Windows on Win PC

TC Windows in Crossover (Chrome beta) is cranky. Occasionally, it is not responsive when button pressed or the overlay sync screen will just turn blank. WebDAV plugin couldn't activate the camera, I have to key-in the URL. The fonts on the screen are not sized correctly. But as far as I can tell, TC file syncing does works, which is what I need most

For info.
Jack

[Usher]

Some additional (more formal) explanations…

Chrome OS isolates Android and Linux apps using VM/containers, and assign private IPs (i.e. 100.115.92.x; rfc 6598)

They are NOT just private IPs. It's Shared Address Space. Read Wikipedia or RFC more accurately, please:
https://tools.ietf.org/html/rfc6598
https://en.wikipedia.org/wiki/IPv4_shared_address_space
https://en.wikipedia.org/wiki/IPv4#Special-use_addresses

It's important distinction. Google uses IP block 100.115.92.0/24 to avoid conflicts with PRIVATE IP addresses in local networks. It's explained in the last message (dated 2017-05-23) of a topic on Chromebook support forum:
https://support.google.com/chromebook/forum/AAAAmKCdEusKlqGYHmrgLs/?hl=en&gpf=%23!msg%2Fchromebook-central%2FKlqGYHmrgLs%2F9ttzkY9WBwAJ&msgid=9ttzkY9WBwAJ

Google has fixed the network address conflicts and pushed out the changes already. To use the words of one of the devs:
"The solution was to allocate a permanent IPv4 global address block specifically for this purpose. The address for the bridge will always be in this space now: 100.115.92.0/24"

RFC is dated on 2012, so some older routers and networking software (including older Android and ChromeOS versions, SDK, apps etc.) may be unaware of this special use and not know how to manage IP address range 100.64.0.0/10 (or subrange allocated by Google) properly. That's why third party app for connection forwarding (bridging or some similar action) may be needed.

[jacn]

Thanks for clarification. Yes, it's not private IP per se, but a special block of IPs that Google choose to use specifically to resolve conflicts with private IPs !

The timings confused me though. These issues and solution using 100.115.92.x and Connection Forwarder itself are all dated 2017 and before, while my TC Android problem surfaced only in Jun 2019 with Chrome OS 75 update. I guess it's ongoing Google's refinement to Android implementation on Chromebook that caused the current problem. It seems to also affect other Chromebook Android apps dealing with incoming network connections, so hopefully there will be a permanent resolution from Google in the future.

[jacn]

This is an update on sharing of files FROM TC Android on Chromebook using Wifi Transfer.

It's 2024 now. Since my last post in 2020, Connection Forwarder Chrome web app and Crossover for ChromeOS are no longer working. But I'm still using TC Windows to sync with my Android files in TC Android on Chromebook, perhaps the only one still doing this

THE PROBLEM:
Android on Chromebook is running in a Virtual Machine (VM) now. The Android VM is assigned an internal VM IP address (100.115.x.x in the Shared Address space) while the ChromeOS is using the regular IP address to access external network and Internet. ChromeOS allows the Android VM outgoing network access to the external network but doesn't permit direct incoming network connections from external network to the Android VM. When files are shared out in TC Android using Wifi Transfer, TC Android is listening to its network port (8081) on its VM IP address (100.115.x.x) which is not reachable from (TC Windows on) external network.

SOLUTION:
For Wifi Transfer to work, the incoming network traffic from (TC Windows on) external network need to be forwarded to the Android VM. Connection Forwarder Chrome app used to do this. Now, I run a small network utility SOCAT in Chromebook Linux to perform the forwarding of network ports. My SOCAT command is below where 100.115.92.20 is the Android VM IP address (which appears in the Wifi Transfer QR code screen). I execute this SOCAT command whenever I need to perform a TC file transfer with my Chromebook :

sudo socat TCP-LISTEN:8081,fork,reuseaddr TCP4:100.115.92.20:8081

To install SOCAT on Chromebook Linux : sudo apt-get install socat

On Windows TC, to connect to TC Android on Chromebook, QR code can't be used as it refers to the unreachable Android VM IP. Need to use the Chrome OS IP address (click on your network connection icon then network info icon) instead. On Windows TC, enter the URL on "Receive via wifi" screen as "xxx.xxx.xxx.xxx:8081/yyyy" where xxx.xxx.xxx.xxx is your Chrome OS IP and 8081/yyyy is the port and code shown on Android TC Wifi Transfer screen.

I have been using this approach to perform file transfer and file sync between Windows TC and Chromebook Android TC for years now.

[ghisler(Author)]

Thanks for providing this information! I recommend that you add a user with a password in the WiFi transfer plugin settings, then you can always use the same base path /8888 and store the URL on the target PC. This way you wouldn't need to scan the (not working) QR code.

[jacn]

And thank you Mr Ghisler for another good tip !

On a side issue, I have a long standing problem with image files copied into my Android phone that are not immediately accessible in image viewing/gallery apps because these apps depend on Android mediastore for image files, and Android mediastore takes a while to scan and update its index. Today, I learnt that running TC internal command 130 on the image folder in my phone SOMEHOW triggers an Android mediastore refresh so my newly copied images are now readily accessible to image viewing/gallery apps ! And TC internal command 130 goes all the way back to 2017 ?!? Well, I will have to monitor to see how well this really works out. Then I remember that I have been using TC Android Wifi Transfer on Chromebook and should put in the little effort to share the solution here, ha ha!

[ghisler(Author)]

How do you copy the files to the phone? Both Total Commander and the WiFi transfer plugin should already call this function used by command 130.

[jacn]

Mmm, the phone (receiving) folder is shared out via WiFi transfer. Images on Chromebook TC Android are copied to the Phone shared folder. Copying this way FROM Chromebook Android TO Android phone works as normal, don't need any port forwarding. The copied images are immediately available within phone TC Android of course, but not seen by other image viewing/gallery apps. I can confirm that after running TC Android command 130 on the phone folder where I stored the images, the image viewing/gallery apps (Aves and Google Gallery) can view the copied images. When Command 130 executes, it runs thru each of the files in the image folder. This solved a long standing problem for me, so I'm rather pleased with command 130. The phone is a Xiaomi Poco F3 running HyperOS 1.0.3.0 (Android 13) and TC Android 3.42 beta1d.

[ghisler(Author)]

Which app did you use the pass the folder to the WiFi transfer plugin?

[jacn]

TC Android. Don't use other File Managers unless I absolutely have to

On the phone, I use TC Android to select folder/s -> click and hold folder -> Send to -> Send via Wifi (Total Commander) to launch TC Wifi Transfer. On Chromebook, in TC Android, click on TC-Wifi Transfer icon in bottom bar then scan QR code on phone screen.

BTW, what is the difference between "Send to" and "Send to */*" options, they both work as far as I can tell.

[ghisler(Author)]

"Send to" gets a list of apps which support the file type of the selected file(s). For example, when a .txt file is sent, it looks for apps supporting files of type "text/plain". "Send to */*" looks for apps which support any file type. This usually gives a longer list of apps, but not all of them may actually accept the passed file(s).