Re: FC8

[phil philgorsuch com]

Into the fray here :-)   Lets be clear, we are trying to make
generalizations between two different technologies.   UMTS is
significantly different from EV-DO at all levels be it network, hardware,
at command sets, etc.

>> > I don't believe you need the APN except in certain circumstances like
>> > roaming or other less-common configurations.  We've got somebody
>> working
>> > on a mobile wizard that should be able to select the right APN for you
>> > though if you need it.
>>
>> Different APNs often mean different billing schemes - for my no-limit
>> flat
>> data plan i need a different APN than for the normal, data volume
>> charged data
>> plans. Guess what APN was stored in the SIM when i got it...

Enabling APN in the GSM world is important - it allows carriers to
differentiate service capabilities, billing rates, and essentially allows
them to group or classify service offerings.   There is no guarantee the
default profile or APN will be the one that should be used.   EV-DO
doesn't quite have this concept, hence perhaps the importance is not so
obvious.

>>
>> >> Was just wondering if it should show the network name, i.e. T-Mobile?
>> and is there a way to get it to show the signal strength?
>> >
>> > Yeah, both of these would be nice things to have.  Unfortunately, some
>> > of that is blocked on the card vendors themselves becoming a bit more
>> > open.  Most cards do not allow you to retrieve information about the
>> > connection while you're connected, unless you use a proprietary
>> protocol
>> > that you must license from the vendor.

1) In Asia/Europe where there are large numbers of carriers competeing for
your business, its pretty critical to be able to identify and select the
appropriate carrier.

2) Network and signal should be available from the single AT port devices
before a PPP connection is established... which would be the critical
stage  to look at these parameters.  Both UMTS and EVDO cards should be
able to do this - albient using different AT commands (IS-707 for EV-DO TS
127 007 for UMTS).

>>
>> Please quantify "most cards". From the ~10 cards i have, only one, the
>> Novatel
>> X870 which only has one usable port, has this problem (but you can still
>> select the provider and check signal strength before connecting).
>> All other cards (Option, Sierra Wireless, Huawei) have two usable ports
>> and
>> you can use one of them to query for network data while being connected.
>
> Yes, you can do this on some cards.  I've never said this was impossible
> for all cards.  I just said it was impossible for huge numbers of common
> cards, many of which are CDMA, and many of which are GSM.
>

Crass generalization here - from my own knowledge of the industry - not
from comments posted here:

1) Most (All?) EV-DO cards do not have a second AT command port (Market
factors perhaps?).
2) Most UMTS cards built within the last 2 years have a second AT command
port
3) All cards older than 2 or so years have a single AT command port
4) Some UMTS cards also support GSM 07.01 multiplexing, allowing multiple
ttys on a single USB endpoint.

For the record:

MC727 - EV-DO
S620 - EV-DO
AC595U - EV-DO
AC580 - EV-DO
AC860 - Older UMTS
PC5750 - EV-DO
KPC680 - EV-DO

Thus I can see the difference in perception.


>
> My point is that lots of people have cards that don't allow this
> functionality under Linux yet.  If most cards used AT commands, I'd add
> support tomorrow.  That would be awesome.

I think the split rather runs - Lots of people with EV-DO cards or older
UMTS cards which cant support multiple AT ports, and another lots of
people with relatively new UMTS cards which do support multiple AT
ports... both are big groups, both are for the most part georaphically
seperated.

> don't, we need to understand the entire field; what cards do?  how do
> they support it?  what cards don't?  how can we easily identify cards
> that do and cards that do not?  If a card does, are there variations in
> the commands and responses?

This is where the umtsmon knowledge can be leveraged - there is alot of
experience dealing with the tricks of the various cards to get them going
sucessfully.

>
> The way this support gets into NetworkManager is going to be the
> following:
>
> 1) Add a property in HAL to tag the secondary port that can be used for
> communication, if it exists
>
> 2) Tag secondary ports of cards known to support AT commands with the
> correct modem.command_sets properties, and then add the property from
> (1) so we know they are a secondary port
>
> 3) Recognize secondary ports in NM, and for those cards that support
> them, provide signal strength and connection speed status to the user
>

Sounds like a good plan to me - note secondary ports could be marked by
what they support - be it AT commands or some proprietary protocol :)

Cheers,

Phil