Upper layers expect Mobile Equipment errors, so try to translate known QMI protocol errors.
The logic to handle the lock information (current lock and unlock retry count) wasn't handling all possible cases properly, e.g.: * When PIN is incorrectly entered too many times, a SIM-PUK error may happen. In this case we need to directly assume SIM-PUK is the current lock (some modems, like Option HSO ones, would incorrectly reply SIM-PIN if CPIN? asked just after the SIM-PUK error). * After every operation acting in SIM locks, we need to update the current unlock retry count. This change tries to cover those cases, by: * The logic to check current lock is extended to also load the unlock retry count when needed. * Whenever a SIM-PUK error happens in the SIM operations, we directly assume that SIM-PUK is required, without re-asking CPIN?. * The overall logic of lock checking is now handled by a state machine, which is much easier to understand.
Even when there is a fatal error during initialization (e.g. missing PIN in a 3GPP modem), we should allow operations on the Firmware interface.
…CheckContext This patch fixes a crash in periodic_registration_checks_ready() due to access of an already deallocated RegistrationCheckContext. Thread 0 *CRASHED* ( SIGSEGV @ 0x00000000 ) 0x7fc344d355cd [ModemManager] - mm-iface-modem-cdma.c:1112 periodic_registration_checks_ready 0x7fc3449ea266 [libgio-2.0.so.0.3200.4] - gsimpleasyncresult.c:767 g_simple_async_result_complete 0x7fc3449ea368 [libgio-2.0.so.0.3200.4] - gsimpleasyncresult.c:779 complete_in_idle_cb 0x7fc344851dc4 [libglib-2.0.so.0.3200.4] - gmain.c:2539 g_main_context_dispatch 0x7fc344852147 [libglib-2.0.so.0.3200.4] - gmain.c:3146 g_main_context_iterate 0x7fc3448525a1 [libglib-2.0.so.0.3200.4] - gmain.c:3340 g_main_loop_run 0x7fc344d0f154 [ModemManager] - main.c:158 main 0x7fc34426a474 [libc-2.15.so] - libc-start.c:234 __libc_start_main 0x7fc344d0eb68 [ModemManager] + 0x0001bb68
Specially the first time that CFUN=1,0 is issued after the initial power up, we really need to wait more than 3s for the AT command reply. Otherwise, the modem won't like it and it will reset itself :-/
The generic plugin should be a fallback, so when starting to probe the port, never start with the Generic plugin first.
Update the default timeout from 3s to 10s.
Every port probing will have the Generic plugin as fallback, and due to some other issues in other plugins (see ee099fc), we need to allow overwriting the suggested plugin from the Generic to a more specific one. One of the drawbacks of this is that we're actually allowing the Generic plugin to probe and accept the port, which means that the generic plugin may accept a specific port type (e.g. QMI) while the specific plugin wouldn't. So, we will now also run the subsystems filter before grabbing the specific port, in order to really filter out those cases. We still keep the subsystems filter in pre-probing, so that we build a better initial plugin list to probe.
…nterface If an error occurs early during the initialization (e.g. during port setup), we would be aborting without even having exported the modem interface. So detect that case and skip setting the modem as valid.
The Location property was never being updated properly.
…cation When the 3GPP location is enabled, we need to reload the operator code information, but only if the modem is registered in a 3GPP network. Now, instead of looking at the global modem state value, look at the specific 3GPP registration state. This will avoid issues like: * updating 3GPP operator info and the modem registered in a CDMA network. * not updating the 3GPP operator info when the modem is registered in a 3GPP network but not yet fully enabled (i.e. 'enabling').
The Bus Pirate v4 presents itself as a CDC ACM device which ModemManager attempts to configure. This results in a range of confusing issues because it injects a bunch of AT commands over whatever is going on at the time. Firmware updates were failing at random points and avrdude failed to work at all. Blacklisting it fixed my issues.
Unfortunately, Sierra secondary APP ports reply to +GCAP with only "OK", and not their APP port number or model number. So instead of using +GCAP, we have to use ATI to get secondary port information. This allows us to detect which port is the APP1 port that we can potentially use for PPP, leaving the primary port available for control and status. Also, some modems have up to 3 or 4 APP secondary ports, which we need to ensure aren't used as primary. The previous check for +GCAP handled that, but let's make it more explicit. AT+GCAP reply: OK ATI reply: Sierra Wireless, Inc. C885 APP1 OK See also: 3f3987e (MM_06)
If the primary port is gone (e.g. when going to sleep) and we are just in the middle of a connection attempt, we won't be able to receive any unsolicited message regarding the status of the attempt. So, if we detect that the port is forced to get closed, we'll just treat it as a connection failure. http://code.google.com/p/chromium-os/issues/detail?id=35391
…ect it Avoids warnings like: GLib-GObject-WARNING **: gsignal.c:2576: instance `0x78624028' has no handler with id `148'
Turns out older devices (like the C885/AT&T Mercury) crash often when we don't wait for them to settle from CFUN=1. 5 seconds is too short, but the crashes go away when we wait for 10 seconds. Newer modems like the USB306 don't have this problem, so we just check to see if the modem is a DirectIP device (using sierra_net) and only use the shorter timeout for those newer devices. This is a separate problem from some older modems returning ERROR to valid commands that are sent too soon after CFUN=1, which was observed on really old devices like the PCMCIA 860.
Some devices prefix the replies with the command, some don't, so strip off the prefix if it exists.
Assume 2000 + year.