Hacker News Reader

Comment by Negitivefrags | Hacker News Reader

> I had assumed that all internet-enabled smartphones would be sitting behind NAT-ing routers, both for security reasons and to conserve IPv4 addresses. But no, on the “3″ network in Australia at least, phones all have externally-accessible IP addresses, meaning they can run servers.

This seems like a terrible thing.

Given that data costs so much on phones, you would think just the internet background noise would cost quite a lot per month.

http://en.wikipedia.org/wiki/Internet_background_noise

According to that article the background noise is about 20 bits per second. According to my back of the envolope calculation that is about 6.1 megabytes per month.

I get around 50 megabytes per $6 on my phone so this is costing me 73c per month!

View on HN

Arguing for NAT in order to compensate for a broken billing model is a terrible idea. :)

Saunalahti in Finland also have publicly routed 3G. I wish this were far more common, it feels very 22nd century to effortlessly ssh to the phone in your pocket, even if the capability existed since the 20th. Such a shame contemporary networks are usually so brain damaged

Broken billing model is anything but flatrate? Hardly practical in practice for such a scarce resource. Noone wants to pay for that, it can only exist as an option where few will use it.

How about denial of service attacks? I could easily kill your battery and drain your quota for the month with a few keystrokes - and there's not much you can do about it.

Yes, I prefer NAT for my mobile connections. Just use a VPN if you want external access.

Not sure how you arrived at flat rate being the only alternative. It's almost trivial to count ingress only for host flows to which the customer's device responds positively (say, by replying using anything except ICMP or a TCP error)

Does any ISP do that though? I've never heard of it, then again I haven't had contact with any ISP delivering external IPs to mobile connections.

The point about battery remains though. And the solution you propose can easily be exploited to allow unlimited data for say, video streaming.

In Saunalahti's case they differentiate by offering different connection speeds, all at flat rate. I'm not really sure if what I suggested is implemented anywhere, just playing devil's advocate. :) One possible solution might be to combine it with stateful filtering, dropping a unidirectional ingress flow after some number of packets if the device never responds. My point was mainly that something must be broken if the customer is getting billed due to the environment beyond their control.

In the case of power management I'm not sure it's that simple, it's at least true that the HTC Dream would not usually respond to pings while the display was off (haven't experimented with other devices). Presumably the application processor only awoke when a kernel timer fires, which only applies to client sockets the device itself created. Actually it makes sense that random inbound data traffic wouldn't wake the phone, otherwise you risk your OS getting a bad reputation because of some crappy telcos sending ARP every 1 second or something.

I agree that it is unreasonable, and is a bit shocked that there are countries where receiving an sms can cost you money... But a reasonable solution to incoming data is to enable NAT, it isn't much of a hinder for a tech savvy user and is otherwise better for the 99.99% of the users.

My phone (Nexus S) always responds to the pings I send. Which kind of makes sense, the default is to have a constant connection to google anyway (so that it can receive any push messages). Apparently google already made the decision that it is worth the battery drain. And android has already gotten plenty of bad reputation for applications misbehaving. While I'm sure some telcos are misbehaving in all ways imaginable as well it is probably nothing compared to the apps users gladly install for themselves.

> something must be broken if the customer is getting billed due to the environment beyond their control.

This is what happens when you debate random tangential topics online while hung over.. so basically I had no point to make, and you made me realize NAT is a pragmatic solution to the imaginary problem I'm complaining about.

> Presumably the application processor only awoke when a kernel timer fires

And of course for the reasons you point out, this presumption was obvious nonsense. :) Now I'm not sure what caused the behaviour I saw on the Dream.

I wouldn't call it trivial - you'd need a stateful firewall (not necessarily a NAT) to keep track of which network flows are active. It would also be exploitable - you could open a TCP control connection to host X, and have host Y stream you data over UDP, to which you never reply directly, but rather use the host X control connection to ack the data.

Some of us in the US still have unlimited data plans. Not many, but some of us were grandfathered into it and hold onto it for dear life :)

Not exactly related to your post, but I'm not sure why he would be concerned with the phone service's NAT if the x-window app is running on a remote server (making him the client). Now if he were running it on his phone (as the server) and connecting to it through the cellular data service, then I could see why.

X windows client server model can seem intuitively backwards. The applications you run on remote servers are clients of the x server (that renders the windows) you are running locally.

It's a relic from a different era: You had a dumb terminal that could only display stuff, and several servers that each could run a piece of software you like.

Also, the networks were (supposedly) less dangerous security wise, so people worried less about things like authentication and access control back then.

X is celebrating 25 years or so these days: And yet, modern clients can mostly work with 25 year old clients, and modern servers can definitely accept connections from 25 year old clients. And it's very usable.

It's a marvel of engineering, even if it is showing its age.

Still, it'd be a good idea to tunnel it through an outbound SSH connection (which is generally the preferred method of starting up the X client app in the first place).

Some providers give you the choice, and let you choose if you want unfiltered access or firewalled, just by changing APN. For some services, like a backup link to your internal network, it's immensely useful.

I would be more concerned about battery usage than data costs.

Reply on news.ycombinator.com