On Wed, 2010-01-20 at 16:02 -0600, Denis Kenzior wrote: > Hi Dan, > > On Wed, Jan 20, 2010 at 3:10 PM, Dan Williams <d...@redhat.com> wrote: > > > > On Mon, 2009-11-23 at 17:15 +0100, Marcel Holtmann wrote: > > > Hi Antti, > > > > > > > > you can't trust the network name string returned by AT+COPS since > > > > > there > > > > > are so many factors coming into play here. So first of all you have > > > > > the > > > > > names stored in the modem itself, then the names stored on the SIM > > > > > card > > > > > and then the potential updates over the network. Every hardware does > > > > > different things to present the result of AT+COPS. > > > > > > > > AFAIK if there's a name stored in the SIM card it will have precedence > > > > over the ones stored inside the modem. And the ones that network sends > > > > are probably most reliable. I have to look though the specs if there's > > > > any information on this. > > > > > > > > Anyway the point is that in most situations we should have a correct > > > > alphabetical name for the provider, right? > > > > > > I have seen different hardware with the same SIM card give different > > > names. And I also have seen different SIM card with the same hardware > > > result in different results. > > > > > > Also you have the problem that names change over time and some hardware > > > and SIM card combination returns still the old one, while newer pieces > > > would give you the new name. > > > > T-Mobile USA hasn't been Voicestream Wireless since 2002, but my ZTE > > MF627 (a quite recent device sold by 3UK) returns: > > > > +COPS: (2,"AT&T@","AT&TD","310410",0),(3,"Voicestream Wireless > > Corporation","VSTREAM","31026",0), > > > > The SIM is a T-Mobile US SIM that is known to return "T-Mobile" in most > > other cases. And what's up with the "AT&T@" and "AT&TD" anyway? > > > > Basically, we simply can't trust that the COPS results are going to be > > in any way accurate... > > > > Fully agreed, the COPS name is junk, and on properly implemented > hardware the COPS name can actually > change once the network performs a NITZ update. Unfortunately there's > no standard way of knowing what > name the hardware is reporting, the one burned into firmware or taken > from NITZ. I've seen this happen on > the Freerunner. Immediately after registering COPS returns > "Cingular", 5 minutes later it will return "AT&T". > > Any such database has to account for the PCS digit for North American > carriers. For instance, T-Mobile > SIMs are provisioned with 3 digit MNC, 260. Yet most (all?) T-Mobile > cells will actually report a 2 digit > MNC, 26. Whether the 3rd MNC digit is reported is completely up to > the network cell tower. Refer to > table 10.5.3 in 3GPP 24.008.
Yep; I've looked over the MCC/MNC data and that may only be a problem for India and the US in the future, but there weren't any clashes that I could find in a quick check where for example one provider's 5-digit conflicts with another provider's 6-digit with the 6-th digit removed. But also, it's not *completely* up to the cell tower, as some modems will pad it out too. See below. Some Option devices will also report *7* MCC/MNC digits in the cops response. Odd firmware I'd presume. Option Quicksilver (AT&T locked & branded, with AT&T 3G SIM): +COPS: (2,"AT&T","","310410",0),(2,"","","3104100",2),(1,"AT&T","","310260",0),,(0-4),(0-2)"; Three interesting notes: (1) the 3G network MCC/MNC is 7 digits, and (2) 310260 is T-Mobile, not AT&T, so AT&T is hiding the actual operator, and (3) it shows 310260 where other devices at that location showed only 5-digit operator strings (Nokia N80). Standards are relative :) Dan > Ultimately the SIM is the one to trust here, not COPS or any other > combination of COPS/CREG, etc. > Much of the COPS/CREG information can be ultimately overridden by the > contents of the SIM > elementary files like EFspn, EFspdi, EFehplmn, EFehplmnpi, EFpnn, > EFopl, etc. Of course various > stacks / modems get this right in varying degrees of correctness. > > Regards, > -Denis _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list