How does WiFi-Tethering work and how do carriers detect it?

Hi!

In german boards there are several speculations about how the N1's WiFi tethering works and how carriers might detect it. But there are no real facts, it seems like there is no one, who really knows about it.

Maybe here are some kind of "cracks", who really know what they are talking about and can provide some real information about it.

How does N1-tethering work? I guess it uses NAT-routing. Is this right? And the probably most important part: How do carriers detect tethering? They officially claim, they could detect it. But the question is, which way do they do this? Can they only detect if you use tethering at all, or do they also have the ability to separate between tethered data and phone's data? Only in that case they would be capable to bill the tethered data (here in Germany some carriers do not prohibit tethering, they can only charge about 50 cent per MB).

Is it possible, that the carrier only detect several devices, that connect to the internet using tethering? I'm a vodafone-customer and I've tried tethering my iPad and my Linux-Netbook several times. Nothing has been charged. Other customers, having the same data-plan, reported, that they habe been charged for tethering within minutes.

Maybe someone can answer my questions.

If it really is like that, then I would just have to use Cisco-VPN on my iPad and they would not be able to read any requests anymore.

But someone in the official German vodafone-board said, the user-agent doesn't matter. And he seemed to be very sure about that. But unfortunately he didn't tell anything else. If you think of Dolphin for Android, which allows you to change the browser-identification, it really looks like this is nothing the carrier could make use of.

Ok, to find out more I've made a little research about how to generally detect Network Address Translation and I've made some tests.

As it seems, the Browser-Identification won't work. Maybe in spain there are some data-plans which only allow browsing with the special phone's browser and only using HTTP-Connections. But that's not suitable for a real data plan, which allows you, to send every data you like from your phone. On the other hand, at least in Germany, I think they wouldn't be allowed to read the data content of TCP-packets.

Then I've used a packet sniffer to find out, how different devices (N1, iPad and Kubuntu10.04) handle things like outgoing ports and packet IDs.
Both won't be very likely to use by the carrier, because Android doesn't increment them, but uses it by shuffle. The iPad also shuffles the packet IDs, but increments the ports. I think this will not matter, because the NAT will redirect the ports anyway. Only Kubuntu increments packet IDs and as they normally aren't changed by NAT, carriers could detect that. In general, all of the devices used outgoing ports between 35,000 and 55,000.

Possibly they could look at the time to live of the packets. The interesting question is, how the N1's NAT handels the TTL. Normally, a router decrements the TTL by 1. But it doesn't have to.
All of my tested devices use a TTL of 64 for outgoing packets (no one will wonder about that, because all those system are based on UNIX or Linux). So, if the NAT decrements the TTL, the carrier could detect tethered packets quite easily. Normal packets would reach the carrier's gateway with TTL 64, tethered packets with TTL 63. Maybe, the NAT doesn't decrement the TTL. Then the carrier wouldn't be able to detect it this way, except of this: As I read, Windows-Systems use a TTL of 128, so the carrier ould detect this immediately, no matter if it's decremented or not. This would explain why some people tell they could tether other phones without being billed, but getting charged when tethering their PC. This could only be covered, if the NAT would rewrite the TTL with 64. It don't think it does.

Maybe someone, who has a rooted phone (mine is not rooted, it's a normal FRF91), could install packet sniffer from the market and then catch some packets while tethering. Then we could have a look at the packet's headers and maybe find out, what the NAT does with the TTL.