Re: Configure a connection for a gsm with dynamic ttyACMx
On Tue, 2015-05-26 at 00:37 +0200, Jean-Christian de Rivaz wrote: Hello, I have a system where the modem have multiple /dev/ttyACMx ports where x is not constant because of the dynamic nature of others serial devices. ModemManager always detect the rights ttyACMx of the modem but NetworkManager only allow to configure a connection for a fixed device. this is not correct. Just leave connection.interface-name unspecified, for example via: $ nmcli connection modify NAME connection.interface-name and check it with $ nmcli connection show NAME 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
nmcli, pppoe (ADSL login and password)
Hi all, My target is: CentOS 7 on a X less gateway My internet provider provides a pppoe connection with a login and a password On CentOS6, I used to setip it up with rp-pppoe wizzard and it works: it sets up the needed things to make the network init script launch the connection at boot. I would like to learn how to do it with NM and CentOS 7. How to invoke nmcli in order to have it connected at boot? Thank you. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Configure a connection for a gsm with dynamic ttyACMx
On Tue, 2015-05-26 at 08:34 +0200, Thomas Haller wrote: On Tue, 2015-05-26 at 00:37 +0200, Jean-Christian de Rivaz wrote: Hello, I have a system where the modem have multiple /dev/ttyACMx ports where x is not constant because of the dynamic nature of others serial devices. ModemManager always detect the rights ttyACMx of the modem but NetworkManager only allow to configure a connection for a fixed device. this is not correct. Just leave connection.interface-name unspecified, for example via: $ nmcli connection modify NAME connection.interface-name It's important to note that this is the ModemManager *control port*, which can be a TTY, a cdc-wdm, etc. One thing we want to do, but haven't done yet, is to add a way to lock the connection to the device ID and/or the SIM ID (IMSI), which should often be more useful than the control port itself. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
dhcpcd support broken
This commit seems have broken dhcpcd support: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/configure.ac?h=nm-1 -0id=7daf63461de4195b1626ca15f835fc7cbc56e847 $ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man - -infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency -tracking --disable-silent-rules --libdir=/usr/lib64 --docdir=/usr/share/doc/networkmanager-1.0.2 --disable -maintainer-mode --disable-gtk-doc --disable-more-warnings --disable-static --localstatedir=/var --disable-lto --disable-config-plugin-ibft --disable-ifnet --without-netconfig --with-dbus-sys-dir=/etc/dbus-1/system.d - -with-udev-dir=/lib/udev --with-config-plugins-default=keyfile --with-iptables=/sbin/iptables --with -libsoup=yes --enable-concheck --with-crypto=gnutls --with-session-tracking=consolekit --with-suspend -resume=upower --enable-bluez5-dun --enable-introspection --enable-ppp --disable-wimax --without-dhclient - -with-dhcpcd --without-modem-manager-1 --with-nmtui --with-resolvconf --without-selinux --disable-teamdctl - -disable-tests --enable-vala --without-valgrind --with-wext --with-pppd-plugin-dir=/usr/lib64/pppd/2.4.7 configure:23483: checking for dhcpcd configure:23502: found /sbin/dhcpcd configure:23514: result: /sbin/dhcpcd configure:23528: WARNING: Cannot use dhcpcd, version 4.x or higher is required configure:23540: WARNING: Could not find a suitable DHCP client, falling back to dhclient ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcpcd support broken
On Tue, 2015-05-26 at 12:22 -0500, Dan Williams wrote:
On Mon, 2015-05-25 at 20:47 +, Joakim Tjernlund wrote:
This commit seems have broken dhcpcd support:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/configure.ac?h=nm-1
-0id=7daf63461de4195b1626ca15f835fc7cbc56e847
$ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu -
-mandir=/usr/share/man -
-infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable
-dependency
-tracking --disable-silent-rules --libdir=/usr/lib64
--docdir=/usr/share/doc/networkmanager-1.0.2 -
-disable
-maintainer-mode --disable-gtk-doc --disable-more-warnings --disable-static
--localstatedir=/var --disable
-lto
--disable-config-plugin-ibft --disable-ifnet --without-netconfig
--with-dbus-sys-dir=/etc/dbus-1/system.d
-
-with-udev-dir=/lib/udev --with-config-plugins-default=keyfile
--with-iptables=/sbin/iptables --with
-libsoup=yes --enable-concheck --with-crypto=gnutls
--with-session-tracking=consolekit --with-suspend
-resume=upower --enable-bluez5-dun --enable-introspection --enable-ppp
--disable-wimax --without-dhclient
-
-with-dhcpcd --without-modem-manager-1 --with-nmtui --with-resolvconf
--without-selinux --disable-teamdctl
-
-disable-tests --enable-vala --without-valgrind --with-wext
--with-pppd-plugin-dir=/usr/lib64/pppd/2.4.7
configure:23483: checking for dhcpcd
configure:23502: found /sbin/dhcpcd
configure:23514: result: /sbin/dhcpcd
configure:23528: WARNING: Cannot use dhcpcd, version 4.x or higher is
required
configure:23540: WARNING: Could not find a suitable DHCP client, falling
back to dhclient
It looks like that commit was wrong, because with the [[ and ]] the []
won't get carried through to configure itself. Could you edit configure
and make the dhcpcd grep section look like:
if test $with_dhcpcd != no; then
if ! $with_dhcpcd --version 21 | grep -q ^dhcpcd
[456789]\.; then
{ $as_echo $as_me:${as_lineno-$LINENO}: WARNING:
Cannot use dhcpcd,
version 4.x or higher is required 5
$as_echo $as_me: WARNING: Cannot use dhcpcd, version 4.x or higher is
required 2;}
with_dhcpcd=no
elif $with_dhcpcd --version 21 | grep -q ^dhcpcd [789]\.;
then
$as_echo #define DHCPCD_SUPPORTS_IPV6 1 confdefs.h
fi
fi
and then rerun configure and see if that fixes things?
It does fix things, although removing the 6 disables IPv6 support, keeping
^dhcpcd [6789]\.
enables IPv6.
I still want to point out that runtime test breaks cross compile(minor) and
testing version for ipv6 is not enough(major) as dhcpcd can be built without
ipv6 support
Jocke
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcpcd support broken
On Tue, 2015-05-26 at 19:49 +0200, Joakim Tjernlund wrote:
On Tue, 2015-05-26 at 12:22 -0500, Dan Williams wrote:
On Mon, 2015-05-25 at 20:47 +, Joakim Tjernlund wrote:
This commit seems have broken dhcpcd support:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/configure.ac?h=nm-1
-0id=7daf63461de4195b1626ca15f835fc7cbc56e847
$ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu -
-mandir=/usr/share/man -
-infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable
-dependency
-tracking --disable-silent-rules --libdir=/usr/lib64
--docdir=/usr/share/doc/networkmanager-1.0.2 -
-disable
-maintainer-mode --disable-gtk-doc --disable-more-warnings
--disable-static --localstatedir=/var -
-disable
-lto
--disable-config-plugin-ibft --disable-ifnet --without-netconfig
--with-dbus-sys-dir=/etc/dbus
-1/system.d
-
-with-udev-dir=/lib/udev --with-config-plugins-default=keyfile
--with-iptables=/sbin/iptables --with
-libsoup=yes --enable-concheck --with-crypto=gnutls
--with-session-tracking=consolekit --with-suspend
-resume=upower --enable-bluez5-dun --enable-introspection --enable-ppp
--disable-wimax --without
-dhclient
-
-with-dhcpcd --without-modem-manager-1 --with-nmtui --with-resolvconf
--without-selinux --disable
-teamdctl
-
-disable-tests --enable-vala --without-valgrind --with-wext
--with-pppd-plugin-dir=/usr/lib64/pppd/2.4.7
configure:23483: checking for dhcpcd
configure:23502: found /sbin/dhcpcd
configure:23514: result: /sbin/dhcpcd
configure:23528: WARNING: Cannot use dhcpcd, version 4.x or higher is
required
configure:23540: WARNING: Could not find a suitable DHCP client, falling
back to dhclient
It looks like that commit was wrong, because with the [[ and ]] the []
won't get carried through to configure itself. Could you edit configure
and make the dhcpcd grep section look like:
if test $with_dhcpcd != no; then
if ! $with_dhcpcd --version 21 | grep -q ^dhcpcd
[456789]\.; then
{ $as_echo $as_me:${as_lineno-$LINENO}: WARNING:
Cannot use dhcpcd,
version 4.x or higher is required 5
$as_echo $as_me: WARNING: Cannot use dhcpcd, version 4.x or higher is
required 2;}
with_dhcpcd=no
elif $with_dhcpcd --version 21 | grep -q ^dhcpcd [789]\.;
then
$as_echo #define DHCPCD_SUPPORTS_IPV6 1 confdefs.h
fi
fi
and then rerun configure and see if that fixes things?
It does fix things, although removing the 6 disables IPv6 support, keeping
^dhcpcd [6789]\.
enables IPv6.
I still want to point out that runtime test breaks cross compile(minor) and
testing version for ipv6 is not enough(major) as dhcpcd can be built without
ipv6 support
Forgot to add that internal dhcp client does not add hostname by default( on
gentoo anyway)
Jocke
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Configure a connection for a gsm with dynamic ttyACMx
On Tue, 2015-05-26 at 16:09 +0200, Jean-Christian de Rivaz wrote: Le 26. 05. 15 15:28, Dan Williams a écrit : On Tue, 2015-05-26 at 08:34 +0200, Thomas Haller wrote: Just leave connection.interface-name unspecified, for example via: $ nmcli connection modify NAME connection.interface-name It's important to note that this is the ModemManager *control port*, which can be a TTY, a cdc-wdm, etc. One thing we want to do, but haven't done yet, is to add a way to lock the connection to the device ID and/or the SIM ID (IMSI), which should often be more useful than the control port itself. Hi Dan, My application is a network of embedded systems where each system can have an internal or an external SIM card. For this kind of use the device ID or IMSI will not help as there will be different on each system and I want a unique configuration file that work on all systems. Understood. In this case your are correct that DeviceID and SimID won't help. However, be aware that kernel bus enumeration means that specific devices are not guaranteed to be found in the same order, and thus a modem that has ttyACM0 one time may get ttyACM3 the next time. Also if the modem crashes and disconnects, sometimes if an application holds the serial port open and doesn't close it on disconnect, that tty cannot be re-used when the modem reappears, and a new one will be chosen. So my point is that the only way to get guaranteed matching between a modem and a connection is via the device ID or SIM ID, because kernel enumeration is not guaranteed to be stable and your tty numbers therefore may not be stable. An other proposition could be to let's tag the devices from the udev rules and allow both ModemManager and NetworkManager use the tag to refer to the device. One advantage of this proposition is that it allow The best way to do this would be to use the udev rules to add symlinks as you've found. However, since the symlinking is N symlinks to 1 kernel device (ttyACMx) ModemManager cannot really use symlinks as the actual control/data port names. to use this tag differently, for example ModemManager could be configured to override the tag with the device ID and/or IMSI to fit your proposed use case. While doing my experiment, I used udev rules that created specific symbolic links for the modem regardless of this actual ttyACMx. If ModemManager could have a way to be configured to use the specific symbolic links, then NetworkManager would have see a fixed device name. This is also an acceptable way for me to solve the problem. I think instead, ModemManager should still use the normal kernel port names. But it could also read symlink names for the ports and make that available in the D-Bus interface so that NetworkManager or other programs could use them for matching. What do you think Aleksander? (note that we cannot change the kernel name (eg ttyUSB0 or ACM1) because udev/kernel do not allow doing that; they only allow creating symlinks to the kernel device. Yes, you can 'mv ttyACM0 modem0' but that breaks udev's 'by-id' symlinks so it's not a great option) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Configure a connection for a gsm with dynamic ttyACMx
Le 26. 05. 15 08:34, Thomas Haller a écrit : On Tue, 2015-05-26 at 00:37 +0200, Jean-Christian de Rivaz wrote: but NetworkManager only allow to configure a connection for a fixed device. this is not correct. Just leave connection.interface-name unspecified, for example via: $ nmcli connection modify NAME connection.interface-name and check it with $ nmcli connection show NAME Thanks Thomas for this trick. I have redacted this /etc/NetworkManager/system-connections/gsm1 file: [connection] id=gsm1 uuid=f5e7b733-beea-4fcb-b213-b2dfcbd61073 type=gsm timestamp=1432623762 [gsm] number=*99# apn=redacted [ipv6] method=auto [ipv4] method=auto And it work as expected after a 'nmcli connection reload'. For my curiosity, where this is documented ? Regards, Jean-Christian ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Configure a connection for a gsm with dynamic ttyACMx
On Tue, 2015-05-26 at 15:51 +0200, Jean-Christian de Rivaz wrote: Le 26. 05. 15 08:34, Thomas Haller a écrit : On Tue, 2015-05-26 at 00:37 +0200, Jean-Christian de Rivaz wrote: but NetworkManager only allow to configure a connection for a fixed device. this is not correct. Just leave connection.interface-name unspecified, for example via: $ nmcli connection modify NAME connection.interface-name and check it with $ nmcli connection show NAME Thanks Thomas for this trick. I have redacted this /etc/NetworkManager/system-connections/gsm1 file: [connection] id=gsm1 uuid=f5e7b733-beea-4fcb-b213-b2dfcbd61073 type=gsm timestamp=1432623762 [gsm] number=*99# apn=redacted [ipv6] method=auto [ipv4] method=auto And it work as expected after a 'nmcli connection reload'. For my curiosity, where this is documented ? The meanings of the properties are documented in man nm-settings On recent NM versions there is also man nm-settings-keyfile (which has some further details when you edit the config-file directly). You ~can~ edit the files by hand, followed by nmcli connection reload or nmcli connection load /etc/NetworkManager/system-connections/gsm1 alternatively, you can use nmcli. See also `man nmcli` and `man nmcli-examples`. 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: Configure a connection for a gsm with dynamic ttyACMx
Le 26. 05. 15 15:28, Dan Williams a écrit : On Tue, 2015-05-26 at 08:34 +0200, Thomas Haller wrote: Just leave connection.interface-name unspecified, for example via: $ nmcli connection modify NAME connection.interface-name It's important to note that this is the ModemManager *control port*, which can be a TTY, a cdc-wdm, etc. One thing we want to do, but haven't done yet, is to add a way to lock the connection to the device ID and/or the SIM ID (IMSI), which should often be more useful than the control port itself. Hi Dan, My application is a network of embedded systems where each system can have an internal or an external SIM card. For this kind of use the device ID or IMSI will not help as there will be different on each system and I want a unique configuration file that work on all systems. An other proposition could be to let's tag the devices from the udev rules and allow both ModemManager and NetworkManager use the tag to refer to the device. One advantage of this proposition is that it allow to use this tag differently, for example ModemManager could be configured to override the tag with the device ID and/or IMSI to fit your proposed use case. While doing my experiment, I used udev rules that created specific symbolic links for the modem regardless of this actual ttyACMx. If ModemManager could have a way to be configured to use the specific symbolic links, then NetworkManager would have see a fixed device name. This is also an acceptable way for me to solve the problem. Regards, Jean-Christian de Rivaz ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcpcd support broken
On Tue, 2015-05-26 at 17:49 +, Joakim Tjernlund wrote:
On Tue, 2015-05-26 at 12:22 -0500, Dan Williams wrote:
On Mon, 2015-05-25 at 20:47 +, Joakim Tjernlund wrote:
This commit seems have broken dhcpcd support:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/configure.ac?h=nm-1
-0id=7daf63461de4195b1626ca15f835fc7cbc56e847
$ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu -
-mandir=/usr/share/man -
-infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable
-dependency
-tracking --disable-silent-rules --libdir=/usr/lib64
--docdir=/usr/share/doc/networkmanager-1.0.2 -
-disable
-maintainer-mode --disable-gtk-doc --disable-more-warnings
--disable-static --localstatedir=/var --disable
-lto
--disable-config-plugin-ibft --disable-ifnet --without-netconfig
--with-dbus-sys-dir=/etc/dbus-1/system.d
-
-with-udev-dir=/lib/udev --with-config-plugins-default=keyfile
--with-iptables=/sbin/iptables --with
-libsoup=yes --enable-concheck --with-crypto=gnutls
--with-session-tracking=consolekit --with-suspend
-resume=upower --enable-bluez5-dun --enable-introspection --enable-ppp
--disable-wimax --without-dhclient
-
-with-dhcpcd --without-modem-manager-1 --with-nmtui --with-resolvconf
--without-selinux --disable-teamdctl
-
-disable-tests --enable-vala --without-valgrind --with-wext
--with-pppd-plugin-dir=/usr/lib64/pppd/2.4.7
configure:23483: checking for dhcpcd
configure:23502: found /sbin/dhcpcd
configure:23514: result: /sbin/dhcpcd
configure:23528: WARNING: Cannot use dhcpcd, version 4.x or higher is
required
configure:23540: WARNING: Could not find a suitable DHCP client, falling
back to dhclient
It looks like that commit was wrong, because with the [[ and ]] the []
won't get carried through to configure itself. Could you edit configure
and make the dhcpcd grep section look like:
if test $with_dhcpcd != no; then
if ! $with_dhcpcd --version 21 | grep -q ^dhcpcd
[456789]\.; then
{ $as_echo $as_me:${as_lineno-$LINENO}: WARNING:
Cannot use dhcpcd,
version 4.x or higher is required 5
$as_echo $as_me: WARNING: Cannot use dhcpcd, version 4.x or higher is
required 2;}
with_dhcpcd=no
elif $with_dhcpcd --version 21 | grep -q ^dhcpcd [789]\.;
then
$as_echo #define DHCPCD_SUPPORTS_IPV6 1 confdefs.h
fi
fi
and then rerun configure and see if that fixes things?
It does fix things, although removing the 6 disables IPv6 support, keeping
^dhcpcd [6789]\.
enables IPv6.
Yeah, that was my fault, it was a local modification for testing.
I've pushed the fix to nm-0-9-10, nm-1-0, and git master.
I still want to point out that runtime test breaks cross compile(minor) and
testing version for ipv6 is not enough(major) as dhcpcd can be built without
ipv6 support
I suppose instead NM could exec dhcpcd -V and then look for the string
DHCPv6 options: in the output the first time dhcpcd is run.
Beniamino, could you look into that?
Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Configure a connection for a gsm with dynamic ttyACMx
Le 26. 05. 15 18:21, Dan Williams a écrit : On Tue, 2015-05-26 at 16:09 +0200, Jean-Christian de Rivaz wrote: Hi Dan, My application is a network of embedded systems where each system can have an internal or an external SIM card. For this kind of use the device ID or IMSI will not help as there will be different on each system and I want a unique configuration file that work on all systems. Understood. In this case your are correct that DeviceID and SimID won't help. However, be aware that kernel bus enumeration means that specific devices are not guaranteed to be found in the same order, and thus a modem that has ttyACM0 one time may get ttyACM3 the next time. Also if the modem crashes and disconnects, sometimes if an application holds the serial port open and doesn't close it on disconnect, that tty cannot be re-used when the modem reappears, and a new one will be chosen. So my point is that the only way to get guaranteed matching between a modem and a connection is via the device ID or SIM ID, because kernel enumeration is not guaranteed to be stable and your tty numbers therefore may not be stable. The fact that the kernel dynamically assign the ttyACMx number can't be changed I agree, but udev rules precisely allow to match a specific device and to set a variable if the rule match. This is exactly how ModemManager already work with the ID_MM_DEVICE_IGNORE for example. This is a reliable way to identify the port of the modem. The proposed idea is to have a udev rule that contain something like this ENV(ID_MM_DEVICE_TAG_NAME)=gsm if the rule match, then ModemManager can use the tag 'gsm' as a fixed reference instead of the dynamic ttyACMx. Of course ModemManager will continue to use the dynamic ttyACMx internally to communicate with the modem but will use the 'gsm' tag on the D-Bus so that NetworkManager get a fixed name too. Now if you prefer to use the device ID or the SIM ID, ModemManager could be configured by a udev rule like ENV(ID_MM_DEVICE_TAG_TYPE)=device-id or sim-id for example. An other proposition could be to let's tag the devices from the udev rules and allow both ModemManager and NetworkManager use the tag to refer to the device. One advantage of this proposition is that it allow The best way to do this would be to use the udev rules to add symlinks as you've found. However, since the symlinking is N symlinks to 1 kernel device (ttyACMx) ModemManager cannot really use symlinks as the actual control/data port names. to use this tag differently, for example ModemManager could be configured to override the tag with the device ID and/or IMSI to fit your proposed use case. While doing my experiment, I used udev rules that created specific symbolic links for the modem regardless of this actual ttyACMx. If ModemManager could have a way to be configured to use the specific symbolic links, then NetworkManager would have see a fixed device name. This is also an acceptable way for me to solve the problem. I think instead, ModemManager should still use the normal kernel port names. But it could also read symlink names for the ports and make that available in the D-Bus interface so that NetworkManager or other programs could use them for matching. What do you think Aleksander? This is an alternative of the ENV(ID_MM_DEVICE_TAG_NAME) trick to get the tag name. The fact that the name on D-Bus should be allowed to be different from the dynamic tty is the main part that you also agree on if I understand you correctly. Jean-Christian ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
dnsmasq on ubuntu/debian not using pulled dns servers
I've had this issue for a while with ubuntu, where openvpn, openconnect vpn's that I've tried don't seem to register the dns servers properly with dnsmasq, so I get no dns resolution on vpn. It seems resolvconf isn't modifying the resolv.conf, leaving the localhost address there, but dnsmasq isn't taking/using the setting, and have not dug enough into NM to see whya, but I'm presuming dnsmasq isn't getting (but should) those out of dbus? Is this a bug or a feature? Normally I'd just uninstall dnsmasq so dns would work as a quick fix, but now in canonical's infinite wisdom, removing dnsmasq on 14.04 wants to gut half the desktop with it. Not really an option now, and has officially gotten beyond an annoyance. Rather not have to grep out my dns servers in syslog from nm to add manually to my resolv.conf every time I reconnect a vpn. -mb ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcpcd support broken
On Mon, 2015-05-25 at 20:47 +, Joakim Tjernlund wrote:
This commit seems have broken dhcpcd support:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/configure.ac?h=nm-1
-0id=7daf63461de4195b1626ca15f835fc7cbc56e847
$ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man -
-infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable-dependency
-tracking --disable-silent-rules --libdir=/usr/lib64
--docdir=/usr/share/doc/networkmanager-1.0.2 --disable
-maintainer-mode --disable-gtk-doc --disable-more-warnings --disable-static
--localstatedir=/var --disable-lto
--disable-config-plugin-ibft --disable-ifnet --without-netconfig
--with-dbus-sys-dir=/etc/dbus-1/system.d -
-with-udev-dir=/lib/udev --with-config-plugins-default=keyfile
--with-iptables=/sbin/iptables --with
-libsoup=yes --enable-concheck --with-crypto=gnutls
--with-session-tracking=consolekit --with-suspend
-resume=upower --enable-bluez5-dun --enable-introspection --enable-ppp
--disable-wimax --without-dhclient -
-with-dhcpcd --without-modem-manager-1 --with-nmtui --with-resolvconf
--without-selinux --disable-teamdctl -
-disable-tests --enable-vala --without-valgrind --with-wext
--with-pppd-plugin-dir=/usr/lib64/pppd/2.4.7
configure:23483: checking for dhcpcd
configure:23502: found /sbin/dhcpcd
configure:23514: result: /sbin/dhcpcd
configure:23528: WARNING: Cannot use dhcpcd, version 4.x or higher is required
configure:23540: WARNING: Could not find a suitable DHCP client, falling back
to dhclient
It looks like that commit was wrong, because with the [[ and ]] the []
won't get carried through to configure itself. Could you edit configure
and make the dhcpcd grep section look like:
if test $with_dhcpcd != no; then
if ! $with_dhcpcd --version 21 | grep -q ^dhcpcd
[456789]\.; then
{ $as_echo $as_me:${as_lineno-$LINENO}: WARNING:
Cannot use dhcpcd,
version 4.x or higher is required 5
$as_echo $as_me: WARNING: Cannot use dhcpcd, version 4.x or higher is
required 2;}
with_dhcpcd=no
elif $with_dhcpcd --version 21 | grep -q ^dhcpcd [789]\.;
then
$as_echo #define DHCPCD_SUPPORTS_IPV6 1 confdefs.h
fi
fi
and then rerun configure and see if that fixes things?
dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Configure a connection for a gsm with dynamic ttyACMx
On Tue, 2015-05-26 at 19:04 +0200, Jean-Christian de Rivaz wrote: Le 26. 05. 15 18:21, Dan Williams a écrit : On Tue, 2015-05-26 at 16:09 +0200, Jean-Christian de Rivaz wrote: Hi Dan, My application is a network of embedded systems where each system can have an internal or an external SIM card. For this kind of use the device ID or IMSI will not help as there will be different on each system and I want a unique configuration file that work on all systems. Understood. In this case your are correct that DeviceID and SimID won't help. However, be aware that kernel bus enumeration means that specific devices are not guaranteed to be found in the same order, and thus a modem that has ttyACM0 one time may get ttyACM3 the next time. Also if the modem crashes and disconnects, sometimes if an application holds the serial port open and doesn't close it on disconnect, that tty cannot be re-used when the modem reappears, and a new one will be chosen. So my point is that the only way to get guaranteed matching between a modem and a connection is via the device ID or SIM ID, because kernel enumeration is not guaranteed to be stable and your tty numbers therefore may not be stable. The fact that the kernel dynamically assign the ttyACMx number can't be changed I agree, but udev rules precisely allow to match a specific device and to set a variable if the rule match. This is exactly how ModemManager already work with the ID_MM_DEVICE_IGNORE for example. This is a reliable way to identify the port of the modem. The proposed idea is to have a udev rule that contain something like this ENV(ID_MM_DEVICE_TAG_NAME)=gsm if the rule match, then ModemManager can use the tag 'gsm' as a fixed reference instead of the dynamic ttyACMx. Of course ModemManager will continue to use the dynamic ttyACMx internally to communicate with the modem but will use the 'gsm' tag on the D-Bus so that NetworkManager get a fixed name too. Now if you prefer to use the device ID or the SIM ID, ModemManager could be configured by a udev rule like ENV(ID_MM_DEVICE_TAG_TYPE)=device-id or sim-id for example. An other proposition could be to let's tag the devices from the udev rules and allow both ModemManager and NetworkManager use the tag to refer to the device. One advantage of this proposition is that it allow The best way to do this would be to use the udev rules to add symlinks as you've found. However, since the symlinking is N symlinks to 1 kernel device (ttyACMx) ModemManager cannot really use symlinks as the actual control/data port names. to use this tag differently, for example ModemManager could be configured to override the tag with the device ID and/or IMSI to fit your proposed use case. While doing my experiment, I used udev rules that created specific symbolic links for the modem regardless of this actual ttyACMx. If ModemManager could have a way to be configured to use the specific symbolic links, then NetworkManager would have see a fixed device name. This is also an acceptable way for me to solve the problem. I think instead, ModemManager should still use the normal kernel port names. But it could also read symlink names for the ports and make that available in the D-Bus interface so that NetworkManager or other programs could use them for matching. What do you think Aleksander? This is an alternative of the ENV(ID_MM_DEVICE_TAG_NAME) trick to get the tag name. The fact that the name on D-Bus should be allowed to be different from the dynamic tty is the main part that you also agree on if I understand you correctly. Yes, I would prefer to do this without more tags, but using the normal symlink scheme that udev already supports well. This also makes it non-ModemManager-specific since symlinks are often used for other programs as well. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ignore virtual interfaces of WiFi devices
On Mon, 2015-05-25 at 19:39 +, Patrick Brauer wrote: Hello, I tried to get NetworkManager to ignore a virtual interface i want to use for a mesh network. I want to have NetworkManager working on some devices in parallel to the mesh networking setup. So i tried to list the device name and/or MAC address in /etc/NetworkManager/NetworkManager.conf like this: [main] plugins=keyfile [keyfile] unmanaged-devices=mac:XX:XX:XX:XX:XX:XX;interface-name:mesh0 However, this did not work. When i used the MAC address of the mesh0 interface NetworkManager did not care about this setting. When i used the MAC address of the original device controlled by NetworkManager before, it ignores both interfaces. Is it somehow possible to ignore the virtual interface alone? I could guess NetworkManager does this because it would not know the state of the physical interface at any time, but i would like to have to deal with that problems by myself. Which version of NetworkManager is this with? Also, are you restarting NM after modifying the config file? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli, pppoe (ADSL login and password)
On Tue, 2015-05-26 at 10:10 +0300, Mihamina Rakotomandimby wrote: Hi all, My target is: CentOS 7 on a X less gateway My internet provider provides a pppoe connection with a login and a password On CentOS6, I used to setip it up with rp-pppoe wizzard and it works: it sets up the needed things to make the network init script launch the connection at boot. I would like to learn how to do it with NM and CentOS 7. How to invoke nmcli in order to have it connected at boot? Hi, With nmcli you can edit a connection. See `man nmcli-examples` and `man nmcli`. See `man nm-settings` for a description of the properties. or also $ nmcli connection edit NAME nmcli help nmcli describe connection.autoconnect First you need a pppoe connection... If you don't have it already, add one with $ nmcli connection add type pppoe con-name NAME ... and then edit it... $ nmcli connection edit NAME $ nmcli connection modify NAME ... Inspect the connection with $ nmcli connection show NAME Whether it connects at boot is the connection.autoconnect property. $ nmcli connection modify NAME connection.autoconnect yes 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
