Re: Auto-negotiation - Out of business

[Francesco Giudici]

On 24/11/2016 13:22, Thomas Haller wrote:
> ...
> sounds good.
> 
> A warning however is not helpful, because it will emit a warning for
> every existing connection out there created by nm-c-e.
> 
> nm_connection_normalize() should fixup such settings. Ideally, we would
> reject them, but for sake of backward compatibility, we silently fix
> them.
> 
> The documentation should mention, that speed and duplex must be set
> together.
> 
> nm-c-e still needs fixing to leave the autonet, speed, and duplex
> settings alone -- until it actually support setting them.
> 

Normalization has been committed:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b029e9256963b3adfde35d1e5adad50b838fdb1d

I have given a try to that with nm-connection-editor... well, now you
just cannot change or create a 802-3-ethernet enabled connection, as the
normalizable error prevents saving the connection.

Well, slight better, at least will not save the connection with hidden
misconfigured properties. But till the alignment of nm-connection-editor
is not there it is broken.
The ideal fix is to change the boolean type of duplex in
nm-connection-editor to track also the unset value (and maybe it is time
to expose the setting... I'm working on a patch for it).
In the meanwhile maybe we can merge the poma's patch that just removes
the default duplex option saving in the connection (in this case I would
slightly prefer to merge patch v1 leaving the other duplex stuff there
till it will be changed).

One last point: upgrading to a new NetworkManager without updating
nm-connection-editor will result so in not beeing able to create a new
ethernet connection. Should we address this too or fine to enforce a
full NM+nm-connection-editor update?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to avoid using policy kit with openvpn

[matti kaasinen]

2016-11-23 19:31 GMT+02:00 matti kaasinen :

> BTW, I got a feeling that I got more services failed after I enabled
> openvpn.service (like avahi). Also these problems did not disappear when I
> disabled openvpn.service and booted card. Same goes with modem problems.
> So, does NetworkManager or somebody else keep some data regarding OpenVPN
> set-up even though its been disabled. If so, would it be better managing
> OpenVPN connection with NetworkManager (-plugin) than using openvpn.service
> for that. Also is openvpn-plugin build automatically and  get into use if
> tun interface is not configured as unmanaged?



To be more exact: service that dos not start anymore after I enable and
later disable it is avahi-daemon.service. It is told in that unit file that:
Alias=dbus-org.freedesktop.Avahi.service.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to avoid using policy kit with openvpn

[matti kaasinen]

2016-11-23 19:31 GMT+02:00 matti kaasinen :

> 2016-11-23 18:13 GMT+02:00 Dan Williams :
>
>> If these are single-user systems, you can rebuild NM with PolicyKit
>> disabled so that it never validates requests against PolicyKit.
>>
> I'll try rebuilding tomorrow. I suppose (hope) there is clear switch for
> disabling it.
>
I thought I found the configuration switch. I ran build using:
--enable-polkit=disabled
set-up.
>From configuration log I can see: following note
NOTE: Running ../NetworkManager-1.0.10/configure  --build=x86_64-linux
  --host=arm-poky-linux-gnueabi
--target=arm-poky-linux-gnueabi   --prefix=/usr
--exec_prefix=/usr   --bindir=/usr/bin
--sbindir=/usr/sbin   --libexecdir=/usr/libexec
--datadir=/usr/share   --sysconfdir=/etc
--sharedstatedir=/com   --localstatedir=/var
--libdir=/usr/lib   --includedir=/usr/include
--oldincludedir=/usr/include   --infodir=/usr/share/info
--mandir=/usr/share/man   --disable-silent-rules
--disable-dependency-tracking
--with-libtool-sysroot=/CPR3/sysroots/am335x-evm
--enable-introspection  --disable-ifcfg-rh --disable-ifnet
--disable-ifcfg-suse --disable-more-warnings
--with-iptables=/usr/sbin/iptables --with-tests --with-nmtui=yes
--disable-static --enable-nls
--enable-polkit=disabled--disable-bluez5-dun
--with-libsoup=no --with-dhclient=/sbin/dhclient
--with-dnsmasq=/usr/bin/dnsmasq --enable-ifupdown
--with-modem-manager-1=yes --with-netconfig=yes --with-crypto=nss
--disable-ppp --disable-qt
--with-systemdsystemunitdir=/lib/systemd/system
--with-session-tracking=systemd --enable-polkit --enable-wifi=no


But later on there is also
checking for POLKIT... yes

and als

Platform:
  session tracking: systemd
  suspend/resume: systemd
  policykit: yes (restrictive modify.system) (default=yes)
  polkit agent: yes
  selinux: no

Also I got similar error message when trying to access SIM.


>>
> Could you 'nmcli g log level debug' on a problem machine and grab some
>> log output from before and after the error?
>>
> I don't have access to that machine now, but I'll do that tomorrow.
>
Please find the NetworkManager journal with above nmcli executed before
(would attachment be better?)
  Read config: /etc/NetworkManager/NetworkManager.conf
  Loaded settings plugin keyfile: (c) 2007 - 2015 Red Hat, Inc.  To
report bugs please use the NetworkManager mailing list.
  keyfile: new connection /etc/NetworkManager/system-connections/eth0
(5769be4a-ee83-4674-890a-f19e96b6c31e,"eth0")
  monitoring kernel firmware directory '/lib/firmware'.
  Loaded device plugin: NMVxlanFactory (internal)
  Loaded device plugin: NMVlanFactory (internal)
  Loaded device plugin: NMVethFactory (internal)
  Loaded device plugin: NMTunFactory (internal)
  Loaded device plugin: NMMacvlanFactory (internal)
  Loaded device plugin: NMInfinibandFactory (internal)
  Loaded device plugin: NMGreFactory (internal)
  Loaded device plugin: NMEthernetFactory (internal)
  Loaded device plugin: NMBridgeFactory (internal)
  Loaded device plugin: NMBondFactory (internal)
  Loaded device plugin: NMWwanFactory
(/usr/lib/NetworkManager/libnm-device-plugin-wwan.so)
  Loaded device plugin: NMBluezManager
(/usr/lib/NetworkManager/libnm-device-plugin-bluetooth.so)
  WiFi enabled by radio killswitch; enabled by state file
  WWAN enabled by radio killswitch; enabled by state file
  WiMAX enabled by radio killswitch; enabled by state file
  Networking is enabled by state file
  (lo): link connected
  (lo): new Generic device (carrier: ON, driver: 'unknown', ifindex:
1)
  (eth0): new Ethernet device (carrier: OFF, driver: 'cpsw', ifindex:
2)
  (eth0): device state change: unmanaged -> unavailable (reason
'managed') [10 20 2]
  ModemManager available in the bus
  (eth0): link connected
  (eth0): device state change: unavailable -> disconnected (reason
'carrier-changed') [20 30 40]
  Auto-activating connection 'eth0'.
  (eth0): Activation: starting connection 'eth0'
(5769be4a-ee83-4674-890a-f19e96b6c31e)
  (eth0): device state change: disconnected -> prepare (reason
'none') [30 40 0]
  NetworkManager state is now CONNECTING
  (eth0): device state change: prepare -> config (reason 'none') [40
50 0]
  (eth0): device state change: config -> ip-config (reason 'none')
[50 70 0]
  Activation (eth0) Beginning DHCPv4 transaction (timeout in 45
seconds)
address 192.168.3.1
plen 22
expires in 600 seconds
gateway 192.168.1.2
nameserver '192.168.1.2'
domain name 'sitecno.fi'
  (eth0): DHCPv4 state changed unknown -> bound
  (eth0): device state change: ip-config -> ip-check (reason 'none')
[70 80 0]
  (eth0): device state change: ip-check -> secondaries (reason
'none') [80 90 0]
  (eth0): device state change: secondaries -> activated (reason
'none') [90 100 0]
  NetworkManager state is now CONNECTED_LOCAL
  NetworkManager state is now CONNECTED_GLOBAL
  Policy set 

Re: Auto-negotiation - Out of business

[Thomas Haller]

On Thu, 2016-11-24 at 12:43 +0100, Francesco Giudici wrote:
> 
> On 24/11/2016 12:08, Thomas Haller wrote:
> 
> > 
> > in the past (up until today) nm-connection-editor always set duplex
> > to
> > "full", although the value was not implemented by the server. Thus,
> > every connection created in the past will change behavior after the
> > update.
> > 
> > to fix that, keyfile must ignore the old values like
> > 
> >   [ethernet]
> >   duplex=full
> > 
> > and treat them as unset.
> > 
> > Of course, we need a new way to encode full/half in keyfile, let's
> > fix
> > keyfile reader/writer to instead use:
> > 
> >   [ethernet]
> >   duplex=f
> >   duplex=h
> > 
> > 
> > 
> > 
> > For the speed value, there is not problem, because nm-c-e would
> > always
> > set it to 0, which is anyway what we want.
> > 
> > 
> > 
> > For the autonegotiation value, there is a problem:
> > 
> >  a)  old nm-c-e would set it to TRUE, with old libnm, old NM would
> > not persist (good)
> >  b1) old nm-c-e would set it to TRUE, with new libnm, new NM would
> > persist as TRUE (wrong)
> > 
> > nm-c-e must be fixed to not touch the default value for
> > autonegotiation, so it would be
> > 
> >  b2) new nm-c-e would not set autonet, which old libnm would not
> > transfer via D-Bus (and new NM wuold not persist) good
> >  b3) new nm-c-e would not set autonet, which new libnm would not
> > transfer via D-Bus (and new NM wuold not persist) good
> > 
> > Note that b1) cannot be fixed, although it's a supported
> > combination.
> > E.g. running nm-c-e 1.4.2 with libnm 1.5.3 against server 1.5.3.
> > It's a bug in nm-c-e, the solution is to upgrade to a fixed
> > version.
> > 
> > 
> > Needs fix in both nm-c-e and in keyfile reader/writer.
> 
> Instead of changing the keyfile, I would just more careful in
> enforcing
> the autonegotiate to manual: in case of autonegotiation disabled and
> just one among speed=0 and duplex=NULL, I would ignore the link
> configuration and put a warning in logs. After all, putting there
> both
> speed and duplex is expected when one wants to set link negotiation
> manually. Otherwise, the missing settings will be random.
> This would also good for b1).

Hi Francesco,

sounds good.

A warning however is not helpful, because it will emit a warning for
every existing connection out there created by nm-c-e.

nm_connection_normalize() should fixup such settings. Ideally, we would
reject them, but for sake of backward compatibility, we silently fix
them.

The documentation should mention, that speed and duplex must be set
together.

nm-c-e still needs fixing to leave the autonet, speed, and duplex
settings alone -- until it actually support setting them.


Thomas

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

Re: Auto-negotiation - Out of business

[Francesco Giudici]

On 24/11/2016 12:08, Thomas Haller wrote:

> in the past (up until today) nm-connection-editor always set duplex to
> "full", although the value was not implemented by the server. Thus,
> every connection created in the past will change behavior after the
> update.
> 
> to fix that, keyfile must ignore the old values like
> 
>   [ethernet]
>   duplex=full
> 
> and treat them as unset.
> 
> Of course, we need a new way to encode full/half in keyfile, let's fix
> keyfile reader/writer to instead use:
> 
>   [ethernet]
>   duplex=f
>   duplex=h
>
> 
> 
> 
> For the speed value, there is not problem, because nm-c-e would always
> set it to 0, which is anyway what we want.
> 
> 
> 
> For the autonegotiation value, there is a problem:
> 
>  a)  old nm-c-e would set it to TRUE, with old libnm, old NM would not 
> persist (good)
>  b1) old nm-c-e would set it to TRUE, with new libnm, new NM would persist as 
> TRUE (wrong)
> 
> nm-c-e must be fixed to not touch the default value for autonegotiation, so 
> it would be
> 
>  b2) new nm-c-e would not set autonet, which old libnm would not transfer via 
> D-Bus (and new NM wuold not persist) good
>  b3) new nm-c-e would not set autonet, which new libnm would not transfer via 
> D-Bus (and new NM wuold not persist) good
> 
> Note that b1) cannot be fixed, although it's a supported combination.
> E.g. running nm-c-e 1.4.2 with libnm 1.5.3 against server 1.5.3.
> It's a bug in nm-c-e, the solution is to upgrade to a fixed version.
> 
> 
> Needs fix in both nm-c-e and in keyfile reader/writer.

Instead of changing the keyfile, I would just more careful in enforcing
the autonegotiate to manual: in case of autonegotiation disabled and
just one among speed=0 and duplex=NULL, I would ignore the link
configuration and put a warning in logs. After all, putting there both
speed and duplex is expected when one wants to set link negotiation
manually. Otherwise, the missing settings will be random.
This would also good for b1).

Poma, thanks for reporting this early.

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

Re: Auto-negotiation - Out of business

[Thomas Haller]

On Wed, 2016-11-23 at 23:39 +0100, poma wrote:
> [...]
> Perhaps what is needed is to harmonise nm-connection-editor with
> changes in NM,
> i.e. not to apply ethernet 'duplex=full' by default.


Hi,



in the past (up until today) nm-connection-editor always set duplex to
"full", although the value was not implemented by the server. Thus,
every connection created in the past will change behavior after the
update.

to fix that, keyfile must ignore the old values like

  [ethernet]
  duplex=full

and treat them as unset.

Of course, we need a new way to encode full/half in keyfile, let's fix
keyfile reader/writer to instead use:

  [ethernet]
  duplex=f
  duplex=h




For the speed value, there is not problem, because nm-c-e would always
set it to 0, which is anyway what we want.



For the autonegotiation value, there is a problem:

 a)  old nm-c-e would set it to TRUE, with old libnm, old NM would not persist 
(good)
 b1) old nm-c-e would set it to TRUE, with new libnm, new NM would persist as 
TRUE (wrong)

nm-c-e must be fixed to not touch the default value for autonegotiation, so it 
would be

 b2) new nm-c-e would not set autonet, which old libnm would not transfer via 
D-Bus (and new NM wuold not persist) good
 b3) new nm-c-e would not set autonet, which new libnm would not transfer via 
D-Bus (and new NM wuold not persist) good

Note that b1) cannot be fixed, although it's a supported combination.
E.g. running nm-c-e 1.4.2 with libnm 1.5.3 against server 1.5.3.
It's a bug in nm-c-e, the solution is to upgrade to a fixed version.


Needs fix in both nm-c-e and in keyfile reader/writer.



Thomas

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

Re: Auto-negotiation - Out of business

[Thomas Haller]

On Wed, 2016-11-23 at 23:39 +0100, poma wrote:
> [...]
> Perhaps what is needed is to harmonise nm-connection-editor with
> changes in NM,
> i.e. not to apply ethernet 'duplex=full' by default.


Hi,



in the past (up until today) nm-connection-editor always set duplex to
"full", although the value was not implemented by the server. Thus,
every connection created in the past will change behavior after the
update.

to fix that, keyfile must ignore the old values like

  [ethernet]
  duplex=full

and treat them as unset.

Of course, we need a new way to encode full/half in keyfile, let's fix
keyfile reader/writer to instead use:

  [ethernet]
  duplex=f
  duplex=h




For the speed value, there is not problem, because nm-c-e would always
set it to 0, which is anyway what we want.



For the autonegotiation value, there is a problem:

 a)  old nm-c-e would set it to TRUE, with old libnm, old NM would not persist 
(good)
 b1) old nm-c-e would set it to TRUE, with new libnm, new NM would persist as 
TRUE (wrong)

nm-c-e must be fixed to not touch the default value for autonegotiation, so it 
would be

 b2) new nm-c-e would not set autonet, which old libnm would not transfer via 
D-Bus (and new NM wuold not persist) good
 b3) new nm-c-e would not set autonet, which new libnm would not transfer via 
D-Bus (and new NM wuold not persist) good

Note that b1) cannot be fixed, although it's a supported combination.
E.g. running nm-c-e 1.4.2 with libnm 1.5.3 against server 1.5.3.
It's a bug in nm-c-e, the solution is to upgrade to a fixed version.


Needs fix in both nm-c-e and in keyfile reader/writer.



Thomas

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

Re: Auto-negotiation - Out of business

[Thomas Haller]

On Wed, 2016-11-23 at 23:39 +0100, poma wrote:
> [...]
> Perhaps what is needed is to harmonise nm-connection-editor with
> changes in NM,
> i.e. not to apply ethernet 'duplex=full' by default.


Hi,



in the past (up until today) nm-connection-editor always set duplex to
"full", although the value was not implemented by the server. Thus,
every connection created in the past will change behavior after the
update.

to fix that, keyfile must ignore the old values like

  [ethernet]
  duplex=full

and treat them as unset.

Of course, we need a new way to encode full/half in keyfile, let's fix
keyfile reader/writer to instead use:

  [ethernet]
  duplex=f
  duplex=h




For the speed value, there is not problem, because nm-c-e would always
set it to 0, which is anyway what we want.



For the autonegotiation value, there is a problem:

 a)  old nm-c-e would set it to TRUE, with old libnm, old NM would not persist 
(good)
 b1) old nm-c-e would set it to TRUE, with new libnm, new NM would persist as 
TRUE (wrong)

nm-c-e must be fixed to not touch the default value for autonegotiation, so it 
would be

 b2) new nm-c-e would not set autonet, which old libnm would not transfer via 
D-Bus (and new NM wuold not persist) good
 b3) new nm-c-e would not set autonet, which new libnm would not transfer via 
D-Bus (and new NM wuold not persist) good

Note that b1) cannot be fixed, although it's a supported combination.
E.g. running nm-c-e 1.4.2 with libnm 1.5.3 against server 1.5.3.
It's a bug in nm-c-e, the solution is to upgrade to a fixed version.


Needs fix in both nm-c-e and in keyfile reader/writer.



Thomas

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