Just because thethering dumb phone can't perform NAT (something I didn't verify) is not a valid reason for segregating traffic on smartphones. No matter if Android ever supported a tethering method that didn't involve NAT, there is no valid technical reason to keep it. It's legacy code which only contribute to bloat. Just because T-Mobile claim they support net neutrality doesn't mean they do.
A slow Android phone is more than fast enough to route/NAT 2TB/month of data. That's not a lot of packets, because it involves large packets.
Anyways, nobody uses Android 2.2 anymore. All recent Android phones have NAT and probably use it. It's not a provision for NAT applications. There is no such application in the play store that doesn't require rooting the phone AFAIK.
And finally, as I originally said, most smartphones do have the ability to perform NAT, and there is no valid technical reason to segregate phone and tethering traffic. Bell Canada is doing it just fine. Android have the ability to segregate these two types of traffic, and again, it's not for a technical reason, but because Google pandered to carriers such as yours, which do not care at all about net neutrality.
You said it was 1:1 routing. That means if you have 12 PCs connected to your phone, the carrier is giving you 12 IPs, plus one for the phone itself I guess. You also said that most phones weren't able to do NAT.
Why is CONFIG_NF_NAT=y enabled by default on base Android configuration then?
It looks to me that NAT is enabled on all Android devices, and chances are it's probably being used for the hot spot function. Otherwise Google would list it as an optional/recommended feature. 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. We are not talking about a lot of packets here, nor a gigabit link.
First of course I know DHCP has nothing to do with NAT. But at first you were claiming that the PC was getting an IP address from the carrier instead of the phone. This is obviously not true on Android. Second, NAT is done at the kernel level in Linux. I'm sure it's long fixed by now, if there ever was any issue with older Android kernels. Then, I don't have a lack of motivation, I just don't know anyone working for Bell who could answer that question. Like most people. I still doubt that the people you talked to really knew what they were talking about. NATing or not, when the device already does routing and powering both radios, must have negligible impacts on battery life and CPU usage. Finally, you need a degree to be an engineer where I live.
What are you talking about? Even a low end Android device is more than powerful enough to do NAT. You are not convincing at all. I'm not going to call Bell to ask the question, as the support agent won't be able to answer such a technical detail anyways. Just open a command line on your phone and type ifconfig and you should see how many IP addresses you have. With ps you should also see the DHCP server running, the IP address your PC get doesn't come from the carrier.
From my phone once and then from my PC, of course. Nexus 5 on Bell Canada. Therefore as you said, my phone is doing NAT. I'm pretty sure yours is doing NAT too, just that you may have two different PPP sessions (one for the phone data, another for tethered data). I don't think your phone is going to get an IP address from the carrier (regardless whether it's public or private trough carrier grade NAT) for each connected device. It might have worked differently in the early days of dumb phone tethering through USB, but with smartphones and WiFi hotspot sharing, where you can have more than one device connected, NAT definately seems like the natural solution.
It's a limitation violating net neutrality. Just like you can agree that bittorrent will be slowed down or banned on your unlimited cell phone plan. It's not because you agree to it that it's not a violation of net neutrality. You can't compare that to reselling your cable connection. We are talking about the same user doing the same usage, only from a different device. Tethering to yourself isn't reselling. Also the content of the Internet itself is free, unlike cable TV. You pay for bandwidth, not content.
I don't think it's 1:1 routing, because there can be many PCs attached to my phone's hot spot. They all get a private IP address assigned by my phone's DHCP server. The obvious solution is to use NAT so that all PCs share the same IP address as seen by the carrier. Whether that IP address is public or not is not relevant.
What you are describing is still NAT. Just because there might be two public IP addresses (I didn't verify) doesn't mean NAT isn't involved. Since the IP address of my PC is on a subnet local to my phone and my PC, different from the subnet used between my phone and the carrier, I would say NAT is used.
Android might be splitting tethering and phone traffic to pander to the carriers, but nothing would stop Google from putting all traffic together. In fact, it would have been a much simpler and cleaner design.
It's an artificial limitation. A byte is a byte. The carrier of a neutral network wouldn't care whether the data comes from the phone or is routed by it.
Last time I checked, my Android phone had a private IP address as well as a DHCP server on its WiFi interface when enabling the hot spot function. My phone acts as a NAT/router, my PC isn't getting an IP address from the carrier, but from the phone. Even when I lose cellular signal I can still ping my phone.
You are confusing vendor lock-in and proprietary software. Vendor lock-in always implies two purchases. A software by itself can't be "vendor-locked", whatever that means.
The reality is that there are actual technical reasons for routing tethering traffic through a different APN
No, there isn't.
Since most phones aren't also routers capable of performing NAT locally, this, again, is a necessity.
Most smartphones (80%) sold last years are Android devices. They all have the Wifi hotspot function, which uses NAT. I am pretty sure Apple does the same and Windows Phone too. So what are you talking about?
The fact that they are routed to different APNs and identifiable by the carrier is itself a violation of net neutrality (and my privacy). Cell phone manufacturers always pander to carriers and that's why they added such functionality. If phones were sold to users instead of carriers, such a functionality would not have been developed to begin with. Just like my ISP doesn't know if my home traffic comes from my router or a device which "tether" its bandwidth.
Anyway it's my phone and I should be free to install whatever application to it. If it breaks the carrier's packet discrimination scheme, it's not my problem.
The short term price can be costly in the long run. That's why I sometimes accept to pay *more* for something. Even tough some cheaper alternative would satisfy my requirements, in the long run they could be more expensive to own/repair/replace. Being vendor locked-in increase long-term costs, or at least the expectation of these costs.
So I avoid vendor lock-in as much as possible. And you know what, it's not even hard in this case. It's not as if I were missing some important software that would improve my life I can't even think of one of these "app" that I wish I could have.
An app is a software. Yes you are being a smart ass, and yes, it is comparable to PC software. PC software too is "meant to work on the ecosystem it was purchased in". It can be highly hardware dependent or not, just like PC software.
The vendor will always want you to be locked-in as much as possible. As a consumer, my goal is to be as free as possible.
Which is still better. Being vendor locked-in in both hardware and software is worse than being locked-in for software only. Of course the ideal is not to be locked at all.
Also the problem isn't only that these apps may be vapor in a few years. They can be vapor *tomorrow* if your phone breaks.... that is, unless you buy another phone from the exact same vendor, which also implies that this vendor must still agree to sell you compatible phones. That's why you are vendor locked-in. You don't have the same freedom that I have to walk away and choose another vendor.
A software is meant to be reusable. You can't compare that to an admission ticket. If I were renting a software for 2 hours I wouldn't care as much about vendor lock-in either. The same goes for food. It is meant to be eaten only once. Eating in one restaurant doesn't force me to eat there next week. If it did, I would consider another restaurant instead. I wouldn't buy a car which could only bring me to one restaurant, however.
There is no advantage to the iPhone's walled garden. On Android, you can allow "unknown sources" if you want to. That option is disabled by default. You would be free not to check it on Android.
I understand that some people prefer the iPhone and/or iOS, for various reasons, but the walled garden is really not something I even consider an argument.
I'd only switch for a stock Android device but if I were to switch now, I'd be giving up all my paid apps
You should have thinked twice before vendor locking-in yourself like that. I personally don't buy applications that can only be executed on devices from a single vendor.
Slashdot Mirror
Just because thethering dumb phone can't perform NAT (something I didn't verify) is not a valid reason for segregating traffic on smartphones.
No matter if Android ever supported a tethering method that didn't involve NAT, there is no valid technical reason to keep it. It's legacy code which only contribute to bloat.
Just because T-Mobile claim they support net neutrality doesn't mean they do.
A slow Android phone is more than fast enough to route/NAT 2TB/month of data. That's not a lot of packets, because it involves large packets.
Anyways, nobody uses Android 2.2 anymore. All recent Android phones have NAT and probably use it. It's not a provision for NAT applications. There is no such application in the play store that doesn't require rooting the phone AFAIK.
And finally, as I originally said, most smartphones do have the ability to perform NAT, and there is no valid technical reason to segregate phone and tethering traffic. Bell Canada is doing it just fine. Android have the ability to segregate these two types of traffic, and again, it's not for a technical reason, but because Google pandered to carriers such as yours, which do not care at all about net neutrality.
You said it was 1:1 routing. That means if you have 12 PCs connected to your phone, the carrier is giving you 12 IPs, plus one for the phone itself I guess.
You also said that most phones weren't able to do NAT.
Why is CONFIG_NF_NAT=y enabled by default on base Android configuration then?
https://source.android.com/dev...
It looks to me that NAT is enabled on all Android devices, and chances are it's probably being used for the hot spot function. Otherwise Google would list it as an optional/recommended feature.
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. We are not talking about a lot of packets here, nor a gigabit link.
First of course I know DHCP has nothing to do with NAT. But at first you were claiming that the PC was getting an IP address from the carrier instead of the phone. This is obviously not true on Android.
Second, NAT is done at the kernel level in Linux. I'm sure it's long fixed by now, if there ever was any issue with older Android kernels.
Then, I don't have a lack of motivation, I just don't know anyone working for Bell who could answer that question. Like most people. I still doubt that the people you talked to really knew what they were talking about.
NATing or not, when the device already does routing and powering both radios, must have negligible impacts on battery life and CPU usage.
Finally, you need a degree to be an engineer where I live.
What are you talking about? Even a low end Android device is more than powerful enough to do NAT. You are not convincing at all.
I'm not going to call Bell to ask the question, as the support agent won't be able to answer such a technical detail anyways.
Just open a command line on your phone and type ifconfig and you should see how many IP addresses you have. With ps you should also see the DHCP server running, the IP address your PC get doesn't come from the carrier.
Because the license for the content is for one household.
From my phone once and then from my PC, of course. Nexus 5 on Bell Canada. Therefore as you said, my phone is doing NAT. I'm pretty sure yours is doing NAT too, just that you may have two different PPP sessions (one for the phone data, another for tethered data). I don't think your phone is going to get an IP address from the carrier (regardless whether it's public or private trough carrier grade NAT) for each connected device.
It might have worked differently in the early days of dumb phone tethering through USB, but with smartphones and WiFi hotspot sharing, where you can have more than one device connected, NAT definately seems like the natural solution.
It's a limitation violating net neutrality. Just like you can agree that bittorrent will be slowed down or banned on your unlimited cell phone plan. It's not because you agree to it that it's not a violation of net neutrality. You can't compare that to reselling your cable connection. We are talking about the same user doing the same usage, only from a different device. Tethering to yourself isn't reselling. Also the content of the Internet itself is free, unlike cable TV. You pay for bandwidth, not content.
I made the test and I get the same public IP in both cases.
I don't think it's 1:1 routing, because there can be many PCs attached to my phone's hot spot. They all get a private IP address assigned by my phone's DHCP server. The obvious solution is to use NAT so that all PCs share the same IP address as seen by the carrier. Whether that IP address is public or not is not relevant.
What you are describing is still NAT. Just because there might be two public IP addresses (I didn't verify) doesn't mean NAT isn't involved. Since the IP address of my PC is on a subnet local to my phone and my PC, different from the subnet used between my phone and the carrier, I would say NAT is used.
Android might be splitting tethering and phone traffic to pander to the carriers, but nothing would stop Google from putting all traffic together. In fact, it would have been a much simpler and cleaner design.
It's an artificial limitation. A byte is a byte. The carrier of a neutral network wouldn't care whether the data comes from the phone or is routed by it.
Last time I checked, my Android phone had a private IP address as well as a DHCP server on its WiFi interface when enabling the hot spot function.
My phone acts as a NAT/router, my PC isn't getting an IP address from the carrier, but from the phone. Even when I lose cellular signal I can still ping my phone.
You are confusing vendor lock-in and proprietary software. Vendor lock-in always implies two purchases. A software by itself can't be "vendor-locked", whatever that means.
The reality is that there are actual technical reasons for routing tethering traffic through a different APN
No, there isn't.
Since most phones aren't also routers capable of performing NAT locally, this, again, is a necessity.
Most smartphones (80%) sold last years are Android devices. They all have the Wifi hotspot function, which uses NAT. I am pretty sure Apple does the same and Windows Phone too. So what are you talking about?
The fact that they are routed to different APNs and identifiable by the carrier is itself a violation of net neutrality (and my privacy). Cell phone manufacturers always pander to carriers and that's why they added such functionality. If phones were sold to users instead of carriers, such a functionality would not have been developed to begin with. Just like my ISP doesn't know if my home traffic comes from my router or a device which "tether" its bandwidth.
Anyway it's my phone and I should be free to install whatever application to it. If it breaks the carrier's packet discrimination scheme, it's not my problem.
The short term price can be costly in the long run. That's why I sometimes accept to pay *more* for something. Even tough some cheaper alternative would satisfy my requirements, in the long run they could be more expensive to own/repair/replace. Being vendor locked-in increase long-term costs, or at least the expectation of these costs.
So I avoid vendor lock-in as much as possible. And you know what, it's not even hard in this case. It's not as if I were missing some important software that would improve my life I can't even think of one of these "app" that I wish I could have.
I second your opinion that 100k/year would be a pretty sweet spot
Sweet spot is generally always 20% more than what you currently make.
An app is a software. Yes you are being a smart ass, and yes, it is comparable to PC software.
PC software too is "meant to work on the ecosystem it was purchased in". It can be highly hardware dependent or not, just like PC software.
The vendor will always want you to be locked-in as much as possible. As a consumer, my goal is to be as free as possible.
Which is still better. Being vendor locked-in in both hardware and software is worse than being locked-in for software only. Of course the ideal is not to be locked at all.
Also the problem isn't only that these apps may be vapor in a few years. They can be vapor *tomorrow* if your phone breaks.... that is, unless you buy another phone from the exact same vendor, which also implies that this vendor must still agree to sell you compatible phones. That's why you are vendor locked-in. You don't have the same freedom that I have to walk away and choose another vendor.
A software is meant to be reusable. You can't compare that to an admission ticket. If I were renting a software for 2 hours I wouldn't care as much about vendor lock-in either. The same goes for food. It is meant to be eaten only once. Eating in one restaurant doesn't force me to eat there next week. If it did, I would consider another restaurant instead. I wouldn't buy a car which could only bring me to one restaurant, however.
It's a matter of principle. I don't want to support vendor lock-in.
There is no advantage to the iPhone's walled garden.
On Android, you can allow "unknown sources" if you want to. That option is disabled by default. You would be free not to check it on Android.
I understand that some people prefer the iPhone and/or iOS, for various reasons, but the walled garden is really not something I even consider an argument.
I'd only switch for a stock Android device but if I were to switch now, I'd be giving up all my paid apps
You should have thinked twice before vendor locking-in yourself like that.
I personally don't buy applications that can only be executed on devices from a single vendor.