Re: recent update makes me crazy...
On 16 July 2014 17:36, Michael Biebl bi...@debian.org wrote: Am 16.07.2014 10:59, schrieb Pal, Laszlo: Hi, One of the recent upgrade continuously trying to destroy my brain by changing my virtual bridge configs... I don't have a very complicated config, one physical ethernet, one wireless and five virtual networks for my KVM machines. It was ok for several months, but after one of the recent update I cannot enable static addressing for my bridges. If I set-up the interface correctly (I mean using static address) and I restart NetworkManager my bridge interfaces are duplicated and NM creates another ones with DHCP enabled... crazy... I'm not sure if this is because virt-manager or nm this is why I post on both list [1] and [2] might be related here. In the Debian package I currently ship [3], to not make NM manage any virtual devices, since I saw a similar behaviour as yours (NM tried to run DHCP on the vbox interfaces). Hope that helps, Michael [1] https://bugzilla.gnome.org/show_bug.cgi?id=731014#c27 [2] https://bugzilla.gnome.org/show_bug.cgi?id=732998 [3] http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=blob;f=debian/patches/0005-Mark-virtual-ethernet-interfaces-as-unmanaged.patch;hb=HEAD The only solution worked for me is to remove ifcfg files related to these bridge connections, also I removed the connections from nm-applet and re-created them (or just recreated by restarting networkmanager, I'm not sure) One thing I noticed, in the previous version there was no virtual nic assigned to bridges, but now I have virb[0..4]-nic for each of them Anyway, it is working again this is the most important :) L: ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nameserver order
I have two interfaces, each of them picking dhcp info from two distinct servers (different networks). How can I tell network manager to use the nameserver from interface B first and then that from interface A? If we were to use /etc/resolv.conf, I want nameserver 192.168.4.1 nameserver 10.0.0.1 Instead of nameserver 10.0.0.1 nameserver 192.168.4.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Request for discussion: patch - remove also request dhcpv6.server-id
On Wed, 2014-07-16 at 23:07 +0200, Thomas Schäfer wrote: Hi, http://www.ietf.org/rfc/rfc3315.txt 15.12. Information-request Message Clients MUST discard any received Information-request messages. Servers MUST discard any received Information-request message that meets any of the following conditions: - The message includes a Server Identifier option and the DUID in the option does not match the server's DUID. - The message includes an IA option. Is the behavior of the devices correct? Are there other RFCs (e.g. RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227 ) with different updated rules? Or I am completely wrong? (because of mixing Server Identifier and Option Request Server Identifier?) The also_request() is saying please server, send me your DUID! so it shouldn't contravene the RFC here. However, I don't think we care a lot about the server DUID in NM itself, so I think the patch should be fine. If dhclient needs the server DUID, dhclient will figure out how to get it. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nameserver order
On Thu, 2014-07-17 at 10:17 -0400, Mauricio Tavares wrote: I have two interfaces, each of them picking dhcp info from two distinct servers (different networks). How can I tell network manager to use the nameserver from interface B first and then that from interface A? If we were to use /etc/resolv.conf, I want nameserver 192.168.4.1 nameserver 10.0.0.1 Instead of nameserver 10.0.0.1 nameserver 192.168.4.1 NM will prefer the nameserver of the default interface, which is the interface that currently has the default route. So if 192.168.4.1 comes from an interface which shouldn't really get the default route, you can set never-default to TRUE for that interface. For nm-connection-editor, that option is the Use this connection only for resources on its network checkbox in the Routes dialog of the IPv4 tab. For other GUIs (eg, KDE) there will be a similar option. For direct config file editing, it depends on your distro... if you have questions, let us know! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to set ipv4 default route
On Wed, 2014-07-16 at 17:12 -0600, Pete Zaitcev wrote: On Wed, 16 Jul 2014 16:48:24 -0600 Pete Zaitcev zait...@redhat.com wrote: [root@localhost ~]# nmcli c mod eth0 ipv4.routes 'default 192.168.129.17' Error: failed to modify ipv4.routes: invalid IPv4 route 'default'. Still, NetworkManager.conf(5) contains this tantalizing hint: Remember that NetworkManager controls the default route, so because the interface is ignored, NetworkManager may assign the default route to some other interface. I know, my shame is going to remain in the list archive forever. The right way to do it is obvious: nmcli c mod eth0 ipv4.addresses '191.168.129.23/28 192.168.129.17' nmcli c mod eth0 ipv6.addresses 'fd2d:acfb:74cc:3::7/64 fd2d:acfb:74cc:3::1' NM automatically sets the default route based on two things: (1) interface priority - all interfaces have a priority and if two interfaces are active, and *not* prevented from getting the default route (see #2), the one with the highest priority wins. Right now, that's a static ordering but we're exploring how to make that dynamic. (2) the never-default option: you can prevent connections (and thus their interface when that connection is active) from ever getting the default route by setting this option. With nmcli: nmcli c mod eth0 ipv4.never-default true nmcli c mod eth0 ipv6.never-default true would prevent connection eth0 from ever receiving the IPv4 or IPv6 default route. This would allow some other connection/interface to receive the default route, when active. Does that help? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Headless VPN connections
On Wed, 2014-07-16 at 10:24 +0200, D.S. Ljungmark wrote: Thanks, good to know. The one thing I did struggle with for a while was permissions on the keyfiles. Now as said, we have a connection defined. It connects as intended, if ordered manually. But it doesn't auto connect or reconnect. VPN autoconnect is not implemented at this time, unless you use the secondaries functionality. VPN reconnect is also not implemented, but we hope to make that work better soon. Dan /D.S. On 16 Jul 2014 10:20, Thomas Haller thal...@redhat.com wrote: On Tue, 2014-07-15 at 17:16 +0200, D.S. Ljungmark wrote: On 15/07/14 15:20, Thomas Haller wrote: ... BUT... for VPN, the settings are opaque to NetworkManager and passed on to the VPN plugin. So, to know the meaning of the [vpn] settings, you have to look for their meaning in NetworkManager-openvpn... usually these parameters correspond to command line options to openvpn. So see `man openvpn`. Aye, we have openVpn setup working. but not integrated with NetworkManager, what we're hoping is to have NM manage all interfaces and VPN's and just have stuff work without having to manage it via various cron jobs to automatically restart things just in case. ( seriously, running curl http://vpn.vpn.vpn || service vpn restart is -not- optimal. But was what we used to have ) Sidenote: NetworkManager-openvpn plugin does not pass any keys blindly to openvpn. It only allows those options, that it understands. The reason is that if the plugin would allow options that it cannot understand, it would not know what openvpn is doing. Thus, there might be some options, that are not implemented in the plugin and do not work. But as you said you got NM connecting, that does not concern you. 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: Headless VPN connections
Thanks, as the machines need unencrypted network to re-negotiate keys, I can't really use the secondaries features, so instead I just ended up with a systemd timer unit set to do nmcli -w 0 c up id vpn as a oneshot. On Thu, Jul 17, 2014 at 10:48 PM, Dan Williams d...@redhat.com wrote: On Wed, 2014-07-16 at 10:24 +0200, D.S. Ljungmark wrote: Thanks, good to know. The one thing I did struggle with for a while was permissions on the keyfiles. Now as said, we have a connection defined. It connects as intended, if ordered manually. But it doesn't auto connect or reconnect. VPN autoconnect is not implemented at this time, unless you use the secondaries functionality. VPN reconnect is also not implemented, but we hope to make that work better soon. Dan /D.S. On 16 Jul 2014 10:20, Thomas Haller thal...@redhat.com wrote: On Tue, 2014-07-15 at 17:16 +0200, D.S. Ljungmark wrote: On 15/07/14 15:20, Thomas Haller wrote: ... BUT... for VPN, the settings are opaque to NetworkManager and passed on to the VPN plugin. So, to know the meaning of the [vpn] settings, you have to look for their meaning in NetworkManager-openvpn... usually these parameters correspond to command line options to openvpn. So see `man openvpn`. Aye, we have openVpn setup working. but not integrated with NetworkManager, what we're hoping is to have NM manage all interfaces and VPN's and just have stuff work without having to manage it via various cron jobs to automatically restart things just in case. ( seriously, running curl http://vpn.vpn.vpn || service vpn restart is -not- optimal. But was what we used to have ) Sidenote: NetworkManager-openvpn plugin does not pass any keys blindly to openvpn. It only allows those options, that it understands. The reason is that if the plugin would allow options that it cannot understand, it would not know what openvpn is doing. Thus, there might be some options, that are not implemented in the plugin and do not work. But as you said you got NM connecting, that does not concern you. Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list -- 8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Request for discussion: patch - remove also request dhcpv6.server-id
On Wed, 2014-07-16 at 22:38 +0200, Thomas Schäfer wrote: Hi, As already observed in the thread dhcpv6-problem some devices are confused by option request dhcpv6.server-id. I looked a little bit in to RFC 3736 and 3315. But I still don't know what is correct. Do you need the server-id, in case they are more than one servers in your LAN? Is a empty server-id request a valid request? ( in case of a selection: does empty mean all or nothing?) Why doesn't windows send this request? Because I don't see any disadvantages I propose to remove this request. At the moment I know three devices which would work with this patch. ZTE 823D ZTEMF93E alcatel one touch W800Z (tct-mobile) alias Telekom Speedsick LTE IV and I don't know any device which would stop working. Regards, Thomas Schäfer Thanks for tracking this down! I've pushed this to git master, 0.9.10, and 0.9.8. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: recent update makes me crazy...
On Wed, 2014-07-16 at 10:59 +0200, Pal, Laszlo wrote: Hi, One of the recent upgrade continuously trying to destroy my brain by changing my virtual bridge configs... I don't have a very complicated config, one physical ethernet, one wireless and five virtual networks for my KVM machines. It was ok for several months, but after one of the recent update I cannot enable static addressing for my bridges. If I set-up the interface correctly (I mean using static address) and I restart NetworkManager my bridge interfaces are duplicated and NM creates another ones with DHCP enabled... crazy... I'm not sure if this is because virt-manager or nm this is why I post on both list Here is my versions Name: NetworkManager Arch: x86_64 Epoch : 1 Version : 0.9.9.1 Release : 4.git20140319.fc20 Installed Packages Name: virt-manager Arch: noarch Version : 1.0.1 Release : 3.fc20 Any idea? Could you attach the NetworkManager logs from 'journalctl -b -u NetworkManager'? I'd love to see what NM says it's doing here. BTW, did you get this version of NetworkManager from a COPR repository somewhere? We've made a lot of fixes to NM since March 19th, and that may very well solve some of the problems that you're having. However, the official Fedora 20 NetworkManager RPM is not this version you're using... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Software to test MAC address privacy
Greetings from IEEE 802 plenay in San Diego. We are winding down, but Monday night we had a talk on Pervasive Surveillance: https://mentor.ieee.org/802-ec/dcn/14/ec-14-0043-00-00EC-internet-privacy-tutorial.pdf I discussed this with the 802 chair and presentation moderator, and we are looking to see if we can actually test the consequences of using random local MAC addresses. The idea is to have an opt-in SSID at future 802 meetings, and perhaps at the IETF as well (same network support company) where only random local MAC addresses are allowed and then to see what problems occur (DHCP, ARP tables, bridging tables, etc.). So we (those of us that want to figure this out to see if it is worth doing) are looking to the OS providers to help. I have been tasked with reaching to the Linux community as I run Fedora. The thought is the MAC address is temporarily overwritten with a local MAC random address. This address should be changed with some periodicity. We have not worked out this part yet. Also per Internet Draft: draft-ietf-6man-ipv6-address-generation-privacy-01.txt privacy for both global and local scope IPv6 addresses. So how do I get interest in this effort and get some revised test app for me (and other Linux users) to participate? thank you ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
