[BUG] A17(+)/GOS | Managed-/Multi-Profiles - Invalid configuration Message on Not Profile That First Started Orbot (Android 17+ Security Measure?)

[TheNec]

Describe the Bug

• Does not Connect/Start Proxy, Invalid Configuration, Address (Port 9050) already in use, unlearned counting +1

To Reproduce

Steps to reproduce the behavior:

1. Install Android 17
2. [ EDIT ] Watch Orbot automatically connecting and running in Owner's Personal Profile after reboot [ edit ] OR Other Profile [ /edit ]
3. While 2. - Watch Orbot failing Everywhere Else (In Managed-Profiles | Not tested under Secondary Users but should be the same
   [ EDIT ] behavior | Should also fail under Owner/Personal when started Somewhere Else Before I think [ edit ] Confirmed: Owner/Work
   [ EDIT ] first OR Owner/Secure first work -> Owner/Personal AND Owner/REMAINING fail [ /edit ]
4. ( Transport jumps automatically from direct to obfs4 at least visually but doesn't do anything while failing equally )

Expected Behavior

Watch Orbot not failing Everywhere Else than in Owner's Personal or First Started Profile

Device/s

• [ EDIT ] Affected: [ Pixel 10 Pro Fold | Pixel (7) Tablet ] | [ All Android 17(+) Devices? ]
• [ EDIT ] OS (Phone): [ GrapheneOS (Most probably unrelated!) | Alpha Channel / Stable Release currently + Security Preview Releases ]
• [ EDIT ] OS (Tablet): [ GrapheneOS (Most probably unrelated!) | Stable Channel / Release + Security Preview Releases ]
• [ EDIT ] Version: [ Build 2026061800(+) / Android 17 + Security Preview Backports ]

[ EDIT ] Application Logs ( Phone | Not checked on Tablet but same behavior! )

Information GoLog: Opening Socks listener on 127.0.0.1:9050
Warning Tor-connection: Could not bind to 127.0.0.1:9050: Address already in use. Is Tor already running?
...
[ EDIT ] Warning Tor-connection: Could not bind to 127.0.0.1:8118: Address already in use. Is Tor already running? | Unrelated? See below!
Error Tor-api: Tor returned with an eror
Error TorService: java.lang.IllegalStateException: Tor could not start!
...
Information GoLog [notice]: Opening HTTP tunnel listener on 127.0.0.1:8118 | Unrelated? Works now!? Why/How?
Information GoLog [notice]: Closing partially... (several stuff)
Information GoLog [warn]: Failed to parse/validate config: Failed to bind one of the listener ports.
...
Error TorService: java.io.IOException: cannot read /data/user/13/org.torproject.android/app_TorService/data/ControlSocket

btw. Address already in use -> Socket already in use.

Additional Context

Before finding the Address already in use (On Port 9050) Warning my first guess was a New Security Measure introduced with Android 17 that Prevents Cross Profile Using Of Localhost Webservers so that the guys maybe couldn't talk to each other which is still my only guess but doesn't explain why the HTTP-Port doesn't work at first but later - maybe not in use by Other Orbot? There are also some Memory Tagging Engine crashes but those are not very often so most probably also unrealated.

Btw. I've had a Similar Issue before usually When Updating Orbot from the Personal Profile while Also Running in Work and/or Secure Profile/s leading to Race Conditions where the Winner Takes Port 9050 and the Other/s Fail/s because it/they Also Want To Use Port 9050 but Without Trying To Change it to 9051+ needing a restart to solve this. So I think both problems could be solved by making the claiming mechnism more robust.

E.g.:

if ( Warning == Tor-connection: Could not bind to 127.0.0.1:9050: Socket already in use. Is Tor already running? )

{

$port = $port++

}

or something like that. ( Alternatives: 127.[0-255].[0-255].[2-254]:9050 )

Thank you in advance and thanks for your work on Orbot! =)

---

[ EDIT ] If anyone has the Same Connection Problem After Orbot Updates as Described Above: Restart is not needed (anymore?) with
[ EDIT ] recent versions. Close/Freeze/Lock all Orbot Running Profiles except The Last One/The First One You Want To Start Orbot in. If it
[ EDIT ] couldn't connect before it should now connect. If this doesn't work automatically open the app and manually dis-/connect. Start
[ EDIT ] sub-profiles again. Orbot connections should work now.

[bitmold]

@TheNec you're correct about the port issues with Android 17. I suspect this isn't Graphene specific, but I'm able to reproduce it on GrapheneOS with Android 17.

I was able to get things working by making these changes to TorConfig. Essentially just using auto for the torrc SOCKSPort, HTTPTunnelPort, DNSPort, and TransPort

@n8fr8 and I were talking about a fix for this. Most users don't rely on any of these ports except for SocksPort. And when they use the SOCKS port, they do so unknowingly when they use Orobt as a VPN.

I think the default behavior will be to:

• turn off all ports except for SOCKSPort
• make SOCKSPort default to auto instead of 9050.
• allow users to turn on the remaining ports for proxying if they so desire
  • when turned on, each port defaults to being set to "auto"
  • on a per profile basis, power users can manually set each port to instead use constants that they desire

--- a/app/src/main/java/org/torproject/android/service/tor/TorConfig.kt
+++ b/app/src/main/java/org/torproject/android/service/tor/TorConfig.kt
@@ -1,6 +1,7 @@
 package org.torproject.android.service.tor
 
 import android.content.ContextWrapper
+import android.util.Log
 import org.torproject.android.service.OrbotConstants
 import org.torproject.android.service.circumvention.Transport
 import org.torproject.android.service.db.OnionServiceColumns
@@ -28,12 +29,12 @@ object TorConfig {
             conf.add("SOCKSPort 0.0.0.0:$socksPortPref $ipv6Pref $isolate")
             conf.add("SocksPolicy accept *:*")
         } else {
-            conf.add("SOCKSPort $socksPortPref $ipv6Pref $isolate")
+            conf.add("SOCKSPort auto $ipv6Pref $isolate")
         }
 
         conf.add("SafeSocks 0")
         conf.add("TestSocks 0")
-        conf.add("HTTPTunnelPort $httpPortPref $isolate")
+        conf.add("HTTPTunnelPort auto $isolate")
 
         if (Prefs.connectionPadding) {
             conf.add("ConnectionPadding 1")
@@ -52,8 +53,8 @@ object TorConfig {
         val transPort = Prefs.torTransPort ?: OrbotConstants.TOR_TRANSPROXY_PORT_DEFAULT.toString()
         val dnsPort = Prefs.torDnsPort ?: OrbotConstants.TOR_DNS_PORT_DEFAULT.toString()
 
-        conf.add("TransPort ${NetworkUtils.checkPortOrAuto(transPort)} $isolate")
-        conf.add("DNSPort ${NetworkUtils.checkPortOrAuto(dnsPort)} $isolate")
+        conf.add("TransPort auto $isolate")
+        conf.add("DNSPort auto $isolate")
         conf.add("VirtualAddrNetwork 10.192.0.0/10")
         conf.add("AutomapHostsOnResolve 1")
         conf.add("DormantClientTimeout 10 minutes")
@@ -111,7 +112,7 @@ object TorConfig {
 
         val custom = Prefs.customTorRc
         if (!custom.isNullOrEmpty()) conf.add(custom)
-
+        Log.wtf("TEST1730", conf.joinToString("\n"))
         return conf.joinToString("\n")
     }

[bitmold]

In the meantime, you can set SOCKSPort et al. to either be auto on each profile, or to ports that don't conflict with ports bound on other profiles. Sorry about this.

[bitmold]

This also seems like it'll require some changes to tor-android's TorService.java...

[TheNec]

@bitmold

Hey thanks for looking into this, trying to help and sorry for the late reply! Also there is no need to apologize!

I don't know if [ SOCKSPort auto ] will solve the problem because before GOS A17 multi-profile only had the problem described above when updating Orbot but not when you start them one after another because then the port number was counted up automatically (this still works most probably but can't test on Android <17 atm.) so I think there is already some kind of automatism that just doesn't work for Android 17 for whatever reason.

---

/** 16.1.0-RC-1-tor-0.4.0.4-rc / 8 July 2019 / - **/

814fbb3 reset default ports to 9050, 8118 but make them dynamic if needed - ports will be checked and if not available, increment +1 - new setting add to allow static setting of http port value

---

As [ torrc ] seems to be not available without root I tried to change the [ Tor-SOCKS ] and [ Tor-HTTP ] Settings (after finding them) but they only allow numbers from the GUI including rejecting c+p. Adding [ SocksPort = auto / HTTPTunnelPort = auto ] values as a User Defined torrc Configuration seem to be ignored or I did something wrong.

---

/** 16.1.1-BETA-2-tor-0.4.0.4-rc / Wed Aug 7 13:33:30 2019 -0400 / - **/

361ea26 ports can be set to "auto" so allow letters as well

---

Atm. I manually set the Ports 9050, 9051, 9052; 8118, 8119, 8120 for the different profiles instanced Orbots which works as expected while additionally working around the update bug.

---

Btw. I couldn't find the manual settings before because I didn't look under Debug as I expected them somewhere else (at Power-User setting maybe)

[bitmold]

@TheNec

I'm going to be mostly away from working on Orbot for a little while, but this ought to be fixed. I have a GOS Android 17 device, and many older Androids, so this is def a priority of mine when there's time.

Adding [ SocksPort = auto / HTTPTunnelPort = auto ] values as a User Defined torrc Configuration seem to be ignored or I did something wrong.

You made a mistake, there aren't any equal signs in torrc so the file would look like:

torrc:

SOCKSPort auto
HTTPTunnelPort auto
DNSPort auto

Things probably didn't work for you because of that equals sign...

On my computer, I can run tor with this one line torrc and verify that it's assigning ports automatically. I'm seeing this work, with Orbot, on my GrapheneOS Android 17 phone too.

SOCKSPort auto

SOCKSPort = auto

But actually, the commit you linked to doesn't even need to be in the app at all... Orbot doesn't need to try and find free ports, tor already does that for itself as demonstrated above. I'm removing this logc form Orbot and defaulting to tor's assignment of auto ports to reduce complexity.

Btw. I couldn't find the manual settings before because I didn't look under Debug as I expected them somewhere else (at Power-User setting maybe)

This will be moved somewhere more sensible in the UI a future release , thanks for catching that! And again, in that future release, the default behavior with ports will be, by default, as I described above:

• turn off all ports except for SOCKSPort
• make SOCKSPort default to auto instead of 9050.
• allow users to turn on the remaining ports for proxying if they so desire (most users don't need these)
• when turned on, each port defaults to being set to "auto"
• on a per profile basis, power users can manually set each port to instead use static constants that they desire