On Fri, Jun 17, 2016 at 2:59 PM, Thomas Lang wrote:
> Without restart:
>
> go@ubuntu:~$ mmcli -b 0
> Bearer '/org/freedesktop/ModemManager1/Bearer/0'
> -
> Status | connected: 'no'
> | suspended: 'no'
> | inter
On Fri, Jun 17, 2016 at 5:56 PM, Thomas Lang wrote:
> ModemManager[835]: QMI IPv4 Settings:
> ModemManager[835]: Address: 100.76.202.73/30
> ModemManager[835]: Gateway: 100.76.202.74
> ModemManager[835]: DNS #1: 139.7.30.126
> ModemManager[835]: DNS #2: 139.7.30.125
> Mod
On Fri, Jun 17, 2016 at 5:46 PM, Dan Williams wrote:
> MM never passes MBIM_CONTEXT_IP_TYPE_DEFAULT which would require paying
> attention to the ip_type in the reply to figure out what type the modem
> activated. Instead, MM always specifies the ip_type it wants to activate,
> and some modems (K
Hey Ralph & Rasmus,
I've just pushed a new patch (broadband-modem: run power up/down
actions unconditionally) to the "qmi-over-mbim" branch in the
ModemManager repo, the libqmi and libmbim ones were not updated.
Could you guys update and retry?
I think I'm actually going to try to buy one of the
te:
> On Wed, Jun 22, 2016 at 1:40 AM, Aleksander Morgado
> wrote:
>
> Hey Ralph & Rasmus, I've just pushed a new patch (broadband-modem: run power
> up/down actions unconditionally) to the "qmi-over-mbim" branch in the
> ModemManager repo, the libqmi and libmbim
On Wed, Jun 22, 2016 at 11:01 PM, Jason L Tibbitts III
wrote:
>
> JD> I've been in and out of the FCC over MBIM stuff over
> JD> here. Alexander, you ever find someone to test with EM7455? I got
> JD> one. Probably can't test until the weekend. But I might have some
> JD> time to tinker around tes
On Thu, Jun 23, 2016 at 7:00 PM, George Tepnadze
wrote:
> old modem manager but patched libqmi-qmi-over-mbim from AUR
Note that an old modemmanager won't try the FCC auth command via
QMI-over-MBIM; you'd need to manually do it yourself using qmicli
before MM tries to connect the modem.
--
Aleks
On Thu, Jun 23, 2016 at 5:43 PM, Aleksander Morgado
wrote:
>> I also have one (Sierra with USB ID 1199:9079). Just found out that I
>> need to rebuild a few things from git branches and was planning on
>> trying to get to that today or tomorrow.
>
> I've actually bo
On Fri, Jun 24, 2016 at 12:28 PM, Aleksander Morgado
wrote:
>>> I also have one (Sierra with USB ID 1199:9079). Just found out that I
>>> need to rebuild a few things from git branches and was planning on
>>> trying to get to that today or tomorrow.
>>
>>
On Sun, Jun 26, 2016 at 9:01 PM, Samo Ratnik wrote:
> Some good news and some bad news. The good news is that I got the thing
> working. I'm using Arch's "stock" NetworkManager and ModemManager and the
> AUR packages mentioned above. I simply issue the "sudo qmicli
> --device-open-mbim -d /dev/cdc
On Wed, Jun 29, 2016 at 6:55 PM, Philipp Hagemeister wrote:
> I am currently using modem-manager 1.4.14-1 from debian unstable on
> Linux 4.7.0-rc4-amd64 (tried with various other versions too). You can
> see a bunch more information at http://superuser.com/q/1079052/62132 ,
> but I am happy to pr
On Wed, Jun 29, 2016 at 8:52 PM, Philipp Hagemeister wrote:
> Thank you very much for the prompt response! I apologize for the delay;
> due to size, I had to upload my logs instead of attaching them.
>
> I believe I have captured both of the logs at
> https://gist.github.com/a99a82d0578c9a4867300e
On Wed, Jun 29, 2016 at 10:01 PM, Philipp Hagemeister wrote:
> Just to be certain, I have most definitly attempted a connection here
> (after /sys/bus/usb/devices/1-5/bConfigurationValue = 3, i.e. MBIM):
>
> https://gist.githubusercontent.com/phihag/a99a82d0578c9a4867300ee91eb9084f/raw/19d42d71495
On Thu, Jun 30, 2016 at 12:05 AM, Philipp Hagemeister wrote:
>> If you don't try the connection, but keep the
>> modem enabled (i.e. just mmcli -m 0 -e"), does it ever get registered
>> after some time?
>
> No, doesn't look that way. I just walked over the whole campus (usually
> good reception ev
On Thu, Jun 30, 2016 at 12:28 PM, Philipp Hagemeister wrote:
>> mmcli -m 0 --3gpp-scan
>
> I see one of two different errors:
>
> $ mmcli -m 0 --3gpp-scan
> error: couldn't scan networks in the modem: 'unknown error'
> $ mmcli -m 0 --3gpp-scan
> error: couldn't scan networks in the modem: 'Timeout
Hey Carlo!
On Thu, Jun 30, 2016 at 1:36 PM, Carlo Lobrano wrote:
> BaseModem
> added reprobe property.
>
> MMDevice
> added logic to recreate the modem if it is set invalid and "to reprobe"
>
> MMBroadbandModem
> * added initialization step for SIM hot swap:
> 1. keep dedicated ports ope
Hey,
>
> sorry but I sent the previous email before completing it. This
> proposal is based on two patches.
> The first, in the previous e-mail, adds the core logic for modems that
> support SIM hot swap,
> The second in this e-mail, is the plugin side implementation for a Telit
> modem.
>
> Carl
Hey Carlo,
>
> I'm using a standard Ubuntu 16.06. I tested with both GUI interface
> and rtcwake, but the "problem" is that the system I was working with
> detaches the modem when it goes in stand by, so there's a full
> de-enumeration/re-enumeration of the ports when passing from S0 to S3
> and b
On Wed, Jun 1, 2016 at 6:16 PM, Dan Williams wrote:
> On Wed, 2016-06-01 at 16:48 +0200, Aleksander Morgado wrote:
>> On Wed, Jun 1, 2016 at 4:34 PM, Carlo Lobrano
>> wrote:
>> >
>> > Hi, has this change already merged?
>> Not yet; IIRC Dan suggested to m
On Thu, Jun 30, 2016 at 4:23 PM, Carlo Lobrano wrote:
>> A long shot maybe, but did you see this issue while you were testing the SIM
>> hotplug thing? Remember that there's an extra port open reference in that
>> case.
>
> No no :), I wouldn't have signaled such an error in a "corrupted"
> Mode
> > > + if (!is_sim_hot_swap_supported) {
> > > + ctx->self->priv->sim_hot_swap_ports_ctx = NULL;
> > > + } else {
> > > + PortsContext *ports;
> > > + GError *error = NULL;
> > > +
> > > + mm_dbg ("Modem supports SIM hot swap. Opening dedicated ports.");
> > > +
> > > + ports = g_new0 (PortsContex
On Fri, Jul 1, 2016 at 6:47 AM, Tomek Mańko wrote:
> Well, it turns out the explanation was pretty mundane - I was duped by my
> worplace. I asked for a L460 with LTE modem, PM passed on a request for a
> L460
> with an LTE modem and apparently requisitioning decided to save by buying
> one
> with
On Fri, Jul 1, 2016 at 8:40 AM, Andreas Fett wrote:
>> But making it work at all is of course the killer feature... And right
>> now we haven't got a clue what the problem with the EM7455 is, so there
>> is no ETA for a fix. It could take forever, literally.
>
> Would any kind of Logs from a Win
On Fri, Jul 1, 2016 at 10:47 AM, Carlo Lobrano wrote:
>
> Consider that the modem sends QSS only from the port where it's been set, so
> I can't set it on the primary and listen on the secondary.
Is it possible to set it in both? E.g. always in primary, and only in
secondary if secondary exists
On Fri, Jul 1, 2016 at 11:07 AM, Carlo Lobrano wrote:
> What about set it in the secondary if it exists, and in the primary if
> it doesn't? I'm thinking about the case where I receive the
> unsolicited on both and I have to decide which one to reject
Ok, this could work.
--
Aleksander
https://
Hey hey,
This 1.5.993 is the fourth release candidate version towards 1.6.0,
tagged as 1.6-rc4.
This release implements support for sending the QMI FCC authentication
command via QMI-over-MBIM if power-up fails via plain MBIM. This new
feature requires libmbim 1.14.0 and libqmi 1.16.0, which will
On Fri, Jul 8, 2016 at 2:34 PM, Ralph Plawetzki wrote:
> I installed the latest qmi-over-mbim branches
Please use git master versions instead, as I explicitly left out some
of the patches from the MM qmi-over-mbim branch.
But nice to see it's working :)
--
Aleksander
https://aleksander.es
__
On Fri, Jul 8, 2016 at 1:03 PM, Bjørn Mork wrote:
>
> I tested booting from poweroff and resuming from hibernate [1] on an
> Thinkpad X1 Carbon with the original Lenovo configured EM7455. This
> worked so well for me that I had to look into the MM logs to make sure
> that the modem still needed th
On Fri, Jul 8, 2016 at 3:13 PM, Bjørn Mork wrote:
> BTW, I just noticed that the Debian packagers have been very busy, and
> the new libqmi, libmbim and ModemManager 1.5.993 is already in Debian
> sid!
Arch Linux packagers were also busy :)
https://www.archlinux.org/packages/testing/x86_64/modemm
On Thu, Jul 7, 2016 at 5:45 PM, Carlo Lobrano wrote:
> I manage to replicate only a slightly different behavior, the log is in
> attachment.
>
>
> The test case is the following:
> 1. modem connected to the network and automatic reconnection set in the nm
> gui.
> 2. system in suspend (I used
Hey,
On Wed, Jul 6, 2016 at 3:35 PM, Carlo Lobrano wrote:
> MMBroadbandModemTelit:
> * added logic to set MMBroadbandModem's SIM_HOT_SWAP property to TRUE
> * added function to enable QSS unsolicited
> * added QSS unsolicited handler
> ---
> plugins/telit/mm-broadband-modem-telit.c | 136
Hey Laurent,
On Tue, Jul 12, 2016 at 7:19 PM, Laurent Savaete wrote:
> I recently bought a couple of dlink USB modems, more exactly DWM-156 HW
> version A8.
> They work ok on linux after figuring out the usb_modeswitch stuff, but now
> I'm stuck with getting them to do USSD.
> I am getting the ex
On Thu, Jul 14, 2016 at 6:51 PM, matthew stanger wrote:
> Is there an easy way from keep MM from probing the serial port?
We maintain a blacklist of serial USB devices that MM shouldn't probe
as udev tags, see:
https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/77-mm-usb-device-bl
On Fri, Jul 1, 2016 at 12:11 AM, Andrew Mackintosh
wrote:
> Jul 01 09:59:35 raspberrypi pppd[2764]: Plugin
> /usr/lib/pppd/2.4.6/nm-pppd-plugin.so loaded.
> Jul 01 09:59:35 raspberrypi NetworkManager[2691]: Plugin
> /usr/lib/pppd/2.4.6/nm-pppd-plugin.so loaded.
> Jul 01 09:59:35 raspberrypi Networ
On Tue, Jul 19, 2016 at 12:57 AM, Ali Nematollahi wrote:
> ModemManager[3100]: [946686725.704970] [mm-port-serial-at.c:440]
> debug_log(): (ttyUSB3): --> 'ATD*99***1#'
> ModemManager[3100]: [946686725.732977] [mm-port-serial-at.c:440]
> debug_log(): (ttyUSB3): <-- 'CONNECT'
> ModemManager[3100]:
On Wed, Jul 20, 2016 at 1:11 AM, matthew stanger wrote:
> I was just finishing up a patch for swwan support in the Cinterion plugin.
> During my testing I noticed that with the PLS8-X & no SIM card inserted
> mmcli gives a timeout error instead of a no-sim error. I traced it back to
> 'mm-inface-m
Hey,
If anyone out there has CDMA/EVDO only modems (and subscriptions),
please test with latest MM git master or the 1.5.993 prerelease, and
report back results.
We're targeting the 1.6 release this week or early next week.
Thanks!
--
Aleksander
https://aleksander.es
__
Hey hey,
This is a new major release of ModemManager, which will be the base for
the 1.6.x stable series (the new "mm-1-6" branch in git). The release
has been tagged as "1.6.0".
Thanks to everyone involved!
ModemManager 1.6.0
---
* This version requires
On 13/05/16 17:15, Carlo Lobrano wrote:
> Inverted steps UPDATE_LOCK_INFO_CONTEXT_STEP_RETRIES and
> UPDATE_LOCK_INFO_CONTEXT_STEP_AFTER_UNLOCK.
>
> Soon after the unlock, the SIM can be busy and
> loading unlock retries might fail.
>
> When implemented, let run "after unlock" logic before any ot
On 13/05/16 17:15, Carlo Lobrano wrote:
> A short delay is necessary with some SIMs when
> they have just been unlocked. Using 1 second as secure margin.
Pushed to git master, thanks!
> ---
> plugins/telit/mm-broadband-modem-telit.c | 38
>
> 1 file changed, 38
Hey Carlo,
>
> this is the second attempt for this patch.
> I should have fixed all the problems observed in the first code review.
>
Sorry for the late recheck on this. I do like how this looks like, but I
believe there are a couple minor things to consider still. See comments
below.
>
> --
On Tue, Jul 26, 2016 at 5:24 PM, Dan Williams wrote:
> When a CDMA-only modem is registered with the EVDO network, its not possible
> to
> read signal strength in the following cases:
>
> 1) while a data connection is active on single-AT-port modems, because the AT
> port is used for PPP and not
On Wed, Jul 27, 2016 at 9:41 PM, matthew stanger wrote:
> I'm trying to fix the GPS for the Cinterion plugin for the PLS8-X and I'm
> just a little confused about the 77-mm-cinterion-port-types.rules file. I
> see it sets a uDev tag based on idVendor and idProduct, of which idProduct
> is wrong fo
The following set of patches try to consolidate the way the different udev
rules are applied in the different plugins. Most of the cases are just
simplifications or redundancy check removals. This series of patches also
serves as base for a follow up series that includes a custom udev rules
pro
---
plugins/cinterion/77-mm-cinterion-port-types.rules | 2 +-
plugins/huawei/77-mm-huawei-net-port-types.rules | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/plugins/cinterion/77-mm-cinterion-port-types.rules
b/plugins/cinterion/77-mm-cinterion-port-types.rules
index 09
---
plugins/cinterion/77-mm-cinterion-port-types.rules | 4 +-
plugins/haier/77-mm-haier-port-types.rules | 3 +-
plugins/longcheer/77-mm-longcheer-port-types.rules | 170 +++---
plugins/mbm/77-mm-ericsson-mbm.rules | 37 ++--
plugins/mtk/77-mm-mtk-port-types.rul
---
plugins/mbm/77-mm-ericsson-mbm.rules | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/plugins/mbm/77-mm-ericsson-mbm.rules
b/plugins/mbm/77-mm-ericsson-mbm.rules
index 3dfed02..c195a86 100644
--- a/plugins/mbm/77-mm-ericsson-mbm.rules
+++ b
---
plugins/cinterion/77-mm-cinterion-port-types.rules | 1 +
1 file changed, 1 insertion(+)
diff --git a/plugins/cinterion/77-mm-cinterion-port-types.rules
b/plugins/cinterion/77-mm-cinterion-port-types.rules
index 9e5d5f5..7afe9c7 100644
--- a/plugins/cinterion/77-mm-cinterion-port-types.rules
---
plugins/huawei/77-mm-huawei-net-port-types.rules | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/plugins/huawei/77-mm-huawei-net-port-types.rules
b/plugins/huawei/77-mm-huawei-net-port-types.rules
index 52bcc80..12cb9f9 100644
--- a/plugins/huawei/77
---
plugins/x22x/77-mm-x22x-port-types.rules | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/plugins/x22x/77-mm-x22x-port-types.rules
b/plugins/x22x/77-mm-x22x-port-types.rules
index 6b5938f..1237028 100644
--- a/plugins/x22x/77-mm-x22x-port-types.rules
+++ b/plugins/x22x
---
plugins/nokia/77-mm-nokia-port-types.rules | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/plugins/nokia/77-mm-nokia-port-types.rules
b/plugins/nokia/77-mm-nokia-port-types.rules
index 4c5340f..e9b594f 100644
--- a/plugins/nokia/77-mm-nokia-port-types.rules
+++ b/pl
---
plugins/haier/77-mm-haier-port-types.rules | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/plugins/haier/77-mm-haier-port-types.rules
b/plugins/haier/77-mm-haier-port-types.rules
index 1a1ed80..41db317 100644
--- a/plugins/haier/77-mm-haier-port-types.rules
+++ b/pl
They're actually a subcase of SUBSYSTEM!="usb", which we apply just before.
---
src/77-mm-usb-device-blacklist.rules | 1 -
src/77-mm-usb-serial-adapters-greylist.rules | 1 -
2 files changed, 2 deletions(-)
diff --git a/src/77-mm-usb-device-blacklist.rules
b/src/77-mm-usb-device-blackli
Just the same kind of match we use for cdc-wdm devices.
---
src/80-mm-candidate.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/80-mm-candidate.rules b/src/80-mm-candidate.rules
index 52e6882..2f95e7d 100644
--- a/src/80-mm-candidate.rules
+++ b/src/80-mm-candidate.ru
---
plugins/longcheer/77-mm-longcheer-port-types.rules | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/plugins/longcheer/77-mm-longcheer-port-types.rules
b/plugins/longcheer/77-mm-longcheer-port-types.rules
index 9ad1493..895096b 100644
--- a/plugins/longcheer/77-mm-longc
The rules were matched only against devices with an exact 'tty' subsystem, and
that means that we were not properly adding additional tags on e.g. wwan or
cdc-wdm devices.
---
plugins/zte/77-mm-zte-port-types.rules | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/plugins
On Wed, Jul 27, 2016 at 10:29 PM, Nicolas Christener wrote:
> I saw some other mails regarding the same topic but was not able to find a
> solution for my problem. I got a Thinkpad T460s and run into problems with the
> built in Sierra Wireless EM7455.
>
> I built libmbim and libqmi from master an
---
plugins/telit/77-mm-telit-port-types.rules | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/plugins/telit/77-mm-telit-port-types.rules
b/plugins/telit/77-mm-telit-port-types.rules
index 398047c..695246c 100644
--- a/plugins/telit/77-mm-telit-port-types.rules
+++ b/p
---
plugins/simtech/77-mm-simtech-port-types.rules | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/plugins/simtech/77-mm-simtech-port-types.rules
b/plugins/simtech/77-mm-simtech-port-types.rules
index 9956b80..a13d2c1 100644
--- a/plugins/simtech/77-mm-simtech-port-ty
On Thu, Jul 28, 2016 at 5:38 PM, Dan Williams wrote:
> On Thu, 2016-07-28 at 00:14 +0200, Aleksander Morgado wrote:
>> The rules were matched only against devices with an exact 'tty'
>> subsystem, and
>> that means that we were not properly adding additional tag
On Thu, Jul 28, 2016 at 5:22 PM, Dan Williams wrote:
>> > They're actually a subcase of SUBSYSTEM!="usb", which we apply just
>> > before.
>> Actually I thought this was to ensure we match the entire USB device,
>> not just a usb_interface. Otherwise ID_MM_DEVICE_IGNORE=1 gets set
>> for
>> both
> What I think is happening (and Aleksander can correct me if not) is
> there can be some provisioning data that is downloaded from the
> operator to the SIM and/or device when it registers with the network.
> Maybe the modem was never in an idle state long enough to do that, or
> maybe Windows kn
On Thu, Jul 28, 2016 at 12:13 AM, Aleksander Morgado
wrote:
> ---
> plugins/cinterion/77-mm-cinterion-port-types.rules | 2 +-
> plugins/huawei/77-mm-huawei-net-port-types.rules | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
Pushed to git master.
> di
On Mon, Aug 1, 2016 at 6:50 PM, Aleksander Morgado
wrote:
> On Thu, Jul 28, 2016 at 5:22 PM, Dan Williams wrote:
>>> > They're actually a subcase of SUBSYSTEM!="usb", which we apply just
>>> > before.
>>> Actually I thought this was to en
On Thu, Jul 28, 2016 at 12:13 AM, Aleksander Morgado
wrote:
> ---
> plugins/cinterion/77-mm-cinterion-port-types.rules | 4 +-
> plugins/haier/77-mm-haier-port-types.rules | 3 +-
> plugins/longcheer/77-mm-longcheer-port-types.rules | 170 +++---
> plugins/mbm
On Thu, Jul 28, 2016 at 12:13 AM, Aleksander Morgado
wrote:
> ---
> plugins/x22x/77-mm-x22x-port-types.rules | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/x22x/77-mm-x22x-port-types.rules
> b/plugins/x2
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> ---
> plugins/cinterion/77-mm-cinterion-port-types.rules | 1 +
> 1 file changed, 1 insertion(+)
>
Pushed to git master.
> diff --git a/plugins/cinterion/77-mm-cinterion-port-types.rules
> b/plugins/cinterion/77
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> ---
> plugins/mbm/77-mm-ericsson-mbm.rules | 32
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/mbm/77-mm-ericsson-mbm.rules
> b
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> ---
> plugins/nokia/77-mm-nokia-port-types.rules | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/nokia/77-mm-nokia-port-types.rules
> b/plugins/noki
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> ---
> plugins/telit/77-mm-telit-port-types.rules | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/telit/77-mm-telit-port-types.rules
> b/plugins/teli
On Thu, Jul 28, 2016 at 12:13 AM, Aleksander Morgado
wrote:
> ---
> plugins/haier/77-mm-haier-port-types.rules | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/haier/77-mm-haier-port-types.rules
> b/plugins/haie
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> ---
> plugins/longcheer/77-mm-longcheer-port-types.rules | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/longcheer/77-mm-longcheer-port-types.rules
> b
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> ---
> plugins/huawei/77-mm-huawei-net-port-types.rules | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/huawei/77-mm-huawei-net-port-t
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> ---
> plugins/simtech/77-mm-simtech-port-types.rules | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
Pushed to git master.
> diff --git a/plugins/simtech/77-mm-simtech-port-types.rules
> b/plu
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> The rules were matched only against devices with an exact 'tty' subsystem, and
> that means that we were not properly adding additional tags on e.g. wwan or
> cdc-wdm devices.
> ---
> plugins/zte/77-mm
On Thu, Jul 28, 2016 at 12:14 AM, Aleksander Morgado
wrote:
> Just the same kind of match we use for cdc-wdm devices.
> ---
> src/80-mm-candidate.rules | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Pushed to git master.
> diff --git a/src/80-mm-candidate
This makes the huawei logic work also when udev support isn't built, as we can
rely on the MMKernelDevice, regardless of how it was built.
---
plugins/huawei/mm-broadband-modem-huawei.c | 48 --
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/plugins/hua
The kernel event reporting logic will use the udev-backend of MMKernelDevice if
the build is compiled with udev support.
---
src/kerneldevice/mm-kernel-device-udev.c | 249 +++
src/kerneldevice/mm-kernel-device-udev.h | 9 +-
src/mm-base-manager.c|
In order to cope with devices already available in the system when the daemon
starts, we allow loading a list of kernel events from an input text file where
the kernel events were recorded since boot.
The file will contain one line per event, e.g.:
action=add, name=wwan0,subsystem=net
acti
Hey everyone,
This series of patches introduces support to avoid requiring udev in
ModemManager. The main use case is being able to use ModemManager under
OpenWRT: assuming it is built with DBus and GLib/GIO, a simple set of hotplug
scripts may be used in this case to report the kernel events t
And we store it in the MMPort. We also avoid storing the parent path in the
MMPort, as we can already retrieve it via the MMKernelDevice.
---
plugins/cinterion/mm-plugin-cinterion.c| 4 +--
plugins/dell/mm-plugin-dell.c | 4 +--
plugins/haier/mm-plugin-haier.c| 4 +-
All ports of the same modem reported by the kernel will all be associated with
a common 'uid' (unique id), which uniquely identifies the physical device.
This logic was already in place, what we do now is avoid calling it the 'sysfs
path' of the physical device, because we may not want to use that
The implementation allows different parameters being reported in the kernel
event, but only 3 of them are mandatory: 'action', 'name' and 'subsystem'. Once
these three parameters are received, ModemManager will load the remaining kernel
device information directly from sysfs.
E.g.:
$ sudo mmcl
@@
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
- * Copyright (C) 2011 Aleksander Morgado
* Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2011-2016 Aleksander Morgado
*/
#i
-}
-
-#endif
-
/*/
/* Test profile setup */
diff --git a/src/mm-context.c b/src/mm-context.c
index df8d07c..b6af1a3 100644
--- a/src/mm-context.c
+++ b/src/mm-context.c
@@ -13,6 +13,7 @@
* Copyright (C) 2012 Aleks
e-udev.c \
$(NULL)
+endif
############
# ModemManager daemon
diff --git a/src/mm-base-manager.c b/src/mm-base-manager.c
index 9da3896..85f66a8 100644
--- a/src/mm-base-manager.c
+++ b/src/mm-base-manager.c
@@ -1
On Mon, Aug 8, 2016 at 3:47 PM, Carlo Lobrano wrote:
> BaseModem
> added reprobe property.
>
> MMDevice
> added logic to recreate the modem if it is set invalid and "to reprobe"
>
> MMBroadbandModem
> * added initialization step for SIM hot swap:
> 1. keep dedicated ports open to listen t
On Mon, Aug 8, 2016 at 3:47 PM, Carlo Lobrano wrote:
> MMBroadbandModemTelit:
> * added logic to set MMBroadbandModem's SIM_HOT_SWAP property to TRUE
> * added function to enable QSS unsolicited
> * added QSS unsolicited handler
> ---
Pushed to git master, thanks!
> plugins/telit/mm-broadban
>
> Thanks Aleksander.
>
> I updated the modem-manager, but still run into problems.
>
> One query, the modem product-code is 1199:68A3, meaning that it is in
> DirectIP mode.
> Do modem-managers support DirectIP-mode modems at all? Or will I have
> to get the OEM-password and unlock its QMI-mode t
>
> Am 04.08.2016 um 17:13 schrieb Nicolas Christener:
> > tl;dr: the WWAN card works now! It might to be related to the SIM PIN.
>
> A now version of the linux kernel has been released for Arch linux. So
with
>
> Name : libmbim
> Version : 1.14.0-1
>
> Name
On 14/08/16 14:25, Ajay Garg wrote:
> qmi-proxy started automatically now on reboot, seems
> the process is initiated if there is at least one /dev/cdc-wdm..
> interface.
No. qmi-proxy is never anywhere configured to start on boot; it's not a
"system daemon".
qmi-proxy is started by libqmi if the
On 13/08/16 03:24, Ajay Garg wrote:
> First of all, my requirement is to have network-connectivity via the
> modem; and have the ability to read SMSes and run AT-commands WITHOUT
> losing the network-connectivity.
>
> I guess mmcli would do the trick, as modem-manager now comes plugged
> in with q
On 13/08/16 20:07, Neil Cherry wrote:
> Yup, and I know very little about the wireless modems. From my setup
> I see some errors in the ModemManager logs but I'm not far enough
> along to figure out if they can be ignored or not. Let me not steal
> this thread.
Just post those warnings/errors in s
On 13/08/16 19:57, Thomas Schäfer wrote:
>> * wwan network-interface will be created by one or more of
>> > qcserial/qmi_wwan
>> > * qcserial/qmi_wwan are definitely required for function of
>> > wwan-interface.
> yes.
qcserial isn't really required if you're running in QMI mode; qmi_w
> So, the story so far ::
>
>
> a)
> As soon as a QMI-modem is plugged in, the kernel presents the
> following two interfaces AUTOMATICALLY ::
>
> * /dev/cdc-... QMI-port interface
> * a wwan-interface
>
> Kernel takes the help of udev/qcserial/qmi_wwan for the above, and
> e
On 15/08/16 03:01, Neil Cherry wrote:
> Okay this was interesting ... I can now reach the modem (Netgear 341u)
> from my server (and browser). But I can't seem to ping anything via
> the wwan0 (other than the we server's address). So some more work.
>
What do you mean you can reach the modem thro
On Mon, Aug 15, 2016 at 12:51 PM, Ajay Garg wrote:
> Thanks Aleksander for the reply.
>
> A small query, if a modem supports both DirectIP and QMI, which is the
> recommended mode?
>
If I'm not mistaken, Sierra Wireless is suggesting to use QMI or MBIM,
they are obsoleting Direct IP.
> AT-comman
On Mon, Aug 15, 2016 at 3:43 PM, Ajay Garg wrote:
> Let's say modem-id is 0.
> So, in the output of "mmcli -m 0", we get an output for signal quality in
> the form ::
>
> signal quality: '71' (recent)
>
>
> What is this value?
> Is this related to the value returned by "AT+CSQ" in
On Mon, Aug 15, 2016 at 3:52 PM, Ajay Garg wrote:
> I have a modem in QMI-mode, and through your help, I have been able to get
> it up and running.
>
>
> Now, my architecture is such ::
>
> *
> There is a python-script, which monitors the health of "wwan0" interface.
>
> *
> There is an applicatio
On Tue, Aug 16, 2016 at 9:29 AM, Ajay Garg wrote:
> c)
> Let the kernel use qcserial/qmi_wwan/qmi-proxy to load /dev/cdc-wdm...
> interface, to set up communication in manner ::
>
> Any-User-App <=> ModemManager <=> qmi-proxy <=> /dev/cdc-wdm ..
> <=> modem
>
401 - 500 of 1794 matches
Mail list logo
