I wrote a non-root tethering app, so I might have a bit of tunnel vision.

First, any good tethering app should be immune to a simple TTL check. The most likely culprits are instead application traffic patterns. The following immediately come to mind:

- Browser user agents

- Automatic status checks under both OS X and Windows

- Application behavior:

* Netflix and Hulu on Android isn't supposed to happen.

* Browsers like Chrome are very aggressive and can open dozens of simultaneous TCP connections. DNS prefetching can also generate dozens of requests over UDP in a very short time window.

Can you avoid these issues by establishing an SSH or VPN tunnel through the 3G/4G connection?

Yep. Any non-root tethering app should just show the encrypted tunnel as a connection originating from the device itself. Just make sure that DNS requests don't leak when using an SSH tunnel. In fact, a simple port-forwarding app is all that's really necessary for most tunnel cases.

All of this makes a $6-$8/mo SSH/VPN privacy service (e.g., cotse.net) rather intriguing.

Most properly configured VPN service providers will reroute any DNS request traffic to their private NS servers (e.g., privateinternetaccess.com).

Another thing I'd like to mention is MPPE is not functioning in most Android builds, so don't rely on PPTP based VPNs on your phone - encryption won't work! Make sure your VPN service provider has IPSec/L2TP tunneling available.

Obviously root users should opt for OpenVPN. (e.g., cyanogenmod 7+)

> First, any good tethering app should be immune to a simple TTL check.

If the phone sets its TTL to 255, what can you do?

The goal is not to forward packets blindly like a NAT. You emulate the NAT's behavior by running a TCP state machine in user space and converting packets to regular Android SDK calls. This is what all of the non-root tethering apps likely do, because raw socket access is not allowed.

ooh, i see. nice.

I have a theory that Verizon, at least, has started installing watchdogs that prevent covert tethering.

My Droid X has an odd property such that connecting it via USB (in USB mass storage mode) causes BSoD, so I've been looking for a way to transfer data without a connection.

The most promising was to run an FTP server on the phone (through a high port, since the lower ones like 21 are protected). This works for me intermittently, and is super-fast when it does, but more often than not, I'm told that it can't connect. The exact same behavior occurs with several different FTP server apps, as well as an HTTP server. It's not due to DHCP shuffling my IP address, and it may even work briefly for a minute before the connection breaks and can't be re-established.

On the other hand, going in the other direction works OK, either through FTP or through an SMB share to my desktop. Unfortunately, this method is painfully slow (I don't know why).

My solution, then, is to do any transfer via my notebook computer, to which the phone can connect via USB with no trouble.

Anyway, the only explanation I can think of for the mostly-not-working FTP server is that there is a watchdog that's looking for the phone to act as a server, and when it detects a port sitting there, it closes it. That's just my theory, but I can't think of anything else to explain the behavior.

I would first suspect some sort of powersaving feature. Try continuously using the phones interface locally (reloading webpages or something of the sort), and I bet you'll notice that your FTP server is always available from other computers.

I say this because I've noticed what seems to be similar behaviour with servers running on my hacked kindle3 (wifi only). They stop responding until you generate traffic from the kindle, which kicks the wifi card up from some sort of lower power level, or something.