Re: Loss of Network Adress is DHCP Server failed for some hours
On Mon, Oct 02, Andrei Borzenkov wrote: > 02.10.2017 18:22, Olaf Hering пишет: > > On Mon, Oct 02, Francesco Giudici wrote: > > > >> With that anyway you miss the option of having different connections > >> that could fallback if the "primary" one with dhcp fails. > > > > How is it a failure if the DHCP server disappears, perhaps right after > > it provided a lease? Well, there is likely some blurb in the RFCs about > > what must be done when the lease expired. > > RFC requires that when upon lease expiration client stop using address > (actually it literally says "stop any network activity") and return to > initial state of acquiring address. Thanks for digging into it. I vaguely remember it from my work on wicked. I assume the dhcpcd binary assigns the address to the kernel inteface. If thats the case, then it is most likely also the responsibility to remove the address again. I think thats not done, but I have not verified when this happened. But whatever dhcpcd does, it is not relevant to the bug discussed here. At some point the configuration worked as expected: "the interface" got a DHCP reply and was therefore "up and running and fine", from NM point of view. Just because the DHCP server is not available at some point does not make "the interface" configuration broken or wrong. NM has to keep going with what was configured. It is the job of dhcpcd to reobtain a lease. In the other replies it sounds like it is a requirement to specifically configure NM not to fail in this scenario. This sounds backwards. But it matches what must be done in other places, like autostart of bridge slaves. In other words, the common case must be explicitly configured... Olaf signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Loss of Network Adress is DHCP Server failed for some hours
On Mon, Oct 02, Francesco Giudici wrote: > With that anyway you miss the option of having different connections > that could fallback if the "primary" one with dhcp fails. How is it a failure if the DHCP server disappears, perhaps right after it provided a lease? Well, there is likely some blurb in the RFCs about what must be done when the lease expired. Defaulting to fail the interface from NM point of view is certainly undesired behaviour. > A change in the default NetworkManager.conf can switch it off for > default connections leaving the feature there if needed: > (https://bugzilla.redhat.com/show_bug.cgi?id=1350830#c7). -EPERM Olaf signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Loss of Network Adress is DHCP Server failed for some hours
On Sun, Oct 1, Oliver Freyermuth wrote: > Is this a bug, or a feature? This is a bug. I'm sure no standard requires the DHCP server to come back within 3 minutes. NetworkManager must keep retrying, forever. Reported here: http://bugzilla.suse.com/show_bug.cgi?id=584544 Workaround here: https://build.opensuse.org/request/show/519609 --- a/src/devices/nm-device.c +++ b/src/devices/nm-device.c @@ -79,7 +79,7 @@ _LOG_DECLARE_SELF (NMDevice); /*/ #define DHCP_RESTART_TIMEOUT 120 -#define DHCP_NUM_TRIES_MAX 3 +#define DHCP_NUM_TRIES_MAX -1UL #define DEFAULT_AUTOCONNECTTRUE /*/ Complete fix is to wipe all usage of DHCP_NUM_TRIES_MAX. Olaf signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
regression: NM 1.8 does not provide nameserver
My scripts expect IP4_NAMESERVERS and/or IP6_NAMESERVERS in the environment, even with dns=none in NetworkManager.conf. This worked fine until 1.8. Now the environment has all addresses in an 'up' event, but the DNS info is missing. What must be done to pass this info to the scripts? According to the sources some "nameserver" property has to be exist. It is unclear where the info is lost. Olaf signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: verbose ipv6 routing messages
On Thu, Aug 18, Thomas Haller wrote: > On Wed, 2016-08-17 at 20:22 +0200, Olaf Hering wrote: > > With NM 1.0.12 lines like this get logged every 30 minutes: > > Aug 17 17:29:17 probook NetworkManager[1458]: Policy set > > 'bridge' (br0) as default for IPv6 routing and DNS. > > Aug 17 17:59:17 probook NetworkManager[1458]: Policy set > > 'bridge' (br0) as default for IPv6 routing and DNS. > > Aug 17 18:29:17 probook NetworkManager[1458]: Policy set > > 'bridge' (br0) as default for IPv6 routing and DNS. > > Any idea if such info is really required more than once? > > Hi, > > seems not really required :) > it's not clear why you see the same line in a row, as > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-policy.c?id=1.0.12#n467 > is guarded by: > if (default_device == priv->default_device4) It keeps doing that with NetworkManager-1.6.2-1.1.x86_64: Apr 28 10:14:12 probook NetworkManager[1297]: [1493367252.4486] policy: set 'bridge' (br0) as default for IPv6 routing and DNS Apr 28 10:44:12 probook NetworkManager[1297]: [1493369052.5665] policy: set 'bridge' (br0) as default for IPv6 routing and DNS Olaf signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
verbose ipv6 routing messages
With NM 1.0.12 lines like this get logged every 30 minutes: Aug 17 17:29:17 probook NetworkManager[1458]: Policy set 'bridge' (br0) as default for IPv6 routing and DNS. Aug 17 17:59:17 probook NetworkManager[1458]: Policy set 'bridge' (br0) as default for IPv6 routing and DNS. Aug 17 18:29:17 probook NetworkManager[1458]: Policy set 'bridge' (br0) as default for IPv6 routing and DNS. Any idea if such info is really required more than once? Olaf signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM ignores knobs regarding ipv6
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? Once I changed it to "Automatic (VPN)" the "Routes ..." knob appeared. 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. 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. Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM ignores knobs regarding ipv6
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 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 GENERAL.SPEC-OBJECT: /org/freedesktop/NetworkManager/ActiveConnection/0 GENERAL.MASTER-PATH: /org/freedesktop/NetworkManager/Devices/1 IP4.ADDRESS[1]: 10.163.0.87/32 IP4.GATEWAY:10.163.0.1 IP4.ROUTE[1]: dst = 10.163.0.0/21, nh = 10.163.0.1, mt = 50 IP4.ROUTE[2]: dst = 10.0.0.0/8, nh = 10.163.0.1, mt = 50 IP4.ROUTE[3]: dst = 149.44.0.0/16, nh = 10.163.0.1, mt = 50 IP4.ROUTE[4]: dst = 147.2.0.0/16, nh = 10.163.0.1, mt = 50 IP4.ROUTE[5]: dst = 164.99.0.0/16, nh = 10.163.0.1, mt = 50 IP4.ROUTE[6]: dst = 137.65.0.0/16, nh = 10.163.0.1, mt = 50 IP4.ROUTE[7]: dst = 151.155.128.0/17, nh = 10.163.0.1, mt = 50 IP4.DNS[1]: 10.160.0.1 IP4.DNS[2]: 10.160.2.88 IP4.DOMAIN[1]: $domain IP6.ADDRESS[1]: 2620:113:80c0:8100:10:163:0:87/64 IP6.GATEWAY: IP6.ROUTE[1]: dst = 2620:113:80c0:8000::/50, nh = 2620:113:80c0:8100:10:16
NM ignores knobs regarding ipv6
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. I also tried to apply just the addresses, ignore the received routes. Whatever happens, all ipv6 traffic goes through the tunnel as a result. Why does NM ignore the knobs? It calls openvpn like that: /usr/sbin/openvpn --remote $host 443 tcp --comp-lzo --nobind --dev tun --dev-type tun --cipher AES-256-CBC --auth SHA512 --auth-nocache --tls-auth $key 1 --reneg-sec 0 --syslog nm-openvpn --script-security 2 --up /usr/lib/nm-openvpn-service-openvpn-helper --tun -- --up-restart --persist-key --persist-tun --management /var/run/NetworkManager/nm-openvpn-05c972e7-1f61-4bca-a5a0-c6b0ed7b44a6 unix --management-client-user root --management-client-group root --management-query-passwords --auth-retry interact --route-noexec --ifconfig-noexec --client --ca $crt --cert $crt --key $key --auth-user-pass --user nm-openvpn --group nm-openvpn Does openvpn do all the address assignment by itself? Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Approaching NetworkManager 1.2
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?
#!/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: Approaching NetworkManager 1.2
On Tue, Nov 03, poma wrote: > Please bring the bridges back to network-manager-applet! Thanks for finding this... The current way of how things are broken is that even if a bridge is active the GNOME GUI still wants to manage a "cabled connection". But instead of actually doing that it tries to fiddle with the slave of the bridge instead of the bridge itself. As a result one gets two connections: one is the bridge with its slave, and another one for eth0. Please break things properly... Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Approaching NetworkManager 1.2
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. 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. 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
Re: failure with bridge devices
On Wed, Sep 30, Dan Williams wrote: > 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 :) Just to emulate a buggy ifup? Not sure if our ifup even had a mode to leave slaves alone. I suggest to patch the buggy behaviour into the distro packages where needed, instead of having people patch the correct behaviour into the packages.. Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: failure with bridge devices
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? >> 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
Re: failure with bridge devices
Am 29.09.2015 um 13:25 schrieb Jirka Klimes: > On Mon, 28 Sep 2015 19:18:12 +0200 > Olaf Hering wrote: > >> Am 28.09.2015 um 09:05 schrieb Olaf Hering: >>> connection.autoconnect-slaves: -1 (default) >> >> Did I miss that knob in the GUI? Setting it to 1 with >> "nmcli connection edit bridge" seems to fix the "up" command. > > You have to use nmcli to configure that. > I think, there is no knob in the GUI. It seems that it should be added. What is the purpose of the current state? I mean, how does one start a configured bridge? Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: vpn password stored in plain text
Am 28.09.2015 um 18:09 schrieb Dan Williams: > 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. I poked around in nm-connection-editor and realized that the icon on the right side of the password fields is actually a mode selector. Now the setting is "ask always", which wipes the password string from /etc. Thanks again! Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: failure with bridge devices
Am 28.09.2015 um 09:05 schrieb Olaf Hering: > connection.autoconnect-slaves: -1 (default) Did I miss that knob in the GUI? Setting it to 1 with "nmcli connection edit bridge" seems to fix the "up" command. Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: vpn password stored in plain text
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. Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
vpn password stored in plain text
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? Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
failure with bridge devices
I'm running openSUSE Tumbleweed, with GNOME 3.16.2 and NM 1.0.6, and have odd issues with networking. Initially GNOME automatically configured the onboard ethernet and named it "Wired Connection 1". I added a few VPN connections and all was fine. A few weeks later I finally got around to reenable my winxp-tax VM. For this I needed a bridge. The GNOME UI is appearently unable to handle bridge. I was unable to get online, under the hood only the onboard connection was enabled. Later I found nm-connection-editor. This showed the bridge devices etc. But in the end, since both seem to disagree about what is configured, I removed the related config files from /etc/NetworkManager/system-connections, used nm-connection-editor to configure a bridge with the onboard ethernet. After a reboot it finally worked. The GNOME UI is still unable to recognize the bridge connection. But in the end I was able to run the VM and all was fine again. With todays TW snapshot the IPv4 part of the connection did not get up. I found the nmcli command. It showed the bridge is online, but no IPv4 route was set. Dowing down and up showed that only the bridge came up, but not the onboard device. Trying the GNOME UI did not get a connection either. To my surprise, once I ran 'nmcli connection up bridge' the established onboard connection from GNOME changed something, now the bridge came up fine including IPv4. Up to now only IPv6 was usable to get outside. So my questions: Are there known bugs in the cooperation between NM and GNOME? Are bridge devices fully supported? If so, why did NM not bringup onboard before configuring bridge? Does NM rely on the iproute2 package in any way? Below is the output of what I configured with 'nm-connection-editor'. Why is that output even localized?! Olaf nmcli connection show br0-onboard connection.id: br0-onboard connection.uuid:e28ba628-68ec-4893-8fbd-49846c89009a connection.interface-name: enp2s0 connection.type:802-3-ethernet connection.autoconnect: yes connection.autoconnect-priority:0 connection.timestamp: 1443421196 connection.read-only: no connection.permissions: connection.zone:-- connection.master: br0 connection.slave-type: bridge connection.autoconnect-slaves: -1 (default) connection.secondaries: connection.gateway-ping-timeout:0 connection.metered: unknown 802-3-ethernet.port:-- 802-3-ethernet.speed: 0 802-3-ethernet.duplex: full 802-3-ethernet.auto-negotiate: yes 802-3-ethernet.mac-address: 1C:C1:DE:B9:BB:48 802-3-ethernet.cloned-mac-address: -- 802-3-ethernet.mac-address-blacklist: 802-3-ethernet.mtu: auto 802-3-ethernet.s390-subchannels: 802-3-ethernet.s390-nettype:-- 802-3-ethernet.s390-options: 802-3-ethernet.wake-on-lan: default 802-3-ethernet.wake-on-lan-password:-- bridge-port.priority: 32 bridge-port.path-cost: 100 bridge-port.hairpin-mode: no nmcli connection show bridge connection.id: bridge connection.uuid:7dcdbbf1-26bb-4981-a837-a617d5de88f6 connection.interface-name: br0 connection.type:bridge connection.autoconnect: yes connection.autoconnect-priority:0 connection.timestamp: 1443421195 connection.read-only: no connection.permissions: 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: no ipv4.may-fail: yes ipv6.method:auto ipv6.dns: ipv6.dns-search: ipv6.addresses: ipv6.gateway: -- ipv6.routes: ipv6.route-metric: -1 ipv6.ignore-aut
API for dispatcher scripts
After upgrading from openSUSE 11.4 with NM 0.9.something to openSUSE Tumbleweed with NM 1.0.2 I was under the impression that the interface/API for the scripts in /etc/NetworkManager/dispatcher.d is much more reliable, and much more informative. But just now I got a different interface for the up and the down event of a gsm connection. Thankfully the DEVICE_IFACE is the same for the up and down event, so I will adjust my scripts to use that. On another host I get different environment for initial vpn-up and a vpn restart. The latter lacks the route info because that is not provided during restart after the vpn gateway timed out. Right now I dont have the exact env data at hand, but I have added logging now to compare both variants. Perhaps there are already ways to catch both. I wonder if there is any promise for the called scripts, or if its just more or less random data that is provided as cmdline arguments and environment. Olaf Wed Aug 19 19:01:07 UTC 2015 124.10 115.21 /etc/NetworkManager/dispatcher.d/01-dnsmasq-conf.sh wwp0s29f7u2i4 up CONNECTION_FILENAME=/etc/NetworkManager/system-connections/Vodafone WebSessions CONNECTION_ID=Vodafone WebSessions CONNECTION_UUID=9d9f7b94-b534-4a68-b78c-ba4e1899d4b3 DEVICE_IFACE=cdc-wdm0 DEVICE_IP_IFACE=wwp0s29f7u2i4 DHCP4_BROADCAST_ADDRESS=10.230.151.223 DHCP4_DHCP_LEASE_TIME=7200 DHCP4_DHCP_MESSAGE_TYPE=5 DHCP4_DHCP_SERVER_IDENTIFIER=10.230.151.221 DHCP4_DOMAIN_NAME_SERVERS=139.7.30.125 139.7.30.126 DHCP4_EXPIRY=1440018067 DHCP4_HOST_NAME=esprimo DHCP4_IP_ADDRESS=10.230.151.220 DHCP4_NETWORK_NUMBER=10.230.151.220 DHCP4_REQUESTED_BROADCAST_ADDRESS=1 DHCP4_REQUESTED_DOMAIN_NAME=1 DHCP4_REQUESTED_DOMAIN_NAME_SERVERS=1 DHCP4_REQUESTED_DOMAIN_SEARCH=1 DHCP4_REQUESTED_HOST_NAME=1 DHCP4_REQUESTED_INTERFACE_MTU=1 DHCP4_REQUESTED_MS_CLASSLESS_STATIC_ROUTES=1 DHCP4_REQUESTED_NDS_CONTEXT=1 DHCP4_REQUESTED_NDS_SERVERS=1 DHCP4_REQUESTED_NDS_TREE_NAME=1 DHCP4_REQUESTED_NETBIOS_DD_SERVER=1 DHCP4_REQUESTED_NETBIOS_NAME_SERVERS=1 DHCP4_REQUESTED_NETBIOS_NODE_TYPE=1 DHCP4_REQUESTED_NETBIOS_SCOPE=1 DHCP4_REQUESTED_NIS_DOMAIN=1 DHCP4_REQUESTED_NIS_SERVERS=1 DHCP4_REQUESTED_NTP_SERVERS=1 DHCP4_REQUESTED_RFC3442_CLASSLESS_STATIC_ROUTES=1 DHCP4_REQUESTED_ROUTERS=1 DHCP4_REQUESTED_STATIC_ROUTES=1 DHCP4_REQUESTED_SUBNET_MASK=1 DHCP4_REQUESTED_WPAD=1 DHCP4_ROUTERS=10.230.151.221 DHCP4_SUBNET_MASK=255.255.255.252 IP4_ADDRESS_0=10.230.151.220/30 10.230.151.221 IP4_GATEWAY=10.230.151.221 IP4_NAMESERVERS=139.7.30.125 139.7.30.126 IP4_NUM_ADDRESSES=1 IP4_NUM_ROUTES=0 IP6_GATEWAY=:: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/ SHLVL=1 _=/usr/bin/env Wed Aug 19 19:11:52 UTC 2015 768.50 1344.47 /etc/NetworkManager/dispatcher.d/01-dnsmasq-conf.sh cdc-wdm0 down CONNECTION_FILENAME=/etc/NetworkManager/system-connections/Vodafone WebSessions CONNECTION_ID=Vodafone WebSessions CONNECTION_UUID=9d9f7b94-b534-4a68-b78c-ba4e1899d4b3 DEVICE_IFACE=cdc-wdm0 DEVICE_IP_IFACE=cdc-wdm0 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PWD=/ SHLVL=1 _=/usr/bin/env ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Extending the mobile-broadband-provider-info database
On Tue, Jul 19, Oleg Zhurakivskyy wrote:
> I am working on GRPS provisioning plugin for oFono open source telephony
> stack. This plugin should make it possible for oFono to automatically
> configure GPRS contexts based on information from the provider database.
> There's an idea to use the mobile-broadband-provider-info package as the
> provider database.
While you are at it, maybe something can be added to really establish an
internet connection for certain providers.
For example Vodafone offers something called Websessions. Once the
gsm/ppp connection is established, one has to start a webbrowser and
connect to any http website. This will trigger the WebBridge to open a window
with the remaining time and it will actually enable the real internet
connection in the 'Weblogic Bridge'. Without that http access, one can
just resolve hostnames, but nothing else can be done. I have no idea
wether Vodafone is the only provider doing that. The script below will
automate the http calls for the Websessions. I have used it in the last
two weeks and it worked well for me.
Olaf
#!/bin/bash
# /etc/NetworkManager/dispatcher.d/01websession.sh
#exit 0
if test "$2" = "up"
then
case "$1" in
ppp*)
(
date
echo "$0 $*"
echo
env
echo
t=`mktemp --tmpdir=/dev/shm`
set -x
w3m -dump_source http://www.inter.net/some_404_url.html
> ${t}
cat ${t}
url="`sed -n
'/window.location.href/s@^\(.*window.location.href[[:blank:]]*=[[:blank:]]*\"\)\([^\"]\+\).*@\2@p'
${t}`"
echo "url '${url}'"
w3m -dump_source "https://web.vodafone.de${url}"; > ${t}
cat ${t}
url="`sed -n
\"/var[[:blank:]]*winRef[[:blank:]]*=[[:blank:]]*window.open/s@^\(.*var[[:blank:]]*winRef[[:blank:]]*=[[:blank:]]*window.open('\)\([^']\+\).*@\2@p\"
${t}`"
echo "url '${url}'"
w3m -dump_source "https://web.vodafone.de${url}"; > ${t}
cat ${t}
rm -fv ${t}
) &> "/dev/shm/websession-${1}-${2}.txt"
;;
esac
fi
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Honor autoconnect user setting for VPN connections
The script below starts a configured VPN connection once the network is
up. It works for me on openSuSE 11.4 with NetworkManager 0.8.2 with a
gsm connection, ethernet may work as well. The script should be stored
in /etc/NetworkManager/dispatcher.d/vpn-auto.py
I send it here for review and comments.
Whats missing is a check wether the VPN connection is already active,
better logging.
I wonder when and how the autoconnect checkbox in the VPN config window
will actually work. Is it already implemented in 0.9?
If not, whats the plan to get this fixed?
Olaf
#!/usr/bin/python
# connect VPN once ethernet, wireless or umts connection is active:
#
# get kernel interface name from argv[1]
# search Devices in org.freedesktop.NetworkManager/ActiveConnections
# compare Interfaces/Properties/IpInterface with kernel interface name
# if match, search VPN connections with autoconnect enabled
import sys
import dbus
from syslog import syslog
debug = False
service_names = [ 'org.freedesktop.NetworkManagerUserSettings',
'org.freedesktop.NetworkManagerSystemSettings' ]
valid_connection_types = [ 'gsm', '802-3-ethernet' ]
invalid_connection_types = [ ]
def get_connections(service_name):
bus = dbus.SystemBus()
proxy = bus.get_object(service_name,
'/org/freedesktop/NetworkManagerSettings')
iface = dbus.Interface(proxy,
dbus_interface='org.freedesktop.NetworkManagerSettings')
return iface.ListConnections()
def get_VPN_Connection_autoconnect(mydata):
bus = dbus.SystemBus()
for service_name in service_names:
for connection in get_connections(service_name):
if debug:
syslog(" get_connection_autoconnect su %s
connection %s" % (service_name, connection))
proxy = bus.get_object(service_name, connection)
iface = dbus.Interface(proxy,
dbus_interface='org.freedesktop.NetworkManagerSettings.Connection')
settings = iface.GetSettings()
if settings['connection']['type'] != 'vpn':
continue
if settings['connection'].has_key("autoconnect") and
settings['connection']['autoconnect'] == 0:
continue
if debug:
syslog(" get_connection_autoconnect settings
'%s' " % settings['connection']['id'])
mydata['service_name'] = service_name
mydata['connection'] = connection
return True
return False
def find_IpInterface_in_Devices(interface, Devices):
bus = dbus.SystemBus()
for Device in Devices:
proxy = bus.get_object('org.freedesktop.NetworkManager', Device)
iface = dbus.Interface(proxy,
dbus_interface='org.freedesktop.DBus.Properties')
IpInterface =
iface.Get('org.freedesktop.NetworkManager.Device', 'IpInterface')
if debug:
syslog(" IpInterface '%s' @ '%s'" % (IpInterface,
Device))
if interface == IpInterface:
if debug:
syslog(" Devices '%s'" %
iface.GetAll('org.freedesktop.NetworkManager.Device'))
return True
return False
def get_ActiveConnections():
bus = dbus.SystemBus()
proxy = bus.get_object('org.freedesktop.NetworkManager',
'/org/freedesktop/NetworkManager')
iface = dbus.Interface(proxy,
dbus_interface='org.freedesktop.DBus.Properties')
return iface.Get('org.freedesktop.NetworkManager', 'ActiveConnections')
def get_active_connection_path(mydata):
ActiveConnections = get_ActiveConnections()
bus = dbus.SystemBus()
for connection in ActiveConnections:
proxy = bus.get_object('org.freedesktop.NetworkManager',
connection)
iface = dbus.Interface(proxy,
dbus_interface='org.freedesktop.DBus.Properties')
Devices =
iface.Get('org.freedesktop.NetworkManager.Connection.Active', 'Devices')
if debug:
syslog(" Devices '%s'" % Devices)
if not find_IpInterface_in_Devices(mydata['kernel_interface'],
Devices):
continue
Connection =
iface.Get('org.freedesktop.NetworkManager.Connection.Active', 'Connection')
ServiceName =
iface.Get('org.freedesktop.NetworkManager.Connection.Active', 'ServiceName')
if debug:
syslog(" Connection '%s' ServiceName '%s'" %
(Connection, ServiceName))
proxy = bus.get_object(ServiceName, Connection)
iface = dbus.Interface(proxy,
dbus_interface='org.freedesktop.NetworkManagerSettings.Connection')
Settings = iface.GetSettings()
if debug:
