Re: Libnm async functions and GMainLoop

[Dan Williams]

On Thu, 2016-03-17 at 11:01 +0100, Thomas Haller wrote:
> On Wed, 2016-03-16 at 16:03 -0700, Aaron Zinghini wrote:
> > 
> > When using async functions such as
> > "nm_client_activate_connection_async" I am not getting the supplied
> > callback being called. Do I need to have a GMainLoop setup for
> > this?
> > Why isn't there a synchronous version of these functions?
> > 
> > Thanks
> Hi,
> 
> 
> you are using libnm, right? No, there is no synchronous version.
> Not sure why, probably it is just a missing feature.

While there are many calls with both sync and async versions, we
recommend the async versions for a variety of reasons.  First the sync
versions can take along time to complete, since they may need to query
NetworkManager for a large amount of data.  They also may require user
interaction which depends entirely on the user to respond in a timely
manner.  Third, your application obviously cannot do anything during
the time the sync request is happening, which often leads to a sub-
optimal user experience, both from GUI and CLI type tools.

Dan

> 
> Yes, you always need a proper GMainLoop running. After all, libnm is
> a
> glib library, and that is a requirement.
> 
> It should be too complicated, have a look at:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examp
> les/C/glib/add-connection-
> libnm.c?id=e2040e5ebeae8e50e3f3b5a0e724fc9211866972
> 
> 
> 
> Thomas
> ___
> 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: NetworkManager 1.1.90 : nm-exported-object.c:293:nm_exported_object_class_add_interface: assertion failed: (object_property != NULL)

[Dan Williams]

e/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[2805]:  [1457951711.093127] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2805]:  [1457951711.094202] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2805]:  [1457951711.094982] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT+CGDCONT=?'
> ModemManager[2805]:  [1457951711.114393] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- '+CGDCONT:
> (1-17,101-116),"IP",,,(0),(0-4)OK'
> ModemManager[2805]:  [1457951711.115380] [mm-modem-
> helpers.c:762]
> mm_3gpp_parse_cgdcont_test_response(): *
> mm_3gpp_parse_cgdcont_test_response *
> ModemManager[2805]:  [1457951711.115998] [mm-modem-
> helpers.c:763]
> mm_3gpp_parse_cgdcont_test_response(): response = +CGDCONT:
> (1-17,101-116),"IP",,,(0),(0-4), g_str_has_prefix = 1
> ModemManager[2805]:  [1457951711.116824] [mm-broadband-
> modem.c:3132]
> load_power_state(): loading power state...
> ModemManager[2805]:  [1457951711.117534] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2805]:  [1457951711.118317] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2805]:  [1457951711.119064] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT+CFUN?'
> ModemManager[2805]:  [1457951711.136606] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- '+CFUN:
> 1OK'
> ModemManager[2805]:  [1457951711.137881] [mm-broadband-
> modem.c:1290]
> modem_load_unlock_required(): checking if unlock required...
> ModemManager[2805]:  [1457951711.138749] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2805]:  [1457951711.139631] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2805]:  [1457951711.140312] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT+CPIN?'
> ModemManager[2805]:  [1457951711.155811] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- '+CPIN:
> READYOK'
> ModemManager[2805]:  [1457951711.156814] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 1 (close)
> ModemManager[2805]:  [1457951711.157924] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 2 (open)
> ModemManager[2805]:  [1457951711.158883] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT^SPIC="SC"'
> ModemManager[2805]:  [1457951711.180386] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- '^SPIC:
> 5OK'
> ModemManager[2805]:  [1457951711.181499] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2805]:  [1457951711.182260] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2805]:  [1457951711.182973] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT^SPIC="SC",1'
> ModemManager[2805]:  [1457951711.210281] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- '^SPIC:
> 10OK'
> ModemManager[2805]:  [1457951711.211504] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> 
> 
>   IP   |  supported: 'none'
> 
> 
> Any ideas wh

Re: nmcli radio off connected to ModemManager power state low

[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 
> > <aleksan...@aleksander.es> wrote:
> > > 
> > > 
> > > On Sun, Mar 13, 2016 at 1:56 PM, Carlo Lobrano <c.lobrano@gmail.c
> > > 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

[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

[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

[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: NetworkManager 1.1.90 : nm-exported-object.c:293:nm_exported_object_class_add_interface: assertion failed: (object_property != NULL)

[Dan Williams]

On Fri, 2016-03-11 at 10:53 -0800, Ali Nematollahi wrote:
> Hi Dan
> 
> I did the changes, and it still fails. I made the wait a little
> longer,
> still fails. I sent an mmcli AT command to the modem, it fails to
> respond:
> 



> Isn't that a response to ^SCFG?

Yes, it is.  But notice how it doesn't actually come as a response to
the AT^SCFG=? request, but only when ModemManager sends the next
request.

Dan


> 
> 
> 
> 
> On Fri, Mar 11, 2016 at 6:59 AM, Dan Williams <d...@redhat.com>
> wrote:
> 
> > 
> > On Thu, 2016-03-10 at 17:34 -0800, Ali Nematollahi wrote:
> > > 
> > > So I've started looking at the code and I looked for the error
> > > message that
> > > says Missing +CGDCONT prefix. I added debugging code to print out
> > > the
> > > "response" and the result of g_str_has_prefix () function call in
> > > src/mm-modem-helpers.c: mm_3gpp_parse_cgdcont_test_response()
> > > 
> > > Here is my debugging output (highlighted in red).
> > > The response clearly has "+CGDCONT" at the beginning...but
> > > g_str_has_prefix() fails to read it. Is it because my glib is
> > > old? Or
> > > could
> > > it be because it comes out with  before it and
> > > g_str_has_prefix()
> > > is confused as a result??
> > The reason it fails is because of the "Serial command timed out";
> > the
> > modem doesn't respond to the AT^SCFG request within the expected
> > time,
> > so ModemManager gives up.  Then the response actually does happen a
> > bit
> > later, but MM has already sent the CGDCONT request, and expects a
> > CGDCONT reply instead of the ^SCFG reply.  So we probably just need
> > to
> > increase the timeout for this modem.  Can you try this change?
> > 
> > In plugins/cinterion/mm-broadband-modem-cinterion.c:
> > 
> > static void
> > load_supported_bands (MMIfaceModem *self,
> >   GAsyncReadyCallback callback,
> >   gpointer user_data)
> > {
> > GSimpleAsyncResult *simple;
> > 
> > simple = g_simple_async_result_new (G_OBJECT (self),
> > callback,
> > user_data,
> > load_supported_bands);
> > 
> > mm_base_modem_at_command (MM_BASE_MODEM (self),
> >   "AT^SCFG=?",
> > - 3,
> > + 6,
> >   FALSE,
> >   (GAsyncReadyCallback)scfg_test_ready,
> >   simple);
> > }
> > 
> > and I bet it'll start working.
> > 
> > Dan
> > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Manager[4969]:  [1457629898.039154] [mm-port-serial-
> > > at.c:440]
> > > debug_log(): (ttyUSB2): --> 'AT^SCFG=?'
> > > ModemManager[4969]:   [1457629901.672443] [mm-iface-
> > > modem.c:3961]
> > > load_supported_bands_ready(): couldn't load Supported Bands:
> > > 'Serial
> > > command timed out'
> > > ModemManager[4969]:  [1457629901.674453] [mm-broadband-
> > > modem.c:1675]
> > > modem_load_supported_ip_families(): loading supported IP
> > > families...
> > > ModemManager[4969]:  [1457629901.675897] [mm-port-
> > > serial.c:1237]
> > > mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> > > ModemManager[4969]:  [1457629901.676875] [mm-port-
> > > serial.c:1294]
> > > _close_internal(): (ttyUSB2) device open count is 2 (close)
> > > ModemManager[4969]:  [1457629901.677831] [mm-port-serial-
> > > at.c:440]
> > > debug_log(): (ttyUSB2): --> 'AT+CGDCONT=?'
> > > ModemManager[4969]:  [1457629901.712009] [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:
> > > "I

Re: nmcli radio off connected to ModemManager power state low

[Dan Williams]

On Fri, 2016-03-11 at 14:49 +0100, Carlo Lobrano wrote:
> Hello everybody,
> 
> making some changes in ModemManager "set power state", I observed
> that setting
> setting a radio interface to OFF with nmcli, the ModemManager power
> state
> triggered is the LOW one, while I expected it to be the OFF one. Is
> that
> correct? If that so, is there a way to set the modem in OFF power
> state
> through network manager?

There are two things that 'nmcli r wwan off' does:

1) attempts to set any kernel rfkill WWAN switches to "blocked"
2) disables the modem with ModemManager, which sets low power state

If your kernel/hardware has rfkill capability then the modem will
actually be completely killed and off, and will often drop off the USB
bus too.

But if your kernel/hardware doesn't have rfkill, NM skips the rfkill
step and asks ModemManager to put the modem into low-power mode.
 Without rfkill capability if the modem/phone powers off completely
(which some do with CFUN=0), there's no way to get the modem turned
back on with 'nmcli r wwan on' because the modem has either completely
disappeared, or isn't responding to commands (because it's off).

So I looked through my collection and out of the 20 USB modems I tried,
only two actually powered off with CFUN=0; Nokia 21M-02 and Ericsson
MD300.  The rest stayed up and running, so obviously it would be
possible to use CFUN=0 (or equivalent) on most devices.

But is there a huge power draw difference between CFUN=0 and CFUN=4 in
most devices?  If there isn't, I'd prefer CFUN=4, and typically an
rfkill-setup is more useful for complete power off than CFUN=0 since
that also kills any USB power draw too.

Dan
___
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)

[Dan Williams]

gt; LF>+CGDCONT:
> (1-16,101-116),"IP",,,(0),(0-4)OK'
> ModemManager[4969]:  [1457629901.714967] [mm-modem-
> helpers.c:762]
> mm_3gpp_parse_cgdcont_test_response(): *
> mm_3gpp_parse_cgdcont_test_response *
> ModemManager[4969]:  [1457629901.716188] [mm-modem-
> helpers.c:763]
> mm_3gpp_parse_cgdcont_test_response(): response = ^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/NWSM",("0","1","2")
> ^SCFG: "Radio/OutputPowerReduction",("4"-"8")
> ^SCFG: "Serial/USB/DDD",("0","1"),("0"),(4),(4),(4),(63),(63),(4)
> ^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
> 
> +CGDCONT: (1-16,101-116),"IP",,,(0),(0-4), g_str_has_prefix = 0
> 
> ModemManager[4969]:   [1457629901.718044] [mm-iface-
> modem.c:3984]
> load_supported_ip_families_ready(): couldn't load Supported IP
> families:
> 'Missing +CGDCONT prefix'
> ModemManager[4969]:  [1457629901.719369] [mm-broadband-
> modem.c:3132]
> load_power_state(): loading power state...
> ModemManager[4969]:  [1457629901.720687] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[4969]:  [1457629901.721917] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[4969]:  [1457629901.723342] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT+CFUN?'
> ModemManager[4969]:   [1457629904.671850] [mm-iface-
> modem.c:3993]
> load_power_state_ready(): couldn't load Power State: 'Serial command
> timed
> out'
> ModemManager[4969]:  [1457629904.672282] [mm-broadband-
> modem.c:1290]
> modem_load_unlock_required(): checking if unlock required...
> ModemManager[4969]:  [1457629904.672492] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[4969]:  [1457629904.672764] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[4969]:  [1457629904.673007] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT+CPIN?'
> ModemManager[4969]:  [1457629904.704292] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): <-- '+CPIN:
> READYOK'
> ModemManager[4969]:  [1457629904.706089] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 1 (close)
> ModemManager[4969]:  [1457629904.707959] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 2 (open)
> 
> 
> 
> 
> On Thu, Mar 10, 2016 at 3:06 PM, Ali Nematollahi <alirez...@gmail.com
> >
> wrote:
> 
> > 
> > Attached is the complete start up log capture of the MM. Hope this
> > helps.
> > 
> > Thanks Dan
> > 
> > On Thu, Mar 10, 2016 at 2:48 PM, Dan Williams <d...@redhat.com>
> > wrote:
> > 
> > > 
> > > On Thu, 2016-03-10 at 13:49 -0800, Ali Nematollahi wrote:
> > > > 
> > > > ^SCFG query comes after CGDCONT query:
>

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

[Dan Williams]

On Thu, 2016-03-10 at 13:49 -0800, Ali Nematollahi wrote:
> ^SCFG query comes after CGDCONT query:

Do you see any "AT^SCFG=?" sent by ModemManager anywhere in the logs?

Dan

> ModemManager[2738]:  [946691988.680690] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT+CGDCONT=?'
> ModemManager[2738]:  [946691988.699302] [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/NWSM",("0","1","2")^SCFG:
> "Radio/OutputPowerReduction",("4"-"8")^SCFG:
> "Serial/USB/DDD",("0","1"),("0"),(4),(4),(4),(63),(63),(4)^SC
> FG:
> "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>+CGDCONT:
> (1-16,101-116),"IP",,,(0),(0-4)OK'
> ModemManager[2738]:   [946691988.701381] [mm-iface-
> modem.c:3984]
> load_supported_ip_families_ready(): couldn't load Supported IP
> families:
> 'Missing +CGDCONT prefix'
> ModemManager[2738]:  [946691988.702102] [mm-broadband-
> modem.c:3132]
> load_power_state(): loading power state...
> ModemManager[2738]:  [946691988.702786] [mm-port-
> serial.c:1237]
> mm_port_serial_open(): (ttyUSB2) device open count is 3 (open)
> ModemManager[2738]:  [946691988.703592] [mm-port-
> serial.c:1294]
> _close_internal(): (ttyUSB2) device open count is 2 (close)
> ModemManager[2738]:  [946691988.704322] [mm-port-serial-
> at.c:440]
> debug_log(): (ttyUSB2): --> 'AT+CFUN?'
> ModemManager[2738]:   [946691991.677255] [mm-iface-
> modem.c:3993]
> load_power_state_ready(): couldn't load Power State: 'Serial command
> timed
> out'
> ModemManager[2738]:  [946691991.683414] [mm-broadband-
> modem.c:1290]
> modem_load_unlock_required(): checking if unlock required...
> 
> 
> On Thu, Mar 10, 2016 at 1:26 PM, Dan Williams <d...@redhat.com>
> wrote:
> 
> > 
> > On Thu, 2016-03-10 at 11:00 -0800, Ali Nematollahi wrote:
> > > 
> > > Hi Dan
> > > 
> > > Perfect. I did that and I see this:
> > > 
> > > 
> > > ModemManager[2757]:  (ttyUSB2) device open count is 2
> > > (close)
> > > ModemManager[2757]:  (ttyUSB2): --> 'AT+CGDCONT=?'
> > > 
> > What are the previous 10 lines here?  Does the modem really respond
> > to
> > AT+CGDCONT=? with unsolicited ^SCFG output or is that left-over
> > from a
> > previous AT^SCFG=? request that MM is making?
> > 
> > Dan
> > 
> > > 
> > > ModemManager[2757]:  (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",

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

[Dan Williams]

On Thu, 2016-03-10 at 11:00 -0800, Ali Nematollahi wrote:
> Hi Dan
> 
> Perfect. I did that and I see this:
> 
> 
> ModemManager[2757]:  (ttyUSB2) device open count is 2 (close)
> ModemManager[2757]:  (ttyUSB2): --> 'AT+CGDCONT=?'
> 

What are the previous 10 lines here?  Does the modem really respond to
AT+CGDCONT=? with unsolicited ^SCFG output or is that left-over from a
previous AT^SCFG=? request that MM is making?

Dan

> ModemManager[2757]:  (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/NWSM",("0","1","2")^SCFG:
> "Radio/OutputPowerReduction",("4"-"8")^SCFG:
> "Serial/USB/DDD",("0","1"),("0"),(4),(4),(4),(63),(63),(4)^SC
> FG:
> "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>+CGDCONT:
> (1-16,101-116),"IP",,,(0),(0-4)OK'
> ModemManager[2757]:   couldn't load Supported IP families:
> 'Missing
> +CGDCONT prefix'
> ModemManager[2757]:  loading power state...
> ModemManager[2757]:  (ttyUSB2) device open count is 3 (open)
> ModemManager[2757]:  (ttyUSB2) device open count is 2 (close)
> 
> This is a modem that only supports IPv4.
> 
> How can I get around this problem?
> 
> 
> 
> On Thu, Mar 10, 2016 at 10:32 AM, Dan Williams <d...@redhat.com>
> wrote:
> 
> > 
> > On Thu, 2016-03-10 at 10:24 -0800, Ali Nematollahi wrote:
> > > 
> > > Hi Thomas
> > > 
> > > Thanks! This is much better...here is the output from start to
> > > finish:
> > > mmcli -m 0
> > > 
> > > /org/freedesktop/ModemManager1/Modem/0 (device id
> > > '2ea06a44171a29335a8b7f781e0f9559bc24976d')
> > >   -
> > >   Hardware |   manufacturer: 'Cinterion'
> > >    |  model: 'PHS8-USA'
> > >    |   revision: 'REVISION 03.001'
> > >    |  supported: 'gsm-umts'
> > >    |current: 'gsm-umts'
> > >    |   equipment id: '351502050184415'
> > >   -
> > >   System   | device:
> > > '/sys/devices/ocp.2/4740.usb/47401c00.usb/musb-
> > > hdrc.1.auto/usb2/2-1'
> > >    |drivers: 'option1'
> > >    | plugin: 'Cinterion'
> > >    |   primary port: 'ttyUSB2'
> > >    |  ports: 'ttyUSB1 (gps), ttyUSB2 (at),
> > > ttyUSB3
> > > (at)'
> > >   -
> > >   Numbers  |   own : '+12899368246'
> > >   -
> > >   Status   |   lock: 'none'
> > >    | unlock retries: 'sim-pin (5), sim-pin2 (5), sim-puk
> > > (10),
> > > sim-puk2 (10), ph-net-pin (10), ph-net-puk (32), ph-fsim-pin
> > > (10),
> > > ph-fsim-puk (32)'
> > >    |  state: 'disabled'
> > >    |power state: 'unknown'
> > >    |access tech: 'unknown'
> > > 

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

[Dan Williams]

On Thu, 2016-03-10 at 10:24 -0800, Ali Nematollahi wrote:
> Hi Thomas
> 
> Thanks! This is much better...here is the output from start to
> finish:
> mmcli -m 0
> 
> /org/freedesktop/ModemManager1/Modem/0 (device id
> '2ea06a44171a29335a8b7f781e0f9559bc24976d')
>   -
>   Hardware |   manufacturer: 'Cinterion'
>    |  model: 'PHS8-USA'
>    |   revision: 'REVISION 03.001'
>    |  supported: 'gsm-umts'
>    |current: 'gsm-umts'
>    |   equipment id: '351502050184415'
>   -
>   System   | device:
> '/sys/devices/ocp.2/4740.usb/47401c00.usb/musb-
> hdrc.1.auto/usb2/2-1'
>    |drivers: 'option1'
>    | plugin: 'Cinterion'
>    |   primary port: 'ttyUSB2'
>    |  ports: 'ttyUSB1 (gps), ttyUSB2 (at), ttyUSB3
> (at)'
>   -
>   Numbers  |   own : '+12899368246'
>   -
>   Status   |   lock: 'none'
>    | unlock retries: 'sim-pin (5), sim-pin2 (5), sim-puk
> (10),
> sim-puk2 (10), ph-net-pin (10), ph-net-puk (32), ph-fsim-pin (10),
> ph-fsim-puk (32)'
>    |  state: 'disabled'
>    |power state: 'unknown'
>    |access tech: 'unknown'
>    | signal quality: '0' (cached)
>   -
>   Modes|  supported: 'allowed: 2g; preferred: none
>    |  allowed: 3g; preferred: none
>    |  allowed: 2g, 3g; preferred: none'
>    |current: 'allowed: any; preferred: none'
>   -
>   Bands|  supported: 'unknown'
>    |current: 'unknown'
>   -
>   IP   |  supported: 'none'
> 
Ok, here's the problem.  Could you grab the ModemManager debug output?

mmcli --set-logging=debug

and then replug the modem (if you can!) or rmmod the modem drivers and
modprobe them again.  We're looking for the response to the
"AT+CGDCONT=?" command and why MM apparently doesn't parse that
correctly.  That'll look something like this:

ModemManager[2768]:  [1457634614.295964] [mm-port-serial-at.c:459] 
debug_log(): (ttyACM3): --> 'AT+CGDCONT=?'
ModemManager[2768]:  [1457634614.309936] [mm-port-serial-at.c:459] 
debug_log(): (ttyACM3): <-- '+CGDCONT: 
(1-10),"IP",,,(0,1),(0,1)+CGDCONT: 
(1-10),"IPV6",,,(0,1),(0,1)+CGDCONT: 
(1-10),"IPV4V6",,,(0,1),(0,1)OK'

which for this device results in:

  IP   |  supported: 'ipv4, ipv6, ipv4v6'

Dan

>   -
>   3GPP |   imei: '351502050184415'
>    |  enabled locks: 'none'
>    |operator id: 'unknown'
>    |  operator name: 'unknown'
>    |   subscription: 'unknown'
>    |   registration: 'unknown'
>   -
>   SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'
> 
>   -
>   Bearers  |  paths: 'none'
> 
> root@beaglebone:~# mmcli -m 0 -e
> ModemManager[2687]:   Modem
> /org/freedesktop/ModemManager1/Modem/0:
> state changed (disabled -> enabling)
> ModemManager[2687]:   (ttyUSB2): port attributes not fully set
> ModemManager[2687]:   Modem
> /org/freedesktop/ModemManager1/Modem/0:
> 3GPP Registration state changed (unknown -> registering)
> ModemManager[2687]:   Modem
> /org/freedesktop/ModemManager1/Modem/0:
> 3GPP Registration state changed (registering -> home)
> 
> mmcli -m 0 --simple-connect="apn=m2minternet.apn"
> ModemManager[2687]:   Modem
> /org/freedesktop/ModemManager1/Modem/0:
> state changed (enabling -> registered)
> successfully enabled the modem
> root@beaglebone:~#
> root@beaglebone:~# mmcli -m 0 --simple-connect="apn=m2minternet.apn"
> ModemManager[2687]:   Simple connect started...
> ModemManager[2687]:   Simple connect state (4/8): Wait to get
> fully
> enabled
> ModemManager[2687]:   Simple connect state (5/8): Register
> ModemManager[2687]:   Simple connect state (6/8): Bearer
> ModemManager[2687]:   Simple connect state (7/8): Connect
> ModemManager[2687]:   Modem
> /org/freedesktop/ModemManager1/Modem/0:
> state changed (registered -> connecting)
> ModemManager[2687]:   (ttyUSB3): port attributes not fully set
> ModemManager[2687]:   Modem
> /org/freedesktop/ModemManager1/Modem/0:
> state changed (connecting -> connected)
> ModemManager[2687]:   Simple connect state (8/8): All done
> successfully connected the modem
> root@beaglebone:~# mmcli -b 0
> Bearer '/org/freedesktop/ModemManager1/Bearer/0'
>   -
>   Status |   connected: 'yes'
>  |   suspended: 'no'
>  |   interface: 'ttyUSB3'
>  |  IP timeout: '20'
>   -
>   Properties | apn: 'm2minternet.apn'
>  | roaming: 'allowed'
>  | IP type: 'none'
> 

Re: NetworkManager dispatchers

[Dan Williams]

On Fri, 2016-03-04 at 10:15 -0800, Ali Nematollahi wrote:
> Hi Dan
> 
> MM 1.4.12 and NM 1.0.10.
> 

Sorry for the late follow-up; the issue appears to be that either NM or
MM is unable to detect the supported IP types of the modem.  That's why
you get this message:

"Connection requested IPv4 but IPv4 is unsuported by the modem"

Can you grab "mmcli -m 0 | grep IP" and we'll see if MM or NM is at
fault here.

Dan


> I understand that the connection to bearer takes a bit of time, but
> when I
> get this:
> root~# mmcli -b /org/freedesktop/ModemManager1/Bearer/1
> Bearer '/org/freedesktop/ModemManager1/Bearer/1'
>   -
>   Status |   connected: 'yes'
>  |   suspended: 'no'
>  |   interface: 'ttyUSB3'
>  |  IP timeout: '20'
>   -
>   Properties | apn: 'm2minternet.apn'
>  | roaming: 'allowed'
>  | IP type: 'none'
>  |user: 'none'
>  |password: 'none'
>  |  number: 'none'
>  | Rm protocol: 'unknown'
>   -
>   IPv4 configuration |   method: 'ppp'
>  |  address: 'unknown'
>  |   prefix: '0'
>  |  gateway: 'unknown'
>  |  DNS: none
>   -
>   IPv6 configuration |   method: 'unknown'
> 
> 
> 
> Does it not mean that I am already connected?? If I bring up PPPD
> manually
> I could ping and I can wget at this point.
> 
> 
> On Fri, Mar 4, 2016 at 8:57 AM, Dan Williams <d...@redhat.com> wrote:
> 
> > 
> > On Thu, 2016-03-03 at 17:06 -0800, Ali Nematollahi wrote:
> > > 
> > > So I did some more work and Here is what I found, which still
> > > doesn't
> > > make
> > > any sense.
> > > 
> > > When I checked the "bearer" info with mmcli:
> > > Bearer '/org/freedesktop/ModemManager1/Bearer/0'
> > >   -
> > >   Status |   connected: 'no'
> > >  |   suspended: 'no'
> > >  |   interface: 'unknown'
> > >  |  IP timeout: '20'
> > >   -
> > >   Properties | apn: 'm2minternet.apn'
> > >  | roaming: 'allowed'
> > >  | IP type: 'none'
> > >  |user: 'none'
> > >  |password: 'none'
> > >  |  number: 'none'
> > >  | Rm protocol: 'unknown'
> > >   -
> > >   IPv4 configuration |   method: 'unknown'
> > >   -
> > >   IPv6 configuration |   method: 'unknown'
> > The bearer will be created but it takes a bit to be connected, so
> > that's probably the state you're in here.
> > 
> > > 
> > > 
> > > 
> > > so I did a simple-connect AGAIN:
> > > mmcli -m 0 --simple-connect="apn=m2minternet.apn"
> > > NetworkManager[2887]:   (ttyUSB2): modem state changed,
> > > 'registered'
> > > --> 'connecting' (reason: user-requested)
> > > NetworkManager[2887]:   (ttyUSB2): modem state changed,
> > > 'connecting'
> > > --> 'connected' (reason: user-requested)
> > > successfully connected the modem
> > > root~# mmcli -b /org/freedesktop/ModemManager1/Bearer/1
> > > Bearer '/org/freedesktop/ModemManager1/Bearer/1'
> > >   -
> > >   Status |   connected: 'yes'
> > >  |   suspended: 'no'
> > >  |   interface: 'ttyUSB3'
> > >  |  IP timeout: '20'
> > >   -
> > >   Properties | apn: 'm2minternet.apn'
> > >  | roaming: 'allowed'
> > >  | IP type: 'none'
> > >  |user: 'none'
> > >  |password: 'none'
> > >  |  number: 'none'
> > >  | Rm protocol: 'unknown'
> > >   -
> > >   IPv4 configuration |   method: 'ppp'
> > >  |  address: 'unknown'
> > >  |   prefix: '0'
> > >    

Re: Bonding wifi and wired

[Dan Williams]

On Tue, 2016-03-08 at 10:50 +0100, Thomas Haller wrote:
> On Mon, 2016-03-07 at 23:34 -0500, Nikolay Martynov wrote:
> > 
> > Hi.
> > 
> >   I just wanted to reach out to ask what's NetworkManager team's
> > position on allowing bonding of wifi and wired interface? Are there
> > any plans to support this? If not - it is due to no one being
> > interested implementing it or because this feature would go against
> > some large plans/ideology?
> > 
> >   I was able to make it work with NM on client side and OpenWRT on
> > router side. Router side is easy. On NM side there is some manual
> > config editing (which is fine) and some kinds that make day-to-day
> > life less enjoyable than it should (like inability to manually
> > connect
> > to bonded wifi). SO I was curious - would patches fixing those
> > smaller
> > kinks be acceptable at all or is it something that NM team is just
> > not
> > interested in?
> > 
> I'm not familiar with the quirks of bonding of Wi-Fi and ethernet.
> 
> Anyway, we are definitely interested in supporting all kind of use-
> cases and patches are always welcome :)

I know it's been done before, but one caveat is that the wifi driver
and the supplicant have to correctly support setting the WiFi device's
MAC address since bonding requires they have the same one.  That's been
a problem in the past and required fixes to the supplicant and drivers.
 But yeah, I'm sure we'd take patches fixing anything on the NM side.

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

Re: NetworkManager dispatchers

[Dan Williams]

t; > (internal)
> > NetworkManager[5255]:   Loaded device plugin: NMBondFactory
> > (internal)
> > NetworkManager[5255]:   Loaded device plugin: NMWifiFactory
> > (/usr/local/lib/NetworkManager/libnm-device-plugin-wifi.so)
> > NetworkManager[5255]:   (/libnm-device-plugin-bluetooth.so):
> > failed
> > to load plugin:
> > /usr/local/lib/NetworkManager/libnm-device-plugin-bluetooth.so:
> > undefined
> > symbol: g_clear_pointer
> > NetworkManager[5255]:   Loaded device plugin: NMWwanFactory
> > (/usr/local/lib/NetworkManager/libnm-device-plugin-wwan.so)
> > NetworkManager[5255]:   Loaded device plugin: NMAtmManager
> > (/usr/local/lib/NetworkManager/libnm-device-plugin-adsl.so)
> > NetworkManager[5255]:   WiFi enabled by radio killswitch;
> > enabled by
> > state file
> > NetworkManager[5255]:   WWAN enabled by radio killswitch;
> > enabled by
> > state file
> > NetworkManager[5255]:   WiMAX enabled by radio killswitch;
> > enabled
> > by state file
> > NetworkManager[5255]:   Networking is enabled by state file
> > NetworkManager[5255]:   (eth0): link connected
> > NetworkManager[5255]:   (eth0): new Ethernet device (carrier:
> > ON,
> > driver: 'cpsw', ifindex: 4)
> > NetworkManager[5255]:   (lo): link connected
> > NetworkManager[5255]:   (lo): new Generic device (carrier:
> > ON,
> > driver: 'unknown', ifindex: 1)
> > NetworkManager[5255]:   (can0): new Generic device (carrier:
> > UNKNOWN, driver: 'c_can_platform', ifindex: 2)
> > NetworkManager[5255]:   (can1): new Generic device (carrier:
> > UNKNOWN, driver: 'c_can_platform', ifindex: 3)
> > NetworkManager[5255]:   startup complete
> > NetworkManager[5255]:   ModemManager available in the bus
> > NetworkManager[5255]:   (ttyUSB2): new Broadband device
> > (carrier:
> > UNKNOWN, driver: 'option1', ifindex: 0)
> > NetworkManager[5255]:   (ttyUSB2): device state change:
> > unmanaged ->
> > unavailable (reason 'managed') [10 20 2]
> > NetworkManager[5255]:   (ttyUSB2): modem state 'registered'
> > NetworkManager[5255]:   (ttyUSB2): device state change:
> > unavailable
> > -> disconnected (reason 'none') [20 30 0]
> > 
> > but when I do con up, I still get nothing:
> > root/usr/local/etc/NetworkManager/system-connections# nmcli con up
> > ppp
> > Error: Connection 'ppp' does not exist.
> > 
> > 
> > 
> > Any ideas what is going on?
> > 
> > 
> > 
> > On Thu, Mar 3, 2016 at 2:37 PM, Ali Nematollahi <alirez...@gmail.co
> > m>
> > wrote:
> > 
> > > 
> > > Thanks Dan!
> > > I removed the connections and restarted NM and did what you
> > > suggested and
> > > here is what I get now:
> > > nmcli con add type gsm con-name ppp ifname ttyUSB2 apn
> > > internet.com
> > > Connection 'ppp' (94e24340-490b-4f96-91bb-c5511a2a5f50)
> > > successfully
> > > added.
> > > 
> > > root/usr/local/etc/NetworkManager/system-connections# nmcli con
> > > up ppp
> > > Error: Connection activation failed: Active connection removed
> > > before it
> > > was initialized
> > > root/usr/local/etc/NetworkManager/system-connections# nmcli con
> > > up ppp
> > > Error: Connection activation failed: Active connection could not
> > > be
> > > attached to the device
> > > 
> > > 
> > > I wonder what that means...hmmm
> > > 
> > > 
> > > Thanks a lot for your help!
> > > 
> > > On Thu, Mar 3, 2016 at 2:25 PM, Dan Williams <d...@redhat.com>
> > > wrote:
> > > 
> > > > 
> > > > On Thu, 2016-03-03 at 13:58 -0800, Ali Nematollahi wrote:
> > > > > 
> > > > > Okay so I was able to get MM 1.4.12 and NM 1.0.10 compiled
> > > > > and
> > > > > deployed on
> > > > > my unit, which I must admit wasn't easy. 0.9.4 was a lot
> > > > > easier, I
> > > > > had to
> > > > > do a whole lot of re-linking and stuff to get 1.0.10 set up
> > > > > and
> > > > > running.
> > > > > Good news is it is up and running!
> > > > > 
> > > > > 
> > > > > I got my 3g up and running and it's all good. Now trying to
> > > > > get NM to
> > > > > start
> > > > > a PPP on it but I'm hitting the wall again.
> > > > > I've read a lot of documents on setting up devices but none
&

Re: nm-pppd-plugin does not start

[Dan Williams]

On Fri, 2016-03-04 at 17:17 +0200, matti kaasinen wrote:
> 2016-03-04 13:50 GMT+02:00 matti kaasinen :
> 
> > 
> > Good point, ppp is not enabled! Option seems to be --enable-ppp.
> > I'll try
> > > 
> > > it. This NDISDUP seemp pretty problematic. In fact I found MM
> > > patch whose
> > > introduction comment describes pretty much how this modem works (
> > > https://cgit.freedesktop.org/ModemManager/ModemManager/log/?h=dcb
> > > w/huawei-at-dhcp).
> > > I'll check if that helps/works with this MM version - then I
> > > suppose, I
> > > should contact MM mailing list...
> > > 
> > > > 
> > > > 
> > This was the problem with ppp connection. PPP connection started
> > working
> > after inserting --enable-ppp option to networkmanager configuration
> > optios
> > (in fact EXTRA_OECONF_append = " --enable-ppp " in my
> > networkmanager_0.9.8.10.bbappend recipe). Somehow NDISDUP does not
> > seem
> > too appealing now. It does not show up as device in nmcli d
> > listing. Nor
> > does it open interface automatically like Huawei 3131/Hilink does.
> > It would
> > require some kind of patching/more debugging. If it then worked
> > like Huawei
> > 3131/HiLink - no need of touching nmcli command at all and no need
> > of
> > writing configuration file - then I would be interested in trying
> > it.
> > Otherwise, I don't see what I get out of it compared to PPP
> > connection.
> > 
> Hi again!
> I was far too curious not trying that Huwei AT^NDISDUP patch. I did
> not
> find official patch, but I used commit number
> 359ec84671f9fc0869443b9f0b9555324a0fff78 to create patch. Patching
> worked
> without problems, it compiled fine and really it worked!! Operation
> from
> user point of view was identical to ppp operation: to make config
> file and
> start connection with nmcli command. Now NM opened wwan0 interface
> instead
> of ppp0. So, I can confirm that above commit fixes problem in NDISDUP
> operation with Huawei 3131 modem that before mode switching shows up
> as
> 12d1:14fe and afterwards as 12d1:1506.
> 
> Now I need to figure out if I make those udev hacks to force PPP
> operation
> or MM patching to fix NDISDUP. Do you have plans to merge this patch
> to
> master branch?

Yeah, we have plans to merge it, but I'm a bit concerned about
regression risk with other modems that might support DHCP.  What do you
think Aleksander?  The patch just makes MM use static bearer IP config
if the modem reports valid details with ^DHCP, instead of requiring a
DHCP run.  That apparently is required on a number of devices.

But ISTR we've had some devices that need DHCP to get kicked into
enabling the data connection, though they weren't Huawei.

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

Re: NetworkManager dispatchers

[Dan Williams]

On Thu, 2016-03-03 at 13:58 -0800, Ali Nematollahi wrote:
> Okay so I was able to get MM 1.4.12 and NM 1.0.10 compiled and
> deployed on
> my unit, which I must admit wasn't easy. 0.9.4 was a lot easier, I
> had to
> do a whole lot of re-linking and stuff to get 1.0.10 set up and
> running.
> Good news is it is up and running!
> 
> 
> I got my 3g up and running and it's all good. Now trying to get NM to
> start
> a PPP on it but I'm hitting the wall again.
> I've read a lot of documents on setting up devices but none that go
> deep
> into setting up GSM and PPP, which is sad. Here is what I have done
> so far:
> 
> - with NMCLI:
> nmcli con add type gsm con-name ppp ifname ppp0 apn internet.com
> Connection 'ppp' (af71d0c7-bbbd-4d4e-941e-a2581dc86a2e) successfully
> added.
> 
> root/usr/local/etc/NetworkManager/system-connections# nmcli con up
> ppp
> Error: Connection activation failed: No suitable device found for
> this
> connection.
> 
> some useful outputs:
> root/usr/local/etc/NetworkManager/system-connections# nmcli con
> NAME   UUID  TYPE  DEVICE
> pppaf71d0c7-bbbd-4d4e-941e-a2581dc86a2e  gsm   --
> radio  f6547503-d831-4cc2-bd3c-a958e645552a  gsm   --
> root/usr/local/etc/NetworkManager/system-connections# nmcli dev
> DEVICE   TYPE  STATE CONNECTION
> ttyUSB2  gsm   disconnected  --
> eth0 ethernet  unmanaged --
> lo   loopback  unmanaged --
> root/usr/local/etc/NetworkManager/system-connections# mmcli -L
> 
> Found 1 modems:
> /org/freedesktop/ModemManager1/Modem/0 [Cinterion] PHS8-USA
> 
> 
> I added another entry to the ppp connection and called it radio:
> cat radio
> [connection]
> id=radio
> uuid=f6547503-d831-4cc2-bd3c-a958e645552a
> type=gsm
> #interface-name=ppp0
> interface-name=wwan0

The interface part is likely your problem.  interface-name is the name
of the NetworkManager control port, which in your case would be ttyUSB2
(as reported by 'nmcli dev').  Data ports (like ppp0) are transient,
they come and go, so locking the connection profile to a specific
device needs to happen with the control interface name.

If you change that to ttyUSB2 or even just remove it entirely, what
happens?

Dan

> permissions=
> secondaries=
> 
> [gsm]
> apn=m2minternet.apn
> number=*99#
> 
> [ipv4]
> dns-search=
> method=auto
> 
> [ipv6]
> dns-search=
> method=auto
> 
> [serial]
> baud=115200
> 
> 
> nmcli con up radio ifname ppp0
> Error: device 'ppp0' not compatible with connection 'radio'.
> 
> 
> Can someone tell me what I'm not doing right? I want to have my PPP0
> interface come up everytime the radio is connected. When I do it
> manually
> through pppd call it works beautifully but I can't get it to work
> with
> NMCLI. Any ideas why not?
> 
> 
> Thanks
> 
> 
> 
> 
> 
> On Tue, Mar 1, 2016 at 7:38 AM, Dan Williams <d...@redhat.com> wrote:
> 
> > 
> > On Mon, 2016-02-29 at 17:40 -0800, Ali Nematollahi wrote:
> > > 
> > > Thanks! I've looked at nmcli radio but there is no good
> > > documentation
> > > I
> > > could find for the version I am using. All of the documentation
> > > is
> > > for
> > > newer version and don't apply.
> > Yeah, you say later you're using NM 0.9.4, which is extremely old
> > (23-
> > Mar-2012) and I'm not surprised some stuff would be different...
> > 
> > > 
> > > First of all, when I do:
> > > 
> > > nmcli nm wwan
> > > WWAN
> > > disabled
> > > 
> > > Then I do:
> > >  nmcli nm wwan on
> > > nmcli nm wwan
> > > WWAN
> > > disabled
> > > 
> > > nmcli nm status
> > > RUNNING STATE   WIFI-HARDWARE   WIFI   WWAN-
> > > HARDWARE
> > > WWAN
> > > running connected   enabled enabledenable
> > > d
> > > disabled
> > What's in /var/lib/NetworkManager/NetworkManager.state ?
> > 
> > Can you turn on NM log debugging (might be an nmcli command for
> > that)
> > and see what NM prints out when you do "nmcli nm wwan on"?
> > 
> > Dan
> > 
> > > 
> > > I was reading on google somewhere that I need a config file
> > > in: /etc/NetworkManager/system-connections/
> > > so I put one in:
> > > 
> > > cat /etc/NetworkManager/system-connections/radio
> > > [connection]
> > > id=MyWwanConnection
> > > type=gsm
> > > 
> > > [ipv4]
> > > method=auto
&

Re: [PATCH 1/1] import: ignore file encoding for ovpn configuration file

[Dan Williams]

On Wed, 2016-03-02 at 12:53 +0100, Thomas Haller wrote:
> Openvpn treats ovpn files as ASCII configuration file and
> does not care about a specific certain encoding. As such,
> only encodings that are an extension of ASCII can work at
> all (like iso8859-* or utf8).
> 
> We should not try to handle configuration files that cannot even
> be handled by openvpn itself.
> 
> As regular options must be ASCII-compatbile, the encoding only
> matters for filenames and inline-blobs.
> 
> Openvpn itself doesn't care about encoding of filenames and passes
> them directly to the system functions (open, access). The same is
> true
> for glib, which expects paths in "GLib file encoding".
> Nowaways, most Linux filesystems use utf8 encoding for paths.
> Therefore,
> if we would know the encoding of the file, we probably would want to
> convert the paths to utf8. However, how do we guess the right
> encoding?
> And what if the user *really* meant what is written in the
> configuration
> file? Note, that openvpn doesn't support escape sequences like
> "\344",
> thus, if the user really wanted to specify such a character, he is
> only
> able to do so if we don't mess with the encoding.
> 
> Inline blobs usually are ASCII/base64 encoded. If they happen to be
> in a
> different encoding, we still want to preserve the original blob and
> not guess and convert encodings.
> 
> The only sane option is ignoring the encoding and pretend it is
> ASCII compatible. Who writes non-utf8 configuration files anyway?
> 

We have to make sure string data we pass through D-Bus (like in the
connection properties) is UTF-8 though.  So it doesn't need to be
converted or validated at some point, or dbus will kick the
editor/whatever off the bus when it tries to send the invalid data to
NM.

Dan

> ---
>  properties/import-export.c| 17 -
>  properties/tests/test-import-export.c |  3 +--
>  2 files changed, 1 insertion(+), 19 deletions(-)
> 
> diff --git a/properties/import-export.c b/properties/import-export.c
> index 8fe0364..6e8159d 100644
> --- a/properties/import-export.c
> +++ b/properties/import-export.c
> @@ -647,7 +647,6 @@ do_import (const char *path, const char
> *contents, gsize contents_len, GError **
>   gs_free char *basename = NULL;
>   gs_free char *default_path = NULL;
>   char *tmp, *tmp2;
> - gs_free char *new_contents = NULL;
>   const char *last_seen_key_direction = NULL;
>   gboolean have_certs, have_ca;
>   GSList *inline_blobs = NULL, *sl_iter;
> @@ -683,22 +682,6 @@ do_import (const char *path, const char
> *contents, gsize contents_len, GError **
>   *tmp = '\0';
>   g_object_set (s_con, NM_SETTING_CONNECTION_ID, basename,
> NULL);
>  
> - if (!g_utf8_validate (contents, contents_len, NULL)) {
> - GError *conv_error = NULL;
> - gsize bytes_written;
> -
> - new_contents = g_locale_to_utf8 (contents,
> contents_len, NULL, _written, _error);
> - if (conv_error) {
> - /* ignore the error, we tried at least. */
> - g_error_free (conv_error);
> - g_free (new_contents);
> - } else {
> - g_assert (new_contents);
> - contents = new_contents;  /* update contents
> with the UTF-8 safe text */
> - contents_len = bytes_written + 1;
> - }
> - }
> -
>   if (strncmp (contents, "\xEF\xBB\xBF", 3) == 0) {
>   /* skip over UTF-8 BOM */
>   contents += 3;
> diff --git a/properties/tests/test-import-export.c
> b/properties/tests/test-import-export.c
> index b2a8f0f..96ca13b 100644
> --- a/properties/tests/test-import-export.c
> +++ b/properties/tests/test-import-export.c
> @@ -494,7 +494,6 @@ test_non_utf8_import (void)
>   NMConnection *connection;
>   NMSettingConnection *s_con;
>   NMSettingVpn *s_vpn;
> - const char *expected_cacert = "Attätaenko.pem";
>   char *expected_path;
>   const char *charset = NULL;
>  
> @@ -515,7 +514,7 @@ test_non_utf8_import (void)
>   s_vpn = nm_connection_get_setting_vpn (connection);
>   g_assert (s_vpn);
>  
> - expected_path = g_strdup_printf ("%s/%s", SRCDIR,
> expected_cacert);
> + expected_path = g_strdup_printf ("%s/%s", SRCDIR,
> "Att\344taenko.pem");
>   _check_item (s_vpn, NM_OPENVPN_KEY_CA, expected_path);
>   g_free (expected_path);
>  
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager dispatchers

[Dan Williams]

On Mon, 2016-02-29 at 17:40 -0800, Ali Nematollahi wrote:
> Thanks! I've looked at nmcli radio but there is no good documentation
> I
> could find for the version I am using. All of the documentation is
> for
> newer version and don't apply.

Yeah, you say later you're using NM 0.9.4, which is extremely old (23-
Mar-2012) and I'm not surprised some stuff would be different...

> First of all, when I do:
> 
> nmcli nm wwan
> WWAN
> disabled
> 
> Then I do:
>  nmcli nm wwan on
> nmcli nm wwan
> WWAN
> disabled
> 
> nmcli nm status
> RUNNING STATE   WIFI-HARDWARE   WIFI   WWAN-
> HARDWARE
> WWAN
> running connected   enabled enabledenabled
> disabled

What's in /var/lib/NetworkManager/NetworkManager.state ?

Can you turn on NM log debugging (might be an nmcli command for that)
and see what NM prints out when you do "nmcli nm wwan on"?

Dan

> I was reading on google somewhere that I need a config file
> in: /etc/NetworkManager/system-connections/
> so I put one in:
> 
> cat /etc/NetworkManager/system-connections/radio
> [connection]
> id=MyWwanConnection
> type=gsm
> 
> [ipv4]
> method=auto
> 
> [gsm]
> number=*99#
> apn=mnet.bell.ca.ioe
> 
> 
> restarted NM, did the same thing, no difference.
> 
> Any documentation for 0.9.4.0 that I can use to figure this out? Can
> someone help me with setting up the radio connections? I'm having no
> luck.
> 
> Thanks
> 
> 
> 
> On Fri, Feb 26, 2016 at 2:22 PM, Dan Williams <d...@redhat.com>
> wrote:
> 
> > 
> > On Fri, 2016-02-26 at 10:50 -0800, Ali Nematollahi wrote:
> > > 
> > > Thanks!
> > > 
> > > How to I enable "service called NetworkManager-dispatcher or
> > > nm-dispatcher"? When I search for "dispatcher" in my filesystem
> > > only
> > > these
> > > come up:
> > > /etc/NetworkManager/dispatcher.d
> > > /etc/dbus-1/system.d/nm-dispatcher.conf
> > > /usr/share/dbus-1/system-
> > > services/org.freedesktop.nm_dispatcher.service
> > > /usr/lib/NetworkManager/nm-dispatcher.action
> > > /usr/sbin/usb_modeswitch_dispatcher
> > > 
> > > 
> > > Starting MM as a service makes perfect sense.
> > > The question is however, how do I find out when to say "enable"
> > > the
> > > modem,
> > > or to do a simple-connect? I was planning on using the
> > > dispatchers
> > > for all
> > > of that, to automate all of those. So basically:
> > NetworkManager will take care of that, if 'wwan' radios are
> > enabled.
> >  See 'nmcli radio'.  As long as 'nmcli radio' reports WWAN enabled,
> > and
> > as long as your machine has no airplane switch for WWAN (or if it
> > does
> > the switch enables the WWAN), NetworkManager will enable the modem
> > when
> > it is discovered by ModemManager and it will be available to
> > connect
> > with from NetworkManager.
> > 
> > Recent versions of NetworkManager (1.0.8+) also have support for
> > WWAN
> > autoconnect, so I don't think you need a dispatcher script here at
> > all.
> > 
> > > 
> > > - MM starts
> > > - modem comes up, status -> Disabled
> > >    - dispatcher kicks in: status -> Enabled
> > > - dispatcher kicks in: simple-connect
> > Dispatcher scripts only trigger on connection up/down, so you don't
> > get
> > any events on modem status changes.  But that shouldn't matter,
> > since
> > NetworkManager can take care of all of the WWAN connection stuff as
> > long as ModemManager is up and running (like if its run as a system
> > service).
> > 
> > Dan
> > 
> > > 
> > > Thanks!
> > > 
> > > 
> > > On Fri, Feb 26, 2016 at 12:36 AM, Thomas Haller <thaller@redhat.c
> > > om>
> > > wrote:
> > > 
> > > > 
> > > > On Thu, 2016-02-25 at 17:16 -0800, Ali Nematollahi wrote:
> > > > > 
> > > > > Hi guys
> > > > > 
> > > > > I'm trying to experiment with NM dispatchers but I can't seem
> > > > > to
> > > > > get
> > > > > anything done. I have a very basic script
> > > > > in /etc/NetworkManager/dispatcher.d/02test:
> > > > > 
> > > > > #!/bin/sh -e
> > > > > 
> > > > > echo "Starting ModemManager"
> > > > > ModemManager --debug &
> > > > > 
> 

Backport th/supplicant-manager-fix-ref-count-rh1298007 to 1.0?

[Dan Williams]

Thomas,

Do you think it's worth backporting th/supplicant-manager-fix-ref-
count-rh1298007 to nm-1-0?  I was just looking at https://bugzilla.redh
at.com/show_bug.cgi?id=1241198 and maybe that branch fixes the bug
there.  The only other plausible reason would be memory corruption.
 But 1.0 would benefit from that fix too.  What do you think?

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

Re: NetworkManager dispatchers

[Dan Williams]

On Fri, 2016-02-26 at 10:50 -0800, Ali Nematollahi wrote:
> Thanks!
> 
> How to I enable "service called NetworkManager-dispatcher or
> nm-dispatcher"? When I search for "dispatcher" in my filesystem only
> these
> come up:
> /etc/NetworkManager/dispatcher.d
> /etc/dbus-1/system.d/nm-dispatcher.conf
> /usr/share/dbus-1/system-
> services/org.freedesktop.nm_dispatcher.service
> /usr/lib/NetworkManager/nm-dispatcher.action
> /usr/sbin/usb_modeswitch_dispatcher
> 
> 
> Starting MM as a service makes perfect sense.
> The question is however, how do I find out when to say "enable" the
> modem,
> or to do a simple-connect? I was planning on using the dispatchers
> for all
> of that, to automate all of those. So basically:

NetworkManager will take care of that, if 'wwan' radios are enabled.
 See 'nmcli radio'.  As long as 'nmcli radio' reports WWAN enabled, and
as long as your machine has no airplane switch for WWAN (or if it does
the switch enables the WWAN), NetworkManager will enable the modem when
it is discovered by ModemManager and it will be available to connect
with from NetworkManager.

Recent versions of NetworkManager (1.0.8+) also have support for WWAN
autoconnect, so I don't think you need a dispatcher script here at all.

> - MM starts
> - modem comes up, status -> Disabled
>    - dispatcher kicks in: status -> Enabled
> - dispatcher kicks in: simple-connect

Dispatcher scripts only trigger on connection up/down, so you don't get
any events on modem status changes.  But that shouldn't matter, since
NetworkManager can take care of all of the WWAN connection stuff as
long as ModemManager is up and running (like if its run as a system
service).

Dan

> Thanks!
> 
> 
> On Fri, Feb 26, 2016 at 12:36 AM, Thomas Haller 
> wrote:
> 
> > On Thu, 2016-02-25 at 17:16 -0800, Ali Nematollahi wrote:
> > > Hi guys
> > > 
> > > I'm trying to experiment with NM dispatchers but I can't seem to
> > > get
> > > anything done. I have a very basic script
> > > in /etc/NetworkManager/dispatcher.d/02test:
> > > 
> > > #!/bin/sh -e
> > > 
> > > echo "Starting ModemManager"
> > > ModemManager --debug &
> > > 
> > > But it is not running. I have made sure the scripts and
> > > directories
> > > are executable (a+x). But I cannot seem to get the scripts to
> > > run.
> > > 
> > > Can someone help me with this please?
> > > NetworkManager --version
> > > 0.9.4.0
> > 
> > You probably also need to enable a service called NetworkManager-
> > dispatcher or nm-dispatcher.
> > 
> > 
> > > Question 2: I wanted to use the dispatcher script to start
> > > ModemManager on startup and to enable the 3G modem I have. Can it
> > > be
> > > done? I have seen examples of how to start a connection when an
> > > interface comes up but nothing that could help me with this.
> > 
> > It looks very wrong to start ModemManager from a dispatcher script.
> > Those scripts are invoked often and at various times, you don't
> > want to
> > start ModemManager every time something happens with a networking
> > interface.
> > 
> > Instead, start ModemManager as a regular system service, just like
> > NetworkManager.
> > 
> > 
> > Thomas
> > 
> ___
> 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

[PATCH] libnm-glib/libnm/vpn: fix handling of ConnectInteractive() failure (rh #1298732)

[Dan Williams]

If the plugin supports interactive mode, but the VPN binary (like vpnc
or openvpn) doesn't support it, then the plugin should return
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED from its connect_interactive()
hook.  This lets NetworkManager know to fall back to plain Connect().

Since this notification is done through an error return, the VPN service
plugin code sees the failure and moves the plugin state back to
STOPPED.  NetworkManager sees that state change, and terminates the
connection attempt while waiting for a reply to the Connect() method.

(VPN service plugins that don't support interactive mode at all don't
have this problem because that error is returned before the plugin's
state is moved to STARTING.)

To fix this, do two things:

1) if the connect_interactive() hook fails and returns the error
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED, postpone the STOPPED
state change for a few seconds to allow NM time to fall back to
plain Connect().  We still want to move the plugin state back to
STOPPED eventually, because otherwise it could stay in STARTING
forever.

2) change state to STARTING only if the connect/connect_interactive
plugin hooks were successful.  Otherwise the plugin would still be
in STARTING state, and it's not valid to call Connect()/ConnectInteractive()
during the STARTING state.

https://bugzilla.redhat.com/show_bug.cgi?id=1298732
---
 libnm-glib/nm-vpn-plugin.c| 24 +---
 libnm/nm-vpn-plugin-old.c | 20 +++-
 libnm/nm-vpn-service-plugin.c | 20 +++-
 3 files changed, 47 insertions(+), 17 deletions(-)

diff --git a/libnm-glib/nm-vpn-plugin.c b/libnm-glib/nm-vpn-plugin.c
index 67ddd83..9f941fc 100644
--- a/libnm-glib/nm-vpn-plugin.c
+++ b/libnm-glib/nm-vpn-plugin.c
@@ -301,12 +301,15 @@ fail_stop (gpointer data)
 }
 
 static void
-schedule_fail_stop (NMVPNPlugin *plugin)
+schedule_fail_stop (NMVPNPlugin *plugin, guint timeout_secs)
 {
    NMVPNPluginPrivate *priv = NM_VPN_PLUGIN_GET_PRIVATE (plugin);
 
    nm_clear_g_source (>fail_stop_id);
-   priv->fail_stop_id = g_idle_add (fail_stop, plugin);
+   if (timeout_secs)
+   priv->fail_stop_id = g_timeout_add_seconds (timeout_secs, 
fail_stop, plugin);
+   else
+   priv->fail_stop_id = g_idle_add (fail_stop, plugin);
 }
 
 static void
@@ -439,6 +442,7 @@ _connect_generic (NMVPNPlugin *plugin,
    NMConnection *connection;
    gboolean success = FALSE;
    GError *local = NULL;
+   guint fail_stop_timeout = 0;
 
    if (priv->state != NM_VPN_SERVICE_STATE_STOPPED &&
    priv->state != NM_VPN_SERVICE_STATE_INIT) {
@@ -457,7 +461,6 @@ _connect_generic (NMVPNPlugin *plugin,
    return FALSE;
    }
 
-
    priv->interactive = FALSE;
    if (details && !vpn_class->connect_interactive) {
    g_set_error_literal (error, NM_VPN_PLUGIN_ERROR, 
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED,
@@ -465,22 +468,29 @@ _connect_generic (NMVPNPlugin *plugin,
    return FALSE;
    }
 
-   nm_vpn_plugin_set_state (plugin, NM_VPN_SERVICE_STATE_STARTING);
+   nm_clear_g_source (>fail_stop_id);
 
    if (details) {
    priv->interactive = TRUE;
-   success = vpn_class->connect_interactive (plugin, connection, 
details, error);
+   success = vpn_class->connect_interactive (plugin, connection, 
details, );
+   if (g_error_matches (local, NM_VPN_PLUGIN_ERROR, 
NM_VPN_PLUGIN_ERROR_INTERACTIVE_NOT_SUPPORTED)) {
+   /* Give NetworkManager a bit of time to fall back to 
Connect() */
+   fail_stop_timeout = 5;
+   }
+   g_propagate_error (error, local);
    } else
    success = vpn_class->connect (plugin, connection, error);
 
    if (success) {
+   nm_vpn_plugin_set_state (plugin, NM_VPN_SERVICE_STATE_STARTING);
+
    /* Add a timer to make sure we do not wait indefinitely for the 
successful connect. */
    connect_timer_start (plugin);
    } else {
    /* Stop the plugin from an idle handler so that the Connect
     * method return gets sent before the STOP StateChanged signal.
     */
-   schedule_fail_stop (plugin);
+   schedule_fail_stop (plugin, fail_stop_timeout);
    }
 
    g_object_unref (connection);
@@ -606,7 +616,7 @@ impl_vpn_plugin_new_secrets (NMVPNPlugin *plugin,
    /* Stop the plugin from and idle handler so that the NewSecrets
     * method return gets sent before the STOP StateChanged signal.
     */
-   schedule_fail_stop (plugin);
+   schedule_fail_stop (plugin, 0);
    }
 
    g_object_unref (connection);
diff --git a/libnm/nm-vpn-plugin-old.c b/libnm/nm-vpn-plugin-old.c
index 9bbac41..19f1417 100644
--- a/libnm/nm-vpn-plugin-old.c
+++ 

[PATCH] wifi: ignore monitor interfaces

[Dan Williams]

If a monitor interface is created, NM will grab that interface
and change it to station mode.  That's not very nice.

diff --git a/src/devices/wifi/nm-wifi-factory.c 
b/src/devices/wifi/nm-wifi-factory.c
index 1c8ca47..2d5f8fa 100644
--- a/src/devices/wifi/nm-wifi-factory.c
+++ b/src/devices/wifi/nm-wifi-factory.c
@@ -66,6 +66,7 @@ create_device (NMDeviceFactory *factory,
gboolean *out_ignore)
 {
    NMDeviceWifiCapabilities capabilities;
+   NM80211Mode mode;
 
    g_return_val_if_fail (iface != NULL, NULL);
    g_return_val_if_fail (plink != NULL, NULL);
@@ -79,6 +80,16 @@ create_device (NMDeviceFactory *factory,
    return NULL;
    }
 
+   /* Ignore monitor-mode and other unhandled interface types.
+    * FIXME: keep TYPE_MONITOR devices in UNAVAILABLE state and manage
+    * them if/when they change to a handled type.
+    */
+   mode = nm_platform_wifi_get_mode (NM_PLATFORM_GET, plink->ifindex);
+   if (mode == NM_802_11_MODE_UNKNOWN) {
+   *out_ignore = TRUE;
+   return NULL;
+   }
+
    if (plink->type == NM_LINK_TYPE_WIFI)
    return nm_device_wifi_new (iface, capabilities);
    else
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Problems with gobi 4000 connecting via QMI

[Dan Williams]

On Mon, 2016-02-22 at 20:05 +0100, Harald Jung wrote:
> Hi,
> 
> a firmware update fixes the problem:
> The update did not work with windows 10-64bit, but with windows 7-
> 32bit.
> 
> Firmware Update:
> http://h20564.www2.hp.com/hpsc/swd/public/detail?sp4ts.oid=5405133
> ItemId=ob_152395_1=4060 

Thanks for the update; good to know it's a firmware thing.  They are
always the most frustrating to figure out :)

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

Re: nm-1-2 blocker cleanup

[Dan Williams]

On Mon, 2016-02-22 at 12:27 +0100, Lubomir Rintel wrote:
> Hi,
> 
> with the 1.2 release approaching, we need to decide on which bugs set
> for 1.2 
> milestone need to block the release. No new features should remain in
> the list,
> only things that absolutely need to be fixed before the release such
> as
> regressions.
> 
> I propose that these should be retargetted for nm-1.4: 
> 
> 683206: maximize device availability (IFF_UP/IFF_LOWER_UP) for IPv6
> link-local communication during runtime and after exit
> 699843: leave interface configuration when removing from NM
> management
> 708829: dnssec: support per-connection DNSSEC options for local zones
> 699810: dns: support for unbound with split DNS and DNSSEC
> 746440: improve behavior for assumed and unmanaged devices, do better
> at seamless take over, and don't touch devices
> 760907: fix handling of invalid connections in libnm/libnm-glib

Yeah, I think all of these can get retargeted.

> And I think these should remain blocking 1.2:
> 
> 697370: live reconfiguration of NMDevices

Like Thomas said, what is left to do here?  Obviously we're not going
to fix everything for 1.2 so I think we should just split/clone this
for specific properties and close 697370?

> 
> 740574: support appindicator based systrays (found in Unity, KDE,
> Enlightenment and more)

This one was only about some additional nice-to-have stuff that would
make the applet easier to maintain.  So I went ahead and did the
required dbusmenu changes and applet side (both linked in the bug) but
we have to wait for a code review on Launchpad and a new library
release.  If things happen in the next few weeks I'm happy to merge
that code for 1.2.  But I doubt it...

> 736406: NetworkManager.service should use KillMode=mixed> 
> 740739: cannot activate shared connection on physically disconnected
> ethernet
> 748302: [review] lr/cli-add-master: Make it possible to specify
> master connection/device for any connection profile
> 760998: resync with systemd upstream code before 1.2
> 761389: don't mess with interface handled by clatd
> 762322: reapply does not restore IP configuration
> 762331: revert behavioral change for NM_UNMANAGED_USER_CONFIG being
> overwritable by USER_EXPLICIT

Thomas fixed this one already it seems.

> 762333: ensure autoconnection does not make a device
> !NM_UNMANAGED_USER_EXPLICT
> 341323: [ENH] Verify subject of remote certificate [See dependency
> tree for bug 341323]

Yeah, this one should get enabled, and maybe we even add it to editor
while we're at it.  I think domain_suffix_match is also simpler for
users and administrators to implement anyway.

Anything I didn't comment on I agree with your assessment.

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

Re: Problems with gobi 4000 connecting via QMI

[Dan Williams]

On Fri, 2016-02-12 at 13:10 +0100, Harald Jung wrote:
> Hi,
> 
> i was able to establish a connection via qmicli, but still not with 
> NetworkManager/ModemManager, maybe this information can help to
> solve 
> the problem:

Good info actually; perhaps it's the IPv6 requests.  If you set IPv6
method to "ignore" in NetworkManager does that make things work?

Or with nmcli, something like:

nmcli con mod  ipv6.method ignore

That should cause NM to stop requesting an IPV4V6 context.  But also,
what version of NetworkManager do you have?  Recent versions of NM have
fallback logic to try only IPV4 if V4V6 fails.

Dan

> 
> 
> ThinClient,initial:root:/sys/devices/pci:00/:00:14.0/usb3/3-
> 11 $ 
> qmicli -d /dev/cdc-wdm0 --wds-start-network=web.vodafone.de 
> --client-no-release-cid
> [/dev/cdc-wdm0] Network started
>  Packet data handle: '1138180728'
> [/dev/cdc-wdm0] Client ID not released:
>  Service: 'wds'
>  CID: '9'
> 
> ThinClient,initial:root:/sys/devices/pci:00/:00:14.0/usb3/3-
> 11 $ 
> /usr/sbin/dhcpcd -B -K -L -A -G -c /usr/libexec/nm-dhcp-helper -4
> wwan0
> wwan0: soliciting a DHCP lease
> wwan0: offered 109.46.87.132 from 109.46.87.129
> wwan0: leased 109.46.87.132 for 7200 seconds
> wwan0: adding route to 109.46.87.128/29
> 
> ThinClient,initial:root:~ $ ifconfig wwan0
> wwan0 Link encap:Ethernet  HWaddr 1A:84:89:C5:C6:76
>    inet addr:109.46.87.132  Bcast:109.46.87.135
> Mask:255.255.255.248
>    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>    RX packets:3 errors:0 dropped:0 overruns:0 frame:0
>    TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
>    collisions:0 txqueuelen:1000
>    RX bytes:954 (954.0 B)  TX bytes:1223 (1.1 KiB
> 
> 
> Harald
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/1] all/trivial: rename STRLEN() macro to NM_STRLEN()

[Dan Williams]

On Fri, 2016-02-12 at 12:34 +0100, Thomas Haller wrote:
> We should not have defines/macros in header files without a nm/NM
> prefix.
> STRLEN() was one of the few offendors.
> ---

LGTM.

Dan

>  clients/cli/settings.c|  8 ++---
>  libnm-core/nm-keyfile-reader.c| 12 
>  libnm-core/nm-setting-8021x.c |  8 ++---
>  libnm-core/nm-utils.c |  2 +-
>  libnm-core/tests/test-keyfile.c   |  4 +--
>  libnm-util/nm-setting-8021x.c |  8 ++---
>  libnm-util/nm-utils.c |  2 +-
>  shared/nm-macros-internal.h   |  2 +-
>  src/NetworkManagerUtils.c | 36 +++
> 
>  src/dhcp-manager/nm-dhcp-client.c |  2 +-
>  src/dhcp-manager/nm-dhcp-dhclient-utils.c |  6 ++--
>  src/dhcp-manager/nm-dhcp-systemd.c|  4 +--
>  src/dhcp-manager/tests/test-dhcp-dhclient.c   |  4 +--
>  src/nm-config-data.c  | 10 +++
>  src/nm-config.c   | 10 +++
>  src/nm-dispatcher.c   |  2 +-
>  src/nm-logging.c  |  2 +-
>  src/nm-route-manager.c|  2 +-
>  src/platform/nm-linux-platform.c  |  4 +--
>  src/platform/nm-platform-utils.c  |  4 +--
>  src/platform/nm-platform.c|  6 ++--
>  src/settings/nm-settings.c|  4 +--
>  src/settings/plugins/ibft/reader.c|  4 +--
>  src/settings/plugins/ifcfg-rh/reader.c|  2 +-
>  src/settings/plugins/ifcfg-rh/utils.c |  8 ++---
>  src/settings/plugins/ifnet/net_utils.c|  2 +-
>  src/settings/plugins/keyfile/tests/test-keyfile.c |  6 ++--
>  src/tests/test-general.c  |  4 +--
>  28 files changed, 84 insertions(+), 84 deletions(-)
> 
> diff --git a/clients/cli/settings.c b/clients/cli/settings.c
> index baf0a92..fc7e0c6 100644
> --- a/clients/cli/settings.c
> +++ b/clients/cli/settings.c
> @@ -3328,8 +3328,8 @@ nmc_property_connection_set_lldp (NMSetting
> *setting, const char *prop,
>   char *p = val_strip; \
>   gboolean success; \
>   \
> - if (strncmp (val_strip,
> NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH, STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH)) == 0) \
> - p += STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH); \
> + if (strncmp (val_strip,
> NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH, NM_STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH)) == 0) \
> + p += NM_STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH); \
>   \
>   success = set_func (NM_SETTING_802_1X (setting), \
>   p, \
> @@ -3350,8 +3350,8 @@ nmc_property_connection_set_lldp (NMSetting
> *setting, const char *prop,
>   const char *path, *password; \
>   gboolean success; \
>   \
> - if (strncmp (val_strip,
> NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH, STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH)) == 0) \
> - p += STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH); \
> + if (strncmp (val_strip,
> NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH, NM_STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH)) == 0) \
> + p += NM_STRLEN
> (NM_SETTING_802_1X_CERT_SCHEME_PREFIX_PATH); \
>   \
>   strv = nmc_strsplit_set (p, " \t,", 2); \
>   path = strv[0]; \
> diff --git a/libnm-core/nm-keyfile-reader.c b/libnm-core/nm-keyfile-
> reader.c
> index 6a0584a..41cd9a7 100644
> --- a/libnm-core/nm-keyfile-reader.c
> +++ b/libnm-core/nm-keyfile-reader.c
> @@ -874,17 +874,17 @@ handle_as_scheme (KeyfileReaderInfo *info,
> GBytes *bytes, NMSetting *setting, co
>  
>   /* It's the PATH scheme, can just set plain data.
>    * In this case, @data_len includes */
> - if (   data_len >= STRLEN
> (NM_KEYFILE_CERT_SCHEME_PREFIX_PATH)
> + if (   data_len >= NM_STRLEN
> (NM_KEYFILE_CERT_SCHEME_PREFIX_PATH)
>   && g_str_has_prefix (data,
> NM_KEYFILE_CERT_SCHEME_PREFIX_PATH)) {
>   if (nm_setting_802_1x_check_cert_scheme (data,
> data_len + 1, NULL) == NM_SETTING_802_1X_CK_SCHEME_PATH) {
> - const char *path = [STRLEN
> (NM_KEYFILE_CERT_SCHEME_PREFIX_PATH)];
> + const char *path = [NM_STRLEN
> (NM_KEYFILE_CERT_SCHEME_PREFIX_PATH)];
>   gs_free char *path_free = NULL;
>  
>   if (path[0] != '/') {
>   /* we want to read absolute paths
> because we use keyfile as exchange
>    * between different processes which
> might not have the 

Re: [PATCH 1/1] shared: add nm_streq() and nm_streq0() macro

[Dan Williams]

On Fri, 2016-02-12 at 12:34 +0100, Thomas Haller wrote:
> Using strcmp() to test for string equality is a well known pattern.
> However the inverse logic still hurts my brain every single time,
> especially in more complex expressions.
> 
> nm_streq() should be preferred over strcmp(). And there is a
> counterpart
> nm_streq0() which uses g_strcmp0().
> 
> Kernel and systemd have also streq() macros.

Yeah, I like this.  +1

Dan

> ---
>  shared/nm-macros-internal.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/shared/nm-macros-internal.h b/shared/nm-macros-
> internal.h
> index 4b43b58..2612cff 100644
> --- a/shared/nm-macros-internal.h
> +++ b/shared/nm-macros-internal.h
> @@ -242,6 +242,11 @@ _NM_IN_STRSET_streq (const char *x, const char
> *s)
>  
>  /***
> **/
>  
> +#define nm_streq(s1, s2)  (strcmp (s1, s2) == 0)
> +#define nm_streq0(s1, s2) (g_strcmp0 (s1, s2) == 0)
> +
> +/***
> **/
> +
>  #define NM_PRINT_FMT_QUOTED(cond, prefix, str, suffix, str_else) \
>   (cond) ? (prefix) : "", \
>   (cond) ? (str) : (str_else), \
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] wifi: allow autoconnect on AP/AdHoc mode connections with manual IP configuration

[Dan Williams]

On Thu, 2016-02-11 at 13:21 +0100, Thomas Haller wrote:
> On Mon, 2016-02-08 at 17:03 -0600, Dan Williams wrote:
> > The existing checks assumed that all AP/AdHoc connections would use
> > the
> > shared IP method.  But what we really want to check for here is
> > whether the
> > connection is AP/AdHoc.  Leave the existing 'shared' check for
> > backwards
> > compatibility.
> > 
> > Also move the check above the timestamp check, since the user
> > shouldn't need
> > to manually set a timestamp just to get an AP-mode connection to
> > autoconnect.
> > ---
> >  src/devices/wifi/nm-device-wifi.c | 19 +--
> >  1 file changed, 13 insertions(+), 6 deletions(-)
> > 
> 
> 
> Patch lgtm, but it doesn't apply anywhere.

Sorry, patch was against 1.0.  I've fixed it up for master and pushed
to 1.0 and master.

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

Re: NM ignores knobs regarding ipv6

[Dan Williams]

On Tue, 2016-02-09 at 19:21 +0100, Olaf Hering wrote:
> On Fri, Feb 05, Dan Williams wrote:
> 
> > Can you grab some NM log output?  the NetworkManager openvpn plugin
> > does have support for IPv6, but we need to figure out if:
> > 
> > 1) NM or NM-openvpn is somehow ignoring your request to have them
> > ignore IPv6 configuration
> 
> In nm-connection-editor I had set IPv6 to "Ignore", which I
> interpreted
> as "whenever the peer offers ipv6, just ignore that offering". So
> this
> interpretion of "ignore" was wrong. Not sure which part of the system
> does actually apply the offered addresses and routes. Are you saying
> there might be some sort of autoconfiguration going on, like it could
> be
> done for wired connections?

It could be better documented, it really means "don't do anything IPv6
related in NetworkManager, but don't prevent anything else either".  So
NM isn't touching IPv6, but the kernel also has IPv6 autoconfiguration
capability and that's what is likely running on the interface outside
of NetworkManager.

> Once I changed it to "Automatic (VPN)" the "Routes ..." knob
> appeared.

Now you've allowed NM to handle the IPv6 configuration on the
interface.

> Here the default is for "Use the connection only for resources for
> this
> network" is disabled. Once I checked that box, the default route is
> not
> applied. I did the same already for ipv4 to avoid that all traffic
> goes
> through tun0.

Sounds right.

> For short: now that I have the checkbox for "Use the connection only
> for
> resources for this network" enabled my connection works as expected.
> 
> If something can be done about the misleading "Ignore", that would be
> great.

Yeah, we should add a 'disabled' too.

Dan

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

Re: IP configuration is useless with openvpn

[Dan Williams]

On Wed, 2016-02-10 at 17:16 +0100, Anthony Bourguignon wrote:
> Hi,
> 
> My OpenVPN provider gives ipv6 connectivity. The IP configuration is
> not pushed to client by the server. So, when I connect to the vpn,
> the
> openvpn plugin send no ipv6 configuration to network manager :
> 
>   NetworkManager[3236]:   No IPv6 configuration
> 
> With the openvpn client, it can be superseded with "ifconfig-ipv6" in
> the configuration file.
> 
> In my network-manager conf, I've set the ipv6.addresses and
> ipv6.gateway parameters but they do not seem to be used in that case.
> When the connection goes up, I've only got the ipv4 part, pushed by
> the
> server.
> 
> If I use ip addr and ip route to set the ipv6 addresses once the
> connection is up, everything works fine.
> 
> I also have a warning concerning the tun-ipv6 parameter but it seems
> there's nothing in network-manager to set it :
> 
>   nm-openvpn[18820]: WARNING: 'tun-ipv6' is present in remote config
> but missing in local config, remote='tun-ipv6'
> 
> Any hint ? Something that I missed ?

I don't think you missed anything.  Currently, NM does not seem to
allow static configuration to be used in addition to or in place of the
VPN daemon sending configuration.  That's an oversight, and something
that should get fixed in NM.

I've filed https://bugzilla.gnome.org/show_bug.cgi?id=761832 for this
issue.

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

Re: Problems with gobi 4000 connecting via QMI

[Dan Williams]

On Tue, 2016-02-09 at 05:57 +0100, Harald Jung wrote:
> yeah, its the vodafone apn i always use in my tests.
> It was running for weeks inside an arm based router with the same 
> settings, before i took it back.
> The SIM has a PIN and was succesfully unlocked.

How long is it between when the PIN unlocks and the connection attempt
occurs?

Also, any chance you can connect to the AT port with minicom and run
"AT+CGDCONT?" for me?

Dan

> Harald
> 
> Am 08.02.2016 um 17:32 schrieb Dan Williams:
> > On Mon, 2016-02-08 at 14:51 +0100, Harald Jung wrote:
> > > Hi,
> > > 
> > > finally the notebook was sent to me and i have the same problems.
> > > I use a SIM which has been succesfully used in other notebooks.
> > > The problem is still the same:
> > > 
> > Are you 100% sure the APN used is correct?
> > 
> > Also, does the SIM have a PIN enabled?  I seem to recall some
> > reports
> > that connections right after unblocking the SIM PIN fail, but
> > waiting a
> > bit makes things work.
> > 
> > Dan
> > 
> > > Feb  8 14:52:40 ThinClient NetworkManager[2243]:  keyfile:
> > > add
> > > connection /etc/NetworkManager/system-connections/1&1 Mobile
> > > Broadband
> > > (c29aa52c-56fa-47cd-b0b4-b44b00175d29,"1&1 Mobile Broadband")
> > > Feb  8 14:52:40 ThinClient NetworkManager[2243]:  (cdc
> > > -wdm0):
> > > Activation: starting connection '1&1 Mobile Broadband'
> > > (c29aa52c-56fa-47cd-b0b4-b44b00175d29)
> > > Feb  8 14:52:40 ThinClient NetworkManager[2243]:  (cdc
> > > -wdm0):
> > > device state change: disconnected -> prepare (reason 'none') [30
> > > 40
> > > 0]
> > > Feb  8 14:52:40 ThinClient NetworkManager[2243]: 
> > > NetworkManager
> > > state is now CONNECTING
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple
> > > connect
> > > started...
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple
> > > connect
> > > state (4/8): Wait to get fully enabled
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple
> > > connect
> > > state (5/8): Register
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple
> > > connect
> > > state (6/8): Bearer
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple
> > > connect
> > > state (7/8): Connect
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]:   Modem
> > > /org/freedesktop/ModemManager1/Modem/0: state changed (registered
> > > ->
> > > connecting)
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]: [/dev/cdc-wdm0]
> > > Allocating new client ID...
> > > Feb  8 14:52:40 ThinClient NetworkManager[2243]:  (cdc
> > > -wdm0):
> > > modem state changed, 'registered' --> 'connecting' (reason: user
> > > -requested)
> > > Feb  8 14:52:40 ThinClient ModemManager[2146]: [/dev/cdc-wdm0]
> > > Registered 'wds' (version 1.23) client with ID '1'
> > > Feb  8 14:52:43 ThinClient ModemManager[2146]:  error:
> > > couldn't
> > > get current settings: QMI protocol error (15): 'OutOfCall'
> > > Feb  8 14:52:43 ThinClient ModemManager[2146]: [/dev/cdc-wdm0]
> > > Allocating new client ID...
> > > Feb  8 14:52:43 ThinClient ModemManager[2146]: [/dev/cdc-wdm0]
> > > Registered 'wds' (version 1.23) client with ID '2'
> > > Feb  8 14:52:43 ThinClient ModemManager[2146]:  error:
> > > couldn't
> > > start network: QMI protocol error (64): '(null)'
> > > Feb  8 14:52:43 ThinClient ModemManager[2146]:   Modem
> > > /org/freedesktop/ModemManager1/Modem/0: state changed (connecting
> > > ->
> > > connected)
> > > Feb  8 14:52:43 ThinClient ModemManager[2146]:  Simple
> > > connect
> > > state (8/8): All done
> > > Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc
> > > -wdm0):
> > > modem state changed, 'connecting' --> 'connected' (reason: user
> > > -requested)
> > > Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc
> > > -wdm0):
> > > failed to connect modem: invalid bearer IP configuration
> > > Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc
> > > -wdm0):
> > > device state change: prepare -> failed (reason 'config-failed')
> > > [40
> > > 120 4]
> > > Feb  8 14:52:43 ThinClient NetworkManager[2243]: 
> > > NetworkManager
> > > state is now DISCONNECTED
> > > F

Re: Problems with gobi 4000 connecting via QMI

[Dan Williams]

On Mon, 2016-02-08 at 14:51 +0100, Harald Jung wrote:
> Hi,
> 
> finally the notebook was sent to me and i have the same problems.
> I use a SIM which has been succesfully used in other notebooks.
> The problem is still the same:
> 
Are you 100% sure the APN used is correct?

Also, does the SIM have a PIN enabled?  I seem to recall some reports
that connections right after unblocking the SIM PIN fail, but waiting a
bit makes things work.

Dan

> Feb  8 14:52:40 ThinClient NetworkManager[2243]:  keyfile: add 
> connection /etc/NetworkManager/system-connections/1&1 Mobile
> Broadband 
> (c29aa52c-56fa-47cd-b0b4-b44b00175d29,"1&1 Mobile Broadband")
> Feb  8 14:52:40 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> Activation: starting connection '1&1 Mobile Broadband' 
> (c29aa52c-56fa-47cd-b0b4-b44b00175d29)
> Feb  8 14:52:40 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> device state change: disconnected -> prepare (reason 'none') [30 40
> 0]
> Feb  8 14:52:40 ThinClient NetworkManager[2243]: 
> NetworkManager 
> state is now CONNECTING
> Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple connect 
> started...
> Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple connect 
> state (4/8): Wait to get fully enabled
> Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple connect 
> state (5/8): Register
> Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple connect 
> state (6/8): Bearer
> Feb  8 14:52:40 ThinClient ModemManager[2146]:  Simple connect 
> state (7/8): Connect
> Feb  8 14:52:40 ThinClient ModemManager[2146]:   Modem 
> /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> 
> connecting)
> Feb  8 14:52:40 ThinClient ModemManager[2146]: [/dev/cdc-wdm0] 
> Allocating new client ID...
> Feb  8 14:52:40 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> modem state changed, 'registered' --> 'connecting' (reason: user
> -requested)
> Feb  8 14:52:40 ThinClient ModemManager[2146]: [/dev/cdc-wdm0] 
> Registered 'wds' (version 1.23) client with ID '1'
> Feb  8 14:52:43 ThinClient ModemManager[2146]:  error: couldn't
> get current settings: QMI protocol error (15): 'OutOfCall'
> Feb  8 14:52:43 ThinClient ModemManager[2146]: [/dev/cdc-wdm0] 
> Allocating new client ID...
> Feb  8 14:52:43 ThinClient ModemManager[2146]: [/dev/cdc-wdm0] 
> Registered 'wds' (version 1.23) client with ID '2'
> Feb  8 14:52:43 ThinClient ModemManager[2146]:  error: couldn't
> start network: QMI protocol error (64): '(null)'
> Feb  8 14:52:43 ThinClient ModemManager[2146]:   Modem 
> /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> 
> connected)
> Feb  8 14:52:43 ThinClient ModemManager[2146]:  Simple connect 
> state (8/8): All done
> Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> modem state changed, 'connecting' --> 'connected' (reason: user
> -requested)
> Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> failed to connect modem: invalid bearer IP configuration
> Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> device state change: prepare -> failed (reason 'config-failed') [40
> 120 4]
> Feb  8 14:52:43 ThinClient NetworkManager[2243]: 
> NetworkManager 
> state is now DISCONNECTED
> Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> Activation: failed for connection '1&1 Mobile Broadband'
> Feb  8 14:52:43 ThinClient ModemManager[2146]:   Modem 
> /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> 
> disconnecting)
> Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> device state change: failed -> disconnected (reason 'none') [120 30
> 0]
> Feb  8 14:52:43 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> modem state changed, 'connected' --> 'disconnecting' (reason: 
> user-requested)
> Feb  8 14:52:44 ThinClient ModemManager[2146]:   Modem 
> /org/freedesktop/ModemManager1/Modem/0: state changed (disconnecting 
> -> 
> registered)
> Feb  8 14:52:44 ThinClient NetworkManager[2243]:  (cdc-wdm0): 
> modem state changed, 'disconnecting' --> 'registered' (reason: 
> user-requested
> 
> 
> regards Harald
> 
> 
> Am 20.01.2016 um 13:46 schrieb Harald Jung:
> > Hi,
> > 
> > when another SIM is used, the messages are  "user request" oder 
> > "none", nm-applet gives a messages
> > Creating object path 
> > '/org/freedesktop/NetworkManager/ActiveConnection/1" failed in nm
> > -glib.
> > But I have no logfile from that test.
> > Anyway the connection was tried with the installed Windows and it 
> > worked with any SIM.
> > 
> > 
> > Harald
> > 
> > Am 06.01.2016 um 17:

Re: WPA2-Enterprise and server certificate verification

[Dan Williams]

On Mon, 2016-02-08 at 12:09 +0100, Christian Hesse wrote:
> Hello everybody,
> 
> when networkmanager connects to a WPA/WPA2-Enterprise secured notwork
> it can
> check the validity of the server certificate against a CA
> certificate.
> 
> Connecting to the authentication server does not include a domain
> name,
> though. So by default there is no way to check the certificate CN
> value. This
> results in a potential security issue: If anybody has a certificate
> with
> *any* CN issued by the same CA networkmanager will accept it as
> valid.
> An attacker can set up access points with same SSID and forged
> authentication
> server to phish user credentials and redirect network traffic.
> 
> Since version 2.1 wpa_supplicant supports configuration option
> 'domain_suffix_match' to manually specify a domain (suffix) to match
> the
> server certificate against. 'domain_match' was added later on.
> 
> I would like to see a configuration option within networkmanager for
> this
> setting. Any chance to add that?

Yes, it's come up recently on bugzilla.gnome.org too and it should
likely get added alongside the existing subject matching support.

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

Re: WPA2-Enterprise and server certificate verification

[Dan Williams]

On Mon, 2016-02-08 at 21:35 +0100, Christian Hesse wrote:
> Christian Hesse  on Mon, 2016/02/08 21:23:
> > > Yes, it's come up recently on bugzilla.gnome.org too and it
> > > should
> > > likely get added  
> > 
> > Ah, nice. Do you have a link for the bug? I did not find it...
> > And is anybody working on this?
> 
> Uh, just found this one...
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=341323
> 
> So this is pending since nearly ten years?

No, the bug was originally about alt_subjectmatch functionality which
was added years ago.  It then got "repurposed" by some people to
request the domain_suffix_match functionality which was first added to
wpa_supplicant in version 2.1.  After some back-and-forth with upstream
supplicant about the exact semantics of domain_suffix_match, even that
won't solve everyone's problems, but it's good enough for most people.

Part of the lag here is that there shouldn't have to be 3+ different
options for validating certificates, and people apparently cannot
figure out a good single mechanism to do so.  I think that would
ideally be a list of allowed domains to match, but the supplicant
doesn't implement that.  So we're left with domain_suffix_match which
will work for many people, but apparently not some large users (like
MIT).

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

[PATCH] wifi: allow autoconnect on AP/AdHoc mode connections with manual IP configuration

[Dan Williams]

The existing checks assumed that all AP/AdHoc connections would use the
shared IP method.  But what we really want to check for here is whether the
connection is AP/AdHoc.  Leave the existing 'shared' check for backwards
compatibility.

Also move the check above the timestamp check, since the user shouldn't need
to manually set a timestamp just to get an AP-mode connection to autoconnect.
---
 src/devices/wifi/nm-device-wifi.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/devices/wifi/nm-device-wifi.c 
b/src/devices/wifi/nm-device-wifi.c
index 8ea3b68..4198a8a 100644
--- a/src/devices/wifi/nm-device-wifi.c
+++ b/src/devices/wifi/nm-device-wifi.c
@@ -1140,13 +1140,25 @@ can_auto_connect (NMDevice *device,
 {
NMDeviceWifi *self = NM_DEVICE_WIFI (device);
NMDeviceWifiPrivate *priv = NM_DEVICE_WIFI_GET_PRIVATE (self);
+   NMSettingWireless *s_wifi;
GSList *ap_iter;
-   const char *method = NULL;
+   const char *method, *mode;
guint64 timestamp = 0;
 
if (!NM_DEVICE_CLASS (nm_device_wifi_parent_class)->can_auto_connect 
(device, connection, specific_object))
return FALSE;
 
+   s_wifi = nm_connection_get_setting_wireless (connection);
+   g_return_val_if_fail (s_wifi, FALSE);
+
+   /* Always allow autoconnect for shared/Ad-Hoc/AP */
+   method = nm_utils_get_ip_config_method (connection, 
NM_TYPE_SETTING_IP4_CONFIG);
+   mode = nm_setting_wireless_get_mode (s_wifi);
+   if (   g_strcmp0 (mode, NM_SETTING_WIRELESS_MODE_ADHOC) == 0
+   || g_strcmp0 (mode, NM_SETTING_WIRELESS_MODE_AP) == 0
+   || g_strcmp0 (method, NM_SETTING_IP4_CONFIG_METHOD_SHARED) == 0)
+   return TRUE;
+
/* Don't autoconnect to networks that have been tried at least once
 * but haven't been successful, since these are often accidental choices
 * from the menu and the user may not know the password.
@@ -1156,11 +1168,6 @@ can_auto_connect (NMDevice *device,
return FALSE;
}
 
-   /* Use the connection if it's a shared connection */
-   method = nm_utils_get_ip_config_method (connection, 
NM_TYPE_SETTING_IP4_CONFIG);
-   if (!strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_SHARED))
-   return TRUE;
-
for (ap_iter = priv->ap_list; ap_iter; ap_iter = g_slist_next 
(ap_iter)) {
NMAccessPoint *ap = NM_AP (ap_iter->data);
 
-- 
2.4.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM ignores knobs regarding ipv6

[Dan Williams]

On Fri, 2016-02-05 at 16:49 +0100, Olaf Hering wrote:
> On Fri, Feb 05, Thomas Haller wrote:
> 
> > On Fri, 2016-02-05 at 09:01 +0100, Olaf Hering wrote:
> > > The openvpn connection I have been using for months just gained
> > > support for ipv6. A few months ago I already set ipv6 to
> > > "Disabled"
> > > in the IPv6 tab of nm-connection-editor 1.0.8. But when the
> > > tunnel
> > > is established NM applies the settings received from the peer
> > > anyway.
> > There exists no ipv6 method "Disabled" until now. What exists is
> > "Ignore" which means, NM leaves it all to the kernel.
> 
> What does it leave to the kernel? I think there is nothing the kernel
> can do on tun0, should there be some autonegitation for link-local?
> Its
> unlikely, and tun0 gets just the provided ipv4+ipv6 address. And
> addition also the ipv6 default route is set to tun0.
> Every knob in the ipv6 tab is ignored.

Can you grab some NM log output?  the NetworkManager openvpn plugin
does have support for IPv6, but we need to figure out if:

1) NM or NM-openvpn is somehow ignoring your request to have them
ignore IPv6 configuration

OR

2) NM is honoring your ipv6.method=ignore, and leaving everything to
the kernel, which sends Router Solictiations over tun0 and gets a reply
back from an IPv6 router on the other side of the VPN.

The NM logs should make that pretty clear, and they'll look something
like this:

  VPN connection 'My VPN' (IP4 Config Get) reply received.
  VPN Gateway: 1.2.3.4
  Tunnel Device: asdadf
  IPv4 configuration:
Internal Address: 2.3.4.5
Internal Prefix: 32
Internal Point-to-Point Address: 2.3.4.6
Maximum Segment Size (MSS): 0
Forbid Default Route: yes
Internal DNS: 5.6.7.8
Internal DNS: 5.6.7.9
DNS Domain: 'myvpn.com'
  No IPv6 configuration

If in your logs you see "No IPv6 configuration", then it's the kernel
doing it's IPv6 stuff on the interface.  If you see "IPv6
configuration: " then it's NM not honoring ipv6.method=ignore.

Dan

> > Can you show
> >   nmcli connection show $CONNECTION_ID
> 
> 
> connection.id:  $VPN
> connection.uuid:b210995e-b03d-4f35-882c
> -523fcf3fe264
> connection.interface-name:  --
> connection.type:vpn
> connection.autoconnect: no
> connection.autoconnect-priority:0
> connection.timestamp:   1454686875
> connection.read-only:   no
> connection.permissions: user:olaf
> connection.zone:--
> connection.master:  --
> connection.slave-type:  --
> connection.autoconnect-slaves:  -1 (default)
> connection.secondaries: 
> connection.gateway-ping-timeout:0
> connection.metered: unknown
> ipv4.method:auto
> ipv4.dns:   
> ipv4.dns-search:
> ipv4.addresses: 
> ipv4.gateway:   --
> ipv4.routes:
> ipv4.route-metric:  -1
> ipv4.ignore-auto-routes:no
> ipv4.ignore-auto-dns:   no
> ipv4.dhcp-client-id:--
> ipv4.dhcp-send-hostname:yes
> ipv4.dhcp-hostname: --
> ipv4.never-default: yes
> ipv4.may-fail:  yes
> ipv6.method:ignore
> ipv6.dns:   
> ipv6.dns-search:
> ipv6.addresses: 
> ipv6.gateway:   --
> ipv6.routes:
> ipv6.route-metric:  -1
> ipv6.ignore-auto-routes:no
> ipv6.ignore-auto-dns:   no
> ipv6.never-default: no
> ipv6.may-fail:  yes
> ipv6.ip6-privacy:   0 (disabled)
> ipv6.dhcp-send-hostname:yes
> ipv6.dhcp-hostname: --
> vpn.service-type:  
>  org.freedesktop.NetworkManager.openvpn
> vpn.user-name:  --
> vpn.data:   $cmdline
> vpn.secrets:
> vpn.persistent: no
> GENERAL.NAME:   $VPN
> GENERAL.UUID:   b210995e-b03d-4f35-882c
> -523fcf3fe264
> GENERAL.DEVICES:br0
> GENERAL.STATE:  activated
> GENERAL.DEFAULT:no
> GENERAL.DEFAULT6:   no
> GENERAL.VPN:yes
> GENERAL.ZONE:   --
> GENERAL.DBUS-PATH: 
>  /org/freedesktop/NetworkManager/ActiveConnection/12
> GENERAL.CON-PATH:  
>  /org/freedesktop/NetworkManager/Settings/4
> 

Re: regarding creating a new interface

[Dan Williams]

On Wed, 2016-02-03 at 17:29 +0530, abhash jain wrote:
> Hi All,
> i want to create a new interface and assign it to new NIC. but while
> getting an ip through bootp i am getting following error. can someone
> please help me?
> 
> root@n7k-xb37-pc7 ~]# ifup eth2 -i
> Active connection state: activating
> Active connection path:
> /org/freedesktop/NetworkManager/ActiveConnection/2
> 
> ** (process:12360): WARNING **: _nm_object_get_property: Error
> getting
> 'State' for /org/freedesktop/NetworkManager/ActiveConnection/2: (19)
> Method
> "Get" with signature "ss" on interface
> "org.freedesktop.DBus.Properties"
> doesn't exist
> 
> 
> state: unknown
> Error: Connection activation failed.

What NetworkManager version do you have?  "nmcli -v" will tell you.

Also, can you grab NetworkManager logs and attach them?  Look over them
first to remove personally identifying information if you like.

journalctl -b -u NetworkManager


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

Re: [PATCH] simplify blob handling

[Dan Williams]

On Wed, 2016-02-03 at 11:21 +0100, Thomas Haller wrote:
> On Wed, 2016-02-03 at 10:40 +0100, Matthias Berndt wrote:
> > Hi Thomas,
> 
> Hi Matthias,
> 
> (CC-ing mailing list)
> 
> > 
> > I didn't look at it very closely, but I'd suggest using more
> > conservative 
> > permissions for the certificate files. The current code leads to
> > warnings
> > in the log files:
> > WARNING: file '/home/mberndt/.cert/client-key.pem' is group or
> > others
> > accessible
> > WARNING: file '/home/mberndt/.cert/test-client-ta.pem' is group or
> > others accessible
> 
> I actually did that in a first version of the patches.
> 
> But then I thought, the import code is run by $USER, putting the
> files
> to ~$USER/.certs.
> 
> The openvpn process is run as nm-openvpn:nm-openvpn (or root:root --
> depending whether chroot succeeds). I don't think we can restrict the
> file permissions there.
> 
> ... which really shows how inherently broken it is to handle
> certificates in files (client-side).

Yeah, it can be broken as root should not necessarily be able to read
normal user files; more of a problem if/when openvpn drops permissions
too.

> What is your suggestion?
> 

PKCS#11, URIs, and a certificate store :)  Alternatively the
certificates could be made "secret" in the VPN data and then retrieved
from the secret agent in the user session, but it's much better to just
use a certificate store.

Dan

> Thomas
> 
> > 
> > Cheers,
> > Matthias
> > 
> > > Gesendet: Freitag, 29. Januar 2016 um 14:55 Uhr
> > > Von: "Thomas Haller" 
> > > An: "Matthias Berndt" , networkmanager
> > > -list
> > > @gnome.org
> > > Betreff: Re: [PATCH] simplify blob handling
> > > 
> > > On Tue, 2016-01-26 at 22:57 +0100, Matthias Berndt wrote:
> > > > Hi,
> > > > 
> > > > here's the patch to simplify blob handling.
> > > > 
> > > > Cheers,
> > > > Matthias
> > > > 
> > > 
> > > Hey Matthias,
> > > 
> > > after merging your patch, I reworked the import code more.
> > > 
> > > https://git.gnome.org/browse/network-manager-openvpn/log/?h=th/ov
> > > pn
> > > -import-bgo761285
> > > https://bugzilla.gnome.org/show_bug.cgi?id=761285
> > > 
> > > It's currently on review, but I think this branch should
> > > eventually
> > > get
> > > merged.
> > > 
> > > 
> > > Just in case you wanted to do another cleanup. Or would be
> > > interested
> > > in testing/reviewing it...
> > > 
> > > 
> > > ciao,
> ___
> 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: How to deal with unsupported wpa_supplicant parameters?

[Dan Williams]

On Fri, 2016-01-29 at 18:00 -0500, Eloy Paris wrote:
> Hi Dan,
> 
> On Thu, Jan 28, 2016 at 12:21:24PM -0600, Dan Williams wrote:
> 
> > On Thu, 2016-01-28 at 17:58 +0100, Toby wrote:
> > > I fully understand that this specific TLS1.2 issue is temporary
> > > and
> > > doesn't
> > > need to be addressed specifically. But there are many more
> > > wpa_supplicant
> > > parameters not covered by the settings spec, and there might be
> > > even
> > > more
> > > in upcoming releases. NM will always lag behind to some extend.
> > > Therefore, I'd vote for a custom settings field, which allows to
> > > specify a
> > > list of key/value pairs as a single string (based on a certain
> > > syntax), and
> > > which get's passed thru to wpa_supplicant as a sequence of
> > > parameter/value
> > > combos blindly. This would be a flexible way to address any
> > > potential
> > > future issues directly. Of course, there's no need to expose such
> > > a
> > > setting
> > > to GUIs.
> > 
> > The supplicant does have a ton of options (some useful and some
> > not),
> > but punching a hole through isn't a great solution the problem at
> > hand
> > and doesn't lend itself to a great user experience, whether that's
> > a
> > GUI or a CLI.  Instead, if you think you need to customize some
> > option,
> > we'd love to hear about it so we can figure out if there is a way
> > to
> > achieve your goal using that option, or some other way.
> 
> A bit of feedback from an enduser, if I may:
> 
> I've also found myself in the same situation as Toby, but not with
> some
> wpa_supplicant option but with an openconnect option. I don't
> remember
> the details but as it was I could not establish an OpenConnect VPN
> connection using NetworkManager, so I had to invoke the openconnect
> binary directly, with sudo and everything.
> 
> At that time I thought "it'd be nice if NetworkManager allowed me to
> plug in extra command arguments for openconnect in
> NetworkManager.conf".
> 
> I think at some other time I needed to debug a DHCP problem and
> needed
> to pass special arguments to dhclient. One can create wrappers, of
> course, but I personally prefer tweaking configuration files because
> then my changes are respected and preserved by the package manager.
> 
> So, I do think there is value in providing a way to pass extra
> arguments
> to the binaries that NetworkManager invokes. It should not be
> something
> that is exposed to users via user interfaces but NetworkManager
> cannot
> possibly get 100% right all the time all the options that the
> binaries
> that it spawns support and that could be helped by providing a way to
> add arbitrary arguments.

Yeah, this comes up every so often.  One big problem here is that
NetworkManager is basically a root hole, but a selective one.  It must
enforce the options that get passed to root-y things, and it must do it
well.  Especially if these are passed as command-line arguments to a
process, or if there is any possibility that the arguments will be
interpreted by a shell somewhere.  And that's not easy, and it would
mean additional restrictions on the arguments anyway.  So we'd prefer
to err on the side of caution here and enforce some sanity checking of
arguments, but that means a whitelist and what kind of argument each
one is, which is the current situation.

For plugins that use stdin or some other mechanism (like vpnc) this
isn't an issue.  Nor is this an issue for wpa_supplicant because the
network config is passed with D-Bus.  But for openvpn and others like
openswan/libreswan, it definitely is.

Dan

> Anyway, I do love NetworkManager, and thank all of you for all the
> work
> you put into it.
> 
> Cheers,
> 
> Eloy Paris.-
> 
> 
> > 
> > As I said before, I don't think this warrants a new NMSetting
> > property,
> > but clearly there is need for a different workaround for the TLS
> > v1.2
> > case.
> > 
> > Dan
> > 
> > > I had been hoping for such a feature to exist without being
> > > documented (as
> > > it would be one of the first things I'd implement), but it looks
> > > like
> > > this
> > > is not the case.
> > > Toby
> > > Am 28.01.2016 17:25 schrieb "Dan Williams" <d...@redhat.com>:
> > > 
> > > > On Thu, 2016-01-28 at 09:50 +0100, Toby wrote:
> > > > > Hi,
> > > > > due to a delay in the upgrade of our corporate radius
> > > > > servers, I
> > &

Re: Changing the dnsmasq options for a shared wifi access point?

[Dan Williams]

On Sat, 2016-01-30 at 17:15 +, Ashley Collins wrote:
> Hello,
> 
> I have set up an access point connection to share my Ubuntu 15.10
> laptop's
> network via wifi. I works really well and I can connect Android and
> other
> devices to it.
> 
> I would like to change the default route given out by dnsmasq for the
> connection and I'd also like to add a static route to it via the
> 10.42.0.1
> address so devices can get to it.
> 

Any particular reason to change the default route instead of letting
the iptables NAT rules that NM adds handle it?  Can you describe more
about what you want to do here?

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

Re: networkmanager starts infinite number of VPN daemons

[Dan Williams]

On Fri, 2016-01-29 at 23:44 +0100, Adrian Freihofer wrote:
> Hi Thomas
> 
> Thank you for taking care about this issue.
> With my current setup I'm able to reproduce this. Unfortunately I
> cannot use NetworkManager 1.2. I'm working on a cross compiled
> Embedded System (based on Yocto). I guess NM 1.2 has been ported to
> GObject, which cannot be cross compiled by design.
> Yocto next will provide a solution based on Qemu. But my project is
> not in a phase where I can upgrade the OS to current unstable branch
> right now. Are you able to reproduce and test this?
> I found a workaround to relax the situation for my use case: If the
> interfaces are enabled exclusively NM works more stable. Given this
> patch cannot be back ported this is OK for me now.
> 
> 
> There is another finding related to the the same use case and setup.
> I have a VPN connection configured with autoconnect=true.
> As a physical connection there are three different types available:
> Ethernet, WLAN and Mobile. Due to the problem you hopefully solved
> now,
> they are enabled only exclusively now. With Ethernet and WLAN NM
> works
> perfect: After the physical connection has established, NM
> immediately
> setup the VPN connection. With Mobile connection VPN is not
> automatically
> established by NM. Only a manual trigger gets the VPN connection
> establishing.
> With latest 0.9 version of NM this worked great. With 1.0.10 it does
> not.
> Also rebooting the system behaves similar. The Mobile connection is
> established but not the VPN.

Debug logs from this last case (WWAN+VPN) would be nice to have here.

And just to be sure, you have the VPN connection set as a "secondary"
on the WWAN connection, right?  VPNs don't actually autoconnect, they
are trigged by a parent connection when the parent is finished
activating.

Dan

> May be you have an idea how to solve this too?
> 
> 
> Regards,
> Adrian
> 
> 
> 
> 
> 
> On Fri, 2016-01-29 at 17:32 +0100, Thomas Haller wrote:
> > On Fri, 2016-01-22 at 14:48 +0100, Adrian Freihofer wrote:
> > > Hi,
> > > 
> > > Setup an OpenVPN connection with NetworkManager 1.0.10 is not
> > > always painless... I ended up with a setup where an
> > > infinite number of openvpn daemons tried to connect to one single
> > > server.
> > > The problem seems to be that NetworkManager does not (or at least
> > > not
> > > in any case) stop a VPN connection (stop the
> > > openvpn daemon) to a particular remote before setting up a new
> > > VPN
> > > connection (start an openvpn daemon) to the same
> > > remote.
> > 
> > 
> > It seems the the pending child processes in nm-openvpn-service are
> > not
> > properly tracked.
> > 
> > I opened BZ https://bugzilla.gnome.org/show_bug.cgi?id=761299 for
> > that
> > and patch
> > https://git.gnome.org/browse/network-manager-openvpn/log/?h=th/hand
> > le
> > -child-process-bgo761299
> > is on review. ...
> > 
> > Thought his patch will not trivially backport to nm-1-0 branch...
> > 
> > 
> > 
> > Thomas
> ___
> 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: How to deal with unsupported wpa_supplicant parameters?

[Dan Williams]

On Thu, 2016-01-28 at 09:50 +0100, Toby wrote:
> Hi,
> due to a delay in the upgrade of our corporate radius servers, I
> temporarily need to deactivate TLSv1.2 in phase1 of WPA2/EAP-PEAP, to
> bypass a conflict with wpa_supplicant >=2.4. (known issue)
> In wpa_supplicant.conf this would require a parameter
> phase="tls_disable_tlsv1_2=0".
> But this parameter is not covered by the current settings spec,
> correct?
> How to deal with this situation?
> Is there a way to extend a profile with arbitrary wpa_supplicant
> parameters?
> Or can I merge stuff from wpa_supplicant.conf with settings
> transferred via
> DBUS?
> Or is excluding this WiFi network from being managed by NM the only
> valid
> solution?

Currently, exclusion or downgrading the supplicant to a version that
does not advertise TLS v1.2 support (eg, downgrade to <= 2.3) are the
solutions.  I don't think we want to add a setting property for this
since it will eventually no longer be required, but perhaps a config
file parameter or some other out-of-band mechanism to disable TLS v1.2
where needed would be acceptable, and that can be dropped at a future
date when this is no longer a problem.

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

Re: How to deal with unsupported wpa_supplicant parameters?

[Dan Williams]

On Thu, 2016-01-28 at 17:58 +0100, Toby wrote:
> I fully understand that this specific TLS1.2 issue is temporary and
> doesn't
> need to be addressed specifically. But there are many more
> wpa_supplicant
> parameters not covered by the settings spec, and there might be even
> more
> in upcoming releases. NM will always lag behind to some extend.
> Therefore, I'd vote for a custom settings field, which allows to
> specify a
> list of key/value pairs as a single string (based on a certain
> syntax), and
> which get's passed thru to wpa_supplicant as a sequence of
> parameter/value
> combos blindly. This would be a flexible way to address any potential
> future issues directly. Of course, there's no need to expose such a
> setting
> to GUIs.

The supplicant does have a ton of options (some useful and some not),
but punching a hole through isn't a great solution the problem at hand
and doesn't lend itself to a great user experience, whether that's a
GUI or a CLI.  Instead, if you think you need to customize some option,
we'd love to hear about it so we can figure out if there is a way to
achieve your goal using that option, or some other way.

As I said before, I don't think this warrants a new NMSetting property,
but clearly there is need for a different workaround for the TLS v1.2
case.

Dan

> I had been hoping for such a feature to exist without being
> documented (as
> it would be one of the first things I'd implement), but it looks like
> this
> is not the case.
> Toby
> Am 28.01.2016 17:25 schrieb "Dan Williams" <d...@redhat.com>:
> 
> > On Thu, 2016-01-28 at 09:50 +0100, Toby wrote:
> > > Hi,
> > > due to a delay in the upgrade of our corporate radius servers, I
> > > temporarily need to deactivate TLSv1.2 in phase1 of WPA2/EAP
> > > -PEAP, to
> > > bypass a conflict with wpa_supplicant >=2.4. (known issue)
> > > In wpa_supplicant.conf this would require a parameter
> > > phase="tls_disable_tlsv1_2=0".
> > > But this parameter is not covered by the current settings spec,
> > > correct?
> > > How to deal with this situation?
> > > Is there a way to extend a profile with arbitrary wpa_supplicant
> > > parameters?
> > > Or can I merge stuff from wpa_supplicant.conf with settings
> > > transferred via
> > > DBUS?
> > > Or is excluding this WiFi network from being managed by NM the
> > > only
> > > valid
> > > solution?
> > 
> > Currently, exclusion or downgrading the supplicant to a version
> > that
> > does not advertise TLS v1.2 support (eg, downgrade to <= 2.3) are
> > the
> > solutions.  I don't think we want to add a setting property for
> > this
> > since it will eventually no longer be required, but perhaps a
> > config
> > file parameter or some other out-of-band mechanism to disable TLS
> > v1.2
> > where needed would be acceptable, and that can be dropped at a
> > future
> > date when this is no longer a problem.
> > 
> > Dan
> > 
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH v2] dns: clean up error paths in dns-manager

[Dan Williams]

On Mon, 2016-01-25 at 22:59 +0100, Beniamino Galvani wrote:
> On Mon, Jan 25, 2016 at 12:59:22PM -0600, Dan Williams wrote:
> > From 2370f508df8400b424fec032f8314cea97fdbaef Mon Sep 17 00:00:00
> > 2001
> > From: Dan Williams <d...@redhat.com>
> > Date: Wed, 20 Jan 2016 13:52:59 -0600
> > Subject: [PATCH] dns: clean up error paths in dns-manager
> > 
> > Specifically for resolvconf, if the write succeeded, but the
> > pclose()
> > failed error would be left NULL and SR_ERROR would be returned,
> > which
> > caused a crash in nm_dns_manager_end_updates().
> > ---
> > v2: fixed thaller's comments except for the '\n' which I'll do in
> > another patch
> 
> Looks good to me.
> 

Pushed along with the newline cleanup Thomas requested.

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

[PATCH v2] platform: ignore permanent MAC addresses of all ones (FF:FF:FF:FF:FF:FF)

[Dan Williams]

Drivers are stupid, and just like the platform ignores an all zeros
permanent address, so should it ignore all ones.

NetworkManager[509]:  [1453743778.854919] [devices/nm-device.c:8885] 
nm_device_update_hw_address(): [0x190370] (eth0): hardware address now 
86:18:52:xx:xx:xx
NetworkManager[509]:  [1453743778.855438] [devices/nm-device.c:9138] 
constructed(): [0x190370] (eth0): read initial MAC address 86:18:52:xx:xx:xx
NetworkManager[509]:  [1453743778.861602] [devices/nm-device.c:9148] 
constructed(): [0x190370] (eth0): read permanent MAC address FF:FF:FF:FF:FF:FF
---
 src/platform/nm-platform-utils.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/platform/nm-platform-utils.c b/src/platform/nm-platform-utils.c
index 953ac8c..b0b0b56 100644
--- a/src/platform/nm-platform-utils.c
+++ b/src/platform/nm-platform-utils.c
@@ -142,7 +142,8 @@ nmp_utils_ethtool_get_permanent_address (const char *ifname,
struct ethtool_perm_addr e;
guint8 _extra_data[NM_UTILS_HWADDR_LEN_MAX + 1];
} edata;
-   guint zeros[NM_UTILS_HWADDR_LEN_MAX] = { 0 };
+   static const guint8 zeros[NM_UTILS_HWADDR_LEN_MAX] = { 0 };
+   static guint8 ones[NM_UTILS_HWADDR_LEN_MAX] = { 0 };
 
if (!ifname)
return FALSE;
@@ -161,6 +162,12 @@ nmp_utils_ethtool_get_permanent_address (const char 
*ifname,
if (memcmp (edata.e.data, zeros, edata.e.size) == 0)
return FALSE;
 
+   /* Some drivers return a permanent address of all ones. Reject that too 
*/
+   if (G_UNLIKELY (ones[0] != 0xFF))
+   memset (ones, 0xFF, sizeof (ones));
+   if (memcmp (edata.e.data, ones, edata.e.size) == 0)
+   return FALSE;
+
memcpy (buf, edata.e.data, edata.e.size);
*length = edata.e.size;
return TRUE;
-- 
2.4.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] wwan: retry connect on some errors and save them for log messages

[Dan Williams]

First, cb751012a2f4b8ef236eab2a7c65687c99205806 mistakenly converted the
act_stage_context_step() in connect_ready() to connect_context_clear()
instead of connect_context_step().  This would cause the IP Type retry
logic to fail and no further types to be tried.  It also throws
away the ctx->first_error and causes all errors that MM returns on the
connect attempt to be dropped on the floor.

Second, not all errors should cause an advance to the next IP Type,
since some errors aren't related to it.  Specifically, MM_CORE_ERROR_RETRY
when using Simple.Connect() means that a timeout was reached
in the internal connect logic, not a modem or network error.  In
that case, try the connect again with the same IP Type before advancing
to the next type.

Fixes: cb751012a2f4b8ef236eab2a7c65687c99205806
---
 src/devices/wwan/nm-modem-broadband.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/src/devices/wwan/nm-modem-broadband.c 
b/src/devices/wwan/nm-modem-broadband.c
index 427f3ed..44ac1021 100644
--- a/src/devices/wwan/nm-modem-broadband.c
+++ b/src/devices/wwan/nm-modem-broadband.c
@@ -52,6 +52,7 @@ typedef struct {
MMSimpleConnectProperties *connect_properties;
GArray *ip_types;
guint ip_types_i;
+   guint ip_type_tries;
GError *first_error;
 } ConnectContext;
 
@@ -331,11 +332,17 @@ connect_ready (MMModemSimple *simple_iface,
} else
g_error_free (error);
 
-   /* If the modem/provider lies and the IP type we tried isn't 
supported,
-* retry with the next one, if any.
-*/
-   ctx->ip_types_i++;
-   connect_context_clear (self);
+   if (ctx->ip_type_tries == 0 && g_error_matches (error, 
MM_CORE_ERROR, MM_CORE_ERROR_RETRY)) {
+   /* Try one more time */
+   ctx->ip_type_tries++;
+   } else {
+   /* If the modem/provider lies and the IP type we tried 
isn't supported,
+* retry with the next one, if any.
+*/
+   ctx->ip_types_i++;
+   ctx->ip_type_tries = 0;
+   }
+   connect_context_step (self);
return;
}
 
@@ -485,9 +492,10 @@ connect_context_step (NMModemBroadband *self)
else
g_assert_not_reached ();
 
-   nm_log_dbg (LOGD_MB, "(%s): launching connection with 
ip type '%s'",
+   nm_log_dbg (LOGD_MB, "(%s): launching connection with 
ip type '%s' (try %d)",
nm_modem_get_uid (NM_MODEM (self)),
-   nm_modem_ip_type_to_string (current));
+   nm_modem_ip_type_to_string (current),
+   ctx->ip_type_tries + 1);
 
mm_modem_simple_connect (self->priv->simple_iface,
 ctx->connect_properties,
-- 
2.4.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH v2] platform: ignore permanent MAC addresses of all ones (FF:FF:FF:FF:FF:FF)

[Dan Williams]

On Tue, 2016-01-26 at 13:41 -0500, Chuck Anderson wrote:
> While we're on this topic, what about other types of invalid MAC
> addresses?  Like ones with the Multicast bit set (odd first octet),
> or
> ones with the LAA (Locallay Administered Address) bit set (2nd least
> significant bit of first octet, e,g, x2: x6: xa: xe:).
> 
> For Multicast Ethernet addresses, I don't see how that could ever
> work
> and it would screw up any network it gets attached to because normal
> switches can't learn them.
> 
> For LAA, they aren't supposed to be permanently programmed into a
> device, but there are unfortunately cheap devices out there that use
> non-IEEE-registered OUIs, some of them LAA, so it may be
> unfortunately
> unworkable to ban those.  Network bridge devices and other software
> devices may also use them.

Yes, Multicast should be rejected too.  There are also some older
drivers that used special addresses to indicate some states that we
used to ignore as well.

But I think we need to allow LAA if the device reports it :(

Dan

> On Tue, Jan 26, 2016 at 11:33:49AM -0600, Dan Williams wrote:
> > Drivers are stupid, and just like the platform ignores an all zeros
> > permanent address, so should it ignore all ones.
> > 
> > NetworkManager[509]:  [1453743778.854919] [devices/nm
> > -device.c:8885] nm_device_update_hw_address(): [0x190370] (eth0):
> > hardware address now 86:18:52:xx:xx:xx
> > NetworkManager[509]:  [1453743778.855438] [devices/nm
> > -device.c:9138] constructed(): [0x190370] (eth0): read initial MAC
> > address 86:18:52:xx:xx:xx
> > NetworkManager[509]:  [1453743778.861602] [devices/nm
> > -device.c:9148] constructed(): [0x190370] (eth0): read permanent
> > MAC address FF:FF:FF:FF:FF:FF
> > ---
> >  src/platform/nm-platform-utils.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/platform/nm-platform-utils.c b/src/platform/nm
> > -platform-utils.c
> > index 953ac8c..b0b0b56 100644
> > --- a/src/platform/nm-platform-utils.c
> > +++ b/src/platform/nm-platform-utils.c
> > @@ -142,7 +142,8 @@ nmp_utils_ethtool_get_permanent_address (const
> > char *ifname,
> > struct ethtool_perm_addr e;
> > guint8 _extra_data[NM_UTILS_HWADDR_LEN_MAX + 1];
> > } edata;
> > -   guint zeros[NM_UTILS_HWADDR_LEN_MAX] = { 0 };
> > +   static const guint8 zeros[NM_UTILS_HWADDR_LEN_MAX] = { 0
> > };
> > +   static guint8 ones[NM_UTILS_HWADDR_LEN_MAX] = { 0 };
> >  
> > if (!ifname)
> > return FALSE;
> > @@ -161,6 +162,12 @@ nmp_utils_ethtool_get_permanent_address (const
> > char *ifname,
> > if (memcmp (edata.e.data, zeros, edata.e.size) == 0)
> > return FALSE;
> >  
> > +   /* Some drivers return a permanent address of all ones.
> > Reject that too */
> > +   if (G_UNLIKELY (ones[0] != 0xFF))
> > +   memset (ones, 0xFF, sizeof (ones));
> > +   if (memcmp (edata.e.data, ones, edata.e.size) == 0)
> > +   return FALSE;
> > +
> > memcpy (buf, edata.e.data, edata.e.size);
> > *length = edata.e.size;
> > return TRUE;
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/1] configure.ac: fix LIBNM_GLIB_CFLAGS in configure.ac

[Dan Williams]

On Sat, 2016-01-23 at 19:07 +0100, Thomas Haller wrote:
> We want to specify the min/max version requirements for libnm-gtk
> (the
> user of libnm-glib), not for libnm-glib itself.
> 
> Fixes: a0d4d15ed22fff2ed856ca6291812e96374afc94
> 
> https://mail.gnome.org/archives/networkmanager-list/2016-January/msg0
> 0021.html
> ---
>  Hi,
> 
>  > He also mentioned that NMA_CFLAGS in configure.ac should probably
> be
>  > LIBNM_GLIB_CFLAGS
> 
>  I think it's the other way around.

We have a number of hits for LIBNM_CLFAGS, which is used in all the
libnm-ported stuff:

src/Makefile.am:$(LIBNM_CFLAGS) \
src/connection-editor/Makefile.am:  $(LIBNM_CFLAGS) \
src/libnma/Makefile.am: $(LIBNM_CFLAGS) \
src/utils/Makefile.am:  $(LIBNM_CFLAGS)
src/utils/tests/Makefile.am:$(LIBNM_CFLAGS)
src/wireless-security/Makefile.am:  $(LIBNM_CFLAGS) \

But there are no hits for NMA_CFLAGS, which has been the CFLAGS
Makefile variable for all the libnm-util/libnm-glib stuff since the
beginning.  There are, however, hits for LIBNM_GLIB_CFLAGS and they
only appear in the parts of code that use libnm-glib:

src/libnm-gtk/Makefile.am:  $(LIBNM_GLIB_CFLAGS) \
src/libnm-gtk/tests/Makefile.am:$(LIBNM_GLIB_CFLAGS) \
src/utils/Makefile.am:  $(LIBNM_GLIB_CFLAGS)
src/wireless-security/Makefile.am:  $(LIBNM_GLIB_CFLAGS) \

So I'm thinking that LIBNM_CFLAGS is correct, but since NMA_CFLAGS
isn't used anywhere and since LIBNM_GLIB_CFLAGS is used but isn't
defined anywhere, that s/NMA_CFLAGS/LIBNM_GLIB_CFLAGS is the right
thing to do?

Dan

> 
>  configure.ac | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 25a98c7..39e8c40 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -87,9 +87,9 @@ NMA_CFLAGS="$NMA_CFLAGS 
> -DNM_VERSION_MIN_REQUIRED=NM_VERSION_1_2"
>  NMA_CFLAGS="$NMA_CFLAGS -DNM_VERSION_MAX_ALLOWED=NM_VERSION_1_2"
>  
>  PKG_CHECK_MODULES(LIBNM, [libnm gio-2.0 >= 2.32 gmodule-export-2.0])
> -LIBNM_CFLAGS="$LIBNM_CFLAGS 
> -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_32"
> -LIBNM_CFLAGS="$LIBNM_CFLAGS 
> -DNM_VERSION_MIN_REQUIRED=NM_VERSION_1_2"
> -LIBNM_CFLAGS="$LIBNM_CFLAGS -DNM_VERSION_MAX_ALLOWED=NM_VERSION_1_2"
> +LIBNM_GLIB_CFLAGS="$LIBNM_GLIB_CFLAGS 
> -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_32"
> +LIBNM_GLIB_CFLAGS="$LIBNM_GLIB_CFLAGS 
> -DNM_VERSION_MIN_REQUIRED=NM_VERSION_1_2"
> +LIBNM_GLIB_CFLAGS="$LIBNM_GLIB_CFLAGS 
> -DNM_VERSION_MAX_ALLOWED=NM_VERSION_1_2"
>  
>  PKG_CHECK_MODULES(LIBSECRET, [libsecret-unstable])
>  
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH v2] dns: clean up error paths in dns-manager

[Dan Williams]

>From 2370f508df8400b424fec032f8314cea97fdbaef Mon Sep 17 00:00:00 2001
From: Dan Williams <d...@redhat.com>
Date: Wed, 20 Jan 2016 13:52:59 -0600
Subject: [PATCH] dns: clean up error paths in dns-manager

Specifically for resolvconf, if the write succeeded, but the pclose()
failed error would be left NULL and SR_ERROR would be returned, which
caused a crash in nm_dns_manager_end_updates().
---
v2: fixed thaller's comments except for the '\n' which I'll do in another patch

 src/dns-manager/nm-dns-manager.c | 152 +++
 1 file changed, 76 insertions(+), 76 deletions(-)

diff --git a/src/dns-manager/nm-dns-manager.c b/src/dns-manager/nm-dns-manager.c
index 20af6d2..66cd500 100644
--- a/src/dns-manager/nm-dns-manager.c
+++ b/src/dns-manager/nm-dns-manager.c
@@ -367,7 +367,6 @@ dispatch_netconfig (NMDnsManager *self,
 
if (searches) {
str = g_strjoinv (" ", searches);
-
write_to_netconfig (self, fd, "DNSSEARCH", str);
g_free (str);
}
@@ -415,10 +414,9 @@ write_resolv_conf (FILE *f,
char **options,
GError **error)
 {
-   char *searches_str = NULL;
-   char *nameservers_str = NULL;
-   char *options_str = NULL;
-   gboolean retval = FALSE;
+   gs_free char *searches_str = NULL;
+   gs_free char *nameservers_str = NULL;
+   gs_free char *options_str = NULL;
char *tmp_str;
GString *str;
int i;
@@ -435,11 +433,10 @@ write_resolv_conf (FILE *f,
g_free (tmp_str);
}
 
-   str = g_string_new ("");
-
if (nameservers) {
int num = g_strv_length (nameservers);
 
+   str = g_string_new ("");
for (i = 0; i < num; i++) {
if (i == 3) {
g_string_append (str, "# ");
@@ -453,28 +450,22 @@ write_resolv_conf (FILE *f,
g_string_append (str, nameservers[i]);
g_string_append_c (str, '\n');
}
+   nameservers_str = g_string_free (str, FALSE);
}
 
-   nameservers_str = g_string_free (str, FALSE);
-
if (fprintf (f, "# Generated by NetworkManager\n%s%s%s",
 searches_str ? searches_str : "",
-nameservers_str,
-options_str ? options_str : "") > 0)
-   retval = TRUE;
-   else {
+nameservers_str ? nameservers_str : "",
+options_str ? options_str : "") < 0) {
g_set_error (error,
 NM_MANAGER_ERROR,
 NM_MANAGER_ERROR_FAILED,
 "Could not write " _PATH_RESCONF ": %s\n",
 g_strerror (errno));
+   return FALSE;
}
 
-   g_free (searches_str);
-   g_free (nameservers_str);
-   g_free (options_str);
-
-   return retval;
+   return TRUE;
 }
 
 static SpawnResult
@@ -484,9 +475,9 @@ dispatch_resolvconf (NMDnsManager *self,
  char **options,
  GError **error)
 {
-   char *cmd;
+   gs_free char *cmd = NULL;
FILE *f;
-   gboolean retval = FALSE;
+   gboolean success = FALSE;
int errnosv, err;
 
if (!g_file_test (RESOLVCONF_PATH, G_FILE_TEST_IS_EXECUTABLE)) {
@@ -497,39 +488,46 @@ dispatch_resolvconf (NMDnsManager *self,
return SR_NOTFOUND;
}
 
-   if (searches || nameservers) {
-   cmd = g_strconcat (RESOLVCONF_PATH, " -a ", "NetworkManager", 
NULL);
-   _LOGI ("Writing DNS information to %s", RESOLVCONF_PATH);
-   if ((f = popen (cmd, "w")) == NULL)
-   g_set_error (error,
-NM_MANAGER_ERROR,
-NM_MANAGER_ERROR_FAILED,
-"Could not write to %s: %s\n",
-RESOLVCONF_PATH,
-g_strerror (errno));
-   else {
-   retval = write_resolv_conf (f, searches, nameservers, 
options, error);
-   err = pclose (f);
-   if (err < 0) {
-   errnosv = errno;
-   g_set_error (error, G_IO_ERROR, 
g_io_error_from_errno (errnosv),
-"Failed to close pipe to 
resolvconf: %d", errnosv);
-   retval = FALSE;
-   } else if (err > 0) {
-   _LOGW ("resolvconf failed with status %d", err);
- 

[PATCH] platform: ignore permanent MAC addresses of all ones (FF:FF:FF:FF:FF:FF)

[Dan Williams]

Drivers are stupid, and just like the platform ignores an all zeros
permanent address, so should it ignore all ones.

NetworkManager[509]:  [1453743778.854919] [devices/nm-device.c:8885] 
nm_device_update_hw_address(): [0x190370] (eth0): hardware address now 
86:18:52:xx:xx:xx
NetworkManager[509]:  [1453743778.855438] [devices/nm-device.c:9138] 
constructed(): [0x190370] (eth0): read initial MAC address 86:18:52:xx:xx:xx
NetworkManager[509]:  [1453743778.861602] [devices/nm-device.c:9148] 
constructed(): [0x190370] (eth0): read permanent MAC address FF:FF:FF:FF:FF:FF
---
 src/platform/nm-platform-utils.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/platform/nm-platform-utils.c b/src/platform/nm-platform-utils.c
index 953ac8c..696dcb9 100644
--- a/src/platform/nm-platform-utils.c
+++ b/src/platform/nm-platform-utils.c
@@ -142,7 +142,8 @@ nmp_utils_ethtool_get_permanent_address (const char *ifname,
struct ethtool_perm_addr e;
guint8 _extra_data[NM_UTILS_HWADDR_LEN_MAX + 1];
} edata;
-   guint zeros[NM_UTILS_HWADDR_LEN_MAX] = { 0 };
+   static const guint8 zeros[NM_UTILS_HWADDR_LEN_MAX] = { 0x00 };
+   static const guint8 ones[NM_UTILS_HWADDR_LEN_MAX] = { 0xFF };
 
if (!ifname)
return FALSE;
@@ -156,10 +157,12 @@ nmp_utils_ethtool_get_permanent_address (const char 
*ifname,
 
g_assert (edata.e.size <= NM_UTILS_HWADDR_LEN_MAX);
 
-   /* Some drivers might return a permanent address of all zeros.
-* Reject that (rh#1264024) */
+   /* Some drivers might return a permanent address of all zeros or
+* all ones.  Reject that (rh#1264024) */
if (memcmp (edata.e.data, zeros, edata.e.size) == 0)
return FALSE;
+   if (memcmp (edata.e.data, ones, edata.e.size) == 0)
+   return FALSE;
 
memcpy (buf, edata.e.data, edata.e.size);
*length = edata.e.size;
-- 
2.4.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to create a simple tap0 interface using nmcli

[Dan Williams]

On Mon, 2016-01-25 at 12:21 +, Vincent Fortier wrote:
> Thnx.  So lets say I previously created a bridge interface and linked
> in my
> eth0:
> $ nmcli connection show
> $ nmcli connection delete 
> $ nmcli connection add type bridge \
>  ifname br0 con-name br0
> $ nmcli connection add type bridge-slave \
>  ifname eth0 con-name eth0 master br0
> 
> Presumably I create tap0 then add it to my br0 such as the following:
> 
> $ nmcli connection add type tun \
> 
>   ifname tap0 con-name tap0 \
> 
>   mode tap owner `id -u` ip4 0.0.0.0/24
> $ nmcli connection add type bridge-slave \
>   ifname tap0 con-name tap0 master br0

Here you're creating two separate network profiles.  You only need to
create one profile for tap0 that includes the bridge-slave bits:

$ nmcli connection add type tun \
 ifname tap0 con-name tap0 \
 slave-type bridge master br0 \
 mode tap owner `id -u` ip4 0.0.0.0/24

or:

$ nmcli connection add type tun \
  ifname tap0 con-name tap0 \
  mode tap owner `id -u` ip4 0.0.0.0/24
$ nmcli connection mod tap0 connection.slave-type bridge \
  connection.master br0

'nmcli con add type <*-slave>' is just a short-cut to fill slave-type
for you.  The major point is that whenever you use "nmcli con add" it
will create a *new* connection profile.  You want to either put all
properties in one 'nmcli con add' or you can use 'nmcli con mod' to set
them after creation.

Dan

> Then I would be good to go with qemu and be all-set "automagically"
> at
> every reboot as autoconnect=yes is set by default.
> 
> NM1.2 not yet available under Ubuntu 16.04 alpha (duno if planned to
> be
> included?) so can't test it unless I recompile from source. 
>  Therefore in
> the meantime it's more of a personnal knowledge thing than anything
> else.
> 
> Thnx in advance!
> 
> - vin
> 
> Le lun. 25 janv. 2016 à 03:22, Beniamino Galvani  > a
> écrit :
> 
> > On Mon, Jan 25, 2016 at 02:46:54AM +, Vincent Fortier wrote:
> > > I was wondering how can I create a tap interface using nmcli? 
> > >  Search
> > again
> > > and again witouth luck...
> > 
> > Hi,
> > 
> > creation of tun/tap devices is supported only in NetworkManager
> > 1.2.
> > On such version you can create a tap connection using the command:
> > 
> >  $ nmcli connection add type tun ifname tap0 con-name mytap0 \
> > mode tap owner `id -u` ip4 x.x.x.x/24
> > 
> > The connection will have autoconnect=yes by default and so the
> > device
> > will be created automatically every time NM starts. You can
> > manually
> > enable or disable the connection with:
> > 
> >  $ nmcli connection up mytap0
> >  $ nmcli connection down mytap0
> > 
> > Beniamino
> > 
> ___
> 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: [PATCH] editor: don't show connections for missing device plugins

[Dan Williams]

On Fri, 2016-01-22 at 21:52 +0300, Mikhail Efremov wrote:
> On Fri, 22 Jan 2016 21:51:08 +0300 Mikhail Efremov wrote:
> > If device plugin is missing (e.g. not installed) then no use
> > to show a connection of this type in the list of connections:
> > it can't be used anyway.
> > ---
> >  src/connection-editor/connection-helpers.c | 43
> > ++
> >  1 file changed, 32 insertions(+), 11 deletions(-)
> 
> Well, I'm not sure that this patch can be applied in current state.
> May be there should be some macros for path to plugins directory and
> for plugins names.
> Consider this patch as proof-of-concept.

The editor can also be used to create connections that could then be
deployed to other machines which might have the missing plugin.  eg, an
administrator may wish to create a Bluetooth or WWAN  or ADSL
connection for deployment to clients that have those plugins installed.
 At a minimum there should be some way to enable editing all
connections (which the editor certainly is capable of, even if the
plugins aren't installed) to preserve this functionality.

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

Re: networkmanager starts infinite number of VPN daemons

[Dan Williams]

On Fri, 2016-01-22 at 15:24 +0100, Thomas Haller wrote:
> On Fri, 2016-01-22 at 14:48 +0100, Adrian Freihofer wrote:
> > Hi,
> > 
> > Setup an OpenVPN connection with NetworkManager 1.0.10 is not
> > always painless... I ended up with a setup where an
> > infinite number of openvpn daemons tried to connect to one single
> > server.
> > The problem seems to be that NetworkManager does not (or at least
> > not
> > in any case) stop a VPN connection (stop the
> > openvpn daemon) to a particular remote before setting up a new VPN
> > connection (start an openvpn daemon) to the same
> > remote.
> > 
> > 
> > "systemd-cgls" shows many openvpn processes (most lines deleted)
> > 
> > ├─1 /sbin/init
> > └─system.slice
> > ...
> >   ├─NetworkManager.service
> >   │ ├─ 466 /usr/sbin/NetworkManager --no-daemon
> >   │ ├─1278 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp
> > -lzo 
> > --nobind --dev tun --cipher BF-CBC --auth-nocache
> > --remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script
> > -
> > security 2 --up /usr/lib/networkmanager-openvpn/nm-
> > openvpn-service-openvpn-helper --tun -- --up-restart --persist-key 
> > --
> > persist-tun --management
> > /var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-
> > 46b464487246 unix --management-client-user root --management-
> > client-group root --management-query-passwords --auth-retry
> > interact
> > --route-noexec --ifconfig-noexec --client --ca
> > /etc/openvpn/nempkeys/ca.crt --cert /etc/openvpn/nempkeys/I-
> > mDeqEu.crt --key /etc/openvpn/nempkeys/I-mDeqEu.key --user
> > nm-openvpn --group nm-openvpn
> >   │ ├─2469 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp
> > -lzo 
> > --nobind --dev tun --cipher BF-CBC --auth-nocache
> > --remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script
> > -
> > security 2 --up /usr/lib/networkmanager-openvpn/nm-
> > openvpn-service-openvpn-helper --tun -- --up-restart --persist-key 
> > --
> > persist-tun --management
> > /var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-
> > 46b464487246 unix --management-client-user root --management-
> > client-group root --management-query-passwords --auth-retry
> > interact
> > --route-noexec --ifconfig-noexec --client --ca
> > /etc/openvpn/nempkeys/ca.crt --cert
> > /etc/openvpn/nempkeys/RVg4sR2b.crt --key
> > /etc/openvpn/nempkeys/RVg4sR2b.key --user
> > nm-openvpn --group nm-openvpn
> >   │ ├─2600 /usr/lib/networkmanager-openvpn/nm-openvpn-service
> >   │ ├─3296 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp
> > -lzo 
> > --nobind --dev tun --cipher BF-CBC --auth-nocache
> > --remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script
> > -
> > security 2 --up /usr/lib/networkmanager-openvpn/nm-
> > openvpn-service-openvpn-helper --tun -- --up-restart --persist-key 
> > --
> > persist-tun --management
> > /var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-
> > 46b464487246 unix --management-client-user root --management-
> > client-group root --management-query-passwords --auth-retry
> > interact
> > --route-noexec --ifconfig-noexec --client --ca
> > /etc/openvpn/nempkeys/ca.crt --cert /etc/openvpn/nempkeys/9-
> > hJsBlB.crt --key /etc/openvpn/nempkeys/9-hJsBlB.key --user
> > nm-openvpn --group nm-openvpn
> > ...
> > 
> > 
> > 
> > "ip address" shows many tun devices, some of them with equal IP
> > addresses!
> > ...
> > 10: tun0:  mtu 1500 qdisc pfifo_fast
> > qlen 100
> > link/[65534] 
> > 17: tun2:  mtu 1500 qdisc pfifo_fast
> > qlen 100
> > link/[65534] 
> > 20: tun3:  mtu 1500 qdisc
> > pfifo_fast qlen 100
> > link/[65534] 
> > inet 10.42.0.146 peer 10.42.0.145/32 brd 10.42.0.146 scope
> > global
> > tun3
> >valid_lft forever preferred_lft forever
> > 22: tun4:  mtu 1500 qdisc
> > pfifo_fast qlen 100
> > link/[65534] 
> > inet 10.42.0.146 peer 10.42.0.145/32 brd 10.42.0.146 scope
> > global
> > tun4
> >valid_lft forever preferred_lft forever
> > 23: tun1:  mtu 1500 qdisc
> > pfifo_fast qlen 100
> > link/[65534] 
> > inet 10.42.0.150 peer 10.42.0.149/32 brd 10.42.0.150 scope
> > global
> > tun1
> >valid_lft forever preferred_lft forever
> > 25: tun6:  mtu 1500 qdisc
> > pfifo_fast qlen 100
> > link/[65534] 
> > inet 10.42.0.150 peer 10.42.0.149/32 brd 10.42.0.150 scope
> > global
> > tun6
> >valid_lft forever preferred_lft forever
> > ...
> > 
> > 
> > 
> > How to reproduce?
> > My application basically creates two connections using
> > NetworkManager's dbus interface: Ethernet + WLAN. Then it creates
> > a VPN connection without explicitly specifying the interface used
> > for
> > VPN. NetworkManager does what it is expected to
> > do: Successfully setup the VPN. After that I remove the WLAN or the
> > 

[PATCH] dns: clean up error paths in dns-manager

[Dan Williams]

Specifically for resolvconf, if the write succeeded, but the pclose()
failed error would be left NULL and SR_ERROR would be returned, which
caused a crash in nm_dns_manager_end_updates().
---
 src/dns-manager/nm-dns-manager.c | 126 ++-
 1 file changed, 58 insertions(+), 68 deletions(-)

diff --git a/src/dns-manager/nm-dns-manager.c b/src/dns-manager/nm-dns-manager.c
index 01e8bf1..48f44ea 100644
--- a/src/dns-manager/nm-dns-manager.c
+++ b/src/dns-manager/nm-dns-manager.c
@@ -357,7 +357,6 @@ dispatch_netconfig (NMDnsManager *self,
 
if (searches) {
str = g_strjoinv (" ", searches);
-
write_to_netconfig (self, fd, "DNSSEARCH", str);
g_free (str);
}
@@ -405,10 +404,9 @@ write_resolv_conf (FILE *f,
char **options,
GError **error)
 {
-   char *searches_str = NULL;
-   char *nameservers_str = NULL;
-   char *options_str = NULL;
-   gboolean retval = FALSE;
+   gs_free char *searches_str = NULL;
+   gs_free char *nameservers_str = NULL;
+   gs_free char *options_str = NULL;
char *tmp_str;
GString *str;
int i;
@@ -425,12 +423,9 @@ write_resolv_conf (FILE *f,
g_free (tmp_str);
}
 
-   str = g_string_new ("");
-
if (nameservers) {
-   int num = g_strv_length (nameservers);
-
-   for (i = 0; i < num; i++) {
+   str = g_string_new ("");
+   for (i = 0; i < g_strv_length (nameservers); i++) {
if (i == 3) {
g_string_append (str, "# ");
g_string_append (str, _("NOTE: the libc 
resolver may not support more than 3 nameservers."));
@@ -443,28 +438,22 @@ write_resolv_conf (FILE *f,
g_string_append (str, nameservers[i]);
g_string_append_c (str, '\n');
}
+   nameservers_str = g_string_free (str, FALSE);
}
 
-   nameservers_str = g_string_free (str, FALSE);
-
if (fprintf (f, "# Generated by NetworkManager\n%s%s%s",
 searches_str ? searches_str : "",
-nameservers_str,
-options_str ? options_str : "") > 0)
-   retval = TRUE;
-   else {
+nameservers_str ? nameservers_str : "",
+options_str ? options_str : "") < 0) {
g_set_error (error,
 NM_MANAGER_ERROR,
 NM_MANAGER_ERROR_FAILED,
 "Could not write " _PATH_RESCONF ": %s\n",
 g_strerror (errno));
+   return FALSE;
}
 
-   g_free (searches_str);
-   g_free (nameservers_str);
-   g_free (options_str);
-
-   return retval;
+   return TRUE;
 }
 
 static SpawnResult
@@ -474,10 +463,11 @@ dispatch_resolvconf (NMDnsManager *self,
  char **options,
  GError **error)
 {
-   char *cmd;
+   gs_free char *cmd = NULL;
FILE *f;
-   gboolean retval = FALSE;
+   gboolean success = FALSE;
int errnosv, err;
+   GError *local = NULL;
 
if (!g_file_test (RESOLVCONF_PATH, G_FILE_TEST_IS_EXECUTABLE)) {
g_set_error_literal (error,
@@ -487,39 +477,45 @@ dispatch_resolvconf (NMDnsManager *self,
return SR_NOTFOUND;
}
 
-   if (searches || nameservers) {
-   cmd = g_strconcat (RESOLVCONF_PATH, " -a ", "NetworkManager", 
NULL);
-   _LOGI ("Writing DNS information to %s", RESOLVCONF_PATH);
-   if ((f = popen (cmd, "w")) == NULL)
-   g_set_error (error,
-NM_MANAGER_ERROR,
-NM_MANAGER_ERROR_FAILED,
-"Could not write to %s: %s\n",
-RESOLVCONF_PATH,
-g_strerror (errno));
-   else {
-   retval = write_resolv_conf (f, searches, nameservers, 
options, error);
-   err = pclose (f);
-   if (err < 0) {
-   errnosv = errno;
-   g_set_error (error, G_IO_ERROR, 
g_io_error_from_errno (errnosv),
-"Failed to close pipe to 
resolvconf: %d", errnosv);
-   retval = FALSE;
-   } else if (err > 0) {
-   _LOGW ("resolvconf failed with status %d", err);
-   retval = FALSE;
-   }
-   }
-   } else {
-   cmd = g_strconcat (RESOLVCONF_PATH, " -d ", "NetworkManager", 
NULL);
+   if (!searches && !nameservers) {

[Fwd: RFP: NetworkManager-openconnect - A Feature Request setting group in vpn config]

[Dan Williams]

 Forwarded Message 
From: Riku Meskanen <riku.h.meska...@jyu.fi>
To: Dan Williams <d...@redhat.com>, David Zeuthen <dav...@redhat.com>,
David Woodhouse <dw...@infradead.org>
Subject: RFP: NetworkManager-openconnect - A Feature Request setting
group in vpn config
Date: Sun, 20 Dec 2015 22:48:51 +0200

Hello,

[ Let me first apologise contacting you directly as your contacts are
in AUTHORS file of the NetworkManager-openconnect-1.0.8 package. And I
did not find a more appropriate place where to post this question and
request. Let me know if there is an address for this kind of message
for this piece of software, please. ]

OK, there’s a very useful feature in Cisco Anyconnect client I'm
wishing would be a very useful feature to add in NetworkManager
-openconnect too.

The feature in question is being able to specify the vpn group in
connection config instead using drop-down list while in login window.

It may not be first hand obvious why, sure, but let me explain bit
more.

It is possible to have some groups that are not published (visible in
dropdown) and are still perfectly work with Anyconnect Client.

The trick is to simply appending group name to the vpn server URL ie. 
https://vpn-server/group-name :)

The openconnect CLI does have a bit different syntax, it uses -g switch
but it works also as advertised which is great.

But a bit more about the feature. That is a very useful feature indeed.
It let’s us share one/single/same vpn-service with users that are given
right to access public groups, but also lets us have also non public
vpn groups for more limited use.

Cisco’s documentation and examples about the matter are bit candid
about the matter, but following config snippet may explain it better.

...
tunnel-group student webvpn-attributes
 group-alias student enable
 group-url https://vpn.domain.org/student enable
...

And the Cisco’s documentation about those directives.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/v
pn/asa_91_vpn_config/vpn_groups.html#pgfId-1042120

It’s the "group-alias student enable” above which publishes the group
so that it appears on dropdown list to choose from, but incase we don’t
want to publish for example sysadmin group then we drop that group
-alias line ...

...
tunnel-group sysadmin webvpn-attributes
 group-url https://vpn.domain.org/sysadmin enable
...

That will let sysadmins log in knowing that they connect 
https://vpn.domain.org/sysadmin using Anyconnect or they  can of course
instead use openconnect using command line or some tiny script like
below

#!/bin/sh
#
#
URL=https://vpn.domain.org/
GROUP=vpn-group-here
USER=login-name
PASSWD='password'

echo "$PASSWD" | sudo openconnect -s /etc/vpnc/vpnc-script \
   -g $GROUP -u $USER --passwd-on-stdin $URL

# eof

So the group select feature is there already in CLI version, but in GUI
there is no way setting that group.

Thus my humble request is. Would it be possible to add that feature in
upcoming versions ? 

It would have been great if I had been able to provide you patches, but
the fact is that I haven’t my self developed GUI code to Gnome
or any of these new desktops and I’m far too busy with networking and
other tasks that I would have time to delve in this kind of venture in
foreseeable future.

Cheers,

:-) riku

-- 
Riku Meskanen
University of Jyväskylä
IT Services
email: riku.meska...@jyu.fi








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

Re: NM attempts connecting to nonexistent AP

[Dan Williams]

On Thu, 2015-12-24 at 17:38 -0600, Robby Workman wrote:
> On Thu, 11 Sep 2014 16:47:45 -0500
> Dan Williams <d...@redhat.com> wrote:
> 
> > On Wed, 2014-09-10 at 22:53 -0500, Robby Workman wrote:
> > > Summary: when resuming from sleep, NM attempts to connect to an
> > > AP
> > > that no longer exists.  
> > 
> > Hmm, odd.  You could turn on debugging and enable the "wifi_scan"
> > log
> > domain to see what's going on at resume time.  NM should be
> > throwing
> > away the scan list on resume and requesting a new scan from
> > wpa_supplicant, and all that should be reflected in the debug logs
> > when the wifi_scan domain is enabled.
> 
> 
> I filed this away to debug later, and "later" never arrived :/
> 
> However, a user on LQ reported some dbus messages getting rejected on
> suspend:
> 
> http://www.linuxquestions.org/questions/slackware-14/current-xfce4-po
> wer-manager-error-messages-on-suspend-resume-4175562257/#post5468365
> 
> I'm seeing those here too:
> 
> Dec 22 17:13:54 liberty dbus[1162]: [system] Rejected send message, 4
> matched \
>   rules; type="method_call", sender=":1.66" (uid=1000 pid=5803 \
>   comm="xfce4-power-manager ")
> interface="org.freedesktop.NetworkManager" \
>   member="Sleep" error name="(unset)" requested_reply="0" \
>   destination="org.freedesktop.NetworkManager" \
>   (uid=0 pid=1198 comm="/usr/sbin/NetworkManager ")
> Dec 22 17:16:41 liberty dbus[1162]: [system] Rejected send message, 4
> matched \
>   rules; type="method_call", sender=":1.66" (uid=1000 pid=5803 \
>   comm="xfce4-power-manager ")
> interface="org.freedesktop.NetworkManager" \
>   member="Sleep" error name="(unset)" requested_reply="0" \
>   destination="org.freedesktop.NetworkManager" \
>   (uid=0 pid=1198 comm="/usr/sbin/NetworkManager ")
> 
> I notice that /etc/dbus
> -1/system.d/org.freedesktop.NetworkManager.conf says
> that they are root-only functions:
> 
>   
>send_member="SetLogging"/>
>send_member="Sleep"/>
> 
> and if I change it to allow one of my groups, then I no longer get
> those 
> logged Rejected messages.
> 
> So... three questions here:
> 
> 1) is this possibly related to my original problem report? I'm not
> able to
> test it just yet and won't be until I go back to work after the
> holidays.

If NM doesn't get the Sleep() method call when suspending, then yes it
won't clear the scan list and when the device is moved it may still see
old APs for a bit.

> 2) is xfce4-power-manager supposed to be calling that Sleep here?
> There is
> a configure option to --(en|dis)able-network-manager that is
> currently
> enabled in our build, but if it should be disabled, we can fix that.

Whatever tells the kernel to suspend the system should be calling
Sleep() on NM.  In my experience that's always been a root process
(like upower or systemd or pm-utils), and since Sleep() has the
capability to drastically change you networking, it was restricted to
root-only.  I'm a bit surprised that xfce4-power-manager is trying to
call Sleep() as the normal user, not root, since suspending the machine
takes root privileges anyway.

> 3) what is the expectation for that Sleep? What is supposed to call
> it (or 
> is *anything* supposed to be calling it from outside NM)?

Whatever tells the kernel to suspend (which requires root) should also
be telling NM to Sleep() (and wake).

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

Re: How do I tell NetworkManager a device is actually wired and not wireless?

[Dan Williams]

On Tue, 2015-12-29 at 13:25 -0800, Steven Stewart-Gallus wrote:
> Hello,
> 
> I using CentOS 7 and have a D-Link dwa-130 (revision E) device that
> shows up with a name like enp0s4f1u7.  NetworkManager seems to think
> the
> device is wired and not wireless which prevents me from connecting. 
>  How
> do I tell NetworkManager a device is actually wired and not wireless?
> 

NetworkManager looks at kernel driver attributes to figure out if the
device is wifi or wired.  What version of NetworkManager do you have,
and do you know what kernel driver the DWA-130 is using?

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

Re: RPi-2 Arch multiple modems

[Dan Williams]

On Sun, 2015-12-13 at 13:12 +0100, Thomas Haller wrote:
> On Sat, 2015-12-12 at 19:33 +, John Whitmore wrote:
> > Hello all,
> > 
> > I had a Raspberry Pi running Arch with two USB LTE Modems on two
> > differet
> > Network operators. This was all working perfectly but suddenly
> > crashed mid
> > week. Instead of repairing that old system, I still have it and can
> > go back to
> > it, but I decided that I'd grab a new SD card and install the
> > latest
> > and
> > greatest.
> > 
> > This is where the problem is I create my two LTE network
> > connections
> > and
> > sometimes the network manager seems to be attempting to create
> > network
> > connections on the wrong modem. 
> > 
> > When I pulled one modem I powered up and got an IP Address from one
> > connection
> > but when I couldn't ping anything I had a look in the network
> > manager
> > and it's
> > connected a "Three" operator connection on a "Vodafone" SIM. This
> > used to work
> > perfectly.
> > 
> > BTW as both my modems are exactly the same model I can't
> > distinguish
> > them with
> > udev rules.
> 
> 
> 
> Only recently, on master there are 3 connection properties to match a
> gsm-onnection on a device: device-id, sim-id, and sim-operator-id.
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=756916
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=
> dd2f09c8b166cc5f317a5298f01ea161c63895e6
> 
> I think that would be a solution for you, but the patches are not
> backported to nm-1-0 branch.

I did backport the branch to dcbw/bgo756916-wwan-connection-filters-1-0
but haven't proposed that yet since I haven't had time to test it. 
 However, the backport was pretty smooth.

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

Re: Don't connect to specific *wired* networks?

[Dan Williams]

On Thu, 2015-12-10 at 15:37 -0200, José Queiroz wrote:
> 2015-12-10 14:55 GMT-02:00 Dan Williams <d...@redhat.com>:
> 
> > On Thu, 2015-12-10 at 08:06 -0800, Nikolaus Rath wrote:
> > > Hello,
> > > 
> > > Is there a way to prevent NetworkManager from automatically
> > > connecting
> > > to specific *wired* networks?
> > > 
> > > I think the network could be identified by the presence (or
> > > absence)
> > > of
> > > specific MACs, but I'd be open to other suggestions as well.
> > 
> > That's the best option for now, but of course there are security
> > issues
> > with that since any MAC address can be spoofed.  There are vague
> > plans
> > to attempt to automatically identify wired networks by listening to
> > the
> > wire for a few seconds and detecting 802.1x EAP-Request Identity
> > packet
> > s or ARPing a specific IP address and matching the returned MAC. 
> >  This
> > feature would  have to be opt-in because obviously it would delay
> > network connections.
> > 
> > If that's something you'd be willing to work on, that would be
> > great...
> > what do you say? :)
> > 
> > Dan
> > 
> 
> 
> What about using IPv6 RA messages to do that?

This could be another check among many, yes.  Though to prevent DoS
most routers have a configured minimum advertisement interval which
could be much longer than a few seconds.

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

Re: Don't connect to specific *wired* networks?

[Dan Williams]

On Thu, 2015-12-10 at 08:06 -0800, Nikolaus Rath wrote:
> Hello,
> 
> Is there a way to prevent NetworkManager from automatically
> connecting
> to specific *wired* networks?
> 
> I think the network could be identified by the presence (or absence)
> of
> specific MACs, but I'd be open to other suggestions as well.

That's the best option for now, but of course there are security issues
with that since any MAC address can be spoofed.  There are vague plans
to attempt to automatically identify wired networks by listening to the
wire for a few seconds and detecting 802.1x EAP-Request Identity packet
s or ARPing a specific IP address and matching the returned MAC.  This
feature would  have to be opt-in because obviously it would delay
network connections.

If that's something you'd be willing to work on, that would be great...
what do you say? :)

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

Re: raw-ip support for qmi (mbim?) modems

[Dan Williams]

On Thu, 2015-12-03 at 19:29 +0100, Thomas Schäfer wrote:
>  25. November 2015, 11:12:45  Bjørn Mork:
> > Judgement time coming up :)  What do you think?  Yes, this might
> > not be
> > the correct forum for kernel patches, but I believe it is where
> > this has
> > any meaning.  The load is on userspace here, and there is
> > absolutely no
> > reason to submit this to the kernel unless it is going to be used
> > by
> > NM/MM.
> 
> 
> > The real question
> > is not whether it will work around the firmware bug, but whether
> > and
> > how we should implement the raw-ip support.
> 
> A very silent discussion :-(
> 
> I know that I voted for ethernet-like behavior three years ago - I
> have 
> changed my mind.
> 

Bjorn just posted a patchset adding raw-ip support to netdev.  So it's
not quiet, just quiet here :)

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

Re: [PATCH 1/1] initscript: remove all distribution initscripts

[Dan Williams]

On Tue, 2015-12-01 at 19:22 +0100, Thomas Haller wrote:
> These initscripts weren't modified for a long time. Are they
> just unused or flawless? It seems they are no longer best-practice
> (e.g. NetworkManager supports reloading configuration with SIGHUP,
> which only x implement).
> 
> Nowadays some distributions moved to systemd and quite possible
> nobody uses these scripts. Also, any potential downstream user
> already has a (probably modified) copy of these initscripts.
> 
> Just remove them.
> 

Robby Workman also +1'd on IRC for the Slackware side of things.

Dan

> ---
>  .gitignore|   5 +-
>  configure.ac  |   7 --
>  initscript/Arch/networkmanager.in |  67 
>  initscript/Debian/NetworkManager.in   |  91 
> 
>  initscript/Mandriva/networkmanager.in | 107 
> --
>  initscript/RedHat/NetworkManager.in   | 104 
> -
>  initscript/SUSE/networkmanager.in |  51 --
>  initscript/Slackware/rc.networkmanager.in |  92 
> -
>  initscript/linexa/networkmanager.in   |  59 
>  9 files changed, 2 insertions(+), 581 deletions(-)
>  delete mode 100644 initscript/Arch/networkmanager.in
>  delete mode 100755 initscript/Debian/NetworkManager.in
>  delete mode 100644 initscript/Mandriva/networkmanager.in
>  delete mode 100755 initscript/RedHat/NetworkManager.in
>  delete mode 100644 initscript/SUSE/networkmanager.in
>  delete mode 100644 initscript/Slackware/rc.networkmanager.in
>  delete mode 100644 initscript/linexa/networkmanager.in
> 
> diff --git a/.gitignore b/.gitignore
> index d6a956c..6629338 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -139,9 +139,6 @@ test-*.trs
>  
>  /include/nm-version-macros.h
>  
> -/initscript/Slackware/rc.networkmanager
> -/initscript/*/[Nn]etwork[Mm]anager
> -
>  /introspection/all.xml
>  /introspection/nmdbus-*.c
>  /introspection/nmdbus-*.h
> @@ -276,5 +273,7 @@ test-*.trs
>  # but they were on older versions. Thus keep ignoring them
>  # otherwise when switching branches these untracked files show
>  # up.
> +/initscript/Slackware/rc.networkmanager
> +/initscript/*/[Nn]etwork[Mm]anager
>  /src/settings/plugins/ifnet/tests/check_ifnet
>  
> diff --git a/configure.ac b/configure.ac
> index c028f32..112f4e5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1061,13 +1061,6 @@ clients/Makefile
>  clients/cli/Makefile
>  clients/tui/Makefile
>  clients/tui/newt/Makefile
> -initscript/RedHat/NetworkManager
> -initscript/Debian/NetworkManager
> -initscript/Slackware/rc.networkmanager
> -initscript/SUSE/networkmanager
> -initscript/Arch/networkmanager
> -initscript/Mandriva/networkmanager
> -initscript/linexa/networkmanager
>  introspection/Makefile
>  introspection/all.xml
>  man/Makefile
> diff --git a/initscript/Arch/networkmanager.in
> b/initscript/Arch/networkmanager.in
> deleted file mode 100644
> index 4846427..000
> --- a/initscript/Arch/networkmanager.in
> +++ /dev/null
> @@ -1,67 +0,0 @@
> -#!/bin/bash
> -
> -prefix=@prefix@
> -exec_prefix=@prefix@
> -sbindir=@sbindir@
> -
> -NETWORKMANAGER_BIN=${sbindir}/NetworkManager
> -
> -# general config
> -. /etc/rc.conf
> -. /etc/rc.d/functions
> -
> -# Sanity checks.
> -[ -x $NETWORKMANAGER_BIN ] || exit 0
> -
> -PID=`pidof -o %PPID $NETWORKMANAGER_BIN`
> -case "$1" in
> - start)
> - stat_busy "Starting NetworkManager"
> - [ ! -d /var/run/NetworkManager ] && install -d
> /var/run/NetworkManager
> - if [ -z "$PID" ]; then
> - $NETWORKMANAGER_BIN
> - fi
> - if [ ! -z "$PID" -o $? -gt 0 ]; then
> - stat_fail
> - else
> - add_daemon networkmanager
> - stat_done
> - fi
> - ;;
> - stop)
> - stat_busy "Stopping NetworkManager"
> - [ ! -z "$PID" ] && kill $PID &> /dev/null
> - if [ $? -gt 0 ]; then
> - stat_fail
> - else
> - rm_daemon networkmanager
> - stat_done
> - fi
> - ;;
> - restart)
> - $0 stop
> - sleep 1
> - $0 start
> - ;;
> - sleep)
> - /usr/bin/dbus-send --system \
> - --dest=org.freedesktop.NetworkManager \
> - --type=method_call \
> - /org/freedesktop/NetworkManager \
> - org.freedesktop.NetworkManager.sleep
> - ;;
> - wake)
> - /usr/bin/dbus-send --system \
> - --dest=org.freedesktop.NetworkManager \
> - --type=method_call \
> - /org/freedesktop/NetworkManager \
> - org.freedesktop.NetworkManager.wake
> - ;;
> - *)
> - echo "usage: $0 

Re: Question about captive portal problem

[Dan Williams]

On Wed, 2015-12-02 at 21:23 +0100, Ties Jan Hefting wrote:
> Hello all!
> 
> First of all: thanks for all the hard work of the Network Manager. It
> makes networking as easy as pie! :)
> 
> I have a problem with the captive portal and I think I should direct
> my 
> questions to this mailing list. If not, please let me know who/where
> I 
> should ask about this. ;)
> 
> In my country there is free WiFi in a lot of trains. It uses a
> captive 
> portal, which is detected perfectly and shows the web authentication 
> window to login. To login I only have to tick a tickbox and click a 
> button. However, when I click this button, nothing happens. So, I
> close 
> the window and go in Firefox to the captive portal manually, and
> there 
> the button works.
> 
> One thing I noticed is that it opens a new window/tab after I've
> logged 
> in successfully. If I take a look at the source code, this button 
> submits a form using JavaScript. The form only consists of the 
> beforementioned tickbox. In the 'form' tag the 'target' attribute is
> set 
> to 'connectiontarget', but I can't find that elsewhere in the source 
> code, nor do I know what the HTML spec says about this non-standard 
> value. I know that my Android smartphone handles this well, while
> there 
> seems to be no distinction between desktop and mobile in the login
> page, 
> so I think it's the same web page.
> http://imgur.com/a/BfmY
> Screenshots can be found here: http://imgur.com/a/BfmY
> http://imgur.com/a/BfmYF
> 
> My questions are:
> 1. Is there a log file I can take a look at to find out what's going 
> wrong here?
> 2. Is this a known problem? If so, is there a solution/workaround?
> 3. If this is unexpected behaviour, where can I file a bug report on 
> this?

So NetworkManager itself just handles detecting whether you are behind
a portal or not; neither it (or nm-applet) actually show the login
browser window.  That's handled by your desktop environment, in your
case GNOME Shell, so that's where the bug really lies.  I'd imagine the
problem could be that the login windows run a pretty limited browser,
but I'm surprised that it wouldn't handle the Javascript parts.

Best thing to do is to file a bug in the GNOME Bugzilla at 
https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-shell against
the "portal-helper" component and include the source of the login page.
 They should be able to help you track it down.

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

Re: MC 7304 ipv4v6

[Dan Williams]

On Wed, 2015-11-25 at 08:51 +0100, Bjørn Mork wrote:
> Dan Williams <d...@redhat.com> writes:
> 
> > Well, if we're going to add rawip support, why bother emulating a
> > netdev at all?
> 
> (assuming you mean etherdev - we'll need the netdev in any case :)
> 
> Good question. Asked before, but I have fewer and fewer arguments. I
> know Marcel H has wanted a raw device from the beginning.
> 
> > I guess because it's convenient and we don't have to
> > destroy the existing wwan0 and create some other tun-type device
> > instead.  But still, seems odd that we'd set raw-ip mode and then
> > emulate ethernet when all that's really going back and forth is IP.
> 
> Yes, it is odd and it does create a few problems which the driver
> tries
> to hide.  It would be more honest to just let userspace decide what
> to
> do, e.g, wrt bridging.
> 
> So when the firmware finally gave up messing with the L2 headers, why
> should the driver continue to do that? Make it raw IP all the way. 
>  Yes,
> I'm starting to lean to that side as well.
> 
> The only "real" objection I once had was that I don't think there are
> any DHCP clients on Linux that will work with such an interface. But
> that is a lousy excuse. Using DHCP here is another bad idea, trying
> to

The downside is that we know some QMI devices don't support the static
IP configuration returned by GetCurrentSettings.  They only allow DHCP,
or at least DHCP seems to kick the device into actually talking. 
 However, maybe that's just a problem in 802.3 mode and raw-ip always
works on those devices with GetCurrentSettings static info?  Not sure,
but something to make sure we test...

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

Re: MC 7304 ipv4v6

[Dan Williams]

On Tue, 2015-11-24 at 23:52 +0100, Bjørn Mork wrote:
> Bjørn Mork <bj...@mork.no> writes:
> > Dan Williams <d...@redhat.com> writes:
> > > On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote:
> > > 
> > > My vote would be sysfs, with values "raw-ip" or "802.3" that you
> > > can
> > > read and write to the file.  At least then they are human
> > > -readable. 
> > >  It's also easier to use from scripts than parsing ethtool
> > > output.
> > 
> > Maybe even easier with a boolean qmi/raw_ip file, since we are only
> > going
> > to offer two alternatives anyway?  Then you don't have to figure
> > out
> > what strings are accepted, and we won't end up having to parse
> > 'raw-ip/rawip/raw_ip/rwa-ip/rawIP/etc'.
> 
> Including a demo patch (not tested...) to illustrate what I mean:
> 
>  $ cat /sys/class/net/wwan1/qmi/raw_ip 
>  N
>  # echo Y >/sys/class/net/wwan1/qmi/raw_ip
> 
> etc

Well, if we're going to add rawip support, why bother emulating a
netdev at all?  I guess because it's convenient and we don't have to
destroy the existing wwan0 and create some other tun-type device
instead.  But still, seems odd that we'd set raw-ip mode and then
emulate ethernet when all that's really going back and forth is IP.

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

Re: MC 7304 ipv4v6

[Dan Williams]

On Tue, 2015-11-24 at 20:55 +0100, Thomas Schäfer wrote:
> Am Dienstag, 24. November 2015, 16:06:22 schrieben Sie:
> > On Mon, 23 Nov 2015 22:42:09 +0100
> > 
> 
> > 
> > Would you be more specific about the problems you have and attach
> > more
> > information?
> > * What NM, MM versions do you use?
> 
> mmcli 1.4.10
> nmcli tool, version 1.0.6
> 
> > * NM, MM logs
> 
> are attached. (maybe I have to repeat the test with more debug
> levels, there 
> is something wrong about /etc/resolv.conf - the file was correct set
> by NM)
> 
> 
> > * mmcli -L
> Found 1 modems:
> /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless,
> Incorporated] 
> MC7304
> 
> > * nmcli con show 
> 
> is attached.
> 
> I made also a trace with wireshark - mc7304.pcapng 
> It contains 
> ping to 8.8.8.8 (working)
> ping6 2600::   (not working)

What if you try to ping6 your DNS server at
 2a01:598:7ff:0:10:74:210:210 ?  Also, can you report the output of:

ip addr
ip -6 route

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

Re: MC 7304 ipv4v6

[Dan Williams]

On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote:
> Reinhard Speyerer  writes:
> 
> > This looks rather similar to the "Dualstack errors with MC7354"
> > problem
> > described here 
> > https://forum.sierrawireless.com/viewtopic.php?f=117=8295 .
> > 
> > Apparently the qmi_wwan patch contained in the thread was not
> > submitted
> > as a Linux kernel patch so far.
> 
> Ouch, bad conscience hitting hard... Again.
> 
> The patch will probably solve the problem, but it makes all the
> header
> fixup magic ten times worse. And at the time I was in doubt whether
> the
> use case was really important enough to warrant a workaround as ugly
> as
> this.  So I wanted to let it rest in the back of my head for a while,
> before making up my mind. The only problem is that there is very
> littly
> that will stick there... And I forgot all about it. Sorry
> 
> (Note that I'm definitely not criticizing the code - it's ugly
> because
> this is an ugly problem. And as the thread shows, I failed to create
> the
> simple solution I hoped for.)
> 
> Thanks for bringing this up again.  I guess we must do something
> about
> it.  But. given the current MC74xx development, I'm really
> tempted
> to say 'use raw IP' in this case.  The thing is, it looks like we
> have
> to support raw IP mode anyway. If so, then we might as well (ab)use
> it
> as workaround for any such header problem instead of adding even more
> specialized ugly header rewriting.
> 
> What do you think?  Is "dual-stack on MC7354" another candidate for
> raw
> IP? If we are going to add it anyway, that is.
> 
> Anyone have any wishes for raw IP driver API/UI?  So far I've added
> about 3 such APIs, and they are all different, non-standard,
> difficult
> to understand and dissatisfying in all ways.  So I think it's best to
> use a completely new method now ;)
> 
> Seriously, if anyone has a good idea then I'm all open for
> proposals. The only requirements I have is that it should be runtime
> configurable and it must be settable per netdev.  I.e., you should be
> able to use both 802.3 and raw-ip qmi_wwan devices at the same time.
> 
> The current approach I use for testing (which I believe I have posted
> a
> few years ago) is ethtool private driver flags.  That's at least a
> standard API.  But I'm all open for sysfs too. Either way, user space
> will have to know about this setting and what it's good for.  And
> sysfs
> has the advantage that you don't need any tool to use it. The cdc_ncm
> sysfs files slipped in without much trouble (although I don't know if
> anyone are using them), so I guess we have a fair chance getting
> something like qmi/linkprotocol or similar accepted too.

My vote would be sysfs, with values "raw-ip" or "802.3" that you can
read and write to the file.  At least then they are human-readable. 
 It's also easier to use from scripts than parsing ethtool output.

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

Re: MC 7304 ipv4v6

[Dan Williams]

Adding libqmi-devel...

On Tue, 2015-11-24 at 21:40 +0100, Reinhard Speyerer wrote:
> [ please keep me CCed, I am not subscribed to the mailing list ]
> 
> On Tue, Nov 24, 2015 at 08:55:42PM +0100, Thomas Schäfer wrote:
> > Am Dienstag, 24. November 2015, 16:06:22 schrieben Sie:
> > > On Mon, 23 Nov 2015 22:42:09 +0100
> > > 
> > 
> > > 
> > > Would you be more specific about the problems you have and attach
> > > more
> > > information?
> > > * What NM, MM versions do you use?
> > 
> > mmcli 1.4.10
> > nmcli tool, version 1.0.6
> > 
> > > * NM, MM logs
> > 
> > are attached. (maybe I have to repeat the test with more debug
> > levels, there 
> > is something wrong about /etc/resolv.conf - the file was correct
> > set by NM)
> > 
> > 
> > > * mmcli -L
> > Found 1 modems:
> > /org/freedesktop/ModemManager1/Modem/0 [Sierra Wireless,
> > Incorporated] 
> > MC7304
> > 
> > > * nmcli con show 
> > 
> > is attached.
> > 
> > I made also a trace with wireshark - mc7304.pcapng 
> > It contains 
> > ping to 8.8.8.8 (working)
> > ping6 2600::   (not working)
> > 
> > 
> 
> This looks rather similar to the "Dualstack errors with MC7354"
> problem
> described here 
> https://forum.sierrawireless.com/viewtopic.php?f=117=8295 .
> 
> Apparently the qmi_wwan patch contained in the thread was not
> submitted
> as a Linux kernel patch so far.

Bjorn, is this still needed?  If so, any chance you could work on a
fixup patch?

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

Re: [RFC] Revise NM behavior for Unmanaged Devices and Assuming Connections (bgo 746440)

[Dan Williams]

On Mon, 2015-11-09 at 17:43 +0100, Thomas Haller wrote:
> Hi,
> 
> 
> Regarding bug https://bugzilla.gnome.org/show_bug.cgi?id=746440,
> about
> unmanaged devices and assuming connections.
> 
> The current behavior is broken and for nm-1-2 this shall be fixed as
> follows:
> 
> Basically, let NM be less smart and instead of "assuming connections"
> let it "activate-gracefully".
> 
> 
> 
> 
> NetworkManager State and Device State
> =
> 
> For doing the right thing when NM starts (after systemctl restart),
> we must know the previous device state.
> 
> Whenever NM activates, manages or unmanges a device, it will write
> the
> device-state to /var/lib/NetworkManager/NetworkManager.state The
> statefile will get the following new entries:
> 
> [main]
> # When we write the statefile, we also remember the boot-id
> # from /proc/sys/kernel/random/boot_id. We need it to properly
> # detect last_seen_current_boot below.
> boot_id=
> 
> 
> # A unique keyfile section for each device-entry.
> # The following keys are under this group.
> [d/43]
> # a mandatory ifname
> ifname=eth0

I'm wondering about device renames, which can happen at any point. 
 Should we just use the ifindex here instead?  That won't change for
any device unless the device has been deleted and re-created (or
hotplugged) at which point we can probably consider it a new device
anyway, at least for virtual devices.

> # optionally, the hwaddress if available. Note that the
> ifname/hwaddr
> # pair consists the key for the entry. When checking the state
> for
> # a device, we first look for an entry which has the same
> ifname/hwaddr
> # pair. If not found, we ignore the hwaddr.
> hwaddr=00:11:22:33:44:55
> 
> # the managed state with
> # STATE = true | false
> managed=STATE
> 
> # last-seen timestamp in POSIX-time (time()). This
> # is so that we can prune the statefile from devices
> # that we didn't see for a while.
> last_seen_timestamp=1447082472
> 
> # Had NM a connection on the device active? This
> # only makes sense for managed=true. Note that
> # this entry will be ignored when the boot-id differs,
> # that means: it's only considered after a restart, not
> # after system reboot.
> last_connection=$CONNECTION_UUID
> 
> 
> The last_seen_timestamp is there to eventually garbage collect the
> state entry. Note that we write a state-entry for every device we
> see.
> Docker for example creates veth devices with unique names so we must
> eventually forget about devices that we didn't see for a while.
> I think NM should handle  many devices and if the state
> -
> list grows larger, we must prune the older ones.

I don't see a great need to make the number configurable right now.  I
know some systems have hundreds of software devices, but maybe we just
put a cap on the number (500?) and see if it needs to be configurable
through experience.

> 
> Whether to manage a device
> ==
> 
> When NM sees a new device, it will very early decide whether to
> manage
> it (nm_device_finish_init()).
> 
> Preferably, we look at the statefile. If the statefile from a
> previous
> NM run indicates whether the device should be mananged/unmanged, do
> it.
> That means, when the user sets
>   nmcli device eth0 set managed on|off
> we will remember that decision in the statefile (yeay).
> 
> In the absence of a statefile entry, we obey other configuration,
> such
> as udev's NM_MANAGED or NM.conf's unmanaged-devices.
> 
> In the absence of any configuration, we manage hardware devices but
> don't manage software devices.

Do you mean how NM currently does, where software devices it creates
are managed, but externally created ones are unmanaged by default?  If
so I agree.

> 
> Note that NM_UNMANAGED_DEFAULT_UNMANAGED goes away (WIP: refactor
> default-unmanged bug 746566 , lr/default-unmanaged-bgo746566).
> 
> 
> 
> Unmanaged Devices
> =
> 
> For unmanaged devices, that's pretty much it. The device is in state
> unmanaged and NM doesn't touch it. No IFF_UP, no sysctl change, etc.
> User can manage the device anytime via `nmcli device set eth0 managed
> yes` or just by activating a connection on it (unless the device
> cannot
> be managed for other reasons like NM_UNMANAGED_PLATFORM_INIT).
> 
> Note that even for unmanaged devices, we already expose the
> Ip4Config/Ip6Config objects and other runtime information. So the
> user
> can see the IP configuration also for unmanaged devices.
> 
> What we will do here however, if we succeed to
> nm_device_generate_connection() on the device, we will add a new in-
> memory NMSettingsConnection and pretend that that connection is
> active
> on the device. That setting will be updated whenever the device
> changes.
> We will not nm_utils_match_connection(), we just generate a new one.
> However, the user can persist the in-memory connection and 

Re: Approaching NetworkManager 1.2

[Dan Williams]

On Sat, 2015-11-21 at 10:02 +0100, Olaf Hering wrote:
> On Fri, Nov 13, Dan Williams wrote:
> 
> > Again, if you can get dispatcher debugging that would be great. 
> >  Slaves
> > should never have IP information *unless it's been added externally
> > to
> > NM* by something, since they are slaves.
> 
> I think the VPN route error happend with gsm. This week the reconnect
> did not even trigger the scripts.
> 
> Not sure why the eth got an address. Perhaps GNOME was messing around
> with the onboard card?
> 
> I'm have this in place as a dispatcher script. Is this similar to
> what
> the nm-dispatcher command would log?

Yeah, it should be.  When you see the issue again, lets see what the
logs from the file are like.

Dan

> #!/usr/bin/env bash
> dnsmasq_dyn_dir="/dev/shm/dnsmasq.d"
> dnsmasq_dyn_env="${dnsmasq_dyn_dir}/nm_dispatcher.env.txt"
> _x() {
> rm -f "${dnsmasq_dyn_env}.$$"
> }
> trap _x EXIT
> #
> mkdir -vp "${dnsmasq_dyn_dir}"
> {
> date -u
> cat /proc/uptime
> echo "$0 $*"
> env | sort
> } > "${dnsmasq_dyn_env}.$$"
> cat "${dnsmasq_dyn_env}.$$" >> "${dnsmasq_dyn_env}"
> #
> 
> Olaf
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to tell NM to ignore some interfaces

[Dan Williams]

On Wed, 2015-11-18 at 09:06 +, Jetchko Jekov wrote:
> OK, I checked  /usr/lib/udev/rules.d/85-nm-unmanaged.rules.
> I extended it for my purposes (w)hy there aren't rules by default for
> libvirt and docker bridges btw?

NM makes a distinction between software/virtual interfaces (like
bridge/bond/team/macvlan/tap/etc) and hardware ones.  By default NM
will manage hardware interfaces because they always exist.  But for
virtual interfaces NM will not manage that interface by default if NM
did not create it.

But for the VM-type interfaces exposed by VMWare, VirtualBox, others
and veth it's not easy to determine, so NM uses the udev rules to do so
instead of hardcoding things like driver names and whatnot in NM
itself.

> I am including updated rules file.
> With all this in place. (NM config file is still the same)
> 
> $ udevadm test /sys/class/net/tap0
> [ -- cut -- ]
> ACTION=add
> DEVPATH=/devices/virtual/net/tap0
> ID_MM_CANDIDATE=1
> ID_NET_DRIVER=tun
> ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
> IFINDEX=6
> INTERFACE=tap0
> NM_UNMANAGED=1
> SUBSYSTEM=net
> SYSTEMD_ALIAS=/sys/subsystem/net/devices/tap0
> TAGS=:systemd:
> USEC_INITIALIZED=184623250
> 
> I see NM_UNMANAGED=1 is there. Still, when I open my vpn connection
> NM is
> running dhclient on it.
> Whats more interesting is that it first kills my dhclient which is
> run from
> openvpn's up script..
> Whats even more interesting is that this tap0 interface ends up with
> 2 IPs
> obtained via dhcp 

NM should not be doing this.  We'll look into it; is there any chance
you could file a bug on bugzilla.gnome.org with the info so it doesn't
get lost/forgotten/etc?

Dan

> Jeka
> 
> 
> 
> 
> 
> 
> 
> On Tue, Nov 17, 2015 at 11:45 PM Dan Williams <d...@redhat.com>
> wrote:
> 
> > On Tue, 2015-11-17 at 13:30 +, Jetchko Jekov wrote:
> > > Hi,
> > > Here it is.
> > 
> > NM will always detect all kernel interfaces and expose them through
> > its
> > APIs, but it will *not* necessarily actively manage them.  That is
> > what
> > an "unmanaged" device means.  But NM will still reflect the state
> > of
> > that device through its D-Bus API.s
> > 
> > In your case, it appears that NM is touching the interface in a few
> > cases, first for IPv6LL and second for the arping.  NM probably
> > shouldn't be doing these things.
> > 
> > Anyway, there are two mechanisms for marking devices as "unmanaged"
> > with NM 1.0.x and later:
> > 
> > 1) NetworkManager.conf with unmanaged-devices; it appears that you
> > have
> > configured this correctly so far, but Thomas would know more.
> > 
> > 2) udev rules; all virtual-type interfaces should already be marked
> > 'unmanaged' by udev rules shipped with NetworkManager in
> >  /usr/lib/udev/rules.d/85-nm-unmanaged.rules.  You can add
> > additional
> > rules by copying that file to /etc/udev/rules.d and modifying it
> > for
> > your own purposes.
> > 
> > Dan
> > 
> > 
> > > Jeka
> > > 
> > > On Tue, Nov 17, 2015 at 2:25 PM Thomas Haller <thal...@redhat.com
> > > >
> > > wrote:
> > > 
> > > > On Mon, 2015-11-16 at 21:58 +, Jetchko Jekov wrote:
> > > > > OK, I spent some time with filtering of NM log. I removed the
> > > > > debug
> > > > > lines related to WiFi connections management (they contain
> > > > > way
> > > > > too
> > > > > much sensitive data IMO, and are irrelevant to my problem
> > > > > anyway).
> > > > > Still the resulting file is around 280k (1,5k lines), so the
> > > > > question
> > > > > is:  Is it OK to attach such "huge" file here? Or shall I
> > > > > gzip
> > > > > (bzip2/xz ) it first?
> > > > 
> > > > If you compress it, it should be small enough.
> > > > Otherwise, you can send it to me off-list.
> > > > 
> > > > Thomas
> > > ___
> > > 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: How to tell NM to ignore some interfaces

[Dan Williams]

On Tue, 2015-11-17 at 13:30 +, Jetchko Jekov wrote:
> Hi,
> Here it is.

NM will always detect all kernel interfaces and expose them through its
APIs, but it will *not* necessarily actively manage them.  That is what
an "unmanaged" device means.  But NM will still reflect the state of
that device through its D-Bus API.s

In your case, it appears that NM is touching the interface in a few
cases, first for IPv6LL and second for the arping.  NM probably
shouldn't be doing these things.

Anyway, there are two mechanisms for marking devices as "unmanaged"
with NM 1.0.x and later:

1) NetworkManager.conf with unmanaged-devices; it appears that you have
configured this correctly so far, but Thomas would know more.

2) udev rules; all virtual-type interfaces should already be marked
'unmanaged' by udev rules shipped with NetworkManager in
 /usr/lib/udev/rules.d/85-nm-unmanaged.rules.  You can add additional
rules by copying that file to /etc/udev/rules.d and modifying it for
your own purposes.

Dan


> Jeka
> 
> On Tue, Nov 17, 2015 at 2:25 PM Thomas Haller 
> wrote:
> 
> > On Mon, 2015-11-16 at 21:58 +, Jetchko Jekov wrote:
> > > OK, I spent some time with filtering of NM log. I removed the
> > > debug
> > > lines related to WiFi connections management (they contain way
> > > too
> > > much sensitive data IMO, and are irrelevant to my problem
> > > anyway).
> > > Still the resulting file is around 280k (1,5k lines), so the
> > > question
> > > is:  Is it OK to attach such "huge" file here? Or shall I gzip
> > > (bzip2/xz ) it first?
> > 
> > If you compress it, it should be small enough.
> > Otherwise, you can send it to me off-list.
> > 
> > Thomas
> ___
> 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: [PATCH] nmcli: Made nmcli build optional

[Dan Williams]

On Fri, 2015-11-13 at 19:35 +, Joel Holdsworth wrote:
> Hi, here's a patch to make the nmcli build optional. In my use-case I
> need to cross-build NetworkManager, and I don't want to have to 
> cross-build GNU readline for a binary I don't need.

Thanks for the patch!  Would you mind making two quick fixes to it?

1) first, the patch will actually break the case where --with-nmcli is
not specified on the command-line, because build_nmcli doesn't get set
to 'yes' if not specified.  You could simply add:

 if test "$with_nmcli" != no; then
 AX_LIB_READLINE
+build_nmcli=yes
 else

2) We should put some log info near the bottom whether nmcli is enabled
or not, like is done for nmcli.  That would be something like:

 echo "  libnm-glib: $with_libnm_glib"
+echo "  nmcli: $build_nmcli"
 echo "  nmtui: $build_nmtui"
 echo

Any chance you could make those changes and resubmit?

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

Re: Approaching NetworkManager 1.2

[Dan Williams]

On Fri, 2015-11-13 at 21:38 +0100, Olaf Hering wrote:
> On Mon, Nov 02, Lubomir Rintel wrote:
> 
> > If anyone believes anything important is missing it's a good time
> > to
> > speak up now.
> 
> The interface for scripts in /etc/NetworkManager/dispatcher.d/ is in
> a
> poor state. IMO there are likle two ways how third party apps
> interact
> with NM: either they receive "events" via the dispatcher hooks, or
> they
> are a dbus client. I dont know much about the latter, thats why I
> assume
> that an app is notified via dbus and get to the "full state" of NM
> via
> dbus. I assume such app does not need dispatcher events.
> 
> For apps/scripts called via the dispatcher interface the event should
> be
> a snapshot of the "full state". But instead they just get some "hey,
> something happend" event with an incomplete chunk of info.
> Essentially
> they are forced to make some sense of this incomplete chunk of info
> and
> maintain the state on their own. This is cumbersome and the amount of
> work
> to get this right is equal to turn them into full dbus apps and grab
> all
> the info from there. For short, the even must include the full info.
> 
> Examples:
> The remote VPN gateway sometimes drops the connection, or the router
> reconnects and gets a new public address. As a result openvpn
> reconnects. The reconnect event does not include the VPN route info,
> just the IPv4 address data. I'm sure NM still knows the routes, but I
> have not looked in dbus whats actually in there.

Can you grab some debug output from the dispatcher when this happens? 
 You can run the dispatcher like so:

nm-dispatcher --debug --persist

and it'll dump out exactly what it's sending to the scripts in the
environment.  Scripts should get a "vpn-down" without much info
(because the connection is already gone) and then a "vpn-up" with all
the addresses and routes in the environment.  If not, then its a bug.

> The bridge interface does dhcp, and the "up/dhcp4-change/dhcp6
> -change"
> events contain the desired info. But because its a bridge there is
> also
> the ethN slave. Most of the time its event carries no info. But it
> happend two times during boot that ethN instead of br0 carried the
> address info. Since my scripts have to ignore ethN the required info
> was
> essentially lost and the system in a wedged state.

Again, if you can get dispatcher debugging that would be great.  Slaves
should never have IP information *unless it's been added externally to
NM* by something, since they are slaves.

Dan

> Please either fix this, or document it clearly in NetworkManager(8)
> that
> the environment info for each event may be incomplete.
> 
> Olaf
> ___
> 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: [PATCH 1/1] all: add C99's "bool" define and encourage its use

[Dan Williams]

On Wed, 2015-11-11 at 13:33 +0100, Thomas Haller wrote:
> ---
>  Let's use bool.
> 
>  Comments?

Since glib uses gboolean in quite a few places, would we have problems
with casting it to gboolean if needed?  Casting would be pretty ugly if
we had to do it a bunch.

Also, I don't think we'd save any space because the compiler is going to
pad any field 1-byte field (like bool) out to 4 or 8 bytes anyway,
unless the structure is packed.

Lastly, using bitfields in structs is not generally recommended since
apparently (at least) gcc creates awful code for accesses.  At least
that's the argument in kernel-land for not doing bitfields, and you
never see them there.

Dan

>  Thomas
> 
>  include/nm-default.h | 46 ++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/include/nm-default.h b/include/nm-default.h
> index d5c9d10..dc02763 100644
> --- a/include/nm-default.h
> +++ b/include/nm-default.h
> @@ -70,4 +70,50 @@
>  
>  
> /*/
>  
> +/**
> + * The boolean type _Bool is C99 but we mostly stick to C89. However, _Bool 
> is too
> + * convinient to miss and is effectively available in gcc and clang. So, 
> just use it.
> + *
> + * Usually, one would include "stdbool.h" to get the bool define which 
> aliases
> + * _Bool. We provide this define here, because we want to make use of it 
> anywhere.
> + * (also, stdbool.h is again C99).
> + *
> + * Using _Bool has advantages over gboolean:
> + *
> + * - commonly, _Bool is one byte large, instead of gboolean's 4 bytes 
> (because gboolean
> + *   is a typedef for gint). Especially when having boolean fields in a 
> struct, we can
> + *   thereby easily save some space.
> + *
> + * - _Bool type is guaranteed that two true expressions compare equal. E.g. 
> the follwing
> + *   will not work:
> + *gboolean v1 = 1;
> + *gboolean v2 = 2;
> + *g_assert_cmpint (v1, ==, v2); // will fail
> + *   For that, we often to use !! to coerce gboolean values to 0 or 1:
> + *g_assert_cmpint (!!v2, ==, TRUE);
> + *   With _Bool this will be properly done by the compiler.
> + *
> + * - For structs, we might want to safe even more space and use bitfields:
> + *   struct s1 {
> + *   gboolean v1:1;
> + *   };
> + *   But the problem here is that gboolean is signed, so that
> + *   v1 will be either 0 or -1 (not 1, TRUE). Thus, the following
> + *   doesn't work:
> + *  struct s1 s = { .v1 = TRUE, };
> + *  g_assert_cmpint (s1.v1, ==, TRUE);
> + *   It will however work just fine with bool/_Bool.
> + *
> + * Also, add the defines for true/false. Those are nicely highlighted by the 
> editor
> + * as special types, contrary to glib's TRUE/FALSE.
> + */
> +
> +#ifndef bool
> +#define bool _Bool
> +#define true1
> +#define false   0
> +#endif
> +
> +/*/
> +
>  #endif /* __NM_DEFAULT_H__ */


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

Re: OpenVPN plugin and private key password

[Dan Williams]

On Mon, 2015-11-09 at 17:51 -0200, Ethy H. Brito wrote:
> On Mon, 9 Nov 2015 13:11:24 +0100
> Jirka Klimes  wrote:
> 
> > On Sat, 7 Nov 2015 13:55:39 -0200
> > "Ethy H. Brito"  wrote:
> > 
> > > 
> > > Hi All
> > > 
> > > I am not certain if here is the right place to ask this. Forgive me
> > > if it is not.
> > > 
> > > Why, if I have a password protected private key, the OpenVPN plug-in
> > > demands me to enter the password to enable the save button?
> > > 
> > > I think this is not right. I don't want my password hanging around.
> > > If, for instance, my laptop gets stolen, the thief has access to my
> > > private data. Saving a password, completely overrides the purpose of
> > > a password protected key!
> > > 
> > > How to make Networkmanager ask for the password when activating the
> > > VPN?
> > > 
> > > Am I doing something wrong here? Missing something perhaps?
> > > 
> > > Regards
> > > 
> > > Ethy
> > 
> > It depends on the GUI you use.
> > 
> > In recent nm-connection-editor, all password entries have an icon
> > attached that allows setting password as "always ask".
> > 
> > See
> > https://bugzilla.gnome.org/show_bug.cgi?id=731891
> > 
> > Jirka
> 
> Tested with "cert-pass-flags=2" and got:
> 
>   The VPN connection 'XXX' failed
>   because there were no valid VPN secrets.
> 
> No window opened to ask the password. Should it?
> 
> Any hints?

What desktop environment are you running?

Dan

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

Re: nm in different linux distributions - ppp versus qmi-wwan

[Dan Williams]

On Fri, 2015-11-06 at 23:40 +0100, Bjørn Mork wrote:
> Thomas Schäfer  writes:
> > lsusb-20151106-suse.txt (good case)
> > lsusb-20151106.txt (manjaro - bad case)
> >
> >
> > both use kernel 4.1.x
> >
> > The diff is not big:
> 
> Yes, the device appears identical, switched to the same mode with a
> single config.  This is as expected.
> 
> > Interface Descriptor:
> >   bLength 9
> >   bDescriptorType 4
> >   bInterfaceNumber3
> >   bAlternateSetting   0
> >   bNumEndpoints   1
> >   bInterfaceClass   255 Vendor Specific Class
> >   bInterfaceSubClass  1 
> >   bInterfaceProtocol  9 
> >   iInterface  0 
> >   ** UNRECOGNIZED:  05 24 00 10 01
> >   ** UNRECOGNIZED:  0d 24 0f 01 00 00 00 00 00 20 01 00 00
> >   ** UNRECOGNIZED:  05 24 06 03 04
> >   Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x85  EP 5 IN
> > bmAttributes3
> >   Transfer TypeInterrupt
> >   Synch Type   None
> >   Usage Type   Data
> > wMaxPacketSize 0x0040  1x 64 bytes
> > bInterval   5
> > Interface Descriptor:
> >   bLength 9
> >   bDescriptorType 4
> >   bInterfaceNumber4
> >   bAlternateSetting   0
> >   bNumEndpoints   2
> >   bInterfaceClass   255 Vendor Specific Class
> >   bInterfaceSubClass  1 
> >   bInterfaceProtocol  8 
> >   iInterface  0 
> 
> 
> 
> Interfaces 3 and 4 make a QMI function together. They are using Huaweis
> well known QMI subclass/protocol values, and the control interface has a
> valid union descriptor.  All looking good.  The mainline option driver
> will not attempt to probe these interfaces by default.
> 
> > [  164.681791] option 4-2:1.3: GSM modem (1-port) converter detected
> > [  164.682175] option 4-2:1.4: GSM modem (1-port) converter detected
> > [  164.682557] usb 4-2: GSM modem (1-port) converter now attached to ttyUSB4
> 
> 
> But the option driver erronously tries to bind (to both interfaces
> actually).  Note that it even attempts to bind to interface #3. Which
> fails of course, since there are no bulk endpoints.
> 
> This is obviously a misconfiguration of the option driver.  It could in
> theory be patched, but I suspect some userspace script has been
> "helpful", adding the device ID dynamically.  Could you post the output
> of "cat /sys/bus/usb-serial/drivers/option1/new_id" as well?

It could also be usb_modeswitch's misguided attempts to force-bind
option when it finds no other suitable driver?  It's got functionality
to do that in some cases.

Dan

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

Re: nm in different linux distributions - ppp versus qmi-wwan

[Dan Williams]

On Fri, 2015-11-06 at 17:22 +0100, Thomas Schäfer wrote:
> Hi,
> 
> 
> That was the problem. option has occupied to much resources.
> After removing option and qmi_wwan and adding them in reverse order 
> everything works as expected.
> So now I have to find the right people of manjaro.. or they read this 
> thread accidentally.

This should work automatically.  What this probably means is that option
is too general in binding to this device, and we should get the 'lsusb
-v' output for the device so we can figure out how to restrict it.  Any
chance you can provide that?

Dan

> Thank You very much!!
> 
> Thomas
> 
> 
> 
> 
> 
> Am 06.11.2015 um 16:13 schrieb Bjørn Mork:
> > Thomas Schäfer  writes:
> >
> >> [  369.482170] option 1-2:1.0: GSM modem (1-port) converter detected
> >> [  369.482562] usb 1-2: GSM modem (1-port) converter now attached to 
> >> ttyUSB0
> >> [  369.482639] option 1-2:1.1: GSM modem (1-port) converter detected
> >> [  369.483008] usb 1-2: GSM modem (1-port) converter now attached to 
> >> ttyUSB1
> >> [  369.483082] option 1-2:1.2: GSM modem (1-port) converter detected
> >> [  369.486206] usb 1-2: GSM modem (1-port) converter now attached to 
> >> ttyUSB2
> >> [  369.507370] option 1-2:1.3: GSM modem (1-port) converter detected
> >> [  369.507707] option 1-2:1.4: GSM modem (1-port) converter detected
> >> [  369.508139] usb 1-2: GSM modem (1-port) converter now attached to 
> >> ttyUSB4
> >
> > Were 4 serial devices expected?  What does the device config look like
> > (lsusb -v ...)?
> >
> > Maybe the option driver is configured to bind to any interface on this
> > modem, "stealing" the QMI interface before qmi_wwan gets the chance?
> > Difficult to know based on the available info
> >
> > You could try to manually unload the drivers and then reload them in the
> > opposite order to see what happens.
> >
> >   rmmod option
> >   rmmod qmi_wwan
> >   modprobe qmi_wwan
> >   modprobe option
> >
> > If the distro (or some relates script) use the dynamic ID feature, then
> >
> >   cat /sys/bus/usb-serial/drivers/option1/new_id
> >
> > would be enlightening. You could also try to manually verify a match
> > against the putput of
> >
> >   modinfo -F alias option
> >   modinfo -F alias qmi_wwan
> >
> > but that will be challenging due to the mix of vendor id and class
> > matching (Huawei devices use subclass + protocol matches).
> >
> >
> > Bjørn
> >
> 
> ___
> 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: Approaching NetworkManager 1.2

[Dan Williams]

On Wed, 2015-11-04 at 07:53 +0100, Tore Anderson wrote:
> * Lubomir Rintel 
> 
> > If anyone believes anything important is missing it's a good time to
> > speak up now.
> 
> A couple of suggestions:
> 
> 1) IPv6 method cleanup:
>* Get rid of «Automatic (DHCP only)»
>* Get rid of «Automatic (Addresses only)»

I wouldn't get rid of "Automatic (Addresses only)" since this is what
enables you to ignore DNS servers/routes and use your own.

>* Replace «Ignore» with «Disabled», which should set the
>  disable_ipv6 sysctl).
> 
> (In general I think the «method» concept is somewhat misguided to begin
> with, even for IPv4. I'd rather see it be replaced by a set of mostly
> independent toggles to enable/disable various features, to allow for
> arbitrary combinations. For example: It is currently impossible to use
> SLAAC in combination with a manual static address. I can't see any good
> reason for that.)

Yeah, we've talked about that for a couple years but nobody's gotten
around to it.  Note that you can currently use SLAAC in addition to
manual addresses already, though what you probably want is SLAAC to
deliver the prefix/DNS/etc and use a static IP with that prefix?

Dan

> 2) Support for IPv6 sharing. Relevant technologies here:
>* DHCPv6 Prefix Delegation (RFC 3633)
>* ND Proxy (RFC 4389)
>* 3GPP /64 share (RFC 7278) [Note: ND Proxy covers this use case]
> 
> Maybe I'll think of more later.
> 
> Tore
> ___
> 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: nm in different linux distributions - ppp versus qmi-wwan

[Dan Williams]

On Thu, 2015-11-05 at 19:15 +0100, Thomas Schäfer wrote:
> Hi,
> 
> the last days I tested the NetorkManager with the Huwei E398 with dualstack 
> on 
> livecd / fresh installed systems. (ISP Deutsche Telekom(t-mobile))
> 
> I observed the 
> 
> Opensuse 42.1
> nm1.0.6/mm1.4.10 --> uses qmi-wwan, connection editor allows to enable IPv6
> and it works
> 
> Ubuntu 15.10
> nm1.0.4/mm1.4.10 --> uses qmi-wwan, connection editor ignores IPv6 completely 
> after changing manually  the method to auto it works
> 
> manjaro-xfce-15.09-x86_64
> manjaro-kde-15.09-x86_64
> 
> nm1.06/mm?? --> uses ppp, connection editor allows to enable IPv6
> but IPv6 via ppp is not supported by the modem
> 
> So my question is: Who does decide between qmi-wwan or ppp?

ModemManager does, based on device discovery.  So it's likely that the
version of ModemManager that you typed as "mm??" isn't able to correctly
recognize the modem as a QMI one.  That is either a ModemManager
problem, a kernel driver problem, or a "modeswitch" problem (where the
device is not told to come up in the right mode by usb_modeswitch, if
the modem requires that).

If you can add "--debug" to the ModemManager service arguments (through
either systemd, dbus autostart, or whatever runs MM on your system) them
we could get more info.

Dan

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

Re: [PATCH] bluetooth: fix missing 'connected' notifications (rh #1255284)

[Dan Williams]

On Sun, 2015-10-25 at 19:55 +0100, Thomas Haller wrote:
> On Fri, 2015-10-23 at 11:50 -0500, Dan Williams wrote:
> > Because Bluez5 dropped DUN support, NM must do that manually which
> > includes emulating the "connected" property for Bluetooth devices
> > when
> > DUN is used.  It does this by setting priv->connected = TRUE in
> > nm_bluez_device_connect_finish().
> > 
> > But for PAN, when NM does process the 'connected' property change
> > notification, priv->connected is already TRUE and
> > _take_variant_property_connected() does nothing.  Hence the
> > corresponding GObject property notification is not emitted,
> > nm-device-bt.c::check_connect_continue() will never return success,
> > and
> > the activation times out.
> > 
> > To fix this, ensure that GObject notifications are emitted when the
> > device is connected, even if emulated internally.
> > 
> 
> 
> Patch looks good to me.
> I merged the patch:
> 
> master: 
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0e3086e8b885164f24b43a1060cb1f87a62723a8
> 
> nm-1-0: 
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=cccb8fe5e6945085d43050411c1ced26453d85df

Thanks!

Dan

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

[PATCH] bluetooth: fix missing 'connected' notifications (rh #1255284)

[Dan Williams]

Because Bluez5 dropped DUN support, NM must do that manually which
includes emulating the "connected" property for Bluetooth devices when
DUN is used.  It does this by setting priv->connected = TRUE in
nm_bluez_device_connect_finish().

But for PAN, when NM does process the 'connected' property change
notification, priv->connected is already TRUE and
_take_variant_property_connected() does nothing.  Hence the
corresponding GObject property notification is not emitted,
nm-device-bt.c::check_connect_continue() will never return success, and
the activation times out.

To fix this, ensure that GObject notifications are emitted when the
device is connected, even if emulated internally.

---

diff --git a/src/devices/bluetooth/nm-bluez-device.c 
b/src/devices/bluetooth/nm-bluez-device.c
index cc44b9e..b703214 100644
--- a/src/devices/bluetooth/nm-bluez-device.c
+++ b/src/devices/bluetooth/nm-bluez-device.c
@@ -600,8 +600,10 @@ nm_bluez_device_connect_finish (NMBluezDevice *self,
return NULL;
 
device = (const char *) g_simple_async_result_get_op_res_gpointer 
(simple);
-   if (device && priv->bluez_version == 5)
+   if (device && priv->bluez_version == 5) {
priv->connected = TRUE;
+   g_object_notify (G_OBJECT (self), NM_BLUEZ_DEVICE_CONNECTED);
+   }
 
return device;
 }

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

Re: device not connecting with type=unknown

[Dan Williams]

On Thu, 2015-10-15 at 17:02 -0500, Alex Ferm wrote:
> I have an embedded arm device running network-manager 1.0.6 with a usb 
> ethernet gadget that I want to automatically connect using DHCP. 
> NetworkManager shows the device type as unknown rather than ethernet, 
> and I was unable to connect with a connection who's type was set to 
> ethernet. I changed it to generic and was able to connect. I do have the 
> autoconnect flag set to "true", but I have to manually connect using nmcli.
> 
> Is there any way I can get it to autoconnect? This device is intended to 
> be headless with the network being the main method of communication.

So you said "gadget"...  There's a couple ways things identify
themselves, so lets see what yours does.  What is the output of:

cat /sys/class/net//type
cat /sys/class/net//uevent

I'll bet when you cat the uevent file, you see DEVTYPE=gadget ?
Currently NM only recognizes ethernet interfaces that don't set DEVTYPE
(which includes almost all of them) as real ethernet, because various
"virtual" types are the ones that set devtype and we don't want to treat
them as actual physical ethernet.  Gadget is somewhat special though, so
maybe NM needs an update to treat 'gadget' as ethernet.

Dan

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

Re: IPv6 with DHCP -- how is default route set?

[Dan Williams]

On Wed, 2015-10-21 at 11:23 +0200, Tore Anderson wrote:
> * Thomas Haller 
> 
> > "Automatic, DHCP only" will not use RA at all.
> 
> Which means this variant really shouldn't exist at all, or at the very
> least not in a GUI where users might deviced into believing it would
> ever be expected to produce a working network attachment.
> 
> FWIW I can only imagine three truly useful modes:
> 
> * Automatic SLAAC/DHCPv6 (the default)
> * Static/manual config
> * Disabled

Yes, at some point here we should simply alias the "DHCP" option to
"Automatic".

Dan

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

Re: CentOS 7 and NetworkManager-gnome package

[Dan Williams]

On Wed, 2015-10-14 at 18:55 +, Ron Wurzberger wrote:
> There use to be a separate NetworkManager-gnome package in CentOS 6.x. Is 
> that package now included in the GNOME Desktop 3, or will it remain a 
> separate package for CentOS 7? If the later, when do you expect it to be 
> released for CentOS 7?

CentOS tracks RHEL; and with RHEL7+ the packages track the Fedora
NetworkManager RPM layout from which they were derived.

That means that you now get separate packages for different components:

NetworkManager - core daemon
NetworkManager-wifi - WiFi support
NetworkManager-adsl - ATM/PPP based ADSL modems
NetworkManager-bluetooth - Bluetooth DUN/PAN support
NetworkManager-wwan - WWAN/cellular support
NetworkManager-team - team support (new-style bonds)

On the UI side, NetworkManager-gnome got split into separate packages:

network-manager-applet - contains nm-applet only
nm-connection-editor - contains nm-connection-editor only
libnm-gtk - contains some libraries used by applet/editor/GNOME Shell

If you're using the default GNOME desktop, then you don't need
'network-manager-applet' at all and you don't need to run nm-applet at
all, becuase GNOME Shell has its own network status indicator that
replaces nm-applet.

Dan

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

Re: [PATCH] ifcfg-rh: deal with weird ifcfg properly

[Dan Williams]

On Thu, 2015-10-08 at 10:45 +0200, Thomas Haller wrote:
> On Wed, 2015-10-07 at 18:18 -0700, Josef Bacik wrote:
> > Dracut when faced with an ipv6 only setup during kickstart will
> > generate a ifcfg
> > file that sets the ipv4 address things to null but sets
> > BOOTPROTO=static.  This
> > makes network manager screw up because it expects an ipv4 address to
> > be set.
> > Instead deal with this case by checking if we have any ipv4 addrs
> > set, and if
> > not just disable ipv4.  This fixes our inability to kickstart in our
> > ipv6 only
> > clusters.  Thanks,
> 
> 
> LGTM
> 
> Acked-By: Thomas Haller 

LGTM too; a candidate for both git master and stable.

Dan


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

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 15:28 -0400, Derek Atkins wrote:
> Dan,
> 
> On Wed, September 30, 2015 12:44 pm, Dan Williams wrote:
> > On Wed, 2015-09-30 at 12:25 -0400, Derek Atkins wrote:
> >> Dan,
> >>
> >> Dan Williams <d...@redhat.com> writes:
> >>
> >> I.e., just to make sure I understand correctly, in order to get what I
> >> want I should just create /etc/sysconfig/network-scripts/ifcfg-eth0:0
> >> and let NM manage my alias that way?  Do I need to do anything special
> >> to get NM to notice it, or it will do so automagically on the next
> >> restart/reboot?
> >
> > There are some alias examples here, FWIW:
> >
> > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/tests/network-scripts
> >
> > And all that's really required is "nmcli con reload", you shouldn't ever
> > need to restart NetworkManager to get config changes taken into account.
> 
> I added this config file but it's not bringing up eth0:0.
> 
> # cat /etc/sysconfig/network-scripts/ifcfg-eth0:0
> DEVICE=eth0:0
> IPADDR=192.168.x.y   (yes, x.y are numbers)
> BOOTPROTO=none
> ONBOOT=yes
> IPV6INIT=no
> #
> 
> What am I missing?  Do I need the base ifcfg-eth0 file, too?  (That file
> was not created by anaconda).  Or do I need some additional fields because
> there is no ifcfg-eth0?  Or do I need to tell NM to bring it up?

Yes, you need a matching ifcfg file for the base interface.  So you need
both ifcfg-eth0 and ifcfg-eth0:0.  See the examples, eg ifcfg-aliasem0
and ifcfg-aliasem0:1.

The alias file should only have DEVICE and IPADDR fields; and DEVICE
must match that of the parent ifcfg file.  They are intimately tied
together in the old initscripts, and the ifcfg-rh plugin remains
compatible with those.

When NetworkManager sees the base file, it will also look for alias
files, and will add the IP address from the alias file to the main
connection's IP address list along with the label.  So even with two
ifcfg files, you will only have one connection and you should see *both*
IP addresses in that one connection.  When the connection is activated,
NM sends the label to the kernel, so /sbin/ip will show both addresses
on one interface, but /sbin/ifconfig will show two interfaces each with
one address, per its ignorance of the real situation.

Dan

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

Re: NM and IETF MIF working group

[Dan Williams]

On Mon, 2015-09-28 at 22:29 +0200, Stjepan Groš wrote:
> On 28.09.2015 11:48, David Woodhouse wrote:
> > On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote:
> >> Two colleagues of mine and I started to work on MIF implementation on 
> >> Fedora. In case someone doesn't know, IETF MIF working group (
> >> https://datatracker.ietf.org/wg/mif/charter/) tries to solve the 
> >> problems of a single node having multiple parallel connections to 
> >> different destinations (Internet, VPN, some private networks, etc.).
> > Please ensure you take proxies into account.
> >
> > If my local DHCP server handed me a proxy PAC file, and if I connect to
> > a split-tunnel VPN which *also* provides a proxy PAC file, I expect
> > that requests I make to to the company VPN (within its domain names and
> > IP ranges) to use one proxy configuration, while requests to the
> > Internet at large should use my local proxy.
> >
> 
> If I understand it correctly, PAC information received from DHCP is send
> by NM via DBus, but otherwise not used in any way? So, it is necessary
> to use some tool like proxydriver
> (https://github.com/jimlawton/proxydriver) that will modify system
> settings based on this info?

Yes, NM gets the information from DHCP and exposes it on D-Bus but does
not make any further use of it.  That's up to whatever proxy
implementation you have that wants to process PAC files, at least at
this point.  I think that's the point of libproxy/pacrunner though,
where apps need to say "how must I access http://it.foobar.com; and the
proxy library consults the list of methods to get there, and returns an
answer like "you must use this proxy" or "just go there directly".  Apps
do need to be smarter here.

Dan

> In any case, this is interesting info because we didn't though of it.
> Namely, if browser is configured to use system proxy settings and it is
> placed within new namespace, then it might happen that wrong proxy is
> used, or global proxy settings are mixed up.
> 
> SG
> ___
> 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: NM and IETF MIF working group

[Dan Williams]

On Tue, 2015-09-22 at 12:44 +0200, Stjepan Groš wrote:
> Hi Lubomir,
> 
> after some time I'm sending followup on this. I would like to flesh out
> and discuss our ideas before we start implementing them to be certain
> that they will be useful for NetworkManager users.
> 
> On 07.09.2015 18:10, Lubomir Rintel wrote:
> > Hello Stjepan,
> >
> > On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote:
> >> So, it seems to me that the NetworkManager is the core component on the
> >> client side that will have to have functionality specified by MIF
> >> allowing node to use multiple connections in parallel (this, of course,
> >> doesn't mean that it is the only component that will have to be
> >> changed). But since we are at the very beginning of this, we would like
> >> to hear thoughts from developers about this? Did anyone tried to do
> >> this? Give any thought to this and come out with a possible solution, or
> >> problems?
> > We do essentially deal with this to some extent by setting metrics to
> > the routes we set up. We assign priorities to different device types so
> > that e.g. Wired Ethernet is preferred over Wi-Fi or Mobile Broadband.
> > We do also remember order in which routes were added so that newly
> > activated connections on multi-homed hosts don't "steal" the existing
> > connections.
> >
> > That said, I haven't really had a look (maybe someone else from the
> > team had?) at the documents you're created and discussed so far so my
> > understanding of the problem scope might be limited.
> >
> 
> First, our task is to implement MIF on Linux/Fedora and we didn't
> participate in the standardization process, at least not until now.
> Anyway, I suppose that the best document to read is RFC6418 which
> summarizes problems associated with multiple interfaces and/or
> connections that MIF WG tries to address. RFC7556 defines solution
> architecture and also discusses some issues. So, I'll continue from that
> point on and use the terminology introduced by the given RFCs.
> 
> What we in my group were discussing in the past two weeks was how to
> approach the problem of multiple, sometimes conflicting, connections on
> a single node. In the end we concluded to approach this using network
> name spaces which would be controlled by Network Manger. In other words,
> whenever NetworkManager receives new PvD (think of PvD as a coherent set
> of network configuration data) it assigns this data to the root network
> name space but also creates a new network name space in which the given
> configuration data is the only network configuration.
> 
> To run a new process (e.g. Firefox) that uses the particular connection
> (for example VPN) it is enough to use nsenter(1) command in CLI. For
> GUI, at the moment, we don't know what is the best way/the most user
> friendly to allow users to run applications in certain name spaces, so
> this is open to discussions.
> 
> Few things are also necessary. First, of course, is the way for
> NetworkManager to discover PvDs (explicit and implicit). The second is
> that not always it is necessary to create new name space. Sometimes
> conflicts between different network configuration can be resolved in a
> single namespace. To solve that problem we would define language and
> engine that would allow control of NMs behavior when applying network
> configuration data. For example, at the present moment interface
> priorities are hardcoded, i.e. if there are WiFi and wired connection,
> default route from wired connection is used. This policy language would
> allow this to be specified independently from the code of NM and thus be
> made much more flexible for different use cases.
> 
> What do you think about it? Do you have any suggestions or alternative
> approaches?

It sounds like there's a ton of overlap with containerized applications
which do just about the same thing.  At least, they need all the same
network setup infrastructure.  If you're going to the trouble of putting
Firefox into a different network namespace, you might as well go to the
trouble of containerizing it for some small additional security and
sandboxing.

Second the user interaction model really needs to be discussed here,
unless there's something I haven't read that addresses it.  The
technical details are easy to understand, but how that translates to
what apps get launched in what PvD and whether PvDs get used at all
(even if the network advertises them), and how segmentation occurs in a
way that's understandable or even usable to the person at the machine.

Anyway, what do you (and the standards) really mean by "conflicting"?
Is that about address ranges, or DNS information, or proxies, or
domains, or...?

Dan

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

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Thu, 2015-10-01 at 13:34 -0400, Derek Atkins wrote:
> Hi Dan,
> 
> On Thu, October 1, 2015 12:49 pm, Dan Williams wrote:
> 
> > Yes, you need a matching ifcfg file for the base interface.  So you need
> > both ifcfg-eth0 and ifcfg-eth0:0.  See the examples, eg ifcfg-aliasem0
> > and ifcfg-aliasem0:1.
> >
> > The alias file should only have DEVICE and IPADDR fields; and DEVICE
> > must match that of the parent ifcfg file.  They are intimately tied
> > together in the old initscripts, and the ifcfg-rh plugin remains
> > compatible with those.
> >
> > When NetworkManager sees the base file, it will also look for alias
> > files, and will add the IP address from the alias file to the main
> > connection's IP address list along with the label.  So even with two
> > ifcfg files, you will only have one connection and you should see *both*
> > IP addresses in that one connection.  When the connection is activated,
> > NM sends the label to the kernel, so /sbin/ip will show both addresses
> > on one interface, but /sbin/ifconfig will show two interfaces each with
> > one address, per its ignorance of the real situation.
> 
> Apparently this still isn't working.  I did the following:
> 
> # cat /etc/sysconfig/network-scripts/ifcfg-eth0
> TYPE=Ethernet
> BOOTPROTO=dhcp
> DEFROUTE=yes
> IPV4_FAILURE_FATAL=no
> UUID=3a02edd8-e82d-4dca-a336-933e9177f4cd
> DEVICE=eth0
> ONBOOT=yes
> HWADDR=00:1f:7b:b2:14:42
> IPV6_FAILURE_FATAL=no
> NAME=eth0
> # cat /etc/sysconfig/network-scripts/ifcfg-eth0:1
> DEVICE=eth0:1
> IPADDR=192.168.x.y

I tested the config here and at least git master NM accepts the DHCP +
aliases configuration.  After doing 'nmcli con reload' could you do
"nmcli con show 3a02edd8-e82d-4dca-a336-933e9177f4cd" and post the
output for the IPv4 block?

Dan

> and after an nmcli con reload it still doesn't provide the alias address. 
> Nor after a reboot.
> 
> I'm sur I'm still missing *something* but I'm at a loss now.
> 
> > Dan
> 
> -derek
> 


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

Re: AP with Radius and VLAN?

[Dan Williams]

On Tue, 2015-09-29 at 21:37 -0700, Frank Rizzo wrote:
> Hey guys!
> 
> I'm using Ubuntu 14.04 LTS, and using the applet I am able to do basic  
> configuration of an AP.  I can then start it, connect to it, and use it.   
> But this base config is very simplistic.  I need something more.  I need  
> Radius server authentication, and VLANs.  (Things that are supported  
> through hostapd).
> 
> Does anyone have an example config that I can base mine upon?

NetworkManager only supports wpa_supplicant's lightweight AP mode and is
not intended as a full-fledged WiFi access point.  For that, you'd want
to configure & run hostapd itself, and make NM ignore the wifi interface
through the config file and the "unmanaged-devices" key.

Dan

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

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 06:26 +0300, Andrei Borzenkov wrote:
> 29.09.2015 20:54, Dan Williams пишет:
> >
> >> Basically I want to automate NM doing, effectively:
> >>
> >>ifconfig eth0:0 192.168.x.y
> >
> > Don't do this with interface aliases; the kernel is perfectly capable of
> > using more than one address on the same interface.  Simply do:
> >
> > ip addr add 192.168.x.y/24 dev eth0
> >
> > and magically you'll have two.
> >
> 
> 
> This makes addresses invisible in ifconfig output and that may confuse 
> legacy software (I know about at least one such case). Adding "label 
> xxx" will emulate legacy aliases enough to make them appear as "normal" 
> interface.

Yes, that is a downside.  However, the kernel functionality underlying
this, address labels, is only for tricking ifconfig.  The alias
interfaces are not normal interfaces and changes made to them affect all
other alias interfaces.  No other tools present this view of the world,
and the upstream kernel is only keeping this functionality for backwards
compatibility.

Dan

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

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 10:15 -0400, Derek Atkins wrote:
> Andrei,
> 
> Andrei Borzenkov <arvidj...@gmail.com> writes:
> 
> > 29.09.2015 20:54, Dan Williams пишет:
> >>
> >>> Basically I want to automate NM doing, effectively:
> >>>
> >>>ifconfig eth0:0 192.168.x.y
> >>
> >> Don't do this with interface aliases; the kernel is perfectly capable of
> >> using more than one address on the same interface.  Simply do:
> >>
> >> ip addr add 192.168.x.y/24 dev eth0
> >>
> >> and magically you'll have two.
> >>
> >
> >
> > This makes addresses invisible in ifconfig output and that may confuse
> > legacy software (I know about at least one such case). Adding "label
> > xxx" will emulate legacy aliases enough to make them appear as
> > "normal" interface.
> 
> Could you explain more detail on how to add "label xxx" to the nmcli
> command (which you inconveniently cut out of your reply, so I've
> included it below)?  I cannot find any reference to "label" in the nmcli
> documentation.
> 
>   nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.x.y/24"

If you really do need address labels (eg, interface aliases) then
NetworkManager has limited support for them.  If you don't truly need
address labels, then I wouldn't use them.  Anyway, NM supports address
labels, but only when they are set via ifcfg "alias" files.  They
currently cannot be added via nmcli or set via the 'keyfile' plugin,
though that's just a case of "didn't implement yet" rather than anything
else.

Dan

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

Re: failure with bridge devices

[Dan Williams]

On Wed, 2015-09-30 at 09:59 +0200, Olaf Hering wrote:
> Am 29.09.2015 um 13:21 schrieb Jirka Klimes:
> > On Mon, 28 Sep 2015 09:05:02 +0200
> > Olaf Hering  wrote:
> >> So my questions:
> >> Are there known bugs in the cooperation between NM and GNOME?
> > I don't think there is a known serious issue.
> 
> At least GNOME 3.16 is unable to do anything with bridges, except that
> they can be configured.
> 
> >> Are bridge devices fully supported? If so, why did NM not bringup
> >> onboard before configuring bridge?
> > Yes, bridge configurations are supported. You might got confused by
> > the fact bringing up a bridge profile does not automatically bring up
> > its slaves. Basically, you need to connect all slaves (bridge master
> > will be connected as a dependency).
> > 
> > But, as you have found there is a new property to influence the
> > behaviour (connection.autoconnect-slaves). When you set it to '1' you
> > can activate bridge and its slaves will be activated too.
> 
> Why is it off by default? What is the point of that behaviour?

Backwards compatibility, an intention to replicate the behavior of
various legacy network initscripts that had the same behavior (where eg
'ifup br0' after boot didn't bring up slaves), and because it's not
always the case that you want every single slave configuration that
references 'br0' to be started when br0 starts.  In general, NM tries to
be less destructive by default, and allow you to opt into destruction :)

(which might be new to some people, but that's the goal for the last 4
years or so)

Dan

> >> Below is the output of what I configured with 'nm-connection-editor'.
> >> Why is that output even localized?!
> > What is the issue with localization/no-localization?
> 
> Its translated at the wrong layer. But after all, they also gave us
> ~/Schreibtisch, ~/ビデオ, ~/Público and other odd directory names. So it
> just makes sense to translate property names as well. I think in the
> future we will get /proc/версия too...
> 
> Olaf
> ___
> 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: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Wed, 2015-09-30 at 12:25 -0400, Derek Atkins wrote:
> Dan,
> 
> Dan Williams <d...@redhat.com> writes:
> 
> >> Could you explain more detail on how to add "label xxx" to the nmcli
> >> command (which you inconveniently cut out of your reply, so I've
> >> included it below)?  I cannot find any reference to "label" in the nmcli
> >> documentation.
> >> 
> >>   nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.x.y/24"
> >
> > If you really do need address labels (eg, interface aliases) then
> > NetworkManager has limited support for them.  If you don't truly need
> > address labels, then I wouldn't use them.  Anyway, NM supports address
> > labels, but only when they are set via ifcfg "alias" files.  They
> > currently cannot be added via nmcli or set via the 'keyfile' plugin,
> > though that's just a case of "didn't implement yet" rather than anything
> > else.
> 
> I.e., just to make sure I understand correctly, in order to get what I
> want I should just create /etc/sysconfig/network-scripts/ifcfg-eth0:0
> and let NM manage my alias that way?  Do I need to do anything special
> to get NM to notice it, or it will do so automagically on the next
> restart/reboot?

There are some alias examples here, FWIW:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/tests/network-scripts

And all that's really required is "nmcli con reload", you shouldn't ever
need to restart NetworkManager to get config changes taken into account.

Dan

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

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Dan Williams]

On Tue, 2015-09-29 at 12:16 -0400, Derek Atkins wrote:
> Hi,
> 
> I've got an esoteric NM question.  I've got two distinct networks that
> share an ethernet fabric (poor man's vlans).  I have a F22 server that I
> want to put on both networks.  It's currently configured to use DHCP for
> the primary network (and my DHCP server provides a static address).
> 
> AFAICT there's really no way to get DHCP to provide two addresses, so
> I'd like to set up a secondary IP statically using nmcli (I did say this
> was a server, right?)

Correct.  DHCPv4 cannot provide more than one IP address.  (DHCPv6 can,
however).

> Basically I want to automate NM doing, effectively:
> 
>   ifconfig eth0:0 192.168.x.y

Don't do this with interface aliases; the kernel is perfectly capable of
using more than one address on the same interface.  Simply do:

ip addr add 192.168.x.y/24 dev eth0

and magically you'll have two.

> I know I can add a second IP to eth0 via:
> 
>   nmcli con mod "Wired connection 1" +ipv4.addresses "192.168.x.y/24"

This is exactly what you do.  Keep the ipv4.method = "auto" however,
that's how DHCP gets signaled.

> But I have no idea how this would interact with the primary address
> being obtained by DHCP.

What should happen is that DHCP will provide everything it currently
does, including the primary IP address, gateway, DNS, etc, and the only
change will be that a second IP address is added to the interface.  You
won't see this address with ifconfig though, because it's stupid.
Use /sbin/ip to see it.

Dan

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

Re: vpn password stored in plain text

[Dan Williams]

On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote:
> Why is the VPN password stored in plain text in
> /etc/NetworkManager/system-connections? Is there a way to let the GUI
> ask for it every time?

Note that the file is read-only by root.  If somebody has root on your
machine, they can do a lot more than read your password.  It's stored
there because no "password flags" have been set for the password that
tell NM where to get it from.

If you set the "agent-owned" flag and the "always ask" flags on the
password, either through the GUI or by editing the file in /etc, then NM
will ask an agent for the password every time.  Most desktop
environments have an agent (eg, GNOME and KDE have their own) and
there's also nm-applet.

For vpnc for example, the user password is "xauthpassword" and the
corresponding item to ask for it every time would be
"xauthpassword-flags=3".  For OpenVPN the user password is "password"
and the corresponding item to ask for it every time is
"password-flags=3".

See also 'man nm-settings' and look for the "Secret flag types" section
near the bottom.

Dan

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

Re: vpn password stored in plain text

[Dan Williams]

On Mon, 2015-09-28 at 17:57 +0200, Olaf Hering wrote:
> Am 28.09.2015 um 17:00 schrieb Dan Williams:
> > On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote:
> >> Why is the VPN password stored in plain text in
> >> /etc/NetworkManager/system-connections? Is there a way to let the GUI
> >> ask for it every time?
> > 
> > Note that the file is read-only by root.  If somebody has root on your
> > machine, they can do a lot more than read your password.
> 
> If the disk gets stolen the password is accessible. Thanks for your
> other suggestions, will work through them.

Yes, that is correct.  Although best practices suggest full-disk
encryption on anything that can walk away, plus two-factor "something
you know and something you have" for VPNs.  But yes, setting the flags
in the file and removing the password should ensure that the password is
not stored on-disk.  You can also set the flags to '1' (agent-owned) and
the common agents like GNOME and KDE will store the password in their
respective keyrings/wallets that is protected by another password.

Dan

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

Re: Network Manager Fails to control Wi-Fi

[Dan Williams]

On Fri, 2015-09-25 at 11:28 +0530, Ramprasad Vempati wrote:
> Thanks Dan. But can you tell me how will Network-Manager find out PID
> of wpa_supplicant? Is it via:/run/sendsigs.omit.d/wpasupplicant.pid ,
> which is from below file? If yes, as long as I remove
> "/sbin/wpa_supplicant" also, Network-Manager shouldn't be able to
> control Wi-Fi, right?

NetworkManager doesn't care about the PID of the supplicant, because
it's using the D-Bus interface to talk to it.  When the supplicant
starts its D-Bus service enabled, it talks to dbus-daemon and says "hey,
I'm fi.w1.wpa_supplicant and I'm ready!".  dbus-daemon broadcasts that
to all other D-Bus clients like NetworkManager.  If the supplicant is
started already when NM starts, then NM asks dbus-daemon "hey, is
fi.w1.wpa_supplicant around?".  So there's no pid files involved.

Instead, to make sure the supplicant and NM cannot talk, make sure you
turn off the D-Bus interface, which you can do by either:

1) removing the "-u" option
from /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service

2) running a different supplicant that isn't built with the D-Bus
interface in the code, or is run without the "-u" option

Dan

> cat /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service
> [D-BUS Service]
> Name=fi.w1.wpa_supplicant1
> Exec=/sbin/wpa_supplicant -B -P /run/sendsigs.omit.d/wpasupplicant.pid
> -u -s -O /var/run/wpa_supplicant
> User=root
> 
> -ram
> 
> 
> On Thu, Sep 24, 2015 at 7:57 PM, Dan Williams <d...@redhat.com> wrote:
> > Since NM couldn't talk to the
> > supplicant, it will essentially ignore the WiFi interfaces and keep them
> > in the "unavailable" state.


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