Could not find "pppd" binary

2016-03-14 Thread Ali Nematollahi
Hi guys

I finally got MM 1.4.12 and 1.0.10 working and talking to each
other...after a long battle.
I got NM to a point that it detects MM and after all MM set up is done, it
tries to bring up the connection I have up but it fails saying pppd binary
not found. I compiled the NM with the option --with-pppd= but it still says
that.

Any idea why? Should I switch to PPP service provided by NM? Is it stable
and ready to use in a production environment? How do I make the switch?

Thanks!
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread Aleksander Morgado
On Mon, Mar 14, 2016 at 2:55 PM, matti kaasinen
 wrote:
> In fact there are two more messages preceding those ones I mentioned before,
> but I guess they have nothing to do with this problem. I'll get following
> messages, if I have MM running from boot:
>
> src/nm-udev-manager.c:568] handle_uevent(): UDEV event: action 'add' subsys
> 'net' device 'wwan0'
> src/nm-udev-manager.c:477] net_add(): (wwan0): ignoring interface with
> devtype 'wwan'
> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
> (re)launch modem-manager...
> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
> (re)launch modem-manager...
> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
> (re)launch modem-manager...

That is trying to launch the old ModemManager, which has a different bus name.

You need to configure NetworkManager explicitly with
"--with-modem-manager-1", or explicitly add ModemManager libraries as
build dependency on your yocto recipe, so that the requirement of
"--with-modem-manager-1" is detected automatically.

-- 
Aleksander
https://aleksander.es
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: NetworkManager 1.1.90 : nm-exported-object.c:293:nm_exported_object_class_add_interface: assertion failed: (object_property != NULL)

2016-03-14 Thread Dan Williams
On Mon, 2016-03-14 at 10:51 -0700, Ali Nematollahi wrote:
> Hello Dan
> Ok, some progress
> One of my colleagues suggested sending an "AT" at the same time as
> "AT^SCFG": AT^SCFG\r\AT"...So I changed the plugin that sends SCFG
> and it
> actually worked. The modem responds to SCFG immediately and MM sees
> the
> response.
> It still asks for AT+CGDCONT=? and the modem responds but the result
> is
> still IP = none:

Yeah, ModemManager chokes on the split PDP context IDs.  Does this
patch give you the right response for supported IP methods?

--- a/src/mm-modem-helpers.c
+++ b/src/mm-modem-helpers.c
@@ -876,7 +876,7 @@ mm_3gpp_parse_cgdcont_test_response (const gchar *response,
 return NULL;
 }
 
-r = g_regex_new 
("\\+CGDCONT:\\s*\\(\\s*(\\d+)\\s*-?\\s*(\\d+)?\\s*\\)\\s*,\\s*\\(?\"(\\S+)\"",
+r = g_regex_new 
("\\+CGDCONT:\\s*\\(\\s*(\\d+)\\s*-?\\s*(\\d+)?[^\\)]*\\)\\s*,\\s*\\(?\"(\\S+)\"",
  G_REGEX_DOLLAR_ENDONLY | G_REGEX_RAW,
  0, _error);
 g_assert (r != NULL);

Dan

> 
> broadband-modem.c:951] modem_load_device_identifier_finish(): loaded
> device
> identifier: 1d1cf54b58614b08fcc472e0fee0860904397d92
> ModemManager[2805]:  [1457951710.659410] [mm-broadband-
> modem.c:1601]
> modem_load_supported_modes(): loading supported modes...
> ModemManager[2805]:  [1457951710.660119] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2805]:  [1457951710.660878] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2805]:  [1457951710.661516] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT*CNTI=2'
> ModemManager[2805]:  [1457951710.684448] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- 'ERROR'
> ModemManager[2805]:  [1457951710.685881] [mm-serial-
> parsers.c:364]
> mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
> ModemManager[2805]:  [1457951710.686652] [mm-broadband-
> modem.c:1535]
> supported_modes_cnti_ready(): Generic query of supported 3GPP
> networks with
> *CNTI failed: 'Unknown error'
> ModemManager[2805]:  [1457951710.687360] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2805]:  [1457951710.688027] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2805]:   [1457951710.689190] [mm-port-
> serial.c:811]
> port_serial_queue_process(): (ttyUSB2) response array is not empty
> when
> using cached reply, cleaning up 5 bytes
> ModemManager[2805]:  [1457951710.689928] [mm-broadband-
> modem.c:1438]
> supported_modes_ws46_test_ready(): Device allows (3GPP) 2G-only
> network mode
> ModemManager[2805]:  [1457951710.690440] [mm-broadband-
> modem.c:1443]
> supported_modes_ws46_test_ready(): Device allows (3GPP) 3G-only
> network mode
> ModemManager[2805]:  [1457951710.691255] [mm-broadband-
> modem.c:1472]
> supported_modes_ws46_test_ready(): Device allows every supported 3GPP
> network mode (2G/3G)
> ModemManager[2805]:  [1457951711.027536] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2805]:  [1457951711.028543] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2805]:  [1457951711.029459] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT^SCFG=?AT'
> ModemManager[2805]:  [1457951711.089542] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- '^SCFG:
> "Audio/Loop",("0","1")^SCFG: "Call/ECC",("0"-
> "255")^SCFG:
> "Call/Speech/Codec",("0","1")^SCFG:
> "GPRS/Auth",("0","1","2")^SCFG:
> "GPRS/AutoAttach",("disabled","enabled")^SCFG:
> "GPRS/MaxDataRate/HSDPA",("0","1")^SCFG:
> "GPRS/MaxDataRate/HSUPA",("0","1")^SCFG:
> "Ident/Manufacturer",(25)^SCFG:
> "Ident/Product",(25)^SCFG:
> "MEopMode/Airplane",("off","on")^SCFG:
> "MEopMode/CregRoam",("0","1")^SCFG:
> "MEopMode/CFUN",("0","1")^SCFG:
> "MEopMode/PowerMgmt/LCI",("disabled","enabled")^SCFG:
> "MEopMode/PowerMgmt/VExt",("high","low")^SCFG:
> "MEopMode/PwrSave",("disabled","enabled"),("0-600"),("1-
> 36000")^SCFG:
> "MEopMode/RingOnData",("on","off")^SCFG:
> "MEopMode/RingUrcOnCall",("on","off")^SCFG:
> "MEShutdown/OnIgnition",("on","off")^SCFG:
> "Radio/Band",("4-108","0-1")^SCFG:
> "Radio/Mtpl",("0-3","1-8","4-108","18-33","18-27")^SCFG:
> "Radio/NWSM",("0","1","2")^SCFG:
> "Radio/OutputPowerReduction",("4"-"8")^SCFG:
> "Serial/USB/DDD",("0","1"),("0"),(4),(4),(4),(63),(63),(4)^SC
> FG:
> "Serial/USB/DeviceClass/RmNet",("Vendor","CDC-ECM")^SCFG:
> "URC/DstIfc",("mdm","app")^SCFG:
> "URC/Datamode/Ringline",("off","on")^SCFG:
> "URC/Ringline",("off","local","asc0","wakeup")^SCFG:
> "URC/Ringline/ActiveTime",("0","1","2","keep")OK<
> LF>OK'
> ModemManager[2805]:  [1457951711.092246] [mm-broadband-
> modem.c:1675]
> modem_load_supported_ip_families(): loading supported IP families...
> 

Re: nmcli c does not list modem device

2016-03-14 Thread matti kaasinen
Yes, mmcli seems workin quite nicely - no problems at all.


2016-03-14 16:27 GMT+02:00 Dan Williams :

> On Mon, 2016-03-14 at 15:55 +0200, matti kaasinen wrote:
> > In fact there are two more messages preceding those ones I mentioned
> > before, but I guess they have nothing to do with this problem. I'll
> > get
> > following messages, if I have MM running from boot:
> >
> > src/nm-udev-manager.c:568] handle_uevent(): UDEV event: action 'add'
> > subsys
> > 'net' device 'wwan0'
> > src/nm-udev-manager.c:477] net_add(): (wwan0): ignoring interface
> > with
> > devtype 'wwan'
> > src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting
> > to
> > (re)launch modem-manager...
> > src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting
> > to
> > (re)launch modem-manager...
> > src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting
> > to
> > (re)launch modem-manager...
> >
>
> This means that NetworkManager cannot see ModemManager on D-Bus.  Does
> 'mmcli -L' produce any output?
>
> Dan
>
>
> > 
> > -Matti
> >
> >
> > 2016-03-14 15:39 GMT+02:00 matti kaasinen :
> >
> > >
> > > There was also other one besides these (re)launch messages. The
> > > first
> > > message was:
> > > modem_manager_disappeared(): trying to start the modem manager...
> > >
> > > then repeating gradually:
> > > Requesting to (re)launch modem-manager...
> > >
> > > 2016-03-14 15:35 GMT+02:00 matti kaasinen  > > >:
> > >
> > > >
> > > > I tried it now: NM can't communicate with MM. There is only one
> > > > type of
> > > > message related to modem-manager:
> > > > src/modem-manager/nm-modem-manager.c:280] poke_modem_cb():
> > > > Requesting to
> > > > (re)launch modem-manager...
> > > >
> > > > -Matti
> > > >
> > > > 2016-03-14 15:01 GMT+02:00 Aleksander Morgado  > > > der.es>:
> > > >
> > > > >
> > > > > On Mon, Mar 14, 2016 at 1:57 PM, matti kaasinen
> > > > >  wrote:
> > > > > >
> > > > > > 2016-03-14 14:53 GMT+02:00 Thomas Haller 
> > > > > > :
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > I can't get modem device listed with
> > > > > > > > nmcli c
> > > > > > > do you mean `nmcli d` (for [d]evice)?
> > > > > >
> > > > > >
> > > > > > Yes, indeed.
> > > > > > BTW, I just monitored dbus traffic (dbus-monitor --system)
> > > > > > and it
> > > > > seems that
> > > > > >
> > > > > > all the information received by mmcli is seen from this
> > > > > > monitorin
> > > > > session.
> > > > >
> > > > >
> > > > > Did you try to run NetworkManager with debug logging? IIRC, the
> > > > > modem
> > > > > management code in NM does print several debug logs when
> > > > > watching MM
> > > > > in the bus.
> > > > >
> > > > > --
> > > > > Aleksander
> > > > > https://aleksander.es
> > > > >
> > > >
> > ___
> > networkmanager-list mailing list
> > networkmanager-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli radio off connected to ModemManager power state low

2016-03-14 Thread Carlo Lobrano
> I'm not entirely sure what you mean with "power off" and "shut down the
> radio", but here are the definitions I'm using:
> power off: the entire modem is powered off not just the radio.  The
> device does not communicate with the host because it is unpowered.
>
> radio off: the radio is powered down and no network communication is
> possible, but the modem can still communicate with the host.

clear, the same as mine.

So, saying that my targets are ModemManager Telit plugin's modem_power_down
and modem_power_off functions, we have:

* modem_power_off (which is not implemented) == power off.
  Ideally, CFUN=0 would be the candidate, but it would make the modem
unrecoverable, so CFUN=4 would be my choice, which is OK, if I understood
correcly.

* modem_power_down is currently implemented with CFUN=4 so == radio off.
  However, considering that it is activated with "mmcli -m 
--set-power-low", it looks to me as a function that puts the modem in a
"power saving state", for which Telit's CFUN=5 would be more appropriate.
  The problem is that if I change modem_power_down to CFUN=5, when I use
"nmcli radio off" ModemManager will send CFUN=5, which is not a "radio off"
state.
  So, the question is, "mmcli -i  --state-power-low" is to be
considered like "go to power save" or "radio off"?


> The ModemManager API specification would not allow CFUN=5 for the
> "disabled" state, since it defines the disabled state as not allowing
> network communication.  So I would still use CFUN=4 for "disabled"
> state.

But, if I got it right, I can't override mm_modem_disable for a plugin,
right? When I disable the modem (mmcli -m ID --disable) no AT+CFUN command
is sent to the modem.

> But couldn't the modem instead be set to CFUN=5 whenever it is
> enabled?  The Telit docs seem to say it's a fully functional state,
> just that the modem can do some power saving.  Which sounds like a win
> without a downside.

I guess that moving in and out from a power saving state would cost some
time (and maybe overhead?) respect CFUN=1 which should be more responsive.
Moreover, I would expect to get into a power saving state issuing
--set-power-low more that with --set-power-on.

Carlo

On 14 March 2016 at 16:01, Dan Williams  wrote:

> On Mon, 2016-03-14 at 09:40 -0500, Dan Williams wrote:
> > On Sun, 2016-03-13 at 18:23 +0100, c.lobr...@gmail.com wrote:
> > >
> > > I'm sorry, I think I explained myself wrong.
> > >
> > > CFUN=4 is ok for radio off, I wanted to say that some plugins might
> > > not
> > > use CFUN=4 for "power low".
> > > In Telit modem, as example, I might use CFUN=5 "mobile full
> > > functionality with power saving enabled" and CFUN=4 for power off,
> > > but
> > > doing so "nmcli radio off" won't shut down the radio (without
> > > rfkill).
> > I'm not entirely sure what you mean with "power off" and "shut down
> > the
> > radio", but here are the definitions I'm using:
> >
> > power off: the entire modem is powered off not just the radio.  The
> > device does not communicate with the host because it is unpowered.
> >
> > radio off: the radio is powered down and no network communication is
> > possible, but the modem can still communicate with the host.
> >
> > The ModemManager API specification would not allow CFUN=5 for the
> > "disabled" state, since it defines the disabled state as not allowing
> > network communication.  So I would still use CFUN=4 for "disabled"
> > state.  But couldn't the modem instead be set to CFUN=5 whenever it
> > is
> > enabled?  The Telit docs seem to say it's a fully functional state,
> > just that the modem can do some power saving.  Which sounds like a
> > win
> > without a downside.
>
> Reading further, if CFUN=5 gets used then the telit plugin would need
> some special handling of DTR and CTS it seems.  So it won't be trivial,
> but probably worthwhile anyway.  We'd probably need some MMPortSerialAt
> support to handle the DTR drop and then wait-for-CTS on DTR on, but
> that's OK.
>
> Dan
>
> > Dan
> >
> > >
> > > Carlo
> > >
> > > On dom, mar 13, 2016 at 5:47 , Aleksander Morgado
> > >  wrote:
> > > >
> > > >
> > > > On Sun, Mar 13, 2016 at 1:56 PM, Carlo Lobrano  > > > om
> > > > >
> > > > >
> > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >  The problem is that if the modem is totally powered off with
> > > > > > a
> > > > > > CFUN=0,
> > > > > >
> > > > >  then how do we power it back on? CFUN=4, where the modem is
> > > > > still
> > > > >
> > > > >  alive but with radio off is already more than enough in most
> > > > > cases.
> > > > > >
> > > > > >
> > > > > >  Why do you need the modem to be totally off?
> > > > >  In power low I could expect that the modem goes in some kind
> > > > > of
> > > > > power saving
> > > > >  configuration but still connected to the network, it really
> > > > > depends
> > > > > on the
> > > > >  modem capabilities, and when rfkill is not available, the
> > > > 

Re: nmcli radio off connected to ModemManager power state low

2016-03-14 Thread Dan Williams
On Mon, 2016-03-14 at 09:40 -0500, Dan Williams wrote:
> On Sun, 2016-03-13 at 18:23 +0100, c.lobr...@gmail.com wrote:
> > 
> > I'm sorry, I think I explained myself wrong.
> > 
> > CFUN=4 is ok for radio off, I wanted to say that some plugins might
> > not 
> > use CFUN=4 for "power low".
> > In Telit modem, as example, I might use CFUN=5 "mobile full 
> > functionality with power saving enabled" and CFUN=4 for power off,
> > but 
> > doing so "nmcli radio off" won't shut down the radio (without
> > rfkill).
> I'm not entirely sure what you mean with "power off" and "shut down
> the
> radio", but here are the definitions I'm using:
> 
> power off: the entire modem is powered off not just the radio.  The
> device does not communicate with the host because it is unpowered.
> 
> radio off: the radio is powered down and no network communication is
> possible, but the modem can still communicate with the host.
> 
> The ModemManager API specification would not allow CFUN=5 for the
> "disabled" state, since it defines the disabled state as not allowing
> network communication.  So I would still use CFUN=4 for "disabled"
> state.  But couldn't the modem instead be set to CFUN=5 whenever it
> is
> enabled?  The Telit docs seem to say it's a fully functional state,
> just that the modem can do some power saving.  Which sounds like a
> win
> without a downside.

Reading further, if CFUN=5 gets used then the telit plugin would need
some special handling of DTR and CTS it seems.  So it won't be trivial,
but probably worthwhile anyway.  We'd probably need some MMPortSerialAt
support to handle the DTR drop and then wait-for-CTS on DTR on, but
that's OK.

Dan

> Dan
> 
> > 
> > Carlo
> > 
> > On dom, mar 13, 2016 at 5:47 , Aleksander Morgado 
> >  wrote:
> > > 
> > > 
> > > On Sun, Mar 13, 2016 at 1:56 PM, Carlo Lobrano  > > om
> > > > 
> > > >  
> > > wrote:
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > >  The problem is that if the modem is totally powered off with
> > > > > a 
> > > > > CFUN=0,
> > > > > 
> > > >  then how do we power it back on? CFUN=4, where the modem is
> > > > still
> > > > 
> > > >  alive but with radio off is already more than enough in most
> > > > cases.
> > > > > 
> > > > > 
> > > > >  Why do you need the modem to be totally off?
> > > >  In power low I could expect that the modem goes in some kind
> > > > of 
> > > > power saving
> > > >  configuration but still connected to the network, it really
> > > > depends 
> > > > on the
> > > >  modem capabilities, and when rfkill is not available, the
> > > > modem
> > > > is 
> > > > only set
> > > >  in power low, which may not be the same as radio off.
> > > > 
> > > >  I totally understand the problem though, modems that use
> > > > CFUN=0
> > > > to 
> > > > power off
> > > >  are not listening to any command to put them ON again.
> > > > 
> > > >  I will look better to rfkill, but I still see a possible 
> > > > misunderstanding
> > > >  between power low intended as radio off and power low intended
> > > > as 
> > > > power
> > > >  saving.
> > > Is there any case in which CFUN=4 doesn't mean radio off? Maybe
> > > we 
> > > got it wrong.
> > > 
> > > --
> > > Aleksander
> > > https://aleksander.es
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli radio off connected to ModemManager power state low

2016-03-14 Thread Dan Williams
On Sun, 2016-03-13 at 18:23 +0100, c.lobr...@gmail.com wrote:
> I'm sorry, I think I explained myself wrong.
> 
> CFUN=4 is ok for radio off, I wanted to say that some plugins might
> not 
> use CFUN=4 for "power low".
> In Telit modem, as example, I might use CFUN=5 "mobile full 
> functionality with power saving enabled" and CFUN=4 for power off,
> but 
> doing so "nmcli radio off" won't shut down the radio (without
> rfkill).

I'm not entirely sure what you mean with "power off" and "shut down the
radio", but here are the definitions I'm using:

power off: the entire modem is powered off not just the radio.  The
device does not communicate with the host because it is unpowered.

radio off: the radio is powered down and no network communication is
possible, but the modem can still communicate with the host.

The ModemManager API specification would not allow CFUN=5 for the
"disabled" state, since it defines the disabled state as not allowing
network communication.  So I would still use CFUN=4 for "disabled"
state.  But couldn't the modem instead be set to CFUN=5 whenever it is
enabled?  The Telit docs seem to say it's a fully functional state,
just that the modem can do some power saving.  Which sounds like a win
without a downside.

Dan

> Carlo
> 
> On dom, mar 13, 2016 at 5:47 , Aleksander Morgado 
>  wrote:
> > 
> > On Sun, Mar 13, 2016 at 1:56 PM, Carlo Lobrano  > > 
> > wrote:
> > > 
> > > > 
> > > >  The problem is that if the modem is totally powered off with
> > > > a 
> > > > CFUN=0,
> > > > 
> > >  then how do we power it back on? CFUN=4, where the modem is
> > > still
> > > 
> > >  alive but with radio off is already more than enough in most
> > > cases.
> > > > 
> > > >  Why do you need the modem to be totally off?
> > >  In power low I could expect that the modem goes in some kind of 
> > > power saving
> > >  configuration but still connected to the network, it really
> > > depends 
> > > on the
> > >  modem capabilities, and when rfkill is not available, the modem
> > > is 
> > > only set
> > >  in power low, which may not be the same as radio off.
> > > 
> > >  I totally understand the problem though, modems that use CFUN=0
> > > to 
> > > power off
> > >  are not listening to any command to put them ON again.
> > > 
> > >  I will look better to rfkill, but I still see a possible 
> > > misunderstanding
> > >  between power low intended as radio off and power low intended
> > > as 
> > > power
> > >  saving.
> > Is there any case in which CFUN=4 doesn't mean radio off? Maybe we 
> > got it wrong.
> > 
> > --
> > Aleksander
> > https://aleksander.es
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli radio off connected to ModemManager power state low

2016-03-14 Thread Dan Williams
On Sun, 2016-03-13 at 12:26 +0100, Aleksander Morgado wrote:
> On Sun, Mar 13, 2016 at 10:28 AM, Carlo Lobrano 
> wrote:
> > 
> > 
> > thank you, it is more clear now. I will check in my system for
> > rfkill.
> > One more question, do you think it will be feasible for NM to check
> > whether
> > rfkill is available and, if not, to set the modem in power off in
> > place of
> > just disabling it?
> The problem is that if the modem is totally powered off with a
> CFUN=0,
> then how do we power it back on? CFUN=4, where the modem is still
> alive but with radio off is already more than enough in most cases.
> Why do you need the modem to be totally off?

I tested that with a bunch of USB modems, and only a small number (2
out of 20 I tried) actually powered completely off with CFUN=0.  The
rest apparently just disable the radio but remain responsive.

Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread Dan Williams
On Mon, 2016-03-14 at 15:55 +0200, matti kaasinen wrote:
> In fact there are two more messages preceding those ones I mentioned
> before, but I guess they have nothing to do with this problem. I'll
> get
> following messages, if I have MM running from boot:
> 
> src/nm-udev-manager.c:568] handle_uevent(): UDEV event: action 'add'
> subsys
> 'net' device 'wwan0'
> src/nm-udev-manager.c:477] net_add(): (wwan0): ignoring interface
> with
> devtype 'wwan'
> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting
> to
> (re)launch modem-manager...
> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting
> to
> (re)launch modem-manager...
> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting
> to
> (re)launch modem-manager...
> 

This means that NetworkManager cannot see ModemManager on D-Bus.  Does
'mmcli -L' produce any output?

Dan


> 
> -Matti
> 
> 
> 2016-03-14 15:39 GMT+02:00 matti kaasinen :
> 
> > 
> > There was also other one besides these (re)launch messages. The
> > first
> > message was:
> > modem_manager_disappeared(): trying to start the modem manager...
> > 
> > then repeating gradually:
> > Requesting to (re)launch modem-manager...
> > 
> > 2016-03-14 15:35 GMT+02:00 matti kaasinen  > >:
> > 
> > > 
> > > I tried it now: NM can't communicate with MM. There is only one
> > > type of
> > > message related to modem-manager:
> > > src/modem-manager/nm-modem-manager.c:280] poke_modem_cb():
> > > Requesting to
> > > (re)launch modem-manager...
> > > 
> > > -Matti
> > > 
> > > 2016-03-14 15:01 GMT+02:00 Aleksander Morgado  > > der.es>:
> > > 
> > > > 
> > > > On Mon, Mar 14, 2016 at 1:57 PM, matti kaasinen
> > > >  wrote:
> > > > > 
> > > > > 2016-03-14 14:53 GMT+02:00 Thomas Haller 
> > > > > :
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > I can't get modem device listed with
> > > > > > > nmcli c
> > > > > > do you mean `nmcli d` (for [d]evice)?
> > > > > 
> > > > > 
> > > > > Yes, indeed.
> > > > > BTW, I just monitored dbus traffic (dbus-monitor --system)
> > > > > and it
> > > > seems that
> > > > > 
> > > > > all the information received by mmcli is seen from this
> > > > > monitorin
> > > > session.
> > > > 
> > > > 
> > > > Did you try to run NetworkManager with debug logging? IIRC, the
> > > > modem
> > > > management code in NM does print several debug logs when
> > > > watching MM
> > > > in the bus.
> > > > 
> > > > --
> > > > Aleksander
> > > > https://aleksander.es
> > > > 
> > > 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread matti kaasinen
In fact there are two more messages preceding those ones I mentioned
before, but I guess they have nothing to do with this problem. I'll get
following messages, if I have MM running from boot:

src/nm-udev-manager.c:568] handle_uevent(): UDEV event: action 'add' subsys
'net' device 'wwan0'
src/nm-udev-manager.c:477] net_add(): (wwan0): ignoring interface with
devtype 'wwan'
src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
(re)launch modem-manager...
src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
(re)launch modem-manager...
src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
(re)launch modem-manager...

-Matti


2016-03-14 15:39 GMT+02:00 matti kaasinen :

> There was also other one besides these (re)launch messages. The first
> message was:
> modem_manager_disappeared(): trying to start the modem manager...
>
> then repeating gradually:
> Requesting to (re)launch modem-manager...
>
> 2016-03-14 15:35 GMT+02:00 matti kaasinen :
>
>> I tried it now: NM can't communicate with MM. There is only one type of
>> message related to modem-manager:
>> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
>> (re)launch modem-manager...
>>
>> -Matti
>>
>> 2016-03-14 15:01 GMT+02:00 Aleksander Morgado :
>>
>>> On Mon, Mar 14, 2016 at 1:57 PM, matti kaasinen
>>>  wrote:
>>> > 2016-03-14 14:53 GMT+02:00 Thomas Haller :
>>> >>
>>> >> > I can't get modem device listed with
>>> >> > nmcli c
>>> >>
>>> >> do you mean `nmcli d` (for [d]evice)?
>>> >
>>> >
>>> >
>>> > Yes, indeed.
>>> > BTW, I just monitored dbus traffic (dbus-monitor --system) and it
>>> seems that
>>> > all the information received by mmcli is seen from this monitorin
>>> session.
>>>
>>>
>>> Did you try to run NetworkManager with debug logging? IIRC, the modem
>>> management code in NM does print several debug logs when watching MM
>>> in the bus.
>>>
>>> --
>>> Aleksander
>>> https://aleksander.es
>>>
>>
>>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread matti kaasinen
There was also other one besides these (re)launch messages. The first
message was:
modem_manager_disappeared(): trying to start the modem manager...

then repeating gradually:
Requesting to (re)launch modem-manager...

2016-03-14 15:35 GMT+02:00 matti kaasinen :

> I tried it now: NM can't communicate with MM. There is only one type of
> message related to modem-manager:
> src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
> (re)launch modem-manager...
>
> -Matti
>
> 2016-03-14 15:01 GMT+02:00 Aleksander Morgado :
>
>> On Mon, Mar 14, 2016 at 1:57 PM, matti kaasinen
>>  wrote:
>> > 2016-03-14 14:53 GMT+02:00 Thomas Haller :
>> >>
>> >> > I can't get modem device listed with
>> >> > nmcli c
>> >>
>> >> do you mean `nmcli d` (for [d]evice)?
>> >
>> >
>> >
>> > Yes, indeed.
>> > BTW, I just monitored dbus traffic (dbus-monitor --system) and it seems
>> that
>> > all the information received by mmcli is seen from this monitorin
>> session.
>>
>>
>> Did you try to run NetworkManager with debug logging? IIRC, the modem
>> management code in NM does print several debug logs when watching MM
>> in the bus.
>>
>> --
>> Aleksander
>> https://aleksander.es
>>
>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread matti kaasinen
I tried it now: NM can't communicate with MM. There is only one type of
message related to modem-manager:
src/modem-manager/nm-modem-manager.c:280] poke_modem_cb(): Requesting to
(re)launch modem-manager...

-Matti

2016-03-14 15:01 GMT+02:00 Aleksander Morgado :

> On Mon, Mar 14, 2016 at 1:57 PM, matti kaasinen
>  wrote:
> > 2016-03-14 14:53 GMT+02:00 Thomas Haller :
> >>
> >> > I can't get modem device listed with
> >> > nmcli c
> >>
> >> do you mean `nmcli d` (for [d]evice)?
> >
> >
> >
> > Yes, indeed.
> > BTW, I just monitored dbus traffic (dbus-monitor --system) and it seems
> that
> > all the information received by mmcli is seen from this monitorin
> session.
>
>
> Did you try to run NetworkManager with debug logging? IIRC, the modem
> management code in NM does print several debug logs when watching MM
> in the bus.
>
> --
> Aleksander
> https://aleksander.es
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread Aleksander Morgado
On Mon, Mar 14, 2016 at 1:57 PM, matti kaasinen
 wrote:
> 2016-03-14 14:53 GMT+02:00 Thomas Haller :
>>
>> > I can't get modem device listed with
>> > nmcli c
>>
>> do you mean `nmcli d` (for [d]evice)?
>
>
>
> Yes, indeed.
> BTW, I just monitored dbus traffic (dbus-monitor --system) and it seems that
> all the information received by mmcli is seen from this monitorin session.


Did you try to run NetworkManager with debug logging? IIRC, the modem
management code in NM does print several debug logs when watching MM
in the bus.

-- 
Aleksander
https://aleksander.es
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread matti kaasinen
2016-03-14 14:53 GMT+02:00 Thomas Haller :

> > I can't get modem device listed with
> > nmcli c
>
> do you mean `nmcli d` (for [d]evice)?
>


Yes, indeed.
BTW, I just monitored dbus traffic (dbus-monitor --system) and it seems
that all the information received by mmcli is seen from this monitorin
session.

-Matti
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: nmcli c does not list modem device

2016-03-14 Thread Thomas Haller
On Mon, 2016-03-14 at 13:48 +0200, matti kaasinen wrote:
> Hi!
> 
> I can't get modem device listed with 
> nmcli c

do you mean `nmcli d` (for [d]evice)?


> command. So, NM does not see it and therefore it can't start
> connection with NM.
> Last week it worked fine. I wrote python code for bringing gathering
> up data from from modem interfrace for NM. Then NM could identify
> this modem and I got 'DeviceAdded' signal. Now NM can't detect modem
> and I don't get this signal.
> 
> Modem manager procedes up to:
> export_modem(): (/org/freedesktop/ModemManager1/Modem/4): 'Huawei'
> modem, VID 0x12D1 PID 0x1506 (usb)
> 
> Device is quite well accessible with mmclient.
> 
> Platform is yocto based am335x board running on Linux 4.1, NM version
> 0.9.8.10, MM version 1.4.2. I have patched MM with commit number
> 359ec84671f9fc0869443b9f0b9555324a0fff78 to fix Huawei AT^NDISDUP
> problem. Last week it worked fine.
> 
> Aren't NM and MM discussing through dbus? Only difference that I can
> figure out is that now I have built python-networkmanager into image.
> Could that disturb somehow?
> What could prevent NM from seeing modem devices?
> 
> Cheers,
> Matti
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list

signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


nmcli c does not list modem device

2016-03-14 Thread matti kaasinen
Hi!

I can't get modem device listed with
nmcli c
command. So, NM does not see it and therefore it can't start connection
with NM.
Last week it worked fine. I wrote python code for bringing gathering up
data from from modem interfrace for NM. Then NM could identify this modem
and I got 'DeviceAdded' signal. Now NM can't detect modem and I don't get
this signal.

Modem manager procedes up to:
export_modem(): (/org/freedesktop/ModemManager1/Modem/4): 'Huawei' modem,
VID 0x12D1 PID 0x1506 (usb)

Device is quite well accessible with mmclient.

Platform is yocto based am335x board running on Linux 4.1, NM version
0.9.8.10, MM version 1.4.2. I have patched MM with commit number
359ec84671f9fc0869443b9f0b9555324a0fff78 to fix Huawei AT^NDISDUP problem.
Last week it worked fine.

Aren't NM and MM discussing through dbus? Only difference that I can figure
out is that now I have built python-networkmanager into image. Could that
disturb somehow?
What could prevent NM from seeing modem devices?

Cheers,
Matti
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list