[aklug] Re: off-topic: android ACS tech-savvy tech support?

From: adam bultman <adamb@glaven.org>
Date: Fri Jul 08 2011 - 13:08:03 AKDT

Thanks, Michael. You basically summed up what I was trying to, but
unable to say.

Some phones (HTC wildfire) don't honor - at least as of the two last
software revisions - anything but the basic PPP username, and the EVDO Auth.

What's really neat is that with EVDO, restrictions could be set in place
to only allow EVDO in certain areas, towers, or during certain times.
So a jerk engineer could make it so that you'd only get EVDO on a tower
across town from where you live, and only from midnight to 5AM on every
other Sunday, when the moon waxing gibbous.

On 07/08/2011 12:06 PM, Michael Fowler wrote:
> On Thu, Jul 07, 2011 at 03:29:17PM -0800, Shane R. Spencer wrote:
>> The mobile interface, for what I see, is of course just an abstract
>> framing system to a mobile packet driver and hardware.
> That is essentially true. In a single data session (on CDMA) there is
> the air interface, the tunnel to the PDSN, the tunnel to the Home Agent,
> and then a firewall, and you're free! At the tether end (and within the
> phone OS most likely) it's presented as a relatively simple network interface.
>
>
>> Apps use standard library IP socket interfaces and a simple
>> addressable IP interface (pointopoint or ethernet), standard IP stack,
>> standard routing tables. When I tether it simply routes packets and I
>> can tcpdump everything on the mobile interface to verify that.
> All essentially true.
>
>
>> Yes thats an oversimplistic view of the process however when I tether I
>> don't see why anything changes since the frame abstraction is in place
>> and happy.
> The difference when you tether is how the mobile sets up its data
> connection. In CDMA, phones can come with several sets of credentials;
> one set for data, one set for EVDO, one set for tethering, one set for
> hotspot, etc. They don't necessarily come with all of these, and they may
> all be the same username and password.
>
> This does require the phone actually honor these, and use them in the
> appropriate situation. A rooted phone will, most likely, not, and could
> decide to use the data credentials despite the fact that it's in
> tethering mode. The network would allow it, but it could be detected if
> you're using too much data despite using normal data connection
> credentials. You could also have your QoS values dropped, or your
> bandwidth otherwise limited, on the assumption that a person using a
> phone can only do so much.
>
>
>> If there are extra hoops and ladders in CDMA land vs GSM land I will
>> check them on my ACS phone when I have time to find out - but that
>> seems unlikely since you can use external C libs as well as standard
>> non Android SDK or IOS SDK functions to deal with raw sockets. Those
>> would have to be wrapped in a very complicated way in order to allow
>> complete transparency.
> GSM is different in that there are APNs involved. This would be
> transparent to the tethering system, but which APN to choose could allow
> for similar things to the multiple credentials for CDMA; this includes
> similar caveats in regard to rooting the phone, and lower QoS values if
> you choose the wrong APN.
>
>
>> I'd thought the PPP related credentials just helped set up the
>> interface. The rest of it helped identify the phone for other non IP
>> related functions which apps can of course hook in to, but don't
>> provide a route to the Internet.
> Most of the credentials are indeed for the basic data connection setup.
> EVDO credentials are somewhat separate, in that they are used to obtain
> a faster data connection, but the data credentials are still used to
> setup the initial session.
>
>
>
> In other words, you are mostly correct in terms of the abstraction.
>
> --
> Michael Fowler
> www.shoebox.net
> ---------
> To unsubscribe, send email to<aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>

-- 
Adam
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri Jul 8 13:08:15 2011

This archive was generated by hypermail 2.1.8 : Fri Jul 08 2011 - 13:08:15 AKDT