We currently convert to and from the modem's set charset and always pass
'15' as the data coding scheme. Passing the correct data coding scheme
as third argument to CUSD only upsets the network. This contradicts 3GPP
TS 23.038. Other tools like gsm-ussd handle it the same way.
Network responses that require further actions are not yet implemented.
(some fixes and cleanups by Dan Williams)
Some devices (8775 specifically) get angry if you don't check for
a PS attach before dialing. The next time they try to connect,
they'll continuously report "searching" as the registration status
and return CME ERROR 30 (No Network Service) for lots of requests.
So initiate a PS attach (which should return OK if the modem is
already attached) before dialing, and if that fails cancel the
dial attempt.
See http://mail.gnome.org/archives/networkmanager-list/2010-October/msg00072.html
"I talked about this problem with a contact at SierraWireless. He said that
a firmware upgrade will not help in this case. But what can help is checking
for PS attach and dial only if PS attach status is attached. Dialing without
PS attach can bring modem into unwanted condition that sometimes restart is
needed to recover."
Checking PIN status makes sure the SIM is initialized, and
that has to happen before we try to read the SIM for the
ICCID. So move PIN checking before getting the ICCID, and
retry the ICCID at least once for odd cards like Gobi 1K
that seems to need one more try right after it's done
booting up.
Depending on when the core requested the ICCID, the port may or may
not be open. Stuff that needs an open serial port needs to make sure
that the port gets opened itself.
An obfuscated SimIdentifier that may be available before the PIN has
been entered, for use in auto-unlocking a device. If this value is
present, it should be used in preference to DeviceIdentifier as it
is SIM-specific like the PIN code.
Pass the device's hardware IDs through modem creation and use them
when calculating the device's identifier. Add a bunch of testcases
for real hardware to ensure we don't break the device ID in the
future unless we really want to.
This is computed before any PIN is entered, and thus before we can
usually get IMEI or MEID/ESN out of the device in many cases. It's
therefore not the same as EquipmentIdentifier.
This is intended to be used by UI programs for matching devices with
PIN numbers for automatic unlocking. While the PIN number is actually
*SIM* specific, no modems allow access to the IMSI before the PIN is
entered, and thus we cannot actually match the PIN with the SIM. The
device ID is the next best thing we can use and should allow auto
unlocking in most cases.
Ensure that valid HDLC frames that are not valid QCDM frames
are correctly rejected, and that their data is correctly
discarded.
The core bug was that Sierra CnS frames have leading and trailing
HDLC frame terminator bytes (0x7E), and the code was incorrectly
treating the leading terminator as the end of a frame, not the
beginning. Thus it would consider the outstanding serial request
finished without actually parsing the response packet.
Now, we make sure we don't tell the serial receive code that
we have a full QCDM frame until we actually do have one, which is
at least 3 bytes + 0x7E.
Test that a Version Info request/response works as expected, and
add a testcase for a bug where specific Sierra CnS responses to
the Version Info request do not properly return an error when
attempting to parse the response as a QCDM packet. Fix for the
second thing forthcoming.
This is the real fix for 81d0fd148f.
Some devices don't interact well with the option driver or the usb-serial
layer; they don't respond to the USB data requests and thus data never
gets written to that port. When close(2) is called, that data is still
pending and so the tty layer waits 30 seconds before returning from
the close. This is the 'closing_wait' value, which unfortunately is
not able to be modified by ModemManager because most serial drivers
for 3G devices don't implement the .ioctl handler or its TCIOSSERIAL
option to change closing_wait.
This goes along with a kernel patch to various drivers to enable
the TIOCSSERIAL ioctl to modify closing_wait which will be posted
soon.
Some devices don't interact well with the option drivr or the usb-serial
layer; they don't respond to the USB data requests and thus data never
gets written to that port. When close(2) is called, that data is still
pending and so the tty layer waits 30 seconds before returning from
the close. This is the 'closing_wait' value, which unfortunately is
not able to be modified by ModemManager because most serial drivers
for 3G devices don't implement the .ioctl handler or its TCIOSSERIAL
option to change closing_wait.
Print out open/close timestamps to help debug this issue and get a
list of modems that have this problem.
And possibly the X225 as well. Can't tell much about the modem and
what commands it supports other than AT+SYSSEL for mode selection.
The driver software and connection manager for Windows/Mac OS X are
written by JRD Communication in China, which is a subsidiary of
TCT, which makes Alcatel-branded phones and data sticks. But it
doesn't appear to be the same firmware as other Alcatel/T&A modems
like X060S and such which are supported by the Longcheer plugin.
For devices like the UMW190 that appear to be dual-mode without needing a
firmware reload (unlike Gobis, which are dual-mode but require a reboot with
different firwmare) prefer CDMA capabilities since that's where these devices
will most likely be used more often. In the end we'll need to change MM to
advertise a "capabilities" attribute on the modem class and modify devices
such that they can implement both GSM and CDMA semantics at the same time.
It's only really used for phonebook and SMS PDU mode in the specs,
which we don't do yet, so if this is the only charset the device
supports we'll try to use it.
Doesn't parse any events yet since we don't know what any events
are. We also need to fix up ModemManager to handle unsolicited
responses in the QcdmSerialPort class.
If the modem returns an error (like "+CME ERROR: incorrect password"
or even just ERROR) make sure we recheck PIN status and thus also
recheck the number of unlock retries instead of just returning the
error to the caller.
More info:
https://bugzilla.redhat.com/show_bug.cgi?id=585394http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1172
dbus-glib was not properly enforcing the 'access' permissions on
object properties exported using its API. There were 2 specific bugs:
1) dbus-glib did not enforce the introspection read/write property
permissions, so if the GObject property definition allowed write
access (which is sometimes desirable), D-Bus clients could modify
that value even if the introspection said it was read-only
2) dbus-glib was not filtering out GObject properties that were
not listed in the introspection XML. Thus, if the GObject defined
more properties than were listed in the introspection XML (which is
also often useful, and MM uses this quite a bit) those properties
would also be exposed to D-Bus clients.
To fix this completely, you need to:
1) get dbus-glib master when the patch is commited, OR grab the
patch from https://bugzilla.redhat.com/show_bug.cgi?id=585394 and
build a new dbus-glib
2) rebuild ModemManager against the new dbus-glib
