Unusual Amtrak Wi-Fi connectivity issue

[Steve Pope]

On this morning's southbound Capitol Corridor, the AmTrak Wi-Fi
connection behaved as follows: the splash page loaded, and accepted
the user's clicking on agreement to TOS; thenceforth, ssh, IPSec, and
some other connection types behaved normally; but browsers
had no connectivity. The behavior was consistent across two
otherwise functional devices, so was definitely in their system.

Fortunately I process email and Usenet from a shell, so I was not
too slowed down. And some sites are still usable from lynx.
But it makes one consider having a browser that tunnels through
ssh as a backup.


Steve

[Roy]

Post by Steve Pope
On this morning's southbound Capitol Corridor, the AmTrak Wi-Fi
connection behaved as follows: the splash page loaded, and accepted
the user's clicking on agreement to TOS; thenceforth, ssh, IPSec, and
some other connection types behaved normally; but browsers
had no connectivity. The behavior was consistent across two
otherwise functional devices, so was definitely in their system.
Fortunately I process email and Usenet from a shell, so I was not
too slowed down. And some sites are still usable from lynx.
But it makes one consider having a browser that tunnels through
ssh as a backup.
Steve

They probably try to save bandwidth by having a transparent caching
proxy somewhere.

Just use VPN software. VPNGate is my recommendation these days. Many
of their servers use SSL which would bypass a proxy. Did I mention its
free???

http://www.vpngate.net/en/

Probably not a bad idea to use a VPN via AMTRAK (or other public Wifi
service) anyway

[Rob Warnock]

Steve Pope <***@speedymail.org> wrote:
+---------------
| Fortunately I process email and Usenet from a shell, so I was not
| too slowed down. And some sites are still usable from lynx.
| But it makes one consider having a browser that tunnels through
| ssh as a backup.
+---------------

Both Firefox & Chrome[1], at least, can be set to use a SOCKS proxy,
and "ssh -D <localport> ..." makes OpenSSH act as a SOCKS proxy
(current OpenSSH speak both SOCKS4 & SOCKS5).

I use this myself in several situations, both with WiFi & cellular
data. In particular, I've found that when using AT&T Edge or 3G
cell data the connection is *much* more stable if *all* of your
traffic is funnelled through *one* SSH connection. [Yes, since I
tend to have multiple shells open at once, that means tunnelling
both the browser *and* all of the other SSH connections through
the first SSH session I open.]

I have hypothesized that this is because AT&T's cell data network
blows away old, long-lived TCP connections in favor of new ones.
If you let your browser run "native", your SSH shell session(s)
will very likely be blown away by the network fairly quickly.
Tunnelling *everything* through one SSH session (hence only one
TCP connection) makes this problem *much* less severe. IME. YMMV.


-Rob

[1] Under ChromeOS (e.g., on Chromebooks), the proxy setting is
specified under the specific *network connection* you're using,
which is a bit weird IMHO, but does allow you to automatically
use SOCKS proxying on some Wifi access points and not others.

The Chromebook "Secure Shell" app is a wrapper ("NaCl") around
OpenSSH, and so allows you to specify the usual "-D/-L/-R"
options.

-----
Rob Warnock <***@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403