While I generally agree with those who say Snow Leopard was Apple's best release, I also have to say that Yosemite does seem to be an (small) step back in that direction. Here's hoping that El Capitan continues that trend and we eventually end up with a faster and more stable version of what Snow Leopard gave us.
I also don't see the "mobilization" and "socialization" that some people are talking about, though I have been watching the OS become more of a consumption platform than a productive tool since Lion. They haven't destroyed it as a productive tool and, again, it seems they're starting to turn it back around with Yosemite, so I'm still using it for now. We'll see how long that lasts.
The difference here is that he didn't get tired of the version of Unity he liked (his car's paint and wheels), he didn't like the version of Unity that was forced upon him as a replacement. That's more akin to selling your car that you love after someone bashes it all to hell with a sledgehammer and steals your wheels; depending on the severity of the damage (and with body work it doesn't take much) it may be less costly to scrap it and buy a new one.
Are you saying that Bell is less secure than T-Mobile for providing me with only one APN one my phone?
Yes. It opens you up to DNS spoofing attacks. Specifically, all a malicious person would need to do in order to be able to push you a malicious MMS message is be in control of your DNS and point mms.bell.ca to their server. Bonus points if they also point web.wireless.bell.ca to something they control as that is Bell's APN proxy, which would effectively give them all of your traffic. As it is, Bell's proxy can capture all of your traffic (and likely does under the guise of "caching"), while T-Mobile does not employ a proxy as per their APN settings.
The only reason it exists is because they pander to the carriers who don't care about net neutrality.
No, the reason it exists is because the phone must handle multiple data sources, such as the privateMMS network and the public internet. The functionality you are complaining about is the very same functionality that allows that. It's not pandering to anyone but the user's security; that some carriers (in your view) abuse it for other purposes is a completely different issue.
The phone would work just fine by sending both phone and tethering data through the same pipe
You're absolutely correct, assuming a full NAT implementation (which has apparently existed in Android as of 3.1, thanks again for pointing that out). However, the functionality you are complaining about would still need to be present to allow for MMS to use a separate and segregated network. That, right there, is a technical reason for its inclusion in phones. Not sure how you're having trouble grasping that, but I've run out of ways to explain it at this point so we're pretty much through unless you have a specific question I can answer to help you understand.
Even if T-Mobile supports 3 or even hundreds of differents APN, there is no technical reason for them to force its users to use different APN for phone and tethering data. Or at least, if there is one, you didn't present it in this thread.
Oh well, that seems fine enough to me since you were asking for a technical reason for Android to support multiple APNs that didn't involve pandering to the carriers. I gave you that. Good day, sir.
Ok, so I just realized how you're directing the argument to be unwinnable. Let me correct that.
Your carrier does not need a technical reason to want to know the source of your data, they merely need a technical means of doing so without inspecting packets (which would violate net neutrality laws in countries that have them). The technical reason for Android to continue supporting multiple APNs is MMS and the technical reason for Android to support it for that functionality is security. MMS messages are sent to your phone over a private network, not from the public internet; and with all the security issues centered around MMS messages lately, you should be thankful for that. Take away the phone's ability to support per-service APNs and you lose that security; take away the carrier's ability to push APN configurations for these services and you take away 99% of peoples' access to mobile data, MMS, and tethering as they won't be able to figure out how to set it up if the carrier does not do it for them.
Good enough? Technical enough? Good.
More to the point, nobody has to trust my words when they can to their own research. Seriously. If I was trying to bullshit you I would have claimed to be a T-Mobile network technician, not to have spoken with a few of them.
I'm not implying that you should trust me. I know who I spoke to and I'm going to take their word over yours. I honestly don't care if you believe me, but you see that email address above my posts? That's a unique identifier by which a number of people know my, personally, so I'm staking my reputation on the quality and accuracy of the information I provide here. Trust that or don't, doesn't matter to me.
I've given accurate information and done my best to correct your inaccuracies; not for your benefit, but for the benefit of anyone else who may read your incorrect statements. Not having followed through after starting to do so would also have weighed on my reputation.
You go right on ahead and consider that. You're saying the guys who actually maintain T-Mobile's network are full of it, too, since they're one of my primary sources. So, you know better than the network techs working for a major carrier, eh? Where's your mobile network, then?
There is much you do not know; more than can be presented here. There is likewise much that I do not know, which I would need in order to properly explain the technical reasons for it in a way you might understand. They do exist, they are valid, and someone closer to the industry can explain them. If you've never dealt with a network larger than your home LAN, I could see how you might think there to be no valid reason for segmenting traffic by source.
And finally, as I originally said, most smartphones do have the ability to perform NAT,
That may be, I'm not arguing that.
and there is no valid technical reason to segregate phone and tethering traffic.
Tethering-enabled dumbphones.
I'll say it again, for the fourth time. Tethering-enabled dumb phones.
Android have the ability to segregate these two types of traffic, and again, it's not for a technical reason
Except that it is. Before Android supported NAT (and even now that it does as some, if not most, carriers use same network for all phones), it used the same method tethering-enabled dumb phones use. Oh and, for the 5th time, tethering-enabled dumb-phones. They still use the carrier-NATed APN.
but because Google pandered to carriers such as yours, which do not care at all about net neutrality
Oh, really? And they've thus far lived up to those words.
Why is CONFIG_NF_NAT=y enabled by default on base Android configuration then?
Why yes, thank you for pointing out that it's been there since 3.1. Froyo (2.2) introduced tethering, though, and NAT wasn't available on Android at that time; I haven't looked at the kernel in... wow, it really has been that long.
For the phone CPU, handling over all the packets to the radio, or NAT/routing them, make no difference in terms of battery or CPU usage.
You're probably right, except that it's not an either-or proposition. The packets have to be passed to the radio either way, it's not like doing the routing in CPU magically means you don't have to pass data to the radio for transmission. Even ignoring that the radio can do this many times more efficiently than the CPU, having the CPU do it then pass it to the radio, rather than just passing it to the radio, does incur a cost. As for why this is enabled in the kernel by default, consider apps like Barnacle, which originally implemented NAT in DALVIK, slow as balls. It makes the platform more attractive to give those apps the ability to do those things natively. You'd have to ask the Android development team for specifics, but I bet the answer won't involve tethering on most carriers.
We are not talking about a lot of packets here
If we're talking about more than 7GB/mo (specifically, 2TB/mo) we're talking about a lot of packets; and if we're not, then how did the discussion start in the first place?
nor a gigabit link
I suppose you've never used external references to illustrate a point? Oh, wait, you literally just did.
But at first you were claiming that the PC was getting an IP address from the carrier instead of the phone.
Quote me on that? I claimed that the phone pulled an IP address to route the computer's traffic to. That's very different.
NATing or not, when the device already does routing and powering both radios, must have negligible impacts on battery life and CPU usage.
The radios handle the networking internally; they, and not the device itself, do the routing. The device only configures the radios which, being specialized devices, use less power to do that work than the CPU would use. To give you some perspective on that, a 5-port gigabit switch can function with an ASIC running in the hundreds of megahertz, maintaining 100% throughput on all ports, while we're still able to walk into a store and buy computers with GHz-class CPUs that can't manage to saturate a single gigabit link because the CPU can't keep up and the system lacks the specialized hardware necessary to offload the task. Mind you, I'm talking bottom-of-the-barrel laptops and the computing appliances Dell, HP, and Asus have started selling, but I'm also talking 1.5-2.5GHz CPUs and 4+GB of RAM being outclassed by a 450MHz ASIC and a couple MB of RAM. Why? Because the specialized hardware just does the job faster, at lower power.
And that's why Android routing is done in the radios; specifically because yes, it would impact CPU and, therefore, battery.
Finally, you need a degree to be an engineer where I live.
And quotation marks have a special meaning where I live. Clearly, not an English major, either.
And, again, having spoken with T-Mobile network technicians, the actual people working on the network and not any support tier (hey, it helps to know people), I know I'm right in this instance, at least as far as my carrier is concerned. You aren't going to convince me you know more than they do; especially when you display a complete lack of motivation to research and learn for yourself rather than making the random guesses you think sound most logical.
The still need to support devices not capable of NAT, so they still need the NAT hardware on their end. So, you're getting NAT from your carrier anyway. If your phone is NATing you, too, it's doing you a disservice by killing its own battery faster, passing packets through a slower chain (your device's CPU and RAM), and double-NATing, when the radio chip everythign has to pass through anyway already has the ability to do the routing necessary to simply use the carrier's already-in-place NAT at almost no pwer cost, without delaying packets at all or adding to the load on the device.
You must be an engineer. Not a good one, probably lacking a degree in the field or any practical experience, but an "engineer", for sure.
It's also likely that all Bell Canada mobile data actually shares the same AP and everything gets NATed at the carrier level. After all, they still have to support those dumb phones, pre-2.2 Android devices, pre-iPhone4 iPhones (before that it was usb and bluetooth only, definitely 1:1 routed), Curve-era Blackberries, and pre-7.5 Windows phones. Hell, it wasn't until a handful of years ago that flagship devices even gained the processing power and RAM required to perform full NAT; even today only mid-line and better devices are powerful enough for it, and it's still a battery killer.
Don't just argue about it on the internet, though. Do as I suggested, talk to some network technicians at your provider. Who knows, maybe Bell does things differently and you are correct; I know, from having done this myself, that I'm correct with regard to T-Mobile. Some rando in the internet is not going to convince me they know more about my carrier's network than the technicians who build and maintain it, sorry.
I don't pay for a "license to tether", I pay for an unlimited _data_ plan.
Right there in the promotional text, though, it says in bold all-caps "ON-SMARTPHONE ONLY". That's what they advertise, that's what they sell, that's what you pay for. Don't shit on the one carrier who's actually up front with their customers about what they're selling just because they don't sell what you want and threaten to terminate your service when you try to take it anyway.
If somebody says my unlimited data plan has tethering restricted, it's pretty much the same that saying my unlimited data plan can only be used if I use it on a 386 machine, or that I can only use it for certain hours of the day, or that I must use my mobile computer with a blindfold for the unlimited part to kick in.
Do you also bitch at McDonalds that you deserve unlimited Big Macs and fries because the Big Mac meal you bought included a drink with unlimited refills? After all, the drink can't really be unlimited if the burger and fries it was sold with are limited, right?
Can you see the point I'm making?
Yes, I see the point you're trying to make. It's wrong, but I see it.
Because if you can't, I'm sorry but you have a blindfold yourself placed on you by corporate interests.
No, I just read what I'm paying for before I pay for it. Unlimited mobile data, not unlimited tethered data. It's spelled out very clearly in all of the marketing materials I've seen. In fact, here's what's on their website right now. It's not even fine print, it's written larger, and in a higher contrast color scheme, than the promotional text on the button you click to select the plan. I'd say they're doing a shit job of hiding it if that's what they're after.
T-mobile have no way of knowing who is tethering and who is simply using a lot of data on the phone.
Tethering uses a different APN than mobile data. You think they can't tell based on that? Clearly, they know when I'm tethering, since they are able to tell me how much of my 7GB tethering allotment I have remaining even when I've used well over 20GB of mobile data on top of it.
Bypassing this by switching your tethering APN won't work, because the mobile data APN doesn't NAT like the tethering APN does, but other solutions exist such as Barnacle, which implements a full NAT router on your phone. T-Mobile can, of course, note that you historically have used 7GB of tethering and (say) 100BM of mobile data then, one month, use 7.1GB of mobile data and no tethering (while testing to see that it works as intended), then suddenly much more mobile data and still no tethering. Any reasonably intelligent person will know that you're bypassing tethering restrictions when that happens.
But you're right, they can't prove beyond all doubt that you are tethering if you bypass the restrictions. Of course, when you sue (neigh arbitrate with) them, the preponderance of evidence will point to excessive tethering in violation of their terms of service and you will lose. But go ahead and try it anyway.
It is an unlimited mobile (read: on your mobile device) data plan. That it includes a bonus 7GB (my mistake, last I checked it was 5, it was 2.5 when I signed up, seems the number keeps getting bigger) of tethering does not negate the fact that what is being sold to you as unlimited is still, in fact, unlimited. They could just as well sell you unlimited LTE mobile data without the option to tether; would you prefer that?
It's under the guise that high demand users are thieves.
No, it's under the guise that high-demand tetherers are violating the terms of service they agreed to by bypassing the restrictions they agreed to abide by. If you were using 2TB/mo legitimately on your phone, they wouldn't care. It's theft in the same way subscribing to basic cable and using a black box to get all the channels is theft, with the added "bonus" that the bandwidth you're using incurs an actual cost for the provider.
I torrent 100% legal files.
And I have a bridge to go buy so I can resell it to anyone else who believes that.
There is no broadband where I live.
That's sad, satellite isn't an option, either?
LTE is it after the local phone company refused to fix my dsl.
Oh, so AT&T cut over to pure U-Verse in your area? Explore that option; if it's served from a VRAD in your area and not an IPDSLAM, it's actually decent service. The easiest way to tell is if they sell U-Verse TV (and not resold Dish) in your area; if so, it's coming from a VRAD and it's the good stuff. It was rock solid, stable, and fast as hell when I had it, then I moved to an area serviced by IPDSLAM and the best they could offer me was 6mbps with shit pings and too much downtime. Ironically, a 3rd party provider was able to sell me a rock solid 20mbps over the same lines, from a remote 600ft farther away. I moved again more recently and the best I can get from either provider is 4mbps; I miss that VRAD. Oh well, DSL is my backup connection now, anyway; it's 150mbps cable all the way, now.
You agreed to the terms, abide by them. Nobody will cry for you when you get cut off for violating them. The LTE mobile data they sell as unlimited is, in fact, unlimited; the limited tethering they add on at no additional charge is advertised as limited. Has been since I signed up which, incidentally, was they day they started offering their un-carrier plans.
That is certainly not the case for a stock Nexus 6 on T-Mobile.
Which phone and carrier? Did you load the page from your phone (with wi-fi turned off, to force mobile data), then again from your computer or laptop tethered to your phone? Or did you load it from your phone both times?
It's almost certainly 1:1 routing. You can have many 1:1 assignments, multiple LAN local private IPs map/route to the same number of carrier-facing private IPs behind a carrier grade NAT solution. Of course, you can't ignore the carrier grade NAT, as that's the NAT part of the equation that you keep repeating must be there despite the fact that I've stated that yes, it is there, several times.
Slashdot Mirror
While I generally agree with those who say Snow Leopard was Apple's best release, I also have to say that Yosemite does seem to be an (small) step back in that direction. Here's hoping that El Capitan continues that trend and we eventually end up with a faster and more stable version of what Snow Leopard gave us.
I also don't see the "mobilization" and "socialization" that some people are talking about, though I have been watching the OS become more of a consumption platform than a productive tool since Lion. They haven't destroyed it as a productive tool and, again, it seems they're starting to turn it back around with Yosemite, so I'm still using it for now. We'll see how long that lasts.
The difference here is that he didn't get tired of the version of Unity he liked (his car's paint and wheels), he didn't like the version of Unity that was forced upon him as a replacement. That's more akin to selling your car that you love after someone bashes it all to hell with a sledgehammer and steals your wheels; depending on the severity of the damage (and with body work it doesn't take much) it may be less costly to scrap it and buy a new one.
And this we agree on.
While this is true, having a proxy in place makes it much easier.
Then your APN settings are wrong. And direct from Bell. Note that those settings are listed as being for the Nexus One, as Bell's support page does not list the Nexus 5.
Are you saying that Bell is less secure than T-Mobile for providing me with only one APN one my phone?
Yes. It opens you up to DNS spoofing attacks. Specifically, all a malicious person would need to do in order to be able to push you a malicious MMS message is be in control of your DNS and point mms.bell.ca to their server. Bonus points if they also point web.wireless.bell.ca to something they control as that is Bell's APN proxy, which would effectively give them all of your traffic. As it is, Bell's proxy can capture all of your traffic (and likely does under the guise of "caching"), while T-Mobile does not employ a proxy as per their APN settings.
The only reason it exists is because they pander to the carriers who don't care about net neutrality.
No, the reason it exists is because the phone must handle multiple data sources, such as the privateMMS network and the public internet. The functionality you are complaining about is the very same functionality that allows that. It's not pandering to anyone but the user's security; that some carriers (in your view) abuse it for other purposes is a completely different issue.
The phone would work just fine by sending both phone and tethering data through the same pipe
You're absolutely correct, assuming a full NAT implementation (which has apparently existed in Android as of 3.1, thanks again for pointing that out). However, the functionality you are complaining about would still need to be present to allow for MMS to use a separate and segregated network. That, right there, is a technical reason for its inclusion in phones. Not sure how you're having trouble grasping that, but I've run out of ways to explain it at this point so we're pretty much through unless you have a specific question I can answer to help you understand.
Even if T-Mobile supports 3 or even hundreds of differents APN, there is no technical reason for them to force its users to use different APN for phone and tethering data. Or at least, if there is one, you didn't present it in this thread.
Oh well, that seems fine enough to me since you were asking for a technical reason for Android to support multiple APNs that didn't involve pandering to the carriers. I gave you that. Good day, sir.
Ok, so I just realized how you're directing the argument to be unwinnable. Let me correct that.
Your carrier does not need a technical reason to want to know the source of your data, they merely need a technical means of doing so without inspecting packets (which would violate net neutrality laws in countries that have them). The technical reason for Android to continue supporting multiple APNs is MMS and the technical reason for Android to support it for that functionality is security. MMS messages are sent to your phone over a private network, not from the public internet; and with all the security issues centered around MMS messages lately, you should be thankful for that. Take away the phone's ability to support per-service APNs and you lose that security; take away the carrier's ability to push APN configurations for these services and you take away 99% of peoples' access to mobile data, MMS, and tethering as they won't be able to figure out how to set it up if the carrier does not do it for them.
Good enough? Technical enough? Good.
More to the point, nobody has to trust my words when they can to their own research. Seriously. If I was trying to bullshit you I would have claimed to be a T-Mobile network technician, not to have spoken with a few of them.
How is minimizing the number of network configurations one has to managebnot a valid reason? Sod off.
I'm not implying that you should trust me. I know who I spoke to and I'm going to take their word over yours. I honestly don't care if you believe me, but you see that email address above my posts? That's a unique identifier by which a number of people know my, personally, so I'm staking my reputation on the quality and accuracy of the information I provide here. Trust that or don't, doesn't matter to me.
I've given accurate information and done my best to correct your inaccuracies; not for your benefit, but for the benefit of anyone else who may read your incorrect statements. Not having followed through after starting to do so would also have weighed on my reputation.
You go right on ahead and consider that. You're saying the guys who actually maintain T-Mobile's network are full of it, too, since they're one of my primary sources. So, you know better than the network techs working for a major carrier, eh? Where's your mobile network, then?
Apparently, nobody can do that.
There is much you do not know; more than can be presented here. There is likewise much that I do not know, which I would need in order to properly explain the technical reasons for it in a way you might understand. They do exist, they are valid, and someone closer to the industry can explain them. If you've never dealt with a network larger than your home LAN, I could see how you might think there to be no valid reason for segmenting traffic by source.
The very post you referenced where you were "correcting" me. I had never so much as uttered your name prior to that.
And finally, as I originally said, most smartphones do have the ability to perform NAT,
That may be, I'm not arguing that.
and there is no valid technical reason to segregate phone and tethering traffic.
Tethering-enabled dumbphones.
I'll say it again, for the fourth time. Tethering-enabled dumb phones.
Android have the ability to segregate these two types of traffic, and again, it's not for a technical reason
Except that it is. Before Android supported NAT (and even now that it does as some, if not most, carriers use same network for all phones), it used the same method tethering-enabled dumb phones use. Oh and, for the 5th time, tethering-enabled dumb-phones. They still use the carrier-NATed APN.
but because Google pandered to carriers such as yours, which do not care at all about net neutrality
Oh, really? And they've thus far lived up to those words.
Why is CONFIG_NF_NAT=y enabled by default on base Android configuration then?
Why yes, thank you for pointing out that it's been there since 3.1. Froyo (2.2) introduced tethering, though, and NAT wasn't available on Android at that time; I haven't looked at the kernel in... wow, it really has been that long.
For the phone CPU, handling over all the packets to the radio, or NAT/routing them, make no difference in terms of battery or CPU usage.
You're probably right, except that it's not an either-or proposition. The packets have to be passed to the radio either way, it's not like doing the routing in CPU magically means you don't have to pass data to the radio for transmission. Even ignoring that the radio can do this many times more efficiently than the CPU, having the CPU do it then pass it to the radio, rather than just passing it to the radio, does incur a cost. As for why this is enabled in the kernel by default, consider apps like Barnacle, which originally implemented NAT in DALVIK, slow as balls. It makes the platform more attractive to give those apps the ability to do those things natively. You'd have to ask the Android development team for specifics, but I bet the answer won't involve tethering on most carriers.
We are not talking about a lot of packets here
If we're talking about more than 7GB/mo (specifically, 2TB/mo) we're talking about a lot of packets; and if we're not, then how did the discussion start in the first place?
nor a gigabit link
I suppose you've never used external references to illustrate a point? Oh, wait, you literally just did.
But at first you were claiming that the PC was getting an IP address from the carrier instead of the phone.
Quote me on that? I claimed that the phone pulled an IP address to route the computer's traffic to. That's very different.
NATing or not, when the device already does routing and powering both radios, must have negligible impacts on battery life and CPU usage.
The radios handle the networking internally; they, and not the device itself, do the routing. The device only configures the radios which, being specialized devices, use less power to do that work than the CPU would use. To give you some perspective on that, a 5-port gigabit switch can function with an ASIC running in the hundreds of megahertz, maintaining 100% throughput on all ports, while we're still able to walk into a store and buy computers with GHz-class CPUs that can't manage to saturate a single gigabit link because the CPU can't keep up and the system lacks the specialized hardware necessary to offload the task. Mind you, I'm talking bottom-of-the-barrel laptops and the computing appliances Dell, HP, and Asus have started selling, but I'm also talking 1.5-2.5GHz CPUs and 4+GB of RAM being outclassed by a 450MHz ASIC and a couple MB of RAM. Why? Because the specialized hardware just does the job faster, at lower power.
And that's why Android routing is done in the radios; specifically because yes, it would impact CPU and, therefore, battery.
Finally, you need a degree to be an engineer where I live.
And quotation marks have a special meaning where I live. Clearly, not an English major, either.
Of course your phone used DHCP to assign IP addresses to connected devices, but a DHCP server has nothing to do with NAT. Which NAT daemon do you see running on your Android device? Tethering was introduced in Foryo (2.2) but Froyo was unable to support NAT due to inability to port the required kernel modules. Can it be done in userland? Sure, no reason you can't implement it in DALVIK (Java), but the performance would be shit. Then, there's this discussion. There's plenty more if you Google a bit.
And, again, having spoken with T-Mobile network technicians, the actual people working on the network and not any support tier (hey, it helps to know people), I know I'm right in this instance, at least as far as my carrier is concerned. You aren't going to convince me you know more than they do; especially when you display a complete lack of motivation to research and learn for yourself rather than making the random guesses you think sound most logical.
The still need to support devices not capable of NAT, so they still need the NAT hardware on their end. So, you're getting NAT from your carrier anyway. If your phone is NATing you, too, it's doing you a disservice by killing its own battery faster, passing packets through a slower chain (your device's CPU and RAM), and double-NATing, when the radio chip everythign has to pass through anyway already has the ability to do the routing necessary to simply use the carrier's already-in-place NAT at almost no pwer cost, without delaying packets at all or adding to the load on the device.
You must be an engineer. Not a good one, probably lacking a degree in the field or any practical experience, but an "engineer", for sure.
It's also likely that all Bell Canada mobile data actually shares the same AP and everything gets NATed at the carrier level. After all, they still have to support those dumb phones, pre-2.2 Android devices, pre-iPhone4 iPhones (before that it was usb and bluetooth only, definitely 1:1 routed), Curve-era Blackberries, and pre-7.5 Windows phones. Hell, it wasn't until a handful of years ago that flagship devices even gained the processing power and RAM required to perform full NAT; even today only mid-line and better devices are powerful enough for it, and it's still a battery killer.
Don't just argue about it on the internet, though. Do as I suggested, talk to some network technicians at your provider. Who knows, maybe Bell does things differently and you are correct; I know, from having done this myself, that I'm correct with regard to T-Mobile. Some rando in the internet is not going to convince me they know more about my carrier's network than the technicians who build and maintain it, sorry.
I don't pay for a "license to tether", I pay for an unlimited _data_ plan.
Right there in the promotional text, though, it says in bold all-caps "ON-SMARTPHONE ONLY". That's what they advertise, that's what they sell, that's what you pay for. Don't shit on the one carrier who's actually up front with their customers about what they're selling just because they don't sell what you want and threaten to terminate your service when you try to take it anyway.
If somebody says my unlimited data plan has tethering restricted, it's pretty much the same that saying my unlimited data plan can only be used if I use it on a 386 machine, or that I can only use it for certain hours of the day, or that I must use my mobile computer with a blindfold for the unlimited part to kick in.
Do you also bitch at McDonalds that you deserve unlimited Big Macs and fries because the Big Mac meal you bought included a drink with unlimited refills? After all, the drink can't really be unlimited if the burger and fries it was sold with are limited, right?
Can you see the point I'm making?
Yes, I see the point you're trying to make. It's wrong, but I see it.
Because if you can't, I'm sorry but you have a blindfold yourself placed on you by corporate interests.
No, I just read what I'm paying for before I pay for it. Unlimited mobile data, not unlimited tethered data. It's spelled out very clearly in all of the marketing materials I've seen. In fact, here's what's on their website right now. It's not even fine print, it's written larger, and in a higher contrast color scheme, than the promotional text on the button you click to select the plan. I'd say they're doing a shit job of hiding it if that's what they're after.
T-mobile have no way of knowing who is tethering and who is simply using a lot of data on the phone.
Tethering uses a different APN than mobile data. You think they can't tell based on that? Clearly, they know when I'm tethering, since they are able to tell me how much of my 7GB tethering allotment I have remaining even when I've used well over 20GB of mobile data on top of it.
Bypassing this by switching your tethering APN won't work, because the mobile data APN doesn't NAT like the tethering APN does, but other solutions exist such as Barnacle, which implements a full NAT router on your phone. T-Mobile can, of course, note that you historically have used 7GB of tethering and (say) 100BM of mobile data then, one month, use 7.1GB of mobile data and no tethering (while testing to see that it works as intended), then suddenly much more mobile data and still no tethering. Any reasonably intelligent person will know that you're bypassing tethering restrictions when that happens.
But you're right, they can't prove beyond all doubt that you are tethering if you bypass the restrictions. Of course, when you sue (neigh arbitrate with) them, the preponderance of evidence will point to excessive tethering in violation of their terms of service and you will lose. But go ahead and try it anyway.
It's under the guise that high demand users are thieves.
No, it's under the guise that high-demand tetherers are violating the terms of service they agreed to by bypassing the restrictions they agreed to abide by. If you were using 2TB/mo legitimately on your phone, they wouldn't care. It's theft in the same way subscribing to basic cable and using a black box to get all the channels is theft, with the added "bonus" that the bandwidth you're using incurs an actual cost for the provider.
I torrent 100% legal files.
And I have a bridge to go buy so I can resell it to anyone else who believes that.
There is no broadband where I live.
That's sad, satellite isn't an option, either?
LTE is it after the local phone company refused to fix my dsl.
Oh, so AT&T cut over to pure U-Verse in your area? Explore that option; if it's served from a VRAD in your area and not an IPDSLAM, it's actually decent service. The easiest way to tell is if they sell U-Verse TV (and not resold Dish) in your area; if so, it's coming from a VRAD and it's the good stuff. It was rock solid, stable, and fast as hell when I had it, then I moved to an area serviced by IPDSLAM and the best they could offer me was 6mbps with shit pings and too much downtime. Ironically, a 3rd party provider was able to sell me a rock solid 20mbps over the same lines, from a remote 600ft farther away. I moved again more recently and the best I can get from either provider is 4mbps; I miss that VRAD. Oh well, DSL is my backup connection now, anyway; it's 150mbps cable all the way, now.
You agreed to the terms, abide by them. Nobody will cry for you when you get cut off for violating them. The LTE mobile data they sell as unlimited is, in fact, unlimited; the limited tethering they add on at no additional charge is advertised as limited. Has been since I signed up which, incidentally, was they day they started offering their un-carrier plans.
That is certainly not the case for a stock Nexus 6 on T-Mobile.
Which phone and carrier? Did you load the page from your phone (with wi-fi turned off, to force mobile data), then again from your computer or laptop tethered to your phone? Or did you load it from your phone both times?
It's almost certainly 1:1 routing. You can have many 1:1 assignments, multiple LAN local private IPs map/route to the same number of carrier-facing private IPs behind a carrier grade NAT solution. Of course, you can't ignore the carrier grade NAT, as that's the NAT part of the equation that you keep repeating must be there despite the fact that I've stated that yes, it is there, several times.