- Dec 07, 2012
-
-
Dan Williams authored
-
Dan Williams authored
-
- Dec 05, 2012
-
-
Dan Williams authored
Some devices prefix the replies with the command, some don't, so strip off the prefix if it exists.
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
Assume 2000 + year.
-
Dan Williams authored
Unlike strtol/stroul, this function doesn't ignore leading or trailing non-digit characters, so document that restriction.
-
Dan Williams authored
Some Huawei modems report these, and we may use the generic helper in the future.
-
Dan Williams authored
-
Dan Williams authored
Parent MMBroadbandModem may not implement these functions so we shouldn't call them unless it does.
-
Dan Williams authored
Many Huawei CDMA modems implement vendor commands for 1x and EVDO signal quality, so use them since they are more accurate than the generic signal checking. (port of a similar patch for MM_06 by heiher <admin@heiher.info>)
-
Dan Williams authored
Both CDMA and 3GPP modems emit this, but using slightly different formats.
-
Dan Williams authored
Both CDMA and 3GPP modems use SYSINFO, so consolidate the parsing of its response.
-
- Dec 03, 2012
-
-
Aleksander Morgado authored
We need the kernel driver to give a proper value for the 'closing_wait' variable, but don't assume it will. This should solve the following kind of issues reported by valgrind: ==8985== Conditional jump or move depends on uninitialised value(s) ==8985== at 0x4409A6: mm_serial_port_close (mm-serial-port.c:932) ==8985== by 0x41A420: disable_all_done (mm-generic-cdma.c:753) ==8985== by 0x4125A4: mm_manager_shutdown (mm-manager.c:1130) ==8985== by 0x40DE35: main (main.c:203)
-
- Nov 29, 2012
-
-
Dan Williams authored
-
- Nov 28, 2012
-
-
Aleksander Morgado authored
-
- Nov 27, 2012
-
-
Aleksander Morgado authored
-
Dan Williams authored
-
Dan Williams authored
The 'hso' driver tags Icera-based modems' proprietary protocol port as a DIAG port, but since they aren't Qualcomm-based, it's not a DIAG port. Just turn off AT probing and let QCDM probing fail the port instead of assuming it's a DIAG port.
-
Dan Williams authored
If we read a response that indicates the port is definitely not an AT capable port, stop AT probing. Certain ports that use proprietary protocols or other non-AT protocols tend to spew data at us, so when this happens we can cut probing short.
-
Dan Williams authored
-
Dan Williams authored
If a response processor closed the port, don't try to read any more data from it. Move the priv->watch_id check to the while condition so the loop terminates before calling g_io_channel_read_chars() again, which caused a warning since the underlying file descriptor was already closed. Also, bytes_read will never be less than zero (it's unsigned), so skip the bytes_read > 0 check and just assert that this condition is true.
-
Dan Williams authored
Signal was attached with user_data as MMPortProbe*, but serial_buffer_full() treated user_data as a PortProbeRunTask*. Hillarity ensued.
-
Dan Williams authored
Sierra devices often have limited AT parsers on their APP ports which reply with OK to any command they don't understand, and thus we need to actually check for a valid IPSYS reply instead of just checking whether the IPSYS request completed without error. Previously MM would detect Icera capability on devices that didn't actually have it.
-
Dan Williams authored
Bandrich C120 returns BAD_LENGTH rather than BAD_COMMAND, perhaps because it re-uses the same subsystem number for something else.
-
Dan Williams authored
If +CIND fails for any reason (generic failure, wrong indexes, etc) or reports zero signal strength (quirky modem) then fall back to +CSQ.
-
Aleksander Morgado authored
-
Jiří Klimeš authored
We can skip additional UTF-8 validity check when parsing operator. mm_charset_take_and_convert_to_utf8() already does a UTF-8 validity check internally before returning the string, so it's pointless to do a new one on the returned string. Plus, mm_charset_take_and_convert_to_utf8() may really return NULL, which would end up in segfaulting as g_utf8_validate() expects always a non-NULL string. Based on 219424a6 (MM_06 branch)
-
Aleksander Morgado authored
The logic gets completely stuck when this happens: Stack trace below: #0 0x77661424 in __kernel_vsyscall () #1 0x77337c3c in pthread_cond_wait () #2 0x773cebaa in g_cond_wait () from /usr/lib/libglib-2.0.so.0 #3 0x774c03cc in g_cancellable_disconnect () from /usr/lib/libgio-2.0.so.0 #4 0x76955d36 in connect_cancelled_cb (cancellable=0x78e055a0, self=0x78e0b590) #5 0x77460982 in g_cclosure_marshal_VOID__VOIDv () from /usr/lib/libgobject-2.0.so.0 #6 0x7745ed8a in ?? () from /usr/lib/libgobject-2.0.so.0 #7 0x77478435 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #8 0x77478eb3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #9 0x774c01eb in g_cancellable_cancel () from /usr/lib/libgio-2.0.so.0 #10 0x776a0eab in mm_bearer_disconnect (self=0x78e0b590, callback=0x776c5980 <disconnect_ready>, #11 0x776c57de in disconnect_next_bearer (ctx=0x78e12870) at mm-iface-modem-simple.c:898 #12 0x776c58d2 in disconnect_auth_ready (self=0x78df3048, res=0x78e06210, ctx=0x78e12870) #13 0x774fed25 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0 #14 0x776a8c4e in authorize_ready (authp=0x78db68d0, res=0x76801638, simple=0x78e06210) #15 0x774fed25 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0 #16 0x774fee3e in ?? () from /usr/lib/libgio-2.0.so.0 #17 0x7738a7a2 in ?? () from /usr/lib/libglib-2.0.so.0 #18 0x7738ce83 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #19 0x7738d248 in ?? () from /usr/lib/libglib-2.0.so.0 #20 0x7738d6eb in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #21 0x77696a7d in main (argc=2, argv=0x7fbb1f04) at main.c:158 http://code.google.com/p/chromium-os/issues/detail?id=36448
-
Ben Chan authored
-
- Nov 15, 2012
-
-
Aleksander Morgado authored
In order to have a proper conversion between DBus error names and GErrors for our known domains, the associations need to be registered before any DBus call attempt. Given that the high-level API of libmm-glib has its entry point always in the MMManager, just register them as soon as the first such object is created.
-
- Nov 14, 2012
-
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
It appears that GIOChannel might also do some flushing, so make sure our warning captures that delay if there is one. Also be paranoid and make sure nothing reset our closing_wait value.
-
- Nov 13, 2012
-
-
- Nov 12, 2012
-
-
Aleksander Morgado authored
Some devices (e173) appear to lie about NDIS support; GETPORTMODE reports NDIS is enabled, but that port is actually the MDM port and responds to AT commands. So, if we get a port reported as NDIS and none reported as MDM, use the one reported as NDIS for PPP. https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1057186
-
- Nov 09, 2012
-
-
Aleksander Morgado authored
Instead of getting the port type hints while grabbing each probed port, we now run a custom init operation in the probing which already gives us the port type, and therefore allows us to completely skip port probings. Also now added hints for 'Diag' (QCDM) ports and AT/'Modem' ports (I guess it's the one for PPP if we don't have a net port, which is unlikely anyway in HSO). This makes the probing of an Option/HSO modem almost instant.
-
- Nov 07, 2012
-
-
Aleksander Morgado authored
-
- Nov 05, 2012
-
-
Dan Williams authored
All Sierra devices appear to require short delay after powering up, otherwise subsequent commands may return errors. Older devices need longer so ensure new devices are penalized just for being new. This is the port to git master of the following commit, for which we don't need to do #2: commit 814febe1 Author: Dan Williams <dcbw@redhat.com> Date: Tue Oct 30 16:16:25 2012 -0500 sierra: fix CFUN power up delay handling 1) all Sierra devices appear to require short delay after powering up, otherwise subsequent commands may return errors. Older devices need longer so ensure new devices are penalized just for being new. 2) When the modem is already in full functionality status and no power up command was sent, there's no need to delay, which was happening regardless of what state the modem was already in. Detect whether the power up was actually executed (response and error will be NULL) and only delay if it was executed.
-