| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The internal libmodem-helpers.la library is also renamed to libhelpers.la
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new tester allows to play with the AT-capable TTY using the same code as
ModemManager itself.
$ sudo ./test/mmtty -d /dev/ttyHS0 --verbose
opening serial port '/dev/ttyHS0'...
(ttyHS0) opening serial port...
(ttyHS0): port attributes not fully set
(ttyHS0) device open count is 1 (open)
flashing serial port '/dev/ttyHS0'...
ready
> AT+GCAP
(ttyHS0): --> 'AT+GCAP<LF><CR>'
(ttyHS0): <-- '<CR><LF>+GCAP: +CGSM,+DS,+ES<CR><LF><CR><LF>OK<CR><LF>'
+GCAP: +CGSM,+DS,+ES
> AT+GMI
(ttyHS0): --> 'AT+GMI<LF><CR>'
(ttyHS0): <-- '<CR><LF>Option N.V.<CR><LF><CR><LF>OK<CR><LF>'
Option N.V.
> ^C
cancelling the main loop...
(ttyHS0) device open count is 0 (close)
(ttyHS0) closing serial port...
(ttyHS0) serial port closed
(ttyHS0) forced to close port
|
|
|
|
|
|
|
|
|
|
|
| |
Old python tests using the old ModemManager interface are removed, as mmcli
provides already a much nicer way to test the DBus interface.
Also, mm-test.py and the PPPD plugin get removed, which were also using the old
interface, and which were not very useful for testing newer non-PPP based
modems.
https://bugzilla.gnome.org/show_bug.cgi?id=702061
|
|
|
|
|
|
|
|
|
| |
Usage:
mmcli-test-sms [MODEM INDEX] [all|ucs2|gsm7|data] [NUMBER]"
If [NUMBER] is not given, a dummy number will be used and NO SMS will be sent.
If you give a proper [NUMBER], we will try to send the SMS.
|
| |
|
| |
|
|
|
|
|
| |
Since udev 147 the gudev API is no longer marked as experimental, and therefore
`G_UDEV_API_IS_SUBJECT_TO_CHANGE' is no longer needed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Might as well keep it simple.
|
| |
|
| |
|
|
|
|
|
|
| |
Python usually uses Unicode, but often the shell encoding
will be in UTF-8, so Python needs some help converting the
message to Unicode. Use LANG to do that if we can.
|
| |
|
|
|
|
|
| |
If the command-line arg doesn't look like an object path,
treat it as the modem # and make the object path.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Depends on dbus-glib 0.86 + this patch:
https://bugs.freedesktop.org/show_bug.cgi?id=28835
Still have to do the bits that allow plugins to add other
location capabilities, but that can come later.
|
| |
|
| |
|
|
|
|
|
|
| |
Some cards (Novatel S720 for example) can take a long time to start
a data call if the device isn't activated on the network or the
signal strength is low.
|
| |
|
|
|
|
|
| |
If they're not there, just ignore them and don't build the PPP-enabled
bits of the test tool.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Registration can be part of the connect process, which can take quite a while.
|
| |
|
| |
|
|
|
|
| |
A helpful little tool to debug udev device relationships.
|
| |
|
|
|
|
|
|
| |
Like UMTS vs. GSM, EVDO and 1x are separate networks and technologies
and have separate registration state. You can even be roaming on
EVDO while in your home 1x network. Handle that.
|
| |
|
| |
|
| |
|