[ILUG] Problems with Three Mobile-Broadband Router

[Kenn Humborg]

> > Perhaps you're defining "traffic" as data you're interested in, and 
> > "packets" as all incoming data, and as you now use a router which 
> > drops more "packets" you're getting less "traffic". However, from the 
> > POV of the OP this is all irrelevant as he's being billed by his 3G 
> > provider for every arriving "packet", not just for "traffic". Hence 
> > Kenn's information about O2's two different APRNs is quite useful,
> Yes, it is useful. Especially on Windows or other OS that gets attacked 
> and you have no Firewall. This is why I recommend people use a separate 
> HW Firewall. Unless they are running Linux *AND* know how to configure a 
> SW firewall.
> > as unwanted "packets" are dropped by O2 using the 'internet' APRN, so 
> > all of the incoming "packets" presumably contain "traffic". Sadly the 
> > OP isn't using O2, but perhaps his provider has a similar option.
> There are two options on 3 here
> http://www.boards.ie/vbulletin/showthread.php?t=2055442502
> 
> A suitably configured native firewall or separate CentOS or OpenWRT 
> could be a solution too.

You're talking about security.  I'm talking about euros & cents.

> >> Packets and Traffic are not the same thing.
...
> http://en.wikipedia.org/wiki/Packet_(information_technology)
> Packets can have varying amount of payload.
> 
> *Network traffic* is data in a network. In computer networks, the data 
> is encapsulated in packets.
> http://en.wikipedia.org/wiki/Network_traffic_measurement
> 
> However I'm not entirely sure what OpenWRT statistics relate to.
> but I have a link to the last 24 hrs.
> http://www.radioway.info/images/traffic.png
> You can see that while the "packets" received remain at over 30% 
> overnight there is no associated traffic.

Most likely they are packets that have no payload (for example
TCP SYN packets as part of port scans or P2P connection attempts).

> Perhaps what OpenWRT is "measuring" as  Packets are infact  connection 
> attempts?
> 
> No-one gets charged for "packets" but you get charged for "traffic".

Oh yes you do!  Let's see if I can get the terminology right...

A TCP segment has a TCP header and a TCP payload.  This TCP segment is
wrapped in an IP packet, which has an IP header.  On your LAN, this
IP packet is wrapped in an Ethernet frame, which has an Ethernet header.
Zero bytes of payload (i.e. no real "data") still requires TCP
header + IP header + Ethernet header.

I don't know what the analogue of the Ethernet layer on GSM/GPRS/3G
looks like, but there will be an equivalent.  In fact, I think there
is even a PPP layer below IP and above GSM.

Now, from my experiments with GPRS services, the "billable bytes"
counting happens very close to the IP-to-GSM interface (I'm sure
with your telco background you'll probably know exactly what this
is called), and /includes the IP and TCP headers/.  Maybe you could 
think of it as the total bytes tunnelled through the PPP layer.

So, here's what happens when you hit a key which is echoed back
on an SSH session over a GPRS connection (if you're lucky):

You send:     IP header + TCP header + 1 byte payload
Server sends: IP header + TCP header + 1 byte payload (piggybacked ACK)
You send:     IP header + TCP header + 0 byte payload (empty ACK)

If you're unlucky and the server doesn't echo back the character
quickly enough, it looks like this:

You send:     IP header + TCP header + 1 byte payload
Server sends: IP header + TCP header + 0 byte payload (empty ACK)
Server sends: IP header + TCP header + 1 byte payload
You send:     IP header + TCP header + 0 byte payload (empty ACK)

If a GPRS session doesn't transfer any data for a few seconds, it
goes into a sort of idle state, which takes about 3-4 seconds
to recover.  You'll see this if you ping after idling, where the first
ping reply takes a lot longer than usual.

So, if you type after this delay, it looks like this:

You send:     IP header + TCP header + 1 byte payload
(Wait first TCP timeout for ACK - none received)
You send:     IP header + TCP header + 1 byte payload
Server sends: IP header + TCP header + 1 byte payload (piggybacked ACK)
You send:     IP header + TCP header + 0 byte payload (empty ACK)

If the server sends you a character after going idle, it looks like 
this:

Server sends: IP header + TCP header + 1 byte payload
(Wait first TCP timeout for ACK - none received)
Server sends: IP header + TCP header + 1 byte payload
You send:     IP header + TCP header + 0 byte payload (empty ACK)

Now for the bad news: IP header + TCP header is about 40 bytes.
Which you pay for.

So, a single echoed keypress from client to server will cost
about 120 bytes.

Now consider that you will be paying for the IP and TCP headers on
any malware-originated traffic to your mobile IP address...
I like Niall's Distributed Denial Of Wallet term.

The 40-bytes per packet base cost matches very well with the
detailed bill breakdowns that I've analyzed.  Going through our
server-side logs, I can count the number of TCP payload bytes
our app sent and the number of TCP packets and empty ACKs that 
would have been generated (our payloads are always small enough that
IP fragmentation isn't an issue).  I get an estimated GPRS
traffic cost from

   billable_bytes = (packet_count * 40) + total_TCP_payload

Adding up all the TCP connections for each GPRS "session" gives
a bytecount that matches the telco's detailed bill to within a
few percent.  And I've done this with multiple telcos.

Later,
Kenn