Secure Shell is not working without Wi-Fi

204 views
Skip to first unread message

arod....@gmail.com

unread,
Dec 11, 2017, 6:18:37 AM12/11/17
to chromium-hterm
Hello,

I have just found out that I cannot connect to a local SSH server on my Chromebook when the Wi-Fi is disabled.
Secure Shell just hang for a while and return with a code 255.

Is it something to expect or is it a bug?

Mike Frysinger

unread,
Dec 11, 2017, 1:30:13 PM12/11/17
to arod....@gmail.com, chromium-hterm
Secure Shell itself shouldn't be dependent upon any network settings.  if it's reachable via whatever network settings are active, Secure Shell should work.

your description overall is a bit vague.  if you aren't connected to a network, then obviously DNS won't work, so you'd have to use an IP address.  that IP address has to be routable too.
-mike

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/975e7780-d2df-4936-ade8-a13e9cdbcdf4%40chromium.org.

Louis Arod

unread,
Dec 13, 2017, 10:55:44 AM12/13/17
to Mike Frysinger, chromium-hterm
I am working on ChromeOS and I run an SSH server locally using Termux. The SSH server has a local address which is 100.115.92.2 and I can ping the address from Crosh (the ChromeOS shell) with or without a network connection. But, Secure Shell can only connect to the IP address when a network connection is available (Wi-Fi or Ethernet). 

Below is the output of the route command with the Wi-Fi enabled:
crosh> route
/0 default via 192.168.0.1 dev mlan0 metric 1 
/1 100.115.92.0/30 dev br0 proto kernel scope link src 100.115.92.1 
/2 192.168.0.0/24 dev mlan0 proto kernel scope link src 192.168.0.32 
/3
Below is the output of the route command with the Wi-Fi disabled:
crosh> route
/0 100.115.92.0/30 dev br0 proto kernel scope link src 100.115.92.1 
/1
Below is a screenshot of my Secure Shell config:
Screenshot 2017-12-13 at 16.43.48.png

Below is the error I get when I try to connect to the local server with the Wi-Fi disabled:
pasted3

So, the IP address seems to be routable and I can reach the network without an Internet connection. Am I missing something? I'd happy to give you more information.

Thank you,
Louis.

Scott Harney

unread,
Dec 13, 2017, 11:02:35 AM12/13/17
to Louis Arod, Mike Frysinger, chromium-hterm
connect to localhost interface 127.0.0.1 instead.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hterm+unsubscribe@chromium.org.
 To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CAO1eQ3gPBVtBCRoyZ8nROy-g953SLT1-eUc%2BC8O5Jf-cVYoVZw%40mail.gmail.com.



--

Louis Arod

unread,
Dec 13, 2017, 11:26:49 AM12/13/17
to Scott Harney, Mike Frysinger, chromium-hterm
I have just tried and it does not work. The server is at the address 100.115.92.2 and I can connect to it when the Wi-Fi is enable.
The problem is that I lose the connection as soon as I disable the Wi-Fi. This is odd because I can still ping the address and the SSH server is still running.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CAO1eQ3gPBVtBCRoyZ8nROy-g953SLT1-eUc%2BC8O5Jf-cVYoVZw%40mail.gmail.com.

Scott Harney

unread,
Dec 13, 2017, 11:32:12 AM12/13/17
to Louis Arod, Mike Frysinger, chromium-hterm
is the ssh server configured to listen on all interfaces (0.0.0.0)?

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hterm+unsubscribe@chromium.org.

Louis Arod

unread,
Dec 13, 2017, 11:56:12 AM12/13/17
to Scott Harney, Mike Frysinger, chromium-hterm
The server is configure to listen on all interface. But, going through all the network verification again, I think that the problem might comes from Termux.

With the Wi-Fi disabled I can ping from Chrome to Termux but I can't ping from Termux to Chrome. That might explain why Secure Shell hangs for a long time before failing. I will ask on the Termux mailing list.

Thank you for your help!

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.

Mike Frysinger

unread,
Dec 13, 2017, 1:22:08 PM12/13/17
to Louis Arod, Scott Harney, chromium-hterm
i suspect this is actually on the CrOS side.  we might take down firewall rules that allow access when the network goes down.  the IP address you're listing is the ARC++ container, not a public IP address.

are you in dev mode ?  if so you'd be able to dump the firewall rules to double check.  i don't think we include that info in debug logs, but we probably should add it.
-mike

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hterm+unsubscribe@chromium.org.

Louis Arod

unread,
Dec 14, 2017, 2:27:47 AM12/14/17
to Mike Frysinger, Scott Harney, chromium-hterm
Hey Mike,

I am not in dev mode. I looked at how to enable it and it seems that it will delete my account and my information. Is there any other way I can access the firewall rules?

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.

Mike Frysinger

unread,
Dec 14, 2017, 3:25:15 PM12/14/17
to Louis Arod, Scott Harney, chromium-hterm
currently i don't think we dump that info anywhere, nor do we provide any commands to explicitly dump it.  seems like it would be worth while adding somewhere.

in the mean time, i don't think we have a workaround for you.
-mike

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hterm+unsubscribe@chromium.org.

Louis Arod

unread,
Dec 18, 2017, 7:06:09 AM12/18/17
to Mike Frysinger, Scott Harney, chromium-hterm
Hello again,

I have switched to developer mode to have a look around. I have listed iptables rules with and without Wi-Fi and they don't  change. Is that what you were talking about with "firewall rules"? 

iptables rules:
chronos@localhost / $ sudo iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A FORWARD -m mark --mark 0x1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.

Mike Frysinger

unread,
Dec 19, 2017, 2:20:49 PM12/19/17
to Louis Arod, Scott Harney, chromium-hterm, Kevin Cernekee
[ +cernekee ]

it might be in other tables and not just the main input/output/forward ones

looking at some bugs, we were still chasing things in R62.  Kevin might know the current status wrt ARC++ connection forwarding.
-mike

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hterm+unsubscribe@chromium.org.

Kevin Cernekee

unread,
Dec 19, 2017, 3:17:05 PM12/19/17
to Mike Frysinger, Louis Arod, Scott Harney, chromium-hterm, abhis...@chromium.org
On Tue, Dec 19, 2017 at 11:20 AM, Mike Frysinger <vap...@chromium.org> wrote:
[ +cernekee ]

it might be in other tables and not just the main input/output/forward ones

looking at some bugs, we were still chasing things in R62.  Kevin might know the current status wrt ARC++ connection forwarding.

For inbound connections from the LAN to Android, the NAT table (`-t nat`) is updated on link up/down/change:


However, that shouldn't affect connections between Chrome OS and Android.  A more likely explanation is that Android tears down the IP and routes when Chrome OS notifies it that there is no active LAN connection.

Here is what I see in termux when Chrome OS wifi is enabled:



After disabling wifi on the Chrome OS side, the Android network is no longer configured:
​

​
This is working as designed, because we want Android apps to be aware when the LAN connection disappears and reappears.​


The SSH server has a local address which is 100.115.92.2 and I can ping the address from Crosh (the ChromeOS shell) with or without a network connection.

This part surprises me, because when I tested it, Android did not have an IP address at all when Chrome OS wifi was disabled.

We are looking into ways to support multiple LAN interfaces concurrently on Android (e.g. exposing both wifi and wired interfaces to Android when both are connected).  Part of this work would involve setting up a dedicated "control" interface for adb and other private CrOS<->Android communication, so that Android would still be accessible when the LAN is down.  So, what you're seeing is a known limitation, and it is on our radar screen.
Reply all
Reply to author
Forward
0 new messages