Hi all,
Some fixes related to power-up/power-down some modems are available in
the 'power-up-check-needed' branch in the following Gitorious repo
[1]:
git://gitorious.org/lanedo/modemmanager.git
The changes being:
* Modified the generic GSM implementation so that we allow plugins to
check
On Wed, 2011-06-22 at 08:21 -0700, Manish S Runwal wrote:
> Sorry to bother you. But I am deadly looking for solution for it.
>
>
Your modem-manager debug logs show that you get NO CARRIER errors when
trying to connect:
(ttyUSB3): --> 'ATD*99***1#'
(ttyUSB3): <-- 'NO CARRIER'
(ttyUSB3): --> 'AT
Hi Dan,
> > Some fixes related to power-up/power-down some modems are available in
> > the 'power-up-check-needed' branch in the following Gitorious repo
> > [1]:
> > git://gitorious.org/lanedo/modemmanager.git
>
> These all look good. I think in the future though we should just define
> so
>
> after hibernation the system asks for the sim pin, which is accepted, but
> still is unable to connect, see the attached log. I deactivate 3g broadband,
> then reactivate. After giving it some time, i have it connect to my provider.
> It then recognizes that it has no SIM PIN available, wh
Hi,
>
> By the virtue of
> https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/459052
> I've ended up running modem-manager from git (today's master).
>
> And yet, not all is well (there's no connection). Here's the syslog
> bits that looked interesting to me:
>
> modem-manager[6071]:
>
> If you're still interested, I can send the MM/NM logs from a typical
> session (there are several error-like anomalous messages on the way).
>
It would be great if you could do that, indeed.
--
Aleksander
___
networkmanager-list mailing list
ne
On Mon, 2011-07-11 at 00:04 +0400, Samium Gromoff wrote:
> On Sun, 10 Jul 2011 21:54:42 +0200, Aleksander Morgado
> wrote:
> >
> > Could you please provide modem-manager debug logs?
> >
> > https://wiki.ubuntu.com/DebuggingModemmanager
>
> In the very b
Hey Samium,
...
> modem-manager[3878]: [1311508930.212757] [mm-serial-port.c:938]
> mm_serial_port_close(): (ttyUSB0) serial port closed
> modem-manager[3878]: [1311508930.213324] [mm-manager.c:687]
> supports_callback(): (tty/ttyUSB0): plugin 0x9542d20 (Cinterion) existing
> 0x9542f20 (Sier
> > ...
> > > modem-manager[3878]: [1311508930.212757] [mm-serial-port.c:938]
> > > mm_serial_port_close(): (ttyUSB0) serial port closed
> > > modem-manager[3878]: [1311508930.213324] [mm-manager.c:687]
> > > supports_callback(): (tty/ttyUSB0): plugin 0x9542d20 (Cinterion) existing
> > > 0x9
Hi everyone,
One of the things that came up during the NM/MM BoF during the Desktop
Summit was about the possibility of having a C library (libmm-glib? [1])
which will enable easy access to ModemManager info in GLib-based
applications.
I'm looking into preparing a "ModemManager.h" with common typ
>
> So, what about having a common "ModemManager.h", and making the daemon
> use it as well? I have mixed feelings on whether it makes sense to have
> it auto-generated from the DBus API XMLs, anyway, as we want it to be
> used also internally; so I would propose to have it manually maintained,
>
Hi,
> I'm not sure why it is better to manually maintain the file rather
> than auto generating it (other than XSLT being a difficult language),
> but I certainly agree with using enum types instead of #defines.
>
It actually depends on what we want to have in that common header. If we
just want
> > > I'm not sure why it is better to manually maintain the file rather
> > > than auto generating it (other than XSLT being a difficult language),
> > > but I certainly agree with using enum types instead of #defines.
> > >
> >
> > It actually depends on what we want to have in that common hea
Hi hi,
> > > > I'm not sure why it is better to manually maintain the file rather
> > > > than auto generating it (other than XSLT being a difficult language),
> > > > but I certainly agree with using enum types instead of #defines.
> > > >
> > >
> > > It actually depends on what we want to have
On Thu, 2011-08-18 at 14:50 -0500, Dan Williams wrote:
> On Wed, 2011-08-17 at 10:55 -0400, Jason Glasgow wrote:
> > I think that looks great. -Jason
>
> Yeah, looks good to me too.
Should I just merge it to git master, or wait until I get the libmm-glib
ready for review?
--
Aleksander
___
On Fri, 2011-08-19 at 15:38 -0500, Dan Williams wrote:
> On Fri, 2011-08-19 at 12:27 +0200, Aleksander Morgado wrote:
> > On Thu, 2011-08-18 at 14:50 -0500, Dan Williams wrote:
> > > On Wed, 2011-08-17 at 10:55 -0400, Jason Glasgow wrote:
> > > > I think that looks g
ger/commit/?id=46d757faa768db7d7bb23d51cc2af3196f7a7e30
--
Aleksander
>From 425cc9294141b83e66a6ed62a3e68674144ca6d8 Mon Sep 17 00:00:00 2001
From: Aleksander Morgado
Date: Sat, 20 Aug 2011 17:22:28 +0200
Subject: [PATCH] nokia: use E1 E0 when initializing the modem
Passing E1 and E0 afterwards
> (ttyHS0): --> 'AT_OPSYS?'
> Sep 15 10:43:34 ThinClient modem-manager[2081]:
> [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <--
> 'ERROR'
> Sep 15 10:43:34 ThinClient modem-manager[2081]:
> [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure
> code 100: Unknown error
> Sep 15
> In an email from a few months ago I saw a reference to a modem-manager cli.
> Is this a publicly availble program?
>
It is not finished yet, but quite usable if you speak English (not
translated yet) and if you know how to clone a git repo and compile
ModemManager youself:
1. Clone git://gi
> > In an email from a few months ago I saw a reference to a modem-manager cli.
> > Is this a publicly availble program?
>
> AFAIK there's no mm-cli at all; there are a number of CLI tools (mainly
> for testing) that talk to MM. A CLI MM tool wouldn't be hugely useful
> for actual connections
Hi all,
I've been lately trying to improve the probing process in ModemManager,
so that it is faster and easier to maintain, keeping in mind the
different specific needs of the current plugins.
The current status of the work can be seen in the 'probing-refactor'
branch in the following git repo:
> >
> > 1. Plugin Manager
> > ---
> >
> > The MMManager object handled too many different tasks, that it made
> > sense to me to have an independent MMPluginManager object which takes
> > care of:
> > * Finding plugins and loading them
> > * Control
Hey,
>
> after doing a lot of testing with bad UMTS connections, I was able to solve
> most of my problems with my patches from
> http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00040.html
> .
>
> There is one problem still left, which I am not able to solve on my own.
>
These methods were available in the old API, and are needed in the new one.
---
new/org.freedesktop.ModemManager1.xml | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/new/org.freedesktop.ModemManager1.xml
b/new/org.freedesktop.ModemManager1.xml
index 6e
SIM objects will be listed as independent objects in the DBus API, and the 'Sim'
property in a given modem object will specify which SIM object is in use.
---
new/org.freedesktop.ModemManager1.Modem.xml |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/new/org.freedeskt
Here is a set of changes to the proposed MM DBus API. Some of them were already
discussed some time ago in the following thread:
https://mail.gnome.org/archives/networkmanager-list/2011-May/msg00162.html
[PATCH 1/8] api: include ScanDevices() and SetLogging() in the new manager API
[PATCH 2/8] api
New 'Manufacturer', 'Model' and 'Revision properties are added, all being
read-only strings.
---
new/org.freedesktop.ModemManager1.Modem.xml | 37 +--
1 files changed, 18 insertions(+), 19 deletions(-)
diff --git a/new/org.freedesktop.ModemManager1.Modem.xml
b/new/org.f
Modems which only expose a single port will not be able to update the signal
quality value while in connected mode. The signal quality value reported in this
case, while the modem is connected, will be the last signal quality value read
before the connection.
The additional boolean value proposed
Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values,
and preference of a specific mode is now given in the new PreferredMode
property and as an extra argument to the SetAllowedModes() call.
* Supported Modes: bitmask specifying which modes are supported by the specific
Makes more sense to have the enum named just as 'mode', as it applies to both
Supported and Allowed.
---
new/org.freedesktop.ModemManager1.Modem.xml |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/new/org.freedesktop.ModemManager1.Modem.xml
b/new/org.freedesktop.Mo
Changing the allowed mode of a modem may fail, for example if trying to set a
mode which is not in the modes reported as Supported by the modem. Therefore, we
need an explicit SetAllowedModes() method with proper error reporting instead of
making the property writable.
---
new/org.freedesktop.Mode
Changing the allowed bands in a modem may fail, for example if trying to set a
frequency band which is not in the bands mask reported as Supported by the
modem.
Therefore, we need an explicit SetAllowedBands() method with proper error
reporting instead of making the property writable.
---
new/org
Hey Thomas,
> > Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE
> > values,
> > and preference of a specific mode is now given in the new PreferredMode
> > property and as an extra argument to the SetAllowedModes() call.
> >
> > * Supported Modes: bitmask specifying whi
> > Here is a set of changes to the proposed MM DBus API. Some of them were
> > already
> > discussed some time ago in the following thread:
> > https://mail.gnome.org/archives/networkmanager-list/2011-May/msg00162.html
> >
> > [PATCH 1/8] api: include ScanDevices() and SetLogging() in the new m
Hey hey,
> > Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE
> > values,
> > and preference of a specific mode is now given in the new PreferredMode
> > property and as an extra argument to the SetAllowedModes() call.
> >
> > * Supported Modes: bitmask specifying which
Hey Thomas,
>
> To reproduce, i do the following:
>
> 1 ) stop NM, MM and disconnect the modem from power supply
> 2 ) connect the modem to power supply
> 3 ) start MM: modem-manager --debug --log-level=DEBUG
> 4 ) start NM: /etc/init.d/network-manager start
> 5 ) nmcli con up uuid baa2af1b-e21e
ttached is a patch that solves the issue. It modifies the common serial
parser, so not something Cinterion-specific, but the change is quite
small and shouldn't affect other plugins.
Cheers,
--
Aleksander
>From 9d56d7b55c55859e259d22476eef515e90d84a0a Mon Sep 17 00:00:00 2001
From: Aleksand
Hi all,
The ObjectManager interface was recently added as a standard interface
in DBus:
http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager
For the 0.6 API, we could be using this interface instead of the
proposed GetDevices() method, the Modems property and
> > So the real problem here is that the Cinterion modem sends a NUL byte
> > before the CONNECT response:
> >
> > > [mm-at-serial-port.c:298] debug_log(): (ttyS1): --> 'ATD*99***1#'
> > > modem-manager[2621]: [1317807408.548825]
> > > [mm-at-serial-port.c:298] debug_log(): (ttyS1): <-- '\0'
>
> Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE
> values,
> and preference of a specific mode is now given in the new PreferredMode
> property and as an extra argument to the SetAllowedModes() call.
>
> * Supported Modes: bitmask specifying which modes are supported b
Hi everyone,
I just pushed a new '06-api' [1] development branch in the upstream
ModemManager git repo. This branch will hold the port of ModemManager to
the new 0.6 API, using GDBus and also targeting the new multi-mode LTE
devices. At some point it will also include the new libmm-glib [2] and
th
Hey Eric,
Some comments inline below.
On Wed, 2011-10-19 at 15:42 -0400, Eric Shienbrood wrote:
> From b129d263ec1674462c218b4ec91260cf082bf77e Mon Sep 17 00:00:00 2001
> From: Eric Shienbrood
> Date: Thu, 11 Aug 2011 13:58:59 -0400
> Subject: [PATCH] Added new property to track which facility l
On Wed, 2011-10-19 at 15:42 -0400, Eric Shienbrood wrote:
> From 7c718db20958c200bc9dcb086763bfe0ebb91399 Mon Sep 17 00:00:00 2001
> From: Eric Shienbrood
> Date: Thu, 14 Jul 2011 19:11:54 -0400
> Subject: [PATCH] Correctly track the number of SIM PIN retries left.
>
> There are other operations
> > i use latest git-snapshot from ModemManager with NM 0.8.4. I try to use
> > a Fastttrack XTend FXT009.
> >
> > I'm unable to get a working connection (see MM-Log).
> > After the connection, the modem does not answer to any AT-commands (see
> > the end of MM-Log).
>
> Hmm, maybe we're diali
> > i use a Fasttrack xTend FXT009 with an external power supply.
> > i use MM on an embedded device and the modem is connected over usb.
> > When i have an active connection with the modem, remove the power from
> > the embedded device (so MM has no chance to cleanup anything) and then i
> > re
On Tue, 2011-11-22 at 12:21 +0100, Marcel Holtmann wrote:
> Actually the HTTP header makes a lot more sense since once you
> received
> the valid one, you can just terminate the HTTP request and do not have
> to deal with downloading the whole file.
You can possibly do just a HTTP HEAD request, w
Hey Eric & Dan,
On Fri, 2011-11-11 at 15:10 -0500, Eric Shienbrood wrote:
> Subject: [PATCH] Added new property to track which facility locks are
> enabled.
>
> The property EnabledFacilityLocks on the .Modem.Gsm.Card interface
> is a bit mask that indicates which of the various personalization
>
Hey hey,
> I guess I don't have a problem with merging them, although strictly
> speaking they refer to different things - locks vs. the PINs needed to
> unlock those locks.
>
Yeah, you're totally right... but at the end the PIN/PUK codes are
directly related to facilities. E.g "SIM facility", ha
Hey Dan & ttuttle,
The 0.6 API in MM has 2 properties named "ModemCapabilities" and
"CurrentCapabilities". The current ones will be the ones reported by
+GCAP, but how do we know the modem ones?
I am assuming here that the ModemCapabilities will be different to the
CurrentCapabilities only when t
Hey,
According to the DBus specs [1], no element within a DBus interface can
start with a digit... so "org.freedesktop.ModemManager1.Modem.3gpp" is a
bad name. :-/
I will temporarily fallback to use:
"org.freedesktop.ModemManager1.Modem.Modem3gpp" (along with
"org.freedesktop.ModemManager1.Modem.
> (For ChromeOS development, I have rigged up a black-box ModemManager
> test system under autotest, which creates a fake gudev device and a
> fake modem that responds to AT commands to test this kind of thing. It
> might be interesting to adapt it into the MM build system somehow;
> right now it'
> This was the only code in ModemManager using g_error(), and not
> appropriately, I think.
> The codebase is still mixed on how to handle errors compiling regular
> expressions; other places in this file use g_assert(), while the rest
> of the code tends to report some kind of parse-failure error
> > > I guess I don't have a problem with merging them, although strictly
> > > speaking they refer to different things - locks vs. the PINs needed to
> > > unlock those locks.
> > >
> > Yeah, you're totally right... but at the end the PIN/PUK codes are
> > directly related to facilities. E.g "SI
> > According to the DBus specs [1], no element within a DBus interface can
> > start with a digit... so "org.freedesktop.ModemManager1.Modem.3gpp" is a
> > bad name. :-/
> >
> > I will temporarily fallback to use:
> > "org.freedesktop.ModemManager1.Modem.Modem3gpp" (along with
> > "org.freedeskt
> > > > > I guess I don't have a problem with merging them, although strictly
> > > > > speaking they refer to different things - locks vs. the PINs needed to
> > > > > unlock those locks.
> > > > >
> > > > Yeah, you're totally right... but at the end the PIN/PUK codes are
> > > > directly relate
On Thu, 2011-06-30 at 11:51 -0500, Dan Williams wrote:
> On Wed, 2011-06-22 at 16:35 +0200, Aleksander Morgado wrote:
> > Hi all,
> >
> > Some fixes related to power-up/power-down some modems are available
> in
> > the 'power-up-check-needed' branc
On 12/21/2011 07:00 PM, John Hibbs wrote:
One thing I do see is 'ATD*99***1***2#'. This does not match the
settings I entered in.
Mobile Broadband Settings:
Connection name: AT&T Mobile
IPv4 Method: Automatic(PPP)
Mobile Broadband Number: *99***1#
Mobile Broadband APN: isp.cingular
Type: Any
Al
Hey!
One thing I do see is 'ATD*99***1***2#'. This does not match the
settings I entered in.
Mobile Broadband Settings:
Connection name: AT&T Mobile
IPv4 Method: Automatic(PPP)
Mobile Broadband Number: *99***1#
Mobile Broadband APN: isp.cingular
Type: Any
Allow roaming
PPP Authentication Allow
On 10/31/2011 06:53 PM, Alfredo C. Harvey wrote:
Hello, list.
Some day ago I posted this issue.
Would deeply appreciate some guidance -a lot of it. :-))
Huawei E173 USB módem for mobile broad band connection.
Fedora 15 Linux.
usb_modeswitch 1.1.7 -came with the system; yum say it is up to date.
Hey,
One of the things that annoys me when using ModemManager is that
whenever I plug in a modem, I need to wait for the modem to get all
ports probed before I can see the NM applet updated with the new
broadband-related menu elements. In the worst case, where the modem just
returns errors to
Hey Dan,
>> One of the things that annoys me when using ModemManager is that
>> whenever I plug in a modem, I need to wait for the modem to get all
>> ports probed before I can see the NM applet updated with the new
>> broadband-related menu elements. In the worst case, where the modem just
>>
Hey Jason,
> One of the things that annoys me when using ModemManager is that
> whenever I plug in a modem, I need to wait for the modem to get all
> ports probed before I can see the NM applet updated with the new
> broadband-related menu elements. In the worst case, where the mod
Hey Dan,
>>
>> On Ubuntu 11.10 there is problem with connection via modem Huawei E220.
>>
>> On Ubuntu 11.10 the NetworkManager is in version 0.9.1.90-0ubuntu5.1
>> On Ubunto 11.04 there is version 0.8.4~git.20110319t175609.d14809b-0ubuntu3
>>
>> The issue for Ubuntu was submitted:
>> https://bugs
at is not the case, I can improve the patch to
make this behaviour configurable per plugin (even for the probing
process). At least it works super well for my use case. If we do accept
this patch, we could possibly remove from the sources the v1_e1 parser,
which wouldn't be needed any more.
--
Aleksan
Hey,
I believe we need a MMBearerType enum in the 0.6 API, so that we can
tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS)
bearer. This property would be redundant for 3GPP-only, CDMA-only or
POTS-only modems, but would be mandatory if we have a mixed
3GPP(LTE)+CDMA bearer. Th
>> I believe we need a MMBearerType enum in the 0.6 API, so that we can
>> tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS)
>> bearer. This property would be redundant for 3GPP-only, CDMA-only or
>> POTS-only modems, but would be mandatory if we have a mixed
>> 3GPP(LTE)+CDMA
Hey Marcel,
>
I believe we need a MMBearerType enum in the 0.6 API, so that we can
tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS)
bearer. This property would be redundant for 3GPP-only, CDMA-only or
POTS-only modems, but would be mandatory if we have a m
> I believe we need a MMBearerType enum in the 0.6 API, so that we can
> tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS)
> bearer. This property would be redundant for 3GPP-only, CDMA-only or
> POTS-only modems, but would be mandatory if we have a mixed
>
>> I believe we need a MMBearerType enum in the 0.6 API, so that we can
>> tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS)
>> bearer. This property would be redundant for 3GPP-only, CDMA-only or
>> POTS-only modems, but would be mandatory if we have a mixed
>>
>>> I believe we need a MMBearerType enum in the 0.6 API, so that we can
>>> tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS)
>>> bearer. This property would be redundant for 3GPP-only, CDMA-only or
>>> POTS-only modems, but would be mandatory if we have a mixe
> +
> +
> +
> +The timezone data provided by the network. It may include one of
> more
> +of the following fields:
> +
> +'offset': offset of the timezone from UTC, in minutes (including DST,
> + if applicable).
> +'dst_offset': amount o
>
> +static GValue *
> +int_to_gvalue (gint i)
> +{
> +GValue *v = g_slice_new0 (GValue);
> +g_value_init (v, G_TYPE_INT);
> +g_value_set_int (v, i);
> +return v;
> +}
> +
> +static void
> +value_destroy (gpointer data)
> +{
> +GValue *v = (GValue *) data;
> +g_value_unse
On 07/31/2011 12:52 AM, Dan Williams wrote:
> On Thu, 2011-06-30 at 18:18 -0400, Eric Shienbrood wrote:
>> I can look at doing that. What should we call it? I think MSISDN is a
>> GSM term. How does GetPhoneNumber() sound?
>
> Hm, old message. Yes, that method sounds fine.
>
Where did this end
>>> On Thu, 2011-06-30 at 18:18 -0400, Eric Shienbrood wrote:
I can look at doing that. What should we call it? I think MSISDN is a
GSM term. How does GetPhoneNumber() sound?
>>>
>>> Hm, old message. Yes, that method sounds fine.
>>
>> Where did this end up?
>>
>> Also, AT+CNUM may repo
>> If you just need to store a signed integer as the value of an entry in
>> the hash table, you can better use GINT_TO_POINTER (integer) and
>> GPOINTER_TO_INT (pointer), instead of packing the integer into a GValue.
>
> I need it in a format that DBus will be okay with -- NetworkTimezone
> is d
>> I'm not sure why we would include leap seconds info here. Leap seconds
>> are adjustments to UTC itself, so if the time retrieved from
>> GetNetworkTime() is always UTC, there is no need for that, as far as I
>> can tell.
>
> I'm including it because one of our modems (the Gobi) exports it as
>>> I can look at doing that. What should we call it? I think MSISDN is
>>> a GSM term. How does GetPhoneNumber() sound?
>>
>> Hm, old message. Yes, that method sounds fine.
>
> Where did this end up?
>
> Also, AT+CNUM may report a list of numbers, not just one.
>>
On Ubuntu 11.10 there is problem with connection via modem Huawei E220.
On Ubuntu 11.10 the NetworkManager is in version 0.9.1.90-0ubuntu5.1
On Ubunto 11.04 there is version 0.8.4~git.20110319t175609.d14809b-0ubuntu3
The issue for Ubuntu was submitted:
https://bu
don't use GValueArrays there.
Cheers,
--
Aleksander
>From 86cec854ed07848d2d0df9341d8f20d3c4d51616 Mon Sep 17 00:00:00 2001
From: Aleksander Morgado
Date: Tue, 7 Feb 2012 12:56:45 +0100
Subject: [PATCH] build: do not warn about using deprecated methods
GValueArray is deprecated since GLib
Hey hey,
>
> I followed you advice, I downloaded the MM_05 branch and compiled in my
> system. I did not changed (means: compiled) other things on the system, so,
> the rest is in the same version I wrote above.
> After the installation, I fixed a path problem (previously I compiled it with
>
Hey,
>
> I would like to inform you about my test result today.
> I downloaded the master repository from the freedesktop git and I compiled it
> successfully.
>
Note that MM_05 also has all latest fixes now.
> So, the latest sms-get.py get both sms messages correctly from the modem,
> whic
>>
>> That CMGS command seems the proper one, so not sure why the ZTE modem
>> didn't like it. Could you run "AT+CMGS=?" in minicom and send back the
>> result?
>>
>
> I turned off the mobile internet connection.
> Here it is:
>
> root@antiX1 :~# echo -e "AT+CPIN?\r" > /dev/ttyUSB1
> root@antiX1
>>> Any idea what command Gammu sends? Does it use PDU mode or text mode to
>>> send it? Is it possible for you to get a log of the serial traffic when
>>> using Gammu so we can compare to what ModemManager does?
>>>
>>> Dan
>>
>> Hi,
>>
>> In attached you can find the gammu log for a successfully
Should I watch the cgit to get the latest patch against this weird
behaviour of
this specific modem?
>>>
>>> Yes.
>>>
>>> Dan
>>
>> Hi, sorry for the question, do you have a schedule for this fix in master or
>> MM_05 branch?
>
> I was hoping that Aleksander meant to do it and t
Hey Dan,
I really do like the new approach, and I would even include it for
0.5.x. Some comments below.
> The core problem was that some devices need to specify a PPP port that's
> *not* the primary port. In these cases the primary port always stays
> open for command and status, while some othe
On 02/13/2012 08:37 PM, Aleksander Morgado wrote:
> Hey Dan,
>
> I really do like the new approach, and I would even include it for
> 0.5.x. Some comments below.
>
I ported this new behaviour to a new '06-api-ports' branch upstream;
will wait for more comments befor
On 02/13/2012 09:33 PM, Andrew Bird (Sphere Systems) wrote:
>Will this redesign allow you to change the udev rule assigned names
> from
> ID_MM_ZTE_PORT_TYPE_MODEM
> to
> ID_MM_PORT_TYPE_MODEM
> etc? I don't think there can be any clash requiring a different namespace as
> the items are fully
ome unit tests.
--
Aleksander
>From 48ce30df846bb2a742943d7b4d4bb1d695cc0d9c Mon Sep 17 00:00:00 2001
From: Aleksander Morgado
Date: Wed, 11 Jan 2012 01:33:05 +0100
Subject: [PATCH] at-serial-port: implement built-in echo/garbage removal
We expect the responses to start always with . We jus
>> +if (response->data[i] == '\r' && response->data[i + 1] ==
>> '\n') {
>> +if (i > 0)
>> +g_byte_array_remove_range (response, 0, i);
>> +else
>> +/* good, we're already started with */
>> +break;
>
> The else + comme
ched to this email; can
someone with commit rights push it?
Cheers!
--
Aleksander
>From 6959af8d54d25c3490372129a7022e0889b5fc05 Mon Sep 17 00:00:00 2001
From: Aleksander Morgado
Date: Thu, 9 Jun 2011 18:26:33 +0200
Subject: [PATCH] modem-manager: query desired IP timeout value
Different mod
Hey,
> This is required for properly displaying
> local-operator-vs-home-provider information, per 3GPP
> (31.102 section 4.1.2 on EF_SPN and 22.101 Annex A).
>
For anyone else checking, that's section 4.2.11 in release 11 of the
document.
> Suggestions welcome on the long and somewhat unwieldy
Hey Dan & Nathan,
> If we did combine both bits into one property, then we'd get the
> following logic:
>
> enum {
> DISPLAY_UNRESTRICTED = 0,
> DISPLAY_REGISTERED = 1,
> DISPLAY_SPN = 2
> } DisplayName;
>
> display = DISPLAY_UNRESTRICTED
> if (registered network is well-known) {
>
Hey,
The new ModemManager codebase in the 06-api branch comes with gtk-doc
based documentation. The (currently) first reference book is about the
ModemManager daemon and comes with general information which should be
helpful for API users and plugin writers:
http://www.lanedo.com/~aleksander/mode
Hey hey,
The new ModemManager codebase in the 06-api branch is almost fully
ready, and some of the plugins are even completely ported (e.g. Nokia,
Iridium, Motorola and Cinterion).
Any help, either writing the port of remaining plugins or testing
already ported plugins, is highly appreciated.
Ch
Hey hey hey,
NetworkManager can now be improved to support the new ModemManager1 DBus
interface implemented in the 06-api branch, directly using
GObject-friendly libmm-glib. Ideally, I guess that NM can be hacked to
temporarily support both the old ModemManager and the new ModemManager1
interfaces
Hey,
The '06-api' branch has a new property
(MM_PLUGIN_BASE_ALLOWED_SINGLE_AT) for MMPluginBase, which allows
specifying that only one AT port is expected in the modem [1]. If this
property is set, whenever the first AT port is grabbed, all the
remaining port probings will cancel their AT-specific
>> The '06-api' branch has a new property
>> (MM_PLUGIN_BASE_ALLOWED_SINGLE_AT) for MMPluginBase, which allows
>> specifying that only one AT port is expected in the modem [1]. If this
>> property is set, whenever the first AT port is grabbed, all the
>> remaining port probings will cancel their A
On 03/09/2012 12:16 AM, Nathan Williams wrote:
> There's a bit of annoying fighting with gchar ** and gdbus's idea of
> constness, but it seems reasonable otherwise.
Just modify load_spdi_finish() (and parse_spdi()) to return a gchar **
(without any const); and then explicitly cast to (const gchar
Hey Nathan,
> Also, if we do expose these two properties we also need to load and
> expose the SPDI network list, or the properties will be useless.
>
>
> Here's a patch to do that. There's a bit of annoying fighting with gchar
> ** and gdbus's idea of constness, but it seems reasonable
> A possible fix to handle the case where we don't know how much
> we can
>
> read would be to try to read the first bytes of the record (3 or
> 4 or 5
> just in case) to get the full record length of the record,
> assuming 1-3
> bytes max f
1 - 100 of 716 matches
Mail list logo
