iPhone TTL modification to cloak tethered packets - let's make them work harder to catch us.

[Fry-man22]

I know this has been discussed that AT&T is most likely keying on the fact that the TTL on packets coming through the iPhone router have an unexpected TTL (63 for OSX/iOS, 127 for Windows) to detect tethering. When they reach ATT's node packets should always have ttl=64 so we can get around this on a client by client bases by setting the TTL on each one to 65. This of course makes it where when the first hop to the phone occurs the packet ttl is decremented to the expected 64.

On OS X clients the TTL can be set appropriately by pasting the following in terminal:

sudo sysctl -w net.inet.ip.ttl=65

To modify the default TTL in Windows, do the following:

Click on Start and Run (or Search) and type "regedit" to open the Windows registry editor.
Navigate to the following registry key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
In the right-hand pane, right-click and select "New - DWORD (32-bit value)" and set its name to "DefaultTTL" and its value to 65 - I make no guarantees this does not adversely affect your Windows box

I have not researched how to modify this on the iOS side (for my iPad) because if I mess with anything in iOS I want it to be a more robust hack than just changing this on EVERY freaking device I connect to my network, it's just my luck some jerk would connect to MyWi and send some data and I get busted.

So now to the point of the thread. I have seen Linux scripts that set ALL traffic routed though a device to a certain value - I want this on my iPhone. Basically I just want to hard code the TTL on ALL packets that leave the phone - regardless of what it was at the source. I don't know what to start with that though so I thought I'd share with the brain trust here and see what we can come up with. At the end of the day I bet we could sell our TetherCloak on Cydia for at least a dollar

 

[Weiser878]

Tagged because I want to see the opinion of those who know more about this than I do

 

[drummr]

Like you said, I'd pay good money (as opposed to bad money?) for a tweak that changed all tethered ip packets to the correct TTL. Assuming this is in-fact how At&t is tracking tethering.

 

[Fry-man22]

So a bit more info - I went ahead and checked if the sysctl is available in iOS and it is. The same command listed above should also set the TTL on the iPad. I just tested with a terminal client on the iPhone but I see mo reason it would not be available on the iPad. I'll post back once I change it.

 

[cldipad]

iPad TTL

Any news on being able to change the ttl on iPad? If so, how did you do it? I assume you have opens installed and open the file system on you laptop?

 

[Fry-man22]

Any news on being able to change the ttl on iPad? If so, how did you do it? I assume you have opens installed and open the file system on you laptop?

Yes - you can change the TTL of the iPad by either installing a terminal client and using the sysctl command on the device or you can ssh into the device and execute it there. The command to change it is the exact same as the one posted above for OSX.

IMPORTANT NOTE though - this does NOT persist though a reboot of the iPad. After a reboot the ttl reverts to 64 and it MUST be changed again. It should be easy to create a shell script to do this and set it to execute at startup. I'll see if can get this done tonight and post how to set it up.

This whole thread should come with the disclaimer that we still don't know for sure if this is how they detect tethering. It is in my opinion by far the most likely, but that could be totally off base.

 

[ulbador]

I hate to break it to you, but this is NOT how this works. While your reasoning is sound, it's totally wrong.

With this setting, it would only handle the packets originating on the device, not routing through. Even then, I'm not even certain if the iOS kernel even respects this setting, or it could be one of those settings (like many of the rest of them), that are read only.

Even if it did work this way, you would still be incrementing the TTL by 1 from a set stock value, not incrementing it by 1 from what it is. Packets don't have a set TTL. The time can vary wildly depending on where it is coming from and how long it's been in transit.

For example:
Packet 1 may have a TTL of 34
Packet 2 may have a TTL of 50
Packet 3 may have a TTL of 20


Setting those all at 65 wouldn't do you any good. You would want to "smartly" rewrite them to either stay at the same value, or increment them one over where they are currently.

To handle the packets that are routed through, you need something like iptables with PRE and POST rules to actually intelligently rewrite the packets as they are routed through the device.


Case in point (stock 64 TTL) on my iMac tethered through my iPhone

daMac:~ adam$ ping www.google.com
PING www.l.google.com (74.125.159.103): 56 data bytes
64 bytes from 74.125.159.103: icmp_seq=0 ttl=49 time=293.547 ms
64 bytes from 74.125.159.103: icmp_seq=1 ttl=49 time=226.122 ms

65 TTL:

daMac:~ adam$ ping www.google.com
PING www.l.google.com (74.125.159.103): 56 data bytes
64 bytes from 74.125.159.103: icmp_seq=0 ttl=49 time=131.768 ms
64 bytes from 74.125.159.103: icmp_seq=1 ttl=49 time=173.036 ms

The result is exactly the same if I run the ping from the device itself.

Adam-IP4:~ root# sysctl -w net.inet.ip.ttl=65
net.inet.ip.ttl: 64 -> 65
Adam-IP4:~ root# ping www.google.com
PING www.l.google.com (74.125.225.17): 56 data bytes
64 bytes from 74.125.225.17: icmp_seq=0 ttl=53 time=32.426 ms
64 bytes from 74.125.225.17: icmp_seq=1 ttl=53 time=34.881 ms
^C--- www.l.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 32.426/33.654/34.881/1.228 ms
Adam-IP4:~ root# sysctl -w net.inet.ip.ttl=64
net.inet.ip.ttl: 65 -> 64
Adam-IP4:~ root# ping www.google.com
PING www.l.google.com (74.125.225.17): 56 data bytes
64 bytes from 74.125.225.17: icmp_seq=0 ttl=53 time=34.285 ms
64 bytes from 74.125.225.17: icmp_seq=1 ttl=53 time=36.551 ms
^C--- www.l.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 34.285/35.418/36.551/1.133 ms

 

[Fry-man22]

I hate to break it to you, but this is NOT how this works. While your reasoning is sound, it's totally wrong.

With this setting, it would only handle the packets originating on the device, not routing through. Even then, I'm not even certain if the iOS kernel even respects this setting, or it could be one of those settings (like many of the rest of them), that are read only.

Even if it did work this way, you would still be incrementing the TTL by 1 from a set stock value, not incrementing it by 1 from what it is. Packets don't have a set TTL. The time can vary wildly depending on where it is coming from and how long it's been in transit.

For example:
Packet 1 may have a TTL of 34
Packet 2 may have a TTL of 50
Packet 3 may have a TTL of 20


Setting those all at 65 wouldn't do you any good. You would want to "smartly" rewrite them to either stay at the same value, or increment them one over where they are currently.

To handle the packets that are routed through, you need something like iptables with PRE and POST rules to actually intelligently rewrite the packets as they are routed through the device.


Case in point (stock 64 TTL) on my iMac tethered through my iPhone

daMac:~ adam$ ping www.google.com
PING www.l.google.com (74.125.159.103): 56 data bytes
64 bytes from 74.125.159.103: icmp_seq=0 ttl=49 time=293.547 ms
64 bytes from 74.125.159.103: icmp_seq=1 ttl=49 time=226.122 ms

65 TTL:

daMac:~ adam$ ping www.google.com
PING www.l.google.com (74.125.159.103): 56 data bytes
64 bytes from 74.125.159.103: icmp_seq=0 ttl=49 time=131.768 ms
64 bytes from 74.125.159.103: icmp_seq=1 ttl=49 time=173.036 ms

The result is exactly the same if I run the ping from the device itself.

Adam-IP4:~ root# sysctl -w net.inet.ip.ttl=65
net.inet.ip.ttl: 64 -> 65
Adam-IP4:~ root# ping www.google.com
PING www.l.google.com (74.125.225.17): 56 data bytes
64 bytes from 74.125.225.17: icmp_seq=0 ttl=53 time=32.426 ms
64 bytes from 74.125.225.17: icmp_seq=1 ttl=53 time=34.881 ms
^C--- www.l.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 32.426/33.654/34.881/1.228 ms
Adam-IP4:~ root# sysctl -w net.inet.ip.ttl=64
net.inet.ip.ttl: 65 -> 64
Adam-IP4:~ root# ping www.google.com
PING www.l.google.com (74.125.225.17): 56 data bytes
64 bytes from 74.125.225.17: icmp_seq=0 ttl=53 time=34.285 ms
64 bytes from 74.125.225.17: icmp_seq=1 ttl=53 time=36.551 ms
^C--- www.l.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 34.285/35.418/36.551/1.133 ms

OK I'll address this so you can get up to speed even though your tone in your ignorance is laughable.

You can't get the accurate TTL data from the ping as in your post as (like you said in your own post ???) they have been routed by the network at that point and the TTL will have changed. You can't look past your router. I've watched the traffic directly on my internal network and I can tell you for sure I can set the TTL on packets as they leave OSX and iOS clients before they hit the first node on the network. I can also tell you for a FACT that tethered packets have a TTL one less after making the hop though a shared connection.

Also, I think you are missing the point of the hack at this point. Yes you are exactly correct that if we want a 100% solution something like iptables will be required - this is the Linux I reference in the OP.

Below are some screenshots of a network sniffer in promiscuous mode to show you "how it works".

As I said, I've tested this. Put together the test case again for the screenshots. I connected my iPad and my iPhone to my MBP via a shared wireless connection from the MBP. The iPhone (10.0.2.9) was at the default TTL=64. I then set MyWi on the iPhone to bridge the USB tether to WiFi and connected my wife's MBP default TTL=64 (so this IP is 10.0.2.9 to our sniffer) to the USB. Next I set the iPad (IP address 10.0.2.8) TTL=65. Screen shots show an exchange with google for each device.

First screenshot (Untitled) - shows the TTL of 64 coming from the iPhone.

Second screenshot (Untitled 2) - confirms that on the first hop the TTL is different on the iPad (65).

Third screenshot (Untitled 3) - Now I start making requests from the MBP tethered to the iPhone. These packets HAVE A TTL OF 63 (one less than the default 64) until I start modifying the client TTL because they have been routed through the phone

Fourth screenshot (Untitled 4) Modified the TTL on the tethered MBP to 70 so I could set it to 69 in the screenshot - I can set it to whatever I want below 255 and it will be decremented by one.


If you have insight as to why the TTL of the packets might not be what they are using to detect then please share, but the reasoning for the hack itself is sound and "right" from a logical AND technical perspective and I'm not going to spend any more time proving the concept.

 

[Natesac]

This stuff is a little over my head, but NOW WE ARE TALKING!!!

There should be some way to make tethered iPad traffic look like regular iPhone traffic.

 

[ulbador]

If you have insight as to why the TTL of the packets might not be what they are using to detect then please share, but the reasoning for the hack itself is sound and "right" from a logical AND technical perspective and I'm not going to spend any more time proving the concept.

Thank you for demonstrating your own ignorance on the subject.

The TTL would be the exact method they would use to detect it. But they should only detect 1 TTL at the router/firewall/iPhone for outgoing traffic, the 64, if the iPhone is the only device being used.

The very fact that all your examples, whether the values are being incremented or not, show different values, would be a damned good indicator that you are tethering.

If your iPhone's only TTL values being reported are 64, then clearly you are NOT tethering. All traffic is originated from your device. But if your TTL table looks like any one of your screenshots, they would know immediately that you were tethering. A Windows box has a TTL of 128, Mac usually 52, iPhone's 64.

The purpose of using iptables to rewrite the packets is two-fold.

One, it flattens out all the outgoing packets to have the same TTL as the border device. Second, and this is where your +1 methodology comes into play, it masks the hop between the router and an internal device to incoming packets by adding 1. This is also used to detect when other devices are behind a router, but in this case it does not apply at all because there would never be a valid case of a Windows machine with a TTL of 128 being bumped to 127 behind an iPhone. In this case, because it's an iPhone, to mask the traffic the first scenario would be what you would have to do, which your solution DOES NOT accomplish.

In fact, doing what you are doing will probably exacerbate the problem by making the TTL different from what AT&T is expecting for an iDevice. If every other iPhone on your network has TTLs coming out of it that are 64, and suddenly yours are 65, 78, 53, etc, that might be an indicator.

 

[Fry-man22]

Thank you for demonstrating your own ignorance on the subject.

The TTL would be the exact method they would use to detect it. But they should only detect 1 TTL at the router/firewall/iPhone for outgoing traffic, the 64, if the iPhone is the only device being used.

The very fact that all your examples, whether the values are being incremented or not, show different values, would be a damned good indicator that you are tethering.

If your iPhone's only TTL values being reported are 64, then clearly you are NOT tethering. All traffic is originated from your device. But if your TTL table looks like any one of your screenshots, they would know immediately that you were tethering. A Windows box has a TTL of 128, Mac usually 52, iPhone's 64.

The purpose of using iptables to rewrite the packets is two-fold.

One, it flattens out all the outgoing packets to have the same TTL as the border device. Second, and this is where your +1 methodology comes into play, it masks the hop between the router and an internal device to incoming packets by adding 1. This is also used to detect when other devices are behind a router, but in this case it does not apply at all because there would never be a valid case of a Windows machine with a TTL of 128 being bumped to 127 behind an iPhone. In this case, because it's an iPhone, to mask the traffic the first scenario would be what you would have to do, which your solution DOES NOT accomplish.

In fact, doing what you are doing will probably exacerbate the problem by making the TTL different from what AT&T is expecting for an iDevice. If every other iPhone on your network has TTLs coming out of it that are 64, and suddenly yours are 65, 78, 53, etc, that might be an indicator.

I can't decide if you're pretending not to get this or if you're really this thick. I AM NOT CHANGING THE IPHONE TTL - I am changing the TTL of devices TETHERED TO IT to 65 - then when it hops through the phone it decrements it to the expected 64. I can't help you understand this any better than the previous post but you clearly don't get whats going on as you posted completely irrelevant ping results as your basis for understanding.

Either port iptables to the phone so we can put in a router solution or just agree to disagree as you don't get the client side solution being discussed and you are clouding the issue for others.

Default TTL for OSX is 64 not 52. Please folks just ignore this fellow on this issue - I am as of this post

 

[scirica]

I'd love for the two of you to be civil. It sounds like you have a lot of knowledge and are on to something here. I'd love to see this built into a solid hack that could be tested and validated, then implemented.

I don't pretend to know who is right or wrong here. I'm just hopeful that one of you is on to something!

Cheers!

 

[Resevdog]

WHOOOSH!

The sound of all this going over my head. But if arguing the way you are guys gets to a solution in how to avoid the dreaded AT&T email/text, by all means, tear each other a new one. However, as Swayze said in Roadhouse, "Be nice."

 

[Fry-man22]

I'd love for the two of you to be civil. It sounds like you have a lot of knowledge and are on to something here. I'd love to see this built into a solid hack that could be tested and validated, then implemented.

I don't pretend to know who is right or wrong here. I'm just hopeful that one of you is on to something!

Cheers!

Edited the part of my post that was too abrasive but my frustration level with dude is pretty high. He's thinking about this from the wrong side for the solution on the client. If there was any modification to the device serving as the router then his statements would be correct. At this point though the hack is to change the packets at the source and then just let the routing take care of making sure all packets are set to 64 when they hit AT&T.

I admit hacking the client is inconvenient and a better solution should be implemented - that was the purpose of the thread. I agree We need iptables for iOS, that was referenced in the OP and anyone not following the logic at this point isn't going to help with that.

 

[headcase]

Edited the part of my post that was too abrasive but my frustration level with dude is pretty high. He's thinking about this from the wrong side for the solution on the client. If there was any modification to the device serving as the router then his statements would be correct. At this point though the hack is to change the packets at the source and then just let the routing take care of making sure all packets are set to 64 when they hit AT&T.

I admit hacking the client is inconvenient and a better solution should be implemented - that was the purpose of the thread. I agree We need iptables for iOS, that was referenced in the OP and anyone not following the logic at this point isn't going to help with that.

Thanks for the original post.

I think what would be most beneficial to the community now, would be for those who leverage your tip (modify the client TTL), to post whether they receive any text/email from AT&T in the future. Otherwise, we'll never know if AT&T is tracking tethering via TTL, or in fact is tracking tethering via some other means.

I for one, and going to leverage your tip, and see if AT&T eventually notifies me. However, given I'm not a heavy data user (usually less than 2GB per month), and rarely tether my iPhone 4, it might be a while. And hence, all the more reason I'll NEVER "force upgrade" to the needless tethering package from AT&T.

 

[Dr Kevorkian94]

This is great (and it makes sense to me, given his supporting evidence) assuming that this is how they are finding out. But there are people who have just used a lot of data and not tethered so they might be basing it off usage as well (witch I feel is wrong). But this should be tested if Many do this and don't get a message then its a sure fire way to tether without getting caught.

 

[headcase]

This is great assuming that this is how they are finding out. But there are people who have just used a lot of data and not tethered so they might be basing it off usage as well (witch I feel is wrong). But this should be tested if Many do this and don't get a message then its a sure fire way to tether without getting caught.

Without getting too off topic: there's too many packet inspection based methods to detect tethering, so its highly unlikely AT&T engineering would simply use high data usage as a means to identify such practice. Not only would that *not* indicate who was tethering vs. who was not tethering (think Netflix, Sling, and the growing list of video-based apps), such an approach would kill their productivity of trying to eliminate unauthorized tethering clients, and it would also open AT&T up to needless lawsuits down the road.

Rather, what is most likely happening, is that AT&T management has decided to systematically detect tethering users, first targeting those who are on the high-end of monthly data consumption (eg. 25+ GB per), and then once they've cleared that list, move down to the next batch (eg. 10+ GB per), and so on. Kind of a "stop the heavy bleeding first" approach for their network. I would even suspect that eventually AT&T will target those who are consuming under 2GB per month who are tethering, just to be consistent in their policy of non-tethering without a proper plan.

 

[cldipad]

Edited the part of my post that was too abrasive but my frustration level with dude is pretty high. He's thinking about this from the wrong side for the solution on the client. If there was any modification to the device serving as the router then his statements would be correct. At this point though the hack is to change the packets at the source and then just let the routing take care of making sure all packets are set to 64 when they hit AT&T.

I admit hacking the client is inconvenient and a better solution should be implemented - that was the purpose of the thread. I agree We need iptables for iOS, that was referenced in the OP and anyone not following the logic at this point isn't going to help with that.

Okay... I have terminal client installed and tried to enter the sysctl line. I get the response net.inet.ip.ttl: 64: Operation not permitted. What am I doing wrong? I haven't tried using SSH, but would like to make this as simple as possible. Were you able to find an easy way or some startup script to change the ttl on iPad? My hope is to change the ttl to 65 and start using PDANetnwith the hide tethering option. Thanks!

 

[Fry-man22]

Okay... I have terminal client installed and tried to enter the sysctl line. I get the response net.inet.ip.ttl: 64: Operation not permitted. What am I doing wrong? I haven't tried using SSH, but would like to make this as simple as possible. Were you able to find an easy way or some startup script to change the ttl on iPad? My hope is to change the ttl to 65 and start using PDANetnwith the hide tethering option. Thanks!

Thanks for pointing this out. Sorry should have mentioned this must be set by the root user. On iOS you become root a little differently than the in line sudo listed above. To become root on iOS type su at the terminal prompt and hit enter. Then type alpine as the password (or whatever you root pwd is if you changed it). You will need to drop the sudo from the OSX command listed in the op so it will look like:

sysctl -w net.inet.ip.ttl=65

Command for OSX can be prefixed with sudo in line and the command will be executed as root and you will be prompted for your password. I'll edit the op with the iOS command without sudo when I'm not posting from my phone.

 

[cldipad]

Thanks for pointing this out. Sorry should have mentioned this must be set by the root user. On iOS you become root a little differently than the in line sudo listed above. To become root on iOS type su at the terminal prompt and hit enter. Then type alpine as the password (or whatever you root pwd is if you changed it). You will need to drop the sudo from the OSX command listed in the op so it will look like:

sysctl -w net.inet.ip.ttl=65

Command for OSX can be prefixed with sudo in line and the command will be executed as root and you will be prompted for your password. I'll edit the op with the iOS command without sudo when I'm not posting from my phone.

I tried the above and it responds with net.inet.ip.ttl: 64 -> 65. I assume that means it changed the ttl to 65. I did check and it shows the ttl is 65. You say that I'll need to set it to 65 when I reboot my iPad. No problem since it only takes a few seconds; however, it would be nice to have some type of script to automatically do it.

Your opinion... changing the TTL to 65 on the ipad and using PDANet hide tethering to change the http user agent should be pretty good at keeping AT&T from noticing? I wish we knew exactly what they were looking at, but of course someone would have a Cydia app out right away to hide the tethering. I still might hold off tethering for a few just to see if any other information comes out. My cutoff date was April 16th and I did tether after that date, but only with my iPad. My billing cycle started over and no changes to my plan. I've only seen one or two posts on all the forums where someone's plan was changed. They didn't give any details so I'm not sure if they were exactly truthful. I've read about many other people continuing to tether and none of them have reported changes and their cutoff date was March 27th. Makes me a little nervous.

Thanks again for all your help on the ttl. Greatly appreciated.

 

[epifan]

does the use of VPN hide TTL from ATT or not?

If I am using a VPN ( on my iphone ) while tethering, can the ATT see TTL in the packets or not? Basically my company provides fully secured VPN tunnel and iphone profile for it, and I can securely connect my iphone to its network. I checked my IP address after that, and that becomes company's IP. Then I tether my laptop to that iphone. Am I fully protected from ATT sniffing the packets, or I still better change TTL on the laptop? Honestly I think using the VPN is the best way to tether, and not being caught by ATT.

 

[iluomo227]

yes even with VPN they can see TTL

@epifan .. yes, even with VPN they can see your TTL values as long as you're using AT&T's network to make the connection from your phone.

This is because the packets, even though the content is encrypted, must contain unencrypted header information so the packets know where to go. Think of it like a paper envelope.. even if the message inside of it is encrypted, you have to have an address on the envelope. In the case of IP headers, the TTL is included on the outside of that envelope.

So, it all comes down to how they are tracking us. Nobody on the outside knows for sure. If it's deep packet inspection, then VPN will solve that. If it's TTL, then only tinkering to modify TTL will work. Maybe it's both... I don't know of anything else they could use (other than just slapping us for whatever reason when we go beyond an invisible ceiling of data usage)

 

[drummr]

Does this change survive reboots on OSX? I did it on my Macbook and hopefully I won't get "the text".

 

[qsl]

@epifan .. yes, even with VPN they can see your TTL values as long as you're using AT&T's network to make the connection from your phone.

This is because the packets, even though the content is encrypted, must contain unencrypted header information so the packets know where to go. Think of it like a paper envelope.. even if the message inside of it is encrypted, you have to have an address on the envelope. In the case of IP headers, the TTL is included on the outside of that envelope.

I'm not sure this is right for the question that was asked. The question as I understood it was: can AT&T detect tethering if a VPN is used _On The iPhone_. I think your answer is correct for a VPN established on the tethered device but not for a VPN established on the iPhone.

I believe that, if the iPhone itself establishes the VPN, any tethered packets would be sent through the VPN, which results in the VPN software sending a new iPhone-originated packet containing the original packet through to the VPN software on the other side, where it's unwrapped and sent on to the original destination. If that's right, there should be no way for an external viewer (e.g. AT&T) to distinguish between a VPN packet originating with an iPhone app and a VPN packet originating from a tethered source.

I could be wrong about this, but I'm actually not sure how it would work for a VPN to NOT encapsulate all traffic, local or not, within a series of VPN packets. From a TCP/IP perspective, the VPN itself is the sender/receiver of all traffic; that there's other TCP/IP information contained within that stream should be irrelevant to the VPN packets themselves.

 

[Rascol]

AT&T Detects Tethering

OK - So I read all of the replies and I also spent quite a bit of time trying to figure out how they do it. Then I followed the Corporate trail as to who's software or services they would be using to do this... and lo and behold - I found the answer.

The have picked up Ciscos Openet - Orange France - and using FusionWorks DPI to detect tethering. I don't know exactly how this works - so if you get this post - there is your answer. How do you conceal tethering through Depp Packet Inspection? And is this even legal for AT&T to do because of some of the Privacy acts from 1988 to now.

The worst part of this is that after talking with AT&T - I have the $30.00 unlimited data plan grandfathered into my contract. I have had the same plan for 3 years now - and AT&T claims through their contract they can just add changes and I must adhere to them. Not as if I signed a contract stating I agree with the new tethering policies. I didn't. They just enforce. The kicker is I don't use that much data at all. I rarely tether and only do so when there is no access around and I must service a client - Then I usually use it for LogMeIn or email. My kids use the iPhone for Netflix and they use a ton of data. As pissed as I was with AT&T - I let them know if they are trying to cut down on usage - I wasn't going to comply.... I was going to run the crap out of Netflix and quadriple my usage - just to prove a point - I can be an ass too. They didn't like my statement to much!

So - anyone who can figure out how to hide tethering through DPI is going to be a hero.

Peace!