On Thu, Jun 09, 2016 at 09:58:10PM +0100, Stuart Henderson wrote: > You're getting further than me. > > Though, looking at list posts, it does seem that Lenovo is another > vendor which requires the command being referred to as "fcc auth" > in order to connect, at least in some of their cards.
That would not be surprising at all. At this point this "fcc auth" would have to be hardcoded into the driver as well it sounds like? > There are several PINs and unlock codes (PIN1 PIN2 PUK1 PUK2) > on a SIM card. A SIM can be setup so that a PIN1 is required to > make calls etc, or not required. PIN2 is for configuration > (setting call restrictions, editing the restricted numbers > list, etc). > > Too many bad attempts to enter a PIN1 will result in the SIM > being locked and requiring the PUK1 to unlock. In most cases > these are fairly easy to obtain from the operator. > > Too many bad attempts to enter a PIN2 will result in the SIM > being locked and requiring the PUK2 to unlock. These are > usually harder to obtain from the operator and at least > require more checks. > > From a phone or older-type WWAN device with AT command set > (or probably the vendor tools on Windows, and maybe libmbim > on linux) you can control which PINs the card asks for. > You'll need to know what a PIN is before you can lock it. > Most operators have a default PIN that they use (different > ones for different operators) though theoretically they > could use a different one per SIM. > > If PIN1 is unlocked (no matter whether PIN2 is locked or not), > you shouldn't need to use a PIN to connect. > > > umb0: SIM not initialized (PIN missing) > > umb0: SIM not initialized (PIN missing) > > The description in the spec for the state which triggers this > message is, > > "The operation failed because the device is > in the process of initializing. Retry the > operation after the ReadyState of the device > changes to MBIMSubscriberReadyStateInitialized." > > Spec may differ from real-world devices, but from my reading > of the spec it doesn't seem to me that this indicates "PIN > missing". > > I think you should rebuild with UMB_DEBUG (one simple way > is to just add "#define UMB_DEBUG" before #ifdef UMB_DEBUG > in if_umb.c) and see if you get more information. It's > probably worth changing the 'umb_debug = 0' to 2 or 4 > while debugging too (this can be done using DDB, but if > you want to capture any possible messages starting at > boot then you probably want to chagne it in the code). Thanks for the explanation on how all the PIN codes work. I wasn't aware it was so complex. I'm compiling a new kernel right now with UMB_DEBUG so we will see what happens there. Bryan
