Could not find "pppd" binary
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
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)
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, &inner_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...
> ModemManager
Re: nmcli c does not list modem device
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
> 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 > > > > > modem > > > > > is > > > > > only set > > > > > in power low,
Re: nmcli radio off connected to ModemManager power state low
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
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
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
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
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
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
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
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 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
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
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
