Re: OK, I give up
On 11/28/2014 06:55 AM, Bjørn Mork wrote: Lubomir Rintel writes: On Thu, 2014-11-27 at 17:15 -0500, Gene Czarcinski wrote: On Fedora 21 with NetworkManager-0.9.10.0-13.git20140704.fc21.x86_6 and on Fedora 20 with NetworkManager-0.9.9.0-46.git20131003.fc20.x86_64 I am seein some strange network devices: 18: rose7: mtu 249 qdisc noop state DOWN group default link/rose 00:00:00:00:00 brd 00:00:00:00:00 19: rose8: mtu 249 qdisc noop state DOWN group default link/rose 00:00:00:00:00 brd 00:00:00:00:00 20: rose9: mtu 249 qdisc noop state DOWN group default link/rose 00:00:00:00:00 brd 00:00:00:00:00 and in /var/log/messages: Nov 27 17:04:53 vulture NetworkManager[24854]: (rose7): new Generic device (driver: 'unknown' ifindex: 18) Nov 27 17:04:53 vulture NetworkManager[24854]: (rose7): exported as /org/freedesktop/NetworkManager/Devices/17 Nov 27 17:04:53 vulture NetworkManager[24854]: (rose8): new Generic device (driver: 'unknown' ifindex: 19) Nov 27 17:04:53 vulture NetworkManager[24854]: (rose8): exported as /org/freedesktop/NetworkManager/Devices/18 Nov 27 17:04:53 vulture NetworkManager[24854]: (rose9): new Generic device (driver: 'unknown' ifindex: 20) Nov 27 17:04:53 vulture NetworkManager[24854]: (rose9): exported as /org/freedesktop/NetworkManager/Devices/19 What is this? As the name suggests, those are ROSE devices. You most likely are using (or attempted to use) an amateur radio? Not necessarily. Those devices will be created by merely loading the rose module, which can be done by referring to its 'net-pf-11' alias. Maybe NM does something that triggers this? Bjørn These "rose" network devices are showing up regularly on a i5-4570 system running Fedora 21. It is a very recent sometimes thing on a i7-4770 system running Fedora 20 and I have never seen it on an AMD 8150 also running Fedora 20. I am testing Fedora 21 virtually on the i7-4770 system if that makes any difference since I never saw this until very recently (like within the last week). Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
OK, I give up
On Fedora 21 with NetworkManager-0.9.10.0-13.git20140704.fc21.x86_6 and on Fedora 20 with NetworkManager-0.9.9.0-46.git20131003.fc20.x86_64 I am seein some strange network devices: 18: rose7: mtu 249 qdisc noop state DOWN group default link/rose 00:00:00:00:00 brd 00:00:00:00:00 19: rose8: mtu 249 qdisc noop state DOWN group default link/rose 00:00:00:00:00 brd 00:00:00:00:00 20: rose9: mtu 249 qdisc noop state DOWN group default link/rose 00:00:00:00:00 brd 00:00:00:00:00 and in /var/log/messages: Nov 27 17:04:53 vulture NetworkManager[24854]: (rose7): new Generic device (driver: 'unknown' ifindex: 18) Nov 27 17:04:53 vulture NetworkManager[24854]: (rose7): exported as /org/freedesktop/NetworkManager/Devices/17 Nov 27 17:04:53 vulture NetworkManager[24854]: (rose8): new Generic device (driver: 'unknown' ifindex: 19) Nov 27 17:04:53 vulture NetworkManager[24854]: (rose8): exported as /org/freedesktop/NetworkManager/Devices/18 Nov 27 17:04:53 vulture NetworkManager[24854]: (rose9): new Generic device (driver: 'unknown' ifindex: 20) Nov 27 17:04:53 vulture NetworkManager[24854]: (rose9): exported as /org/freedesktop/NetworkManager/Devices/19 What is this? It sure does clutter up the output of "ip addr" Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: veth won't be configured in libvirt managed LXC container
On 10/19/2014 09:53 AM, Lubomir Rintel wrote: On Sat, 2014-10-18 at 16:00 -0400, Gene Czarcinski wrote: On 10/16/2014 07:08 AM, Lubomir Rintel wrote: Hi, currently it is impossible to get useful network configuration for LXC containers on boot. (At least if they're managed via libvirt; I have no idea if anything is different with native LXC tooling). They're supposed to obtain their configuration via DHCP, but instead connection is assumed. Firstly because there's an IPv6 local link address that (I think) gets assigned when libvirt ups the interface and secondly because it's a software link. Why do we assume connection on all software links? Virtual ethernet devices are supposed to behave much like ordinary ethernet devices; they have carrier detection, etc. I'm following up with the patches that resolve the problem for me, but I'm not quite sure about the special case for veth. Thoughts? This may be related to a problem in libvirt-sandbox (Secure Containers): https://www.redhat.com/archives/libvir-list/2014-September/msg00540.html Does that mean lxc (or libvirt or whatever) is supposed to configure the interface before spawning the container? In that case it would indeed make sense for NM to assume the connection. My only experience is with Secure Containers created by virt-sandbox-service of the libvirt-sandbox package. Without my patches, you can successfully create a virtual NIC with either static or dhcp addresses. With dhcp, dhclient needs to be started. Without the patches, dhcp does not work. I do not know if this problem applies generally to containers or not. Although not a secure container, the following does work: virt-sandbox -c lxc:/// -N dhcp,source=default /bin/sh I has some problem with chrony but, when you get in, ip addr will show eth0 with an address Now, through all of this, NetworkManager is going nuts trying to get dhclient to work with vnetN but it never succeeds. Could someone who understands what NetworkManager "should" be doing and why explain. It is certainly not clear to me that NetworkManager should be doing anything! Gene -- ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: veth won't be configured in libvirt managed LXC container
On 10/16/2014 07:08 AM, Lubomir Rintel wrote: Hi, currently it is impossible to get useful network configuration for LXC containers on boot. (At least if they're managed via libvirt; I have no idea if anything is different with native LXC tooling). They're supposed to obtain their configuration via DHCP, but instead connection is assumed. Firstly because there's an IPv6 local link address that (I think) gets assigned when libvirt ups the interface and secondly because it's a software link. Why do we assume connection on all software links? Virtual ethernet devices are supposed to behave much like ordinary ethernet devices; they have carrier detection, etc. I'm following up with the patches that resolve the problem for me, but I'm not quite sure about the special case for veth. Thoughts? This may be related to a problem in libvirt-sandbox (Secure Containers): https://www.redhat.com/archives/libvir-list/2014-September/msg00540.html However, I do find it very annoying that NetworkManager insists on playing with the vnet interfaces. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
restoring forgotten device
OK, I give up ... what is the "magic dance" I need to do to restore a forgotten NIC? I was "playing" with gnome's network editor and on the reset page for a device, I hit the "Forget" button. Device was "removed" but now I would like to "restore it". How do I do that (other than to do another complete install of Fedora 20)? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
F20 alpha .. some good, some not so good
When I reported that IPv6 was not working on F20 alpha: https://bugzilla.redhat.com/show_bug.cgi?id=1013583 I was interesting in getting the fix. Since an errata was not instantly available, I extracted the extremely simple patch from the git. Next, I got the src.rpm ... well, although my problem occurred with NetworkManager-0.9.9.0-12.git20130913.fc20, I found that an update was transitioning out: NetworkManager-0.9.9.0-13.git20131001.fc20 Naturally, go for the latest and greatest ... complete disaster!!! Not only does it have problems but the gnome applet says it is not compatible someone needs to do some quick syncing to get the right package versions into F20 updates-testing. Anyway, hunted around and got the source for 0.9.9.0-12.git20130913.fc20, applied the patch and it looks good but I am definitely staying away from "13". I am going to bring it up on a KVM virtual to collect data for a bug report although the way this hit I would be surprised if someone does not beat me to reporting it. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: controlling wireless connections
On 08/07/2013 04:17 PM, Dan Williams wrote: On Wed, 2013-08-07 at 10:11 -0400, Gene Czarcinski wrote: I recently moved into a new development and pretty much each and every home in this development has a WIFI network. While most of these network are secure a few of them are not but require some kind of handshake to establish "guest" access. These "guest access" WIFI networks are a pain because my Fedora 18 client systems (running Network Manager) will sometimes attempt to use one of these network rather then my secure WIFI network. Is there some way to "blacklist" WIFI network not to be used? Or, to reverse that question, is there some way of specifying that only networks with a specific SSID should be used? NM will only autoconnect to networks that it has been told to connect to before, based on SSID and security settings. So, if you run 'nm-connection-editor', do you see configurations for those bad SSIDs? If they exist, something (either a UI applet or you) told NM to connect to them, but they can easily be deleted from there. (Or from the command line too with 'nmcli con', then find the ID or UUID and "nmcli con delete id " or "nmcli con delete uuid ") Thanks. I appear to have had a "senior moment" which caused a pilot error. Now that I understand that I can forget wireless networks that I never want to connect to, it is working. This forgetting works over a boot where NM is restarted. Time will tell to see what happens when one of the wireless networks is restarted. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
controlling wireless connections
I recently moved into a new development and pretty much each and every home in this development has a WIFI network. While most of these network are secure a few of them are not but require some kind of handshake to establish "guest" access. These "guest access" WIFI networks are a pain because my Fedora 18 client systems (running Network Manager) will sometimes attempt to use one of these network rather then my secure WIFI network. Is there some way to "blacklist" WIFI network not to be used? Or, to reverse that question, is there some way of specifying that only networks with a specific SSID should be used? If this capability does not currently exist, should it be implemented? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
controlling wireless connections
I recently moved into a new development and pretty much each and every home in this development has a WIFI network. While most of these network are secure a few of them are not but require some kind of handshake to establish "guest" access. These "guest access" WIFI networks are a pain because my Fedora 18 client systems (running Network Manager) will sometimes attempt to use one of these network rather then my secure WIFI network. Is there some way to "blacklist" WIFI network not to be used? Or, to reverse that question, is there some way of specifying that only networks with a specific SSID should be used? If this capability does not currently exist, should it be implemented? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
controlling wireless connections
I recently moved into a new development and pretty much each and every home in this development has a WIFI network. While most of these network are secure a few of them are not but require some kind of handshake to establish "guest" access. These "guest access" WIFI networks are a pain because my Fedora 18 client systems (running Network Manager) will sometimes attempt to use one of these network rather then my secure WIFI network. Is there some way to "blacklist" WIFI network not to be used? Or, to reverse that question, is there some way of specifying that only networks with a specific SSID should be used? If this capability does not currently exist, should it be implemented? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: v1.0.8 & DUID
On 02/15/2013 03:28 PM, Dan Williams wrote: On Fri, 2013-02-15 at 14:32 -0500, Gene Czarcinski wrote: >Although there is a v1.0.8 tag in the NM git, there is still hope since >there has not been a Release Announcement yet. Hmm, I don't see a 1.0.8 or a 1.0.2. The latest release was 0.9.6.4, and the next release will be 0.9.8. This next release will be from this branch: Oops ... trying to work too many different packages at the same time: NetworkManager-0.9.7.997; libvirt-1.0.2 ... but the same topic: DUID Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
v1.0.8 & DUID
Although there is a v1.0.8 tag in the NM git, there is still hope since there has not been a Release Announcement yet. I would like to encourage the inclusion of two patches into v1.0.2 before it ships: commit c0efef8c92aecb23df7dcbf3670236719d097873 dhcp: add special machine-id parse functio commit 1b1b4bd91c29425c25e8e979cd77b7a67deb9bf5 dhcp: write DUID out to lease file if not already present Without these the DUID support just does not work. And, speak of DUID ... I am planning to write a small utility program to help with DUIDs. It would output two lines. The first line with be the default-duid in "dhclient format" and the second with be the hex-string equivalent for use with libvirt and dnsmasq. By default, it would generate DUID-UUID based on the machine-id. Optionally it would product DUID-LL and DUID-LLT format when the MAC is provided. I am going to do this for myself but is there interest in including such a utility in the NM package? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/2] save duid to lease file
On 02/13/2013 11:36 AM, Dan Williams wrote: On Wed, 2013-02-13 at 11:16 -0500, Gene Czarcinski wrote: On 02/13/2013 10:43 AM, Dan Williams wrote: On Wed, 2013-02-13 at 03:01 -0500, Gene Czarcinski wrote: get_duid() got a default-duid from the lease file, from one of the system files, or from the machine-id but did not save it back to the lease file so that dhclient could use it. Signed-off-by: Gene Czarcinski Instead of writing it when getting it, we should actually write it when we're about to execute dhclient for IPv6. So something like this instead? Good catch though, thanks for looking into this. Dan Works for me. Once I turned on logging level=debug and realized that the DUID had the correct value but that it was never saved, the answer was obvious. I believe you will find the other patch equally interesting. There was no way to get duid-UUID with uuid_parse(). Yeah, I'd looked at the code for libuuid already. I saw that it was ignoring '-' already, which obviously machine-id doesn't have, but I mentally passed over the strlen() == 36 parts. I've got that patch and a cleanup in my tree waiting on some testing and then I'll push. Thanks! Dan The code in patch 2 is a "little paranoid" about machine-id being the right length, format , etc. but I noticed that uuid_parse() is pretty paranoid too. I would rather be too paranoid than having the software go off into the weeds with no indication what happened. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/2] save duid to lease file
On 02/13/2013 10:43 AM, Dan Williams wrote:
On Wed, 2013-02-13 at 03:01 -0500, Gene Czarcinski wrote:
get_duid() got a default-duid from the lease file, from
one of the system files, or from the machine-id but did
not save it back to the lease file so that dhclient
could use it.
Signed-off-by: Gene Czarcinski
Instead of writing it when getting it, we should actually write it when
we're about to execute dhclient for IPv6. So something like this
instead? Good catch though, thanks for looking into this.
Dan
Works for me. Once I turned on logging level=debug and realized that
the DUID had the correct value but that it was never saved, the answer
was obvious.
I believe you will find the other patch equally interesting. There was
no way to get duid-UUID with uuid_parse().
Gene
diff --git a/src/dhcp-manager/nm-dhcp-dhclient.c
b/src/dhcp-manager/nm-dhcp-dhclient.c
index d9f5135..c43ecf5 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient.c
@@ -455,8 +455,9 @@ dhclient_start (NMDHCPClient *client,
GError *error = NULL;
const char *iface, *uuid, *system_bus_address;
char *binary_name, *cmd_str, *pid_file = NULL, *system_bus_address_env
= NULL;
- gboolean ipv6;
+ gboolean ipv6, success;
guint log_domain;
+ char *escaped;
g_return_val_if_fail (priv->pid_file == NULL, -1);
@@ -497,6 +498,20 @@ dhclient_start (NMDHCPClient *client,
return -1;
}
+ /* Save the DUID to the leasefile dhclient will actually use */
+ if (ipv6) {
+ escaped = nm_dhcp_dhclient_escape_duid (duid);
+ success = nm_dhcp_dhclient_save_duid (priv->lease_file, escaped,
&error);
+ g_free (escaped);
+ if (!success) {
+ nm_log_warn (log_domain, "(%s): failed to save DUID to %s:
(%d) %s.",
+iface, priv->lease_file,
+error ? error->code : -1,
+error && error->message ? error->message :
"(unknown)");
+ return -1;
+ }
+ }
+
argv = g_ptr_array_new ();
g_ptr_array_add (argv, (gpointer) priv->path);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 0/2] Fix default-duid support
On 02/13/2013 03:01 AM, Gene Czarcinski wrote: These two patches correct the code for default-duid support. The first patch changes the code so that a default-duid is gotten from the lease file, from one of the system files such as /etc/dhclient6.leases, or a generate duid-UUID based on the machine-id. The second patch adds the routine machine_id_parse() and uses it in place of uuid_parse(). The machine-id "uuid" is not compatable with standard uuid. Gene Czarcinski (2): save duid to lease file add special machine-id parse function src/dhcp-manager/nm-dhcp-client.c | 30 +- src/dhcp-manager/nm-dhcp-dhclient.c | 24 +--- 2 files changed, 50 insertions(+), 4 deletions(-) This is based on git 0.9.7.997 but appears to apply to master also. Besides duid-UUID now working, I tested getting a sysadmin specified default-duid from /etc/dhclient6.leases, /var/lib/dhcp/dhclient6.leases, /var/lib/dhclient/dhclient6.leases, or from the NetworkManger connection-specific lease file. I suggest this be applied before releasing 0.9.8.0. I rebased to nm-0-9-8 with no problems or corrections needed. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/2] add special machine-id parse function
The original used uuid_parse() but that function did not
work properly since the format of the machine-id is
not compatable with a real uuid. This patch adds a new
machine_id_parse() routine to correctly convert the
character string of hex digits to a 16 byte binary string.
Signed-off-by: Gene Czarcinski
---
src/dhcp-manager/nm-dhcp-client.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/dhcp-manager/nm-dhcp-client.c
b/src/dhcp-manager/nm-dhcp-client.c
index 2cdd304..a74f2ad 100644
--- a/src/dhcp-manager/nm-dhcp-client.c
+++ b/src/dhcp-manager/nm-dhcp-client.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -323,6 +324,32 @@ nm_dhcp_client_start_ip4 (NMDHCPClient *self,
return priv->pid ? TRUE : FALSE;
}
+/* uuid_parse does not work for machine-id, so we use our own converter */
+static int
+machine_id_parse (const char *in, uuid_t uu)
+{
+ const char *cp;
+ int i;
+ unsigned char buf[3];
+
+ if (strlen(in) != 32)
+ return -1;
+ for (i = 0, cp = in; i < 32; i++, cp++)
+ {
+ if (!isxdigit(*cp))
+ return -1;
+ }
+ buf[2] = 0;
+ cp = in;
+ for (i = 0; i < 16; i++)
+ {
+ buf[0] = *cp++;
+ buf[1] = *cp++;
+ uu[i] = strtoul (buf, NULL, 16);
+ }
+ return 0;
+}
+
static GByteArray *
generate_duid_from_machine_id (void)
{
@@ -348,7 +375,8 @@ generate_duid_from_machine_id (void)
}
contents = g_strstrip (contents);
- ret = uuid_parse (contents, uuid);
+ nm_log_dbg (LOGD_DHCP6, "/etc/machine-id len= %d, value= '%s'",
strlen(contents), contents);
+ ret = machine_id_parse (contents, uuid);
g_free (contents);
if (ret != 0) {
--
1.8.1.2
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 0/2] Fix default-duid support
These two patches correct the code for default-duid support. The first patch changes the code so that a default-duid is gotten from the lease file, from one of the system files such as /etc/dhclient6.leases, or a generate duid-UUID based on the machine-id. The second patch adds the routine machine_id_parse() and uses it in place of uuid_parse(). The machine-id "uuid" is not compatable with standard uuid. Gene Czarcinski (2): save duid to lease file add special machine-id parse function src/dhcp-manager/nm-dhcp-client.c | 30 +- src/dhcp-manager/nm-dhcp-dhclient.c | 24 +--- 2 files changed, 50 insertions(+), 4 deletions(-) -- 1.8.1.2 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/2] save duid to lease file
get_duid() got a default-duid from the lease file, from
one of the system files, or from the machine-id but did
not save it back to the lease file so that dhclient
could use it.
Signed-off-by: Gene Czarcinski
---
src/dhcp-manager/nm-dhcp-dhclient.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/src/dhcp-manager/nm-dhcp-dhclient.c
b/src/dhcp-manager/nm-dhcp-dhclient.c
index d9f5135..ad41dcd 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient.c
@@ -643,7 +643,6 @@ get_duid (NMDHCPClient *client)
TRUE);
nm_log_dbg (LOGD_DHCP, "Looking for DHCPv6 DUID in '%s'.", leasefile);
duid = nm_dhcp_dhclient_read_duid (leasefile, &error);
- g_free (leasefile);
if (error) {
nm_log_warn (LOGD_DHCP, "Failed to read leasefile '%s': (%d)
%s",
@@ -666,8 +665,27 @@ get_duid (NMDHCPClient *client)
}
}
- /* return our DUID, otherwise let the parent class make a default DUID
*/
- return duid ? duid : NM_DHCP_CLIENT_CLASS
(nm_dhcp_dhclient_parent_class)->get_duid (client);
+ /* If no DUID, let the parent class make a default DUID */
+ if (!duid)
+ duid = NM_DHCP_CLIENT_CLASS
(nm_dhcp_dhclient_parent_class)->get_duid (client);
+
+ nm_log_dbg (LOGD_DHCP, "Attempting to write default-duid to leasefile
'%s'", leasefile);
+ if (duid) {
+ if (!nm_dhcp_dhclient_save_duid (leasefile,
nm_dhcp_dhclient_escape_duid (duid), &error)) {
+ nm_log_warn (LOGD_DHCP, "Failed to write default-duid
to leasefile '%s' :(%d) %s",
+ leasefile,
+ error ? error->code : -1,
+ error ? error->message :
"(unknown)");
+ g_clear_error(&error);
+ }
+ }
+ else {
+ nm_log_warn (LOGD_DHCP, "Failed to get duid-UUID from parent");
+ }
+
+ g_free (leasefile);
+
+ return duid;
}
/***/
--
1.8.1.2
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: making DUID work .. was [Dnsmasq-discuss]
On 02/12/2013 10:53 AM, Gene Czarcinski wrote: On 02/12/2013 10:13 AM, Gene Czarcinski wrote: On 02/12/2013 09:23 AM, Gene Czarcinski wrote: On 02/11/2013 04:51 PM, Dan Williams wrote: On Mon, 2013-02-11 at 16:42 -0500, Gene Czarcinski wrote: On 02/11/2013 04:06 PM, Dan Williams wrote: Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to dhcleint, which appears to generate a default DUID itself; but the NetworkManager code will honor that existing DUID if it finds it in the interface+connection specific lease file [1]. If NM does *not*, please let me know and we'll fix that bug. It is *not*. I assume that NM is suppose to be examining the lease file before dhclient starts because it sure looks like it is dhclient that is creating the default. I have a real-hardware system that I can reboot or whatever so if you need me to test something, just tell me. I know that it is frustrating on both sides if I say there is a problem and you cannot reproduce it. If you need to see the configuration file, then I should probably open a bugzilla report and file it there. BTW, I tried putting the default-duid in /etc/dhclient.leases and also in /var/lib/dhclient.leases and the only thing that seems to work is /var/lib/NetworkManager/dhclient6-.lease You want one of dhclient*6*.leases, in this priority order: SYSCONFDIR "/dhclient6.leases", LOCALSTATEDIR "/lib/dhcp/dhclient6.leases", LOCALSTATEDIR "/lib/dhclient/dhclient6.leases", or the interface+connection-specific leasefile, eg: /var/lib/dhclient/dhclient6-cc98bcbe-ef64-4db7-9b46-b12ca02172e6-wlan12.lease When I saw the above, hand slaps forehead ... of course it should be dhclient6.leases and not dhclient.leases. So I changed it in both /etc/dhclient6.leases and /var/lib/dhclient/dhcleit6.leases but it still did not work. Only replacing the interface+connection-specific leasefile with the one line file specifying the default-duid works. However, I cannot see that as a NM problem and will need to investigate dhclient. OK, so I took a look at the dhclient code and it only looks for one dhclient6 lease file. It is either the default /var/lib/dhclient/dhclient6.leases or what is specified by the -SF command line argument such as done by NetworkManager. NetworkManager could create a new NM file such as /etc/default-duid that, if present, was use for the initial dhclient6-...lease file but dhclient will do nothing to help. From my perspective, for NetworkManager to do something like this would be useful because it could be set during the install process and the system would be configured properly from first boot. Would the NM project be receptive to a patch which implemented something like that? No need for a new patch! Just need to make the code that is there work. It appears to me that in dhclient.c nm_dhcp_dhclient_init() is defined but never called by anything. Therefore, priv->def_leasefile is NULL and get_duid() does not access any of the alternate locations to get the default-duid value. I will see what kind of patch I can com up with. I am also moving this thread over to the Network Manager mailing list. I have figured out what was incorrect (mainly that the lease file was not being saved) and will pretty up things before I support the patch. This patch fixes things so that if the specific lease file is missing or does not have a valid default-duid AND if a default-duid is specified in /etc/dhclient6.leases, /var/lib/dhcp/dhclient6.leases or /var/lib//dhclient/dhclient6.leases, then the default-duid will be written out the the lease file. That fixes one thing. The other is a puzzling problem. If none of the above files exists, then a duid-UUID is suppose to be generated. BUT, in the logs a get the message that the /etc/machine-id could not be parsed. I don't know about other systems but all of mine have a /etc/machine-id consisting of a string of 32 hex digits representing 16 bytes. From the man-page for uuid_parse I get: The uuid_parse function converts the UUID string given by in into the binary representation. The input UUID is a string of the form 1b4e28ba-2fa1-11d2-883f-b9a761bde3fb (in printf(3) format "%08x-%04x-%04x-%04x-%012x", 36 bytes plus the trailing '\0') And from the dbus-uuidgen man-page: Note that the D-Bus UUID has no relationship to RFC 4122 and does not generate UUIDs compatible with that spec. Comments? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
0.9.7.997 and DUID
Forget my other message because I want to start fresh. I enable DEBUG logging which gets me more correct info as to what is going on. The following are the relevant log message: Feb 12 11:37:08 hawk NetworkManager[5693]: Activation (p5p1) Stage 3 of 5 (IP Configure Start) starting DHCPv6 as requested by IPv6 router... - Feb 12 11:37:08 hawk NetworkManager[5693]: [1360687028.778061] [nm-dhcp-dhclient.c:644] get_duid(): Looking for DHCPv6 DUID in '/var/lib/NetworkManager/dhclient6-14635fbe-a487-435e-bfba-9edace13e382-p5p1.lease'. --- Feb 12 11:37:08 hawk NetworkManager[5693]: [1360687028.778138] [nm-dhcp-dhclient.c:658] get_duid(): Looking for default DHCPv6 DUID in '/etc/dhclient6.leases'. -- Feb 12 11:37:08 hawk NetworkManager[5693]: [1360687028.778355] [nm-dhcp-client.c:442] nm_dhcp_client_start_ip6(): (p5p1): DHCPv6 DUID is '00:03:00:01:00:21:91:19:94:f3' -- Feb 12 11:37:08 hawk NetworkManager[5693]: Activation (p5p1) Beginning DHCPv6 transaction (timeout in 45 seconds) Feb 12 11:37:08 hawk NetworkManager[5693]: [1360687028.980172] [nm-dhcp-dhclient.c:545] dhclient_start(): running: /sbin/dhclient -d -6 -N -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient6-p5p1.pid -lf /var/lib/NetworkManager/dhclient6-14635fbe-a487-435e-bfba-9edace13e382-p5p1.lease -cf /var/lib/NetworkManager/dhclient6-p5p1.conf p5p1 - Here is my analysis as to what is happening: 1. in nm-dhcp-client.c nm_dhcp_client_start_ip6() calls get_duid() in nm-dhcp-dhclient.c 2. get_duid() tries /var/lib/NetworkManager/dhclient6-14635fbe-a487-435e-bfba-9edace13e382-p5p1.lease but that file does not exist (apparently this is not an error since there is no log message. 3. The get_duid() tries /etc/dhclient6.leases 4. There is obvious success because back in nm_dhcp_client_start_ip6() a log message is issued with the default-duid from /etc/dhclient6.leases Now the problems as I see them: 1. in get_duid() in nm-dhcp-dhclient.c needs to check if the specific lease file exists. If it does not AND if it was able to get a default-duid from on the the def_leasefiles, then it should write that default-duid to the specific lease file. This is the only place where the needed information to make the decision exists. Ok, this should take care of the first part of the problem. 2. in nm-dhcp-client.c nm_dhcp_client_start_ip6() does not test the result of the call to get_duid() in nm-dhcp-dhclient.c. It could be that no default-duid was found. In this case, the get_duid() in nm-dhcp-client.c should be called to generate a duid-UUID. Comments? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
making DUID work .. was [Dnsmasq-discuss]
On 02/12/2013 10:13 AM, Gene Czarcinski wrote: On 02/12/2013 09:23 AM, Gene Czarcinski wrote: On 02/11/2013 04:51 PM, Dan Williams wrote: On Mon, 2013-02-11 at 16:42 -0500, Gene Czarcinski wrote: On 02/11/2013 04:06 PM, Dan Williams wrote: Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to dhcleint, which appears to generate a default DUID itself; but the NetworkManager code will honor that existing DUID if it finds it in the interface+connection specific lease file [1]. If NM does *not*, please let me know and we'll fix that bug. It is *not*. I assume that NM is suppose to be examining the lease file before dhclient starts because it sure looks like it is dhclient that is creating the default. I have a real-hardware system that I can reboot or whatever so if you need me to test something, just tell me. I know that it is frustrating on both sides if I say there is a problem and you cannot reproduce it. If you need to see the configuration file, then I should probably open a bugzilla report and file it there. BTW, I tried putting the default-duid in /etc/dhclient.leases and also in /var/lib/dhclient.leases and the only thing that seems to work is /var/lib/NetworkManager/dhclient6-.lease You want one of dhclient*6*.leases, in this priority order: SYSCONFDIR "/dhclient6.leases", LOCALSTATEDIR "/lib/dhcp/dhclient6.leases", LOCALSTATEDIR "/lib/dhclient/dhclient6.leases", or the interface+connection-specific leasefile, eg: /var/lib/dhclient/dhclient6-cc98bcbe-ef64-4db7-9b46-b12ca02172e6-wlan12.lease When I saw the above, hand slaps forehead ... of course it should be dhclient6.leases and not dhclient.leases. So I changed it in both /etc/dhclient6.leases and /var/lib/dhclient/dhcleit6.leases but it still did not work. Only replacing the interface+connection-specific leasefile with the one line file specifying the default-duid works. However, I cannot see that as a NM problem and will need to investigate dhclient. OK, so I took a look at the dhclient code and it only looks for one dhclient6 lease file. It is either the default /var/lib/dhclient/dhclient6.leases or what is specified by the -SF command line argument such as done by NetworkManager. NetworkManager could create a new NM file such as /etc/default-duid that, if present, was use for the initial dhclient6-...lease file but dhclient will do nothing to help. From my perspective, for NetworkManager to do something like this would be useful because it could be set during the install process and the system would be configured properly from first boot. Would the NM project be receptive to a patch which implemented something like that? No need for a new patch! Just need to make the code that is there work. It appears to me that in dhclient.c nm_dhcp_dhclient_init() is defined but never called by anything. Therefore, priv->def_leasefile is NULL and get_duid() does not access any of the alternate locations to get the default-duid value. I will see what kind of patch I can com up with. I am also moving this thread over to the Network Manager mailing list. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: fixed ipv6 address with DHCPv6
On 02/09/2013 04:04 PM, Pavel Simerda wrote: Yeah, just read it. And I don't think it changes anything from the NetworkManager perspective. Cheers, Pavel OK, here is what I wrote on the dnsmasq-discuss mailing list: Unfortunately, what you have done is not going to scratch my itch! First, I would like a bit of clarification. Is the DUID-UUID going to be per system or per network interface? By per system I mean that all interfaces would have the same DUID-UUID. Now, what I want/need is the have a DUID which is predictable and fixed for an interface on a hardware system. The hardware system supports multi-boot of different installations such as a Fedora 17 system and a Fedora 18 system. I have a firm, learned the hard way, rule never to destroy a working systems ... all my installs are fresh installs into different partition, LVs, or btrfs-subvolumes. I want to be able to boot these system up and have them all use the same DUID. The reason for wanting this predictable, unchanging DUID is that I want my dnsmasq server to assign this system a specific IPv6 address without having to manually configure the system. This specific IPv6 address is used for routing IPv6 address of virtual guests running on that system. I checked and /etc/machine-id differs on each installed system. For me, the DUID-UUID is no better than DUID-LLT. However, I suspect that there are situations where DUID-UUID is the correct solution. Given these two different approaches/solutions, what I would like to see is to optionally do either one (on a per interface basis). If the value of DUID-UUID is kept in the interface configuration file, then maybe that could be extended so the DUID-LL could be specified (DUID-LLT is the default for dhclient if nothing else is done). How is dhclient "told" to use a specific DUID-UUID value? I believe that the problem is we are trying to solve two different/incompatible problems. I need to look at the new code in NetworkManager to see what is being done. I have now examined the code. I had not realized that the duid and duid-UUID bases on /etc/machine-id code was included in 0.9.7.997 (0.9.8.0-beta2) and that I did not have to apply any patches to add this support. I am going to update to this version as soon as I complete my virtual testing to see how this all works. I will state again that the UUID based on the machine-id does not satisfy my need to keep the client-id the same for all installations on a system which use a particular interface. One thing I have found is that if I disable an interface, delete the related lease file and then recreate that file with default-duid "0:3:0:1:MAC"; as the first and only line, I will get a LL client id. I was very happy that I could specify the default-duid as colon separated hex bytes rather than whatever that strange encoding the dhclient uses. However, in other cases where i stop the interface, delete the lease file, and then restart the interface appear to me to be using LLT for the client-id. How do you get a UUID-based-on-machine-id default-duid? One thing I have yet to try is to remove an interface definition and than add it back in. Tried it, no difference. Nope, I still do not understand how to have duid-UUID used. While I can live with manually specifying the default-duid, I would still prefer an option where the command-line "-D LL" was used. Well, time to start testing this on real systems so I can give feedback. Gene ----- Original Message - From: "Gene Czarcinski" To: networkmanager-list@gnome.org Sent: Saturday, February 9, 2013 5:03:52 PM Subject: Re: fixed ipv6 address with DHCPv6 See my reply to dcbw on the dnsmasq-discuss mailing list. Gene On 02/08/2013 12:20 PM, Pavel Simerda wrote: - Original Message - From: "Gene Czarcinski" For some time I have been having a problem attempting to have a dnsmasq server provide a system with a fixed IPv6 address. Setting an IPv4 address and identifying the system with its NIC's MAC address. But, with DHCPv6 there is no relationship defined in the standard for DHCPv6 to use the MAC. Correct. It's replaced with UUID. I tried using the system's name but that has not proven reliable. When the system and the dnsmasq server get "out of sync", it takes manual intervention to correct things. When things do work, it works fine. System's name is generally considered unreliable due to possible collisions. I looked into using the Client-ID but that "number" is based on the MAC plus time and will vary unpredictably. This has been already fixed by dcbw after long talks with me and cyphermox. Suddenly (like yesterday) I found what appears to be the solution and it is likely to have been there for some time. By default, dhclient will use LLT (Link-Layer plus Time) to define its DUID (Client-ID). We are switchin
Re: fixed ipv6 address with DHCPv6
See my reply to dcbw on the dnsmasq-discuss mailing list. Gene On 02/08/2013 12:20 PM, Pavel Simerda wrote: - Original Message - From: "Gene Czarcinski" For some time I have been having a problem attempting to have a dnsmasq server provide a system with a fixed IPv6 address. Setting an IPv4 address and identifying the system with its NIC's MAC address. But, with DHCPv6 there is no relationship defined in the standard for DHCPv6 to use the MAC. Correct. It's replaced with UUID. I tried using the system's name but that has not proven reliable. When the system and the dnsmasq server get "out of sync", it takes manual intervention to correct things. When things do work, it works fine. System's name is generally considered unreliable due to possible collisions. I looked into using the Client-ID but that "number" is based on the MAC plus time and will vary unpredictably. This has been already fixed by dcbw after long talks with me and cyphermox. Suddenly (like yesterday) I found what appears to be the solution and it is likely to have been there for some time. By default, dhclient will use LLT (Link-Layer plus Time) to define its DUID (Client-ID). We are switching to DUID-UUID from /etc/machine-id reportedly required by D-Bus (even though I can't image any reason as D-Bus is not commonly used over the network). But, there is an command-line override which can change this to LL (Link-Layer) which uses the MAC prepended with 0:3:0:1. This was the solution I originally proposed but... 1) It has some drawbacks. 2) You don't need it for normal operation. DUID-LLT saved in a disk file is stable enough for day-to-day operation. This has been solved by cyphermox even before we switched to machine-id. The important info is here: http://tools.ietf.org/html/rfc3315#section-9.4 See: * http://tools.ietf.org/html/rfc6355 for the DUID-UUID (in the form of /etc/machine-id). * https://bugzilla.gnome.org/show_bug.cgi?id=691885 Also examine the dhclient man age and scroll down to "*-D*/ LL or LLT/" I admit that DUID-LL is still better than non-stored DUID-LLT but DUID-UUID proves to be a better match that the two of those. If you have specific needs, you can still override the DUID manually. I then did a quick (two line) patch to NetworkManage [src/dhcp-manager/nm-dhcp-dhclient.c] to hardcode the addition of "-D", "LL" to the command-line if it is "-6". It works as advertised. Thanks for your effort but unless there's a very good reason to use DUID-LL, we're not going to do that (but you can still override the actual DUID e.g. by a script). While this works for me, I do not propose that this be the solution in NetworkManager. Instead, I propose that the default remain the same and a new configuration file parameter be added: DUID= which will have only two valid values: LL or LLT. As UUID is now the default, this proposal is obsolete. If DUID= is not specified then the default is LLT. Once this is accepted and part of NetworkManager, I will update network-manager-applet so the the DUID value can be specified when defining an IPv6 interface. Initially, editing the configuration file should be adequate. Do you have any questions or arguments for still supporting DUID-LL when we have DUID-UUID? Cheers, Pavel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
fixed ipv6 address with DHCPv6
For some time I have been having a problem attempting to have a dnsmasq server provide a system with a fixed IPv6 address. Setting an IPv4 address and identifying the system with its NIC's MAC address. But, with DHCPv6 there is no relationship defined in the standard for DHCPv6 to use the MAC. I tried using the system's name but that has not proven reliable. When the system and the dnsmasq server get "out of sync", it takes manual intervention to correct things. When things do work, it works fine. I looked into using the Client-ID but that "number" is based on the MAC plus time and will vary unpredictably. Suddenly (like yesterday) I found what appears to be the solution and it is likely to have been there for some time. By default, dhclient will use LLT (Link-Layer plus Time) to define its DUID (Client-ID). But, there is an command-line override which can change this to LL (Link-Layer) which uses the MAC prepended with 0:3:0:1. The important info is here: http://tools.ietf.org/html/rfc3315#section-9.4 Also examine the dhclient man age and scroll down to "*-D*/ LL or LLT/" I then did a quick (two line) patch to NetworkManage [src/dhcp-manager/nm-dhcp-dhclient.c] to hardcode the addition of "-D", "LL" to the command-line if it is "-6". It works as advertised. While this works for me, I do not propose that this be the solution in NetworkManager. Instead, I propose that the default remain the same and a new configuration file parameter be added: DUID= which will have only two valid values: LL or LLT. If DUID= is not specified then the default is LLT. Once this is accepted and part of NetworkManager, I will update network-manager-applet so the the DUID value can be specified when defining an IPv6 interface. Initially, editing the configuration file should be adequate. Comments? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager git20121211
On 01/31/2013 04:38 PM, Dan Williams wrote: And by "virtual networks" you mean bridge interfaces, as I see from the bug. Bridging support will be turned off-by-default in the 0.9.8 release until we can become better at cooperating with existing configurations. It will be enabled by editing the NetworkManager.conf file if you'd like to use NM to configure bridges. I have been following the "discussion on bugzilla 905035 and agree that slowly, slowly is a good approach for introducing bridge support in NM. Once the support is there and used to some degree (and all the usual corner-case "features" dealt with), then integration with other services such as libvirt can proceed. In any case, I will be watching bugzilla for an available update. When it is available, I will give it a try. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager git20121211
On 01/31/2013 10:59 AM, Gene Czarcinski wrote: I needed some functionality (dynamic dns update) not available in the NetworkManager package available in Fedora 18 so I created my own version based on git20121130. This worked nicely providing the functionality and did not appear to have any bad side effects. Then the NetworkManager git20121211 package appeared in rawhide it is usually better to use a package available from Fedora. So, I got the source rpm and rebuilt it for Fedora 18. This appeared to work fine until I realized that all of the virtual networks did not have the expected IPv4 addresses. Surprisingly, if IPv6 was defined for a network, it was there. After some investigation, I could only see that NetworkManager may be the problem. I downgraded to the git20121130 package and rebooted. The virtual networks were now OK. Any suggestions on how to report this problem? (against what and what release?) I am effectively cross-posting by sending identical messages to the NetworkManager and libvirt mailing lists. Yes, I believe the problem is with NetworkManager but there is a large libvirt impact. https://bugzilla.redhat.com/show_bug.cgi?id=905035 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager git20121211
I needed some functionality (dynamic dns update) not available in the NetworkManager package available in Fedora 18 so I created my own version based on git20121130. This worked nicely providing the functionality and did not appear to have any bad side effects. Then the NetworkManager git20121211 package appeared in rawhide it is usually better to use a package available from Fedora. So, I got the source rpm and rebuilt it for Fedora 18. This appeared to work fine until I realized that all of the virtual networks did not have the expected IPv4 addresses. Surprisingly, if IPv6 was defined for a network, it was there. After some investigation, I could only see that NetworkManager may be the problem. I downgraded to the git20121130 package and rebooted. The virtual networks were now OK. Any suggestions on how to report this problem? (against what and what release?) I am effectively cross-posting by sending identical messages to the NetworkManager and libvirt mailing lists. Yes, I believe the problem is with NetworkManager but there is a large libvirt impact. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: problem with "make dist"
On 11/28/2012 02:57 PM, Pavel Simerda wrote: From: "Gene Czarcinski" I have a clone of the NetworkManager git repository and, this morning, I ran "git pull" (from master) to make sure it was up to date. I also have a couple of other branches checked out: pavlix/ipv6 and pavlix/dhcp. I wanted to make a distribution tarball for pavlix/ipv6 so I could build an rpm of it. Don't do that. The 'pavlix/ipv6' branch is obsolete. I'm only keeping it just in case I need some of the patches later. Use 'master' for IPv6 testing instead. But, I seem to be having a problem doing that. Can someone tell me the magic dance I need to do to create a tarball from the git. It should work for you from the current master. Here is what I did on each of those branches: |./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var make make dist And here is what I get: make[2]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs/api' (cd libnm-glib && make top_distdir=../../NetworkManager-0.9.7.0 distdir=../../NetworkManager-0.9.7.0/docs/libnm-glib \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) make[2]: Entering directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' DOC Scanning header files DOC Introspecting gobjects (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed make \ top_distdir="../../NetworkManager-0.9.7.0" distdir="../../NetworkManager-0.9.7.0/docs/libnm-glib" \ dist-hook make[3]: Entering directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' *** gtk-doc must be installed and enabled in order to make dist make[3]: *** [dist-check-gtkdoc] Error 1 make[3]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' make[2]: *** [distdir] Error 2 make[2]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs' make: *** [distdir] Error 1 One other thing: I did "yum install libnl3-devel" before I ran the above (I need to remove it when I work on libvirt). I also tried to do a "make clean" before I did "make dist" but that just produced another error. I am sure there is a way this works but I do not know "the magic dance." ./autogen.sh && make && make dist That's all. You can allways clean the whole git tree (be careful, it deletes all unversioned files) with git clean -dfx before that. You can also look at: https://bugzilla.gnome.org/show_bug.cgi?id=688258 But remember that 'make dist' may work even if 'make distcheck' doesn't (distcheck actually checks the dist results). Nope ... some kind of "magic dance" [maybe some environment variable?] is needed. *** gtk-doc must be installed and enabled in order to make dist make[3]: *** [dist-check-gtkdoc] Error 1 gtk-doc is installed but I am not sure what is needed to be "enabled" ... good news ... There is a "magic dance" ... you need to add "--with-docs" to the ./autogen Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
problem with "make dist"
I have a clone of the NetworkManager git repository and, this morning, I ran "git pull" (from master) to make sure it was up to date. I also have a couple of other branches checked out: pavlix/ipv6 and pavlix/dhcp. I wanted to make a distribution tarball for pavlix/ipv6 so I could build an rpm of it. But, I seem to be having a problem doing that. Can someone tell me the magic dance I need to do to create a tarball from the git. Here is what I did on each of those branches: |./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var make make dist And here is what I get: make[2]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs/api' (cd libnm-glib && make top_distdir=../../NetworkManager-0.9.7.0 distdir=../../NetworkManager-0.9.7.0/docs/libnm-glib \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) make[2]: Entering directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' DOC Scanning header files DOC Introspecting gobjects (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed (process:17064): GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed make \ top_distdir="../../NetworkManager-0.9.7.0" distdir="../../NetworkManager-0.9.7.0/docs/libnm-glib" \ dist-hook make[3]: Entering directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' *** gtk-doc must be installed and enabled in order to make dist make[3]: *** [dist-check-gtkdoc] Error 1 make[3]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' make[2]: *** [distdir] Error 2 make[2]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs/libnm-glib' make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/home/gc/devel/git-test/NetworkManager/docs' make: *** [distdir] Error 1 One other thing: I did "yum install libnl3-devel" before I ran the above (I need to remove it when I work on libvirt). I also tried to do a "make clean" before I did "make dist" but that just produced another error. I am sure there is a way this works but I do not know "the magic dance." Gene | ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.9.6.4 and 0.9.7.0
On 11/28/2012 07:47 AM, Gene Czarcinski wrote: I am more than a little confused. There was an announcement on this list that 0.9.6.4 is the latest stable version for NM and the applet and these updates are available for Fedora 17. Fedora 18 has entered beta and includes 0.9.7.0 (git20121004) which can be rebuilt for Fedora 17. I also notice that Fedora has its own git repository for NetworkManager. Why are there two such streams? I do not understand. Could someone please explain? Never mind ... I figured it out. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
0.9.6.4 and 0.9.7.0
I am more than a little confused. There was an announcement on this list that 0.9.6.4 is the latest stable version for NM and the applet and these updates are available for Fedora 17. Fedora 18 has entered beta and includes 0.9.7.0 (git20121004) which can be rebuilt for Fedora 17. I also notice that Fedora has its own git repository for NetworkManager. Why are there two such streams? I do not understand. Could someone please explain? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: prefix=48 static route
On 10/10/2012 02:31 AM, Pavel Simerda wrote: Static route should work, but the syntax is different from IPv4. I'm working on getting it work the same (see 'pavlix/keyfile' branch). I don't currently know how this works with ifcfg-rh. Pavel Since prefix=64 is such a big deal with a lot of code (radvd requires it by RFC definition), I was not sure. I am not sure how you are going to improve the specification. I hope that a mask is not involved. I thought that the "/nn" was a great improvement. And as far as the IP6 address itself, once I got use to it, it was not bad at all. In fact, when you do not have many/any limits on what the address can bem using things like :dead:beef: and :face: makes remembering them easier. You just need to remember that some cases such as a web browser the Ip6 address needs to look like [fd00:beef::1:10]. Except for some additional testing, it will be back to libvirt for me. Gene - Original Message - From: "Gene Czarcinski" To: networkmanager-list@gnome.org Sent: Sunday, October 7, 2012 6:30:28 PM Subject: prefix=48 static route Should I be able to specify an IPv6 prefix=48 static route and have it work? I tried but it was with a lot of other "testing" and things may have just gotten a bit screwed up. So many things about IPv6 seem to want only prefix=64. Gene ___ 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
prefix=48 static route
Should I be able to specify an IPv6 prefix=48 static route and have it work? I tried but it was with a lot of other "testing" and things may have just gotten a bit screwed up. So many things about IPv6 seem to want only prefix=64. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 10/01/2012 11:44 AM, Jiri Popelka wrote: On 09/27/2012 10:22 PM, Gene Czarcinski wrote: also request fqdn.fqdn; also request fqdn.hostname; also request fqdn.domainname; These are DHCPv4 options which DHCPv6 client doesn't know. That is not clear. The dhcp-options man-page could be interpreted either way. also request dhcp6.hostname; also request dhcp6.domainname; I can't find such options in dhcp-options(5). I was grasping at straws. also request dhcp6.domain-search; This is requested by default as well as dhcp6.name-servers. See request statement in dhclient.conf(5) also request dhcp6.client-id; dhcp6.client-id is provided by client so I see no reason to request it from server. also request dhcp6.server-id; I'd say that dhcpv6 server sends this by default, by it's only a guess. This last requests are provided by dnsmasq so I thought it would be good to ask for them. And then there is (draft) RFC4704 where it says "Servers SHOULD send the complete fully qualified domain name in Client FQDN options." But, then it is "just" a draft RFC so maybe it is OK to ignore this. I did not want to assume that what they were suppose to send to the client would be sent. Regardless, the "current" patch had to "extra" stuff removed. And it does work ... integration is "in process." Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 10/01/2012 12:47 PM, Jiri Popelka wrote: On 10/01/2012 06:33 PM, Gene Czarcinski wrote: One of the problems I see is that, while there are a couple of viable dchp servers out there, where the ISC server is suppose to be the industrial strength one, dhclient seems to be the only client for the linux/*bsd/Unix systems. I wonder if there is interest in reviving the defunct dhcpv6c effort? If you mean https://fedorahosted.org/dhcpv6/ then no. It was also one-guy effort and David Cantrell stopped the development immediately after ISC dhcp-4.1.0 was released. Yes, there is dribbler but that seems like a one-guy effort and I do not see much support for it ... yes, dnsmasq is another one-guy effort but it also is popluar and has other people fixing things and submitting patches. I have no experience with Dibbler, but I believe it's a good implementation because Tomasz Mrugalski is very active on dhcwg at ietf.org Right now I believe we just grin and bear it with dhclient. Maybe ISC gets their act together, and mabe it does not. Maybe dribbler starts getting use and interest ... after all, dnsmasq seems to have gotten a lot of interest. Time will tell. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: For review: version 3 of IPv6 dynamic dns support
On 09/28/2012 05:27 PM, Pavel Simerda wrote: I just realized that your patch will both conflict with modifications in my branch and improve it at the same time. I had plans to improve DHCPv6 configuration as a whole. I kindly ask Dan and others to let me coordinate with Gene and integrate mine and his patches together. Thanks in advance, Pavel No problem with you taking this over. My objective has always been to get the functionality implemented. When you get everything integrated integrated, give me a shout-out and I will be happy to test it. I would appreciate knowing of anything wrong or just plain stupid that you find in the patch. I tried to clean up all of the vestiges of the earlier version now that dhclient6 has a conf file. I assume that the attached patch file is adequate but if you need anything else just ask. Gene - Original Message - From: "Gene Czarcinski" To: networkmanager-list@gnome.org Sent: Friday, September 28, 2012 6:40:32 PM Subject: For review: version 3 of IPv6 dynamic dns support Here is the next round of my patch to add support for IPv6 dynamic dns to NetworkManager. As before, this depends on using dhclient on the client side. As before, IPv4 support remains the same. While this does work if method dhcp is selected, this is purely by chance. The real usage is when method auto is selected where the dhcp service supplies the IPv6 address and dynamic update of dns with RA (such as from radvd) supplying the default route. As far as I know, there are not any "Red Hat ism" dependencies ... the patch now creates a conf file for dhclient-6. Some functions were renamed to include "ip4" in the names since there is now a "ip6" version also. This has been tested with both radvd/named/dhcpd/dhcpd and radvd/dnsmasq providing the server side support. It was developed based on the NetworkManager-0.9.7.0-1.git20120820 rpms. The patch is an attached file because my mail browser (Thunderbird) seems to screw up inline patches. The final submittal will be as an attached file or from git ... your choice guys. Comment?? Suggestions?? Whatever?? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM bug 684242 and other stuff
On 09/26/2012 04:51 PM, Pavel Simerda wrote: The proper keyfile configuration is for example: [connection] id=Ethernet uuid=d880f3bb-8c51-4ca4-aef7-1954e022820f type=802-3-ethernet [802-3-ethernet] mac-address=52:54:00:eb:e9:fb [ipv4] method=auto [ipv6] nmmethod=auto I believe you have a type for ipv6. For ipv6, it should be the same as for ipv4: method=auto Or at least this is what i got when it worked correctly: ipvr dhcp address and dns update plus RA for default route ... same as for ifcfg-rh. One thing I have learned while "playing around". To make sure things are working correctly: On the client, stop NetworkManager, delete the keyfile and lease files. On the server, stop named, dhcpd, and dhcpd6; then delete the dhcpd lease info files, and restart everything. Now, back to the client, start NetworkManager and then enable the network device (usually Auto Ethernet). When I did not clean up everything and start fresh on both sides, I got unpredictable results. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
For review: version 3 of IPv6 dynamic dns support
Here is the next round of my patch to add support for IPv6 dynamic dns
to NetworkManager.
As before, this depends on using dhclient on the client side. As
before, IPv4 support remains the same.
While this does work if method dhcp is selected, this is purely by
chance. The real usage is when method auto is selected where the dhcp
service supplies the IPv6 address and dynamic update of dns with RA
(such as from radvd) supplying the default route.
As far as I know, there are not any "Red Hat ism" dependencies ... the
patch now creates a conf file for dhclient-6. Some functions were
renamed to include "ip4" in the names since there is now a "ip6" version
also.
This has been tested with both radvd/named/dhcpd/dhcpd and radvd/dnsmasq
providing the server side support. It was developed based on the
NetworkManager-0.9.7.0-1.git20120820 rpms.
The patch is an attached file because my mail browser (Thunderbird)
seems to screw up inline patches. The final submittal will be as an
attached file or from git ... your choice guys.
Comment?? Suggestions?? Whatever??
Gene
diff -urp NetworkManager-0.9.7.0-orig-0/libnm-util/libnm-util.ver NetworkManager-0.9.7.0/libnm-util/libnm-util.ver
--- NetworkManager-0.9.7.0-orig-0/libnm-util/libnm-util.ver 2012-07-17 09:43:14.0 -0400
+++ NetworkManager-0.9.7.0/libnm-util/libnm-util.ver 2012-09-28 11:11:27.925410145 -0400
@@ -310,6 +310,7 @@ global:
nm_setting_ip6_config_error_get_type;
nm_setting_ip6_config_error_quark;
nm_setting_ip6_config_get_address;
+ nm_setting_ip6_config_get_dhcp_hostname;
nm_setting_ip6_config_get_dns;
nm_setting_ip6_config_get_dns_search;
nm_setting_ip6_config_get_ignore_auto_dns;
diff -urp NetworkManager-0.9.7.0-orig-0/libnm-util/nm-setting-ip6-config.c NetworkManager-0.9.7.0/libnm-util/nm-setting-ip6-config.c
--- NetworkManager-0.9.7.0-orig-0/libnm-util/nm-setting-ip6-config.c 2012-07-17 09:43:14.0 -0400
+++ NetworkManager-0.9.7.0/libnm-util/nm-setting-ip6-config.c 2012-09-28 11:11:27.927410131 -0400
@@ -66,6 +66,7 @@ G_DEFINE_TYPE (NMSettingIP6Config, nm_se
typedef struct {
char *method;
+ char *dhcp_hostname;
GSList *dns;/* array of struct in6_addr */
GSList *dns_search; /* list of strings */
GSList *addresses; /* array of NMIP6Address */
@@ -81,6 +82,7 @@ typedef struct {
enum {
PROP_0,
PROP_METHOD,
+ PROP_DHCP_HOSTNAME,
PROP_DNS,
PROP_DNS_SEARCH,
PROP_ADDRESSES,
@@ -122,6 +124,23 @@ nm_setting_ip6_config_get_method (NMSett
}
/**
+ * nm_setting_ip6_config_get_dhcp_hostname:
+ * @setting: the #NMSettingIP6Config
+ *
+ * Returns the value contained in the #NMSettingIP6Config:dhcp-hostname
+ * property.
+ *
+ * Returns: the configured hostname to send to the DHCP server
+ **/
+const char *
+nm_setting_ip6_config_get_dhcp_hostname (NMSettingIP6Config *setting)
+{
+ g_return_val_if_fail (NM_IS_SETTING_IP6_CONFIG (setting), NULL);
+
+ return NM_SETTING_IP6_CONFIG_GET_PRIVATE (setting)->dhcp_hostname;
+}
+
+/**
* nm_setting_ip6_config_get_num_dns:
* @setting: the #NMSettingIP6Config
*
@@ -693,6 +712,14 @@ verify (NMSetting *setting, GSList *all_
return FALSE;
}
+ if (priv->dhcp_hostname && !strlen (priv->dhcp_hostname)) {
+ g_set_error (error,
+ NM_SETTING_IP6_CONFIG_ERROR,
+ NM_SETTING_IP6_CONFIG_ERROR_INVALID_PROPERTY,
+ NM_SETTING_IP6_CONFIG_DHCP_HOSTNAME);
+ return FALSE;
+ }
+
return TRUE;
}
@@ -751,6 +778,10 @@ set_property (GObject *object, guint pro
case PROP_IGNORE_AUTO_DNS:
priv->ignore_auto_dns = g_value_get_boolean (value);
break;
+ case PROP_DHCP_HOSTNAME:
+ g_free (priv->dhcp_hostname);
+ priv->dhcp_hostname = g_value_dup_string (value);
+ break;
case PROP_NEVER_DEFAULT:
priv->never_default = g_value_get_boolean (value);
break;
@@ -794,6 +825,9 @@ get_property (GObject *object, guint pro
case PROP_IGNORE_AUTO_DNS:
g_value_set_boolean (value, priv->ignore_auto_dns);
break;
+ case PROP_DHCP_HOSTNAME:
+ g_value_set_string (value, priv->dhcp_hostname);
+ break;
case PROP_NEVER_DEFAULT:
g_value_set_boolean (value, priv->never_default);
break;
@@ -860,6 +894,20 @@ nm_setting_ip6_config_class_init (NMSett
G_PARAM_READWRITE | NM_SETTING_PARAM_SERIALIZE));
/**
+ * NMSettingIP6Config:dhcp-hostname:
+ *
+ * The specified name will be sent to the DHCP server when acquiring a lease.
+ **/
+ g_object_class_install_property
+ (object_class, PROP_DHCP_HOSTNAME,
+ g_param_spec_string (NM_SETTING_IP6_CONFIG_DHCP_HOSTNAME,
+ "DHCP Hostname",
+ "The specified name will be sent to the DHCP server "
+ "when acquiring a lease.",
+ NULL,
+ G_PARAM_READWRITE | NM_SETTING_PARAM_SERIALIZE));
+
+ /**
* NMSettingIP6Config:dns:
*
* Array of DNS servers, where each member of the array is a byte array
diff -urp NetworkManager-0.9.7.0-orig-0/libnm-util/nm-setting-ip6-config.h NetworkManager-0.9.7.0/libnm-util/nm-setting-
Re: Grrrr ... dhcpd6
On 09/28/2012 08:15 AM, Pavel Simerda wrote: You*may* be right. But, unfortunately, I have been playing with DHCPv6 implementations and there wasn't one that I would actually like. Except ISC DHCP which works for me but needs improvement. Give dnsmasq a look. It seems that not only NetworkManager using it as a caching name server but libvirt is using if not dependent on it. Granted, it is nothing I would like trying to scale to "industrial size" networks, but it sure configures and works well. As Dan pointed out in another message, there is sudden activity on the dnsmasq discussion mailinglist to get its RA support to work better ... maybe even suplant the need for radvd to configure routes when dhcp supplies the address and dynamic dns. You might want to consider adding it to the suite of tests you use. For my testing, I am using both named/dhcpd/dhcpd6 and dnsmasq (both requiring radvd). Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Grrrr ... dhcpd6
On 09/27/2012 04:22 PM, Gene Czarcinski wrote:
OK, anyone have any experience sending commands, requests etc. via
dhclient?
I have my patch fixed up so that it works from a conf file rather than
"-F" on the commandline since that is a "Red Hat ism".
I am asking for some stuff and I get little back from dhcpd6 [that is
using radvd, named, dhcpd, and dhcpd6 to provide services]. On the
other hand, I get pretty much what I asked for from dnsmasq [radvd and
dnsmasq provide the services]. In fact, I based what I put in by what
dnsmasq was delivering without bein asked.
Anyway, here is nm-dhclient6-eth0.conf
# Created by NetworkManager
send fqdn.fqdn "f17user28";
send fqdn.encoded on;
send fqdn.no-client-update on;
send fqdn.server-update on;
also request fqdn.fqdn;
also request fqdn.hostname;
also request fqdn.domainname;
also require dhcp6.name-servers;
also request dhcp6.fqdn;
also request dhcp6.hostname;
also request dhcp6.domainname;
also request dhcp6.domain-search;
also request dhcp6.client-id;
also request dhcp6.server-id;
---
And here is dhclient6--eth0.lease
-
lease6 {
interface "eth0";
ia-na 00:e6:01:85 {
starts 1348776391;
renew 0;
rebind 0;
iaaddr fd00:dead:beef:28::2fe {
starts 1348776391;
preferred-life 7200;
max-life 21600;
}
}
option dhcp6.client-id 0:1:0:1:17:f7:6e:46:52:54:0:e6:1:85;
option dhcp6.server-id 0:1:0:1:17:f7:6d:f9:52:54:0:15:48:2;
option dhcp6.name-servers fd00:dead:beef:28::91;
option dhcp6.domain-search "vtest.";
}
-
Any insight would be appreciated. The patch is "almost there" but I
would really like to understand this.
BTW, on the client side stuff is working in that I get dhcpd6
addresses and dns update with a RA route. This is both for
radvd/dnsmasq and radvd/named/dhcpd/dhcpd6 configurations. Yup, that
auto stuff really works nicely.
A little more information. I re-ran my test but this time I had
wireshark running on the server.
The requests for fqdn.fqdn, fqdn.hostname, fqdn.domainname, dhcp6.fqdn,
dhcp6.hostname, and dhcp6.domainname were not sent from the dhclient to
the server. Whether dhcpd6 could/would supply the info is not known
since dhclient never asked. At this point I am going to just drop those
requests. The dynamic dns update is done and the address is supplied. I
do not feel up to digging into dhclient code to see what is screwed up
there.
At least stuff works.
Gene
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Grrrr ... dhcpd6
OK, anyone have any experience sending commands, requests etc. via dhclient?
I have my patch fixed up so that it works from a conf file rather than
"-F" on the commandline since that is a "Red Hat ism".
I am asking for some stuff and I get little back from dhcpd6 [that is
using radvd, named, dhcpd, and dhcpd6 to provide services]. On the
other hand, I get pretty much what I asked for from dnsmasq [radvd and
dnsmasq provide the services]. In fact, I based what I put in by what
dnsmasq was delivering without bein asked.
Anyway, here is nm-dhclient6-eth0.conf
# Created by NetworkManager
send fqdn.fqdn "f17user28";
send fqdn.encoded on;
send fqdn.no-client-update on;
send fqdn.server-update on;
also request fqdn.fqdn;
also request fqdn.hostname;
also request fqdn.domainname;
also require dhcp6.name-servers;
also request dhcp6.fqdn;
also request dhcp6.hostname;
also request dhcp6.domainname;
also request dhcp6.domain-search;
also request dhcp6.client-id;
also request dhcp6.server-id;
---
And here is dhclient6--eth0.lease
-
lease6 {
interface "eth0";
ia-na 00:e6:01:85 {
starts 1348776391;
renew 0;
rebind 0;
iaaddr fd00:dead:beef:28::2fe {
starts 1348776391;
preferred-life 7200;
max-life 21600;
}
}
option dhcp6.client-id 0:1:0:1:17:f7:6e:46:52:54:0:e6:1:85;
option dhcp6.server-id 0:1:0:1:17:f7:6d:f9:52:54:0:15:48:2;
option dhcp6.name-servers fd00:dead:beef:28::91;
option dhcp6.domain-search "vtest.";
}
-
Any insight would be appreciated. The patch is "almost there" but I
would really like to understand this.
BTW, on the client side stuff is working in that I get dhcpd6 addresses
and dns update with a RA route. This is both for radvd/dnsmasq and
radvd/named/dhcpd/dhcpd6 configurations. Yup, that auto stuff really
works nicely.
Gene
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: For review: updates to add IPv6 dynamic dns support
On 09/27/2012 04:43 AM, Jiri Popelka wrote: On 09/26/2012 06:44 PM, Subhendu Ghosh wrote: Can those patches or options be submitted again? dhcp is going thru a re-write along with bind 10 Submitted to dhcp-sugg...@isc.org as [ISC-Bugs #31164] I'll post the reply here. While it will be nice if ISC picks up the patches, I believe that as far as NM is concerned the "correct" approach is to create a conf file so that we can do it properly and also request the correct info. Dnsmasq provides most/all of that unsolicited but dhcpv6 could also if only asked. GEne ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM bug 684242 and other stuff
On 09/26/2012 02:04 PM, Gene Czarcinski wrote: BTW, my testing that worked was using named/dhcpd/dhcp6 on the server. I now need to test dnsmasq to make sure that it works too. It is possible that for a small network (which is the primary use of dnsmasq), you might not need radvd because dnsmasq does some RA support too. That might be very convenient for the libvirt folks ... if it works or can be made to work. For anyone interested, dnsmasq works with this too. I need to do more testing to see if in can replace radvd in small networks. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM bug 684242 and other stuff
On 09/26/2012 02:38 PM, Dan Williams wrote: There's some example keyfiles here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/keyfile/tests/keyfiles manual IPv6 is for example: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/keyfile/tests/keyfiles/Test_Wired_Connection_IP6 but that doesn't describe SLAAC. For that, you just need: [ipv6] method=auto What I am looking for (without diving into the Networkmanager code any more than I have too) is a keyfile configuration which will cause RA to be used for the default route and dhcpv6 for the client's IPv6 address and,m if dhclient is used with my mods, a ddns update. On the surface, I must say that I like keyfile a lot better than the ifcfg-rh stuff. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM bug 684242 and other stuff
On 09/25/2012 07:55 PM, Pavel Simerda wrote: I'll divide my reaction into four parts and post it also to NM mailing list so that anyone can benefit. 1) DHCPv6 currently works according to IETF standards and has been tested with NetworkManager commit 70f64fbc4277c636c0a373d6e6eddf0574d53827 before merging the 'ipv6' branch into master. The problem with setting default route has been fixed in the previous commit 70f64fbc4277c636c0a373d6e6eddf0574d53827. You can look at them for more details. I have just checkout out 0.9.6.0, ran ./autogen.sh, make, make install and ran NetworkManager. DHCPv6 works like a charm including RA-originated default route. It even works without any configuration (just delete it or move it away). # ip address show dev eth1 3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:eb:e9:fb brd ff:ff:ff:ff:ff:ff inet 192.168.25.12/24 brd 192.168.25.255 scope global eth1 inet6 2001:abcd:1:1::1:115b/128 scope global valid_lft forever preferred_lft forever inet6 fe80::5054:ff:feeb:e9fb/64 scope link valid_lft forever preferred_lft forever # ip -6 route show default default via fe80::5054:ff:fe44:5d16 dev eth1 proto static metric 1 default via fe80::20c:42ff:fe13:857b dev eth0 proto kernel metric 1024 expires 57sec default via fe80::5054:ff:fe44:5d16 dev eth1 proto kernel metric 1024 expires 252sec The routes with metric 1024 are from kernel. NetworkManager wants to make eth1 the default interface so it creates the same route with metric 1. The testing server environment is as described in: https://fedoraproject.org/wiki/Tools/NetworkManager/IPv6#DHCPv6_address_and_DNS_configuration I'm doing first tests with firewall and selinux disabled (if applicable). If your tests show different results, please present them in their full beauty. When you are right, you are right! Yes, Pavel you very much right! The small difference between what I had and what is specified for the test is radvd.conf. The configuration that works adds "AdvManagedFlag on;", deletes most of the rest, and has "AdvAutonomous off;". What a difference that made. Now, my next question. The above was with plugin=ifcfg-rh and I also have a virtual system using plugin=keyfile (I want to made sure that my ddns works). What parameters do I need to add to the keyfile definition so that it works too? When I tested both virtual systems I removed all previous configuration stuff and let NM create some default configuration files. The results were that plugin=ifcfg-rh worked and plugin=keyfile did not. For the default plugin=keyfile system you got a SLAAC address and a good default route. If I specify that method=dhcp, then dhcp6 assigns an address and named is updated but there is no good default route. BTW, my testing that worked was using named/dhcpd/dhcp6 on the server. I now need to test dnsmasq to make sure that it works too. It is possible that for a small network (which is the primary use of dnsmasq), you might not need radvd because dnsmasq does some RA support too. That might be very convenient for the libvirt folks ... if it works or can be made to work. 2) NetworkManager supports the following methods: method=auto (this is the automatic configuration described in IPv6 standards including DHCPv6) method=manual (you can set up addresses here) method=link-local (global addressing is disabled) It doesn't currently support all sorts of hybrids. If you want it to support something more than autoconf (including DHCP) and manual configuration, please file a RFE in bugzilla (if it's not filed already). Don't use method=dhcp (aka DHCP only). It never worked. Don't use method=ignore, it was there to leave everything up to the kernel when NetworkManager didn't have such good support for IPv6. DHCP worked for IPv4 because there was a lot of "just make it work" stuff done. But IPv6 is a new ballgame. I do not know if implementing support for a static, specified default route if worth the effort or not, I do not know that it is needed other than when you do a manual, static configuration. BTW, I found that I could make some interesting entries in nm-applet's route specification for IPv6 when crashed NetworkManager real hard ... took a reboot to get it back. I will have to collect more info and bugzilla that. 3) http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 This draft is recycling something that has been proposed for *years*. In my opinion, there is no need to care about this at all at this point of time. I think mostly only need to care about the current IPv6 node requirements: http://tools.ietf.org/html/rfc6434 This is what you can expect from IPv6 configuration daemon. If this document is updated/obsoleted, then there's time for implementing the change in NetworkManager. Unless, of course, you have a very good reason to do otherwise. 4) Looking forward to seeing your IPv
Re: For review: updates to add IPv6 dynamic dns support
On 09/25/2012 02:49 PM, Dan Williams wrote: On Tue, 2012-09-25 at 13:43 +0200, Jiri Popelka wrote: On 09/24/2012 02:45 PM, Gene Czarcinski wrote: 1. Modified nm-dhcp-manager.c and nm-dhcp-dhclient.c to put the HOSTNAME or DHCP_HOSTNAME on the dhclient "-6" command line using the "-F" parameter. This tells dhclient to send the name as a fqdn.fqdn to the dhcp server. Hi, the -F as well as -B,-H,-I,-R,-V options are Fedora/RHEL specific. There are no such options in upstream dhclient. You probably need to put "send fqdn.fqdn " to NM generated dhclient.conf Yeah, I forgot about that. Which is probably why we didn't use -F and -H originally for IPv4 too. I recall those patches were submitted upstream years ago but upstream didn't like them. Thanks ... this is why I put this up for review. Back to work. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
IPV6 routing
OK, I have done more testing. 1. With 0.9.7.0, the failing default route message is gone. 2. If you have radvd configured and running on the IPv6 network, the using "automatic" for IPv6 works and you get a default route which works. 3. If you configure IPv6 to use dhcp, then there is no default route. 4. Specifying IPV6_DEFAULTGW or IPV6_DEFAULTDEV seem to have no effect with dhcp ... I need to look at the code to see what is going on. 5. Configuring IPV6 for manual works and you can specify a gateway which works. Strange, a little while ago I was using ip -6 route add default via dev eth0 and it worked. Now, only ip -6 add default dev eth0 is accepted and works. There was a kernel update between. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: failed to set IPv6 default route
On 09/24/2012 02:49 PM, Gene Czarcinski wrote: On 09/24/2012 01:05 PM, Gene Czarcinski wrote: On 09/24/2012 12:30 PM, Dan Williams wrote: On Mon, 2012-09-24 at 08:05 -0400, Gene Czarcinski wrote: On 09/23/2012 08:56 AM, Gene Czarcinski wrote: I have been doing some work trying to improve IPv6 dhcp support in NetworkManager. This has involved a lot of (virtual) testing. One thing I began to notice is a lot of the following message appearing in syslog: [nm-system.c:1121] nm_system_replace_default_ip6_route(): (p32p1): failed to set IPv6 default route: -7 The only way I have been able to get an IPv6 default route set is to use manual configuration and specify a gateway. Everything else seems to produce this message. OK, is this a bug or is there something about configuration I do not understand? My question concerning if this is a bug stands. However, I have been playing around (marvelous what you can do with some qemu/kvm/libvirt virtual guests when you do not care if things get really screwed up). I thried using NetworkManager (the applet) to set a default route but nothing seemed to work except specifying the gateway when manually configuring IPv6. I finally googled what appears to be (sort of) an answer. enter something like the following command line command: ip -6 route add default via dev eth0 So that's essentially what NM is trying to do, actually, but NM is trying to do it with netlink (which is what /sbin/ip uses too actually) but apparently the netlink options we're adding aren't quite correct here. They unfortunately change periodically when kernel changes happen. -7 appears to be NLE_INVAL, which would indicate the kernel doesn't think the route we gave it is valid. We'd have to dig a bit further down to figure out what that error actually is. Last time I had to do this, I had to rebuild /sbin/ip and make it print out the exact netlink packet it was sending to the kernel. Then I had NM print out its packet and compared the two. If only there was an easier way... I am currently running 0.9.4.0 and in the process of updating to 0.9.7.0 is see if that makes a difference. I build and installed 0.9.7.0-1.git20120820 on real hardware. Does not appear to make any difference. Should I bugzilla this? At this point in time ... it works and I will not bugzilla naturally. First thing is that it took 0.9.7.0. Next I am using dhcp6 with dynamic DNS updating using dnsmasq as the server and it did not really work until I stopped NetworkManager, deleted the dhclient lease files, and then restarted NetworkManager. Old lease files can confuse things. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: failed to set IPv6 default route
On 09/24/2012 01:05 PM, Gene Czarcinski wrote: On 09/24/2012 12:30 PM, Dan Williams wrote: On Mon, 2012-09-24 at 08:05 -0400, Gene Czarcinski wrote: On 09/23/2012 08:56 AM, Gene Czarcinski wrote: I have been doing some work trying to improve IPv6 dhcp support in NetworkManager. This has involved a lot of (virtual) testing. One thing I began to notice is a lot of the following message appearing in syslog: [nm-system.c:1121] nm_system_replace_default_ip6_route(): (p32p1): failed to set IPv6 default route: -7 The only way I have been able to get an IPv6 default route set is to use manual configuration and specify a gateway. Everything else seems to produce this message. OK, is this a bug or is there something about configuration I do not understand? My question concerning if this is a bug stands. However, I have been playing around (marvelous what you can do with some qemu/kvm/libvirt virtual guests when you do not care if things get really screwed up). I thried using NetworkManager (the applet) to set a default route but nothing seemed to work except specifying the gateway when manually configuring IPv6. I finally googled what appears to be (sort of) an answer. enter something like the following command line command: ip -6 route add default via dev eth0 So that's essentially what NM is trying to do, actually, but NM is trying to do it with netlink (which is what /sbin/ip uses too actually) but apparently the netlink options we're adding aren't quite correct here. They unfortunately change periodically when kernel changes happen. -7 appears to be NLE_INVAL, which would indicate the kernel doesn't think the route we gave it is valid. We'd have to dig a bit further down to figure out what that error actually is. Last time I had to do this, I had to rebuild /sbin/ip and make it print out the exact netlink packet it was sending to the kernel. Then I had NM print out its packet and compared the two. If only there was an easier way... I am currently running 0.9.4.0 and in the process of updating to 0.9.7.0 is see if that makes a difference. I build and installed 0.9.7.0-1.git20120820 on real hardware. Does not appear to make any difference. Should I bugzilla this? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: libnm-util reference manual
On 09/24/2012 12:25 PM, Dan Williams wrote: On Sat, 2012-09-22 at 15:25 -0400, Gene Czarcinski wrote: >I am in the process of developing some patches to NetworkManager which >implementingdhcp dynamic dns updating for dhcp6. The patches involve >some small updating to the code in libnm-util. There is a reference >manual for libnm-util. What is the process/procedure for doing the >updates to that? The reference manual is actually autogenerated from code comments. There are a lot of docbook-style comments in the code, like: I should be ok then. For the most part I copied the code and comments from ip4 and put it into ip6 changing '4' to '6'. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: failed to set IPv6 default route
On 09/24/2012 12:30 PM, Dan Williams wrote: On Mon, 2012-09-24 at 08:05 -0400, Gene Czarcinski wrote: On 09/23/2012 08:56 AM, Gene Czarcinski wrote: I have been doing some work trying to improve IPv6 dhcp support in NetworkManager. This has involved a lot of (virtual) testing. One thing I began to notice is a lot of the following message appearing in syslog: [nm-system.c:1121] nm_system_replace_default_ip6_route(): (p32p1): failed to set IPv6 default route: -7 The only way I have been able to get an IPv6 default route set is to use manual configuration and specify a gateway. Everything else seems to produce this message. OK, is this a bug or is there something about configuration I do not understand? My question concerning if this is a bug stands. However, I have been playing around (marvelous what you can do with some qemu/kvm/libvirt virtual guests when you do not care if things get really screwed up). I thried using NetworkManager (the applet) to set a default route but nothing seemed to work except specifying the gateway when manually configuring IPv6. I finally googled what appears to be (sort of) an answer. enter something like the following command line command: ip -6 route add default via dev eth0 So that's essentially what NM is trying to do, actually, but NM is trying to do it with netlink (which is what /sbin/ip uses too actually) but apparently the netlink options we're adding aren't quite correct here. They unfortunately change periodically when kernel changes happen. -7 appears to be NLE_INVAL, which would indicate the kernel doesn't think the route we gave it is valid. We'd have to dig a bit further down to figure out what that error actually is. Last time I had to do this, I had to rebuild /sbin/ip and make it print out the exact netlink packet it was sending to the kernel. Then I had NM print out its packet and compared the two. If only there was an easier way... I am currently running 0.9.4.0 and in the process of updating to 0.9.7.0 is see if that makes a difference. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
For review: updates to add IPv6 dynamic dns support
Note: this is for review and not submit. After I respond to any
comments, make appropriate additions and/or subtractions, and gone over
the code myself "just one more time", I will submit the patch and it
should be RSN (real soon now).
Note: NO changes were made to the IPv4 dhcp support.
OK, there are multiple parts to this.
1. Modified nm-dhcp-manager.c and nm-dhcp-dhclient.c to put the
HOSTNAME or DHCP_HOSTNAME on the dhclient "-6" command line using the
"-F" parameter. This tells dhclient to send the name as a fqdn.fqdn to
the dhcp server. Note: sending a hostname in dhcp6 does not work; it
must be the fqdn.fqdn. And yes, the hostname is not a fully qualified
domain name (with dots) but that is OK and specified in the dhcp-options
man-page as well as RFC4704.
2. Modify IPv6 stuff in libnm-util to add IPv6 having its own copy of
the DHCP_HOSTNAME. I am not sure what/how docs such as the libnm-util
reference manual to update.
3. Add code to ifcfg-rh/reader.c and ifcfg-rh/writer.c to set the IPv6
DHCP_HOSTNAME both ways. While the code in ifcfg-rh/writer.c may
duplicate what IPv4 has already done, it is necessary because without
it, when you run a single IPv6 stack network, the DHCP_HOSTNAME will
disappear.
4. I added some nm_log_dbg and PLUGIN_WARN statements to help with the
debugging. I plan to leave these in ... who knows, they may be needed
at a later point in time.
Most of the testing has been done with qemu/kvm/libvirt virtual guests.
It works. I tested with both dhcpd6/named and dnsmasq as servers. I
found dnsmasq to actually do a better job (I am not sure that dhcpd6 is
in compliance with the RFC).
I did a little test with using plugin=keyfile instead of plugin=ifcfg-rh
and it worked. I am not sure what kind of testing could be done or what
kind of parameters could be specified. The ifcfg-rh plugin seems to
handle a whole bunch of IPV6 parameters but none of these appears to be
supported by the applet.
All development and testing was done on Fedora 17 using
NetworkManager-0.9.4.0-9.git20120521. However, I have applied the patch
(with no changes) to NetworkManager-0.9.7.0-1.git20120820 as well as a
git clone copy ... it apples clean and "makes" clean. I will be testing
0.9.7.0 as soon as I figure out how to get its rpms and
network-manager-applet rpms built.
Comment? Suggestions?? Whatever?
BTW, my reason for doing this is so that I can add IPv6 dhcp and ddns
support (via dnsmasq) to libvirt.
Gene
diff -urp NetworkManager-0.9.4.0.orig/libnm-util/libnm-util.ver NetworkManager-0.9.4.0/libnm-util/libnm-util.ver
--- NetworkManager-0.9.4.0.orig/libnm-util/libnm-util.ver 2012-05-21 08:20:28.0 -0400
+++ NetworkManager-0.9.4.0/libnm-util/libnm-util.ver 2012-09-23 18:48:11.944984285 -0400
@@ -310,6 +310,7 @@ global:
nm_setting_ip6_config_error_get_type;
nm_setting_ip6_config_error_quark;
nm_setting_ip6_config_get_address;
+ nm_setting_ip6_config_get_dhcp_hostname;
nm_setting_ip6_config_get_dns;
nm_setting_ip6_config_get_dns_search;
nm_setting_ip6_config_get_ignore_auto_dns;
diff -urp NetworkManager-0.9.4.0.orig/libnm-util/nm-setting-ip6-config.c NetworkManager-0.9.4.0/libnm-util/nm-setting-ip6-config.c
--- NetworkManager-0.9.4.0.orig/libnm-util/nm-setting-ip6-config.c 2012-02-28 04:26:07.0 -0500
+++ NetworkManager-0.9.4.0/libnm-util/nm-setting-ip6-config.c 2012-09-23 18:48:11.946984271 -0400
@@ -67,6 +67,7 @@ G_DEFINE_TYPE (NMSettingIP6Config, nm_se
typedef struct {
char *method;
+ char *dhcp_hostname;
GSList *dns;/* array of struct in6_addr */
GSList *dns_search; /* list of strings */
GSList *addresses; /* array of NMIP6Address */
@@ -82,6 +83,7 @@ typedef struct {
enum {
PROP_0,
PROP_METHOD,
+ PROP_DHCP_HOSTNAME,
PROP_DNS,
PROP_DNS_SEARCH,
PROP_ADDRESSES,
@@ -123,6 +125,23 @@ nm_setting_ip6_config_get_method (NMSett
}
/**
+ * nm_setting_ip6_config_get_dhcp_hostname:
+ * @setting: the #NMSettingIP6Config
+ *
+ * Returns the value contained in the #NMSettingIP6Config:dhcp-hostname
+ * property.
+ *
+ * Returns: the configured hostname to send to the DHCP server
+ **/
+const char *
+nm_setting_ip6_config_get_dhcp_hostname (NMSettingIP6Config *setting)
+{
+ g_return_val_if_fail (NM_IS_SETTING_IP6_CONFIG (setting), NULL);
+
+ return NM_SETTING_IP6_CONFIG_GET_PRIVATE (setting)->dhcp_hostname;
+}
+
+/**
* nm_setting_ip6_config_get_num_dns:
* @setting: the #NMSettingIP6Config
*
@@ -694,6 +713,14 @@ verify (NMSetting *setting, GSList *all_
return FALSE;
}
+ if (priv->dhcp_hostname && !strlen (priv->dhcp_hostname)) {
+ g_set_error (error,
+ NM_SETTING_IP6_CONFIG_ERROR,
+ NM_SETTING_IP6_CONFIG_ERROR_INVALID_PROPERTY,
+ NM_SETTING_IP6_CONFIG_DHCP_HOSTNAME);
+ return FALSE;
+ }
+
return TRUE;
}
@@ -752,6 +779,10 @@ set_property (GObject *object, guint pro
case PROP_IGNORE_AUTO_DNS:
priv->ignore_auto_dns = g_value_get_boolea
Re: failed to set IPv6 default route
On 09/23/2012 08:56 AM, Gene Czarcinski wrote: I have been doing some work trying to improve IPv6 dhcp support in NetworkManager. This has involved a lot of (virtual) testing. One thing I began to notice is a lot of the following message appearing in syslog: [nm-system.c:1121] nm_system_replace_default_ip6_route(): (p32p1): failed to set IPv6 default route: -7 The only way I have been able to get an IPv6 default route set is to use manual configuration and specify a gateway. Everything else seems to produce this message. OK, is this a bug or is there something about configuration I do not understand? My question concerning if this is a bug stands. However, I have been playing around (marvelous what you can do with some qemu/kvm/libvirt virtual guests when you do not care if things get really screwed up). I thried using NetworkManager (the applet) to set a default route but nothing seemed to work except specifying the gateway when manually configuring IPv6. I finally googled what appears to be (sort of) an answer. enter something like the following command line command: ip -6 route add default via dev eth0 With that, "ip -6 route' actually shows a good default and, even better, stuff starts to work. IPv6 does not have a way of specifying a default route with dhp6 but, that does not mean that we can do something which will be "good enough" until those great folks in the IETF get things worked out. We need something in the applet so that we can specify a default and then issue something like the above command. Note: I may be wrong and this can be done in the applet and set correctly ... if so, some kind of doc or change to the applet is needed to make this capability clear. Sort-of OT question: Why can't I specify additional name servers and search domains if I select IPV6 dhcp? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
failed to set IPv6 default route
I have been doing some work trying to improve IPv6 dhcp support in NetworkManager. This has involved a lot of (virtual) testing. One thing I began to notice is a lot of the following message appearing in syslog: [nm-system.c:1121] nm_system_replace_default_ip6_route(): (p32p1): failed to set IPv6 default route: -7 The only way I have been able to get an IPv6 default route set is to use manual configuration and specify a gateway. Everything else seems to produce this message. OK, is this a bug or is there something about configuration I do not understand? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
F17 and 0.9.7.0
I am running Fedora 17 but would like to update to NetworkManager-0.9.7.0. There are src and binary rpms for F18 but it is not practical to use the F18 binaries on F17 so I need to rebuild them on F17 ... no problem ... for NetworkManager itself. But 0.9.7.0 splits out the network-manager-applet into a separate src and binary package. Unfortunately, to build the network-manager-applet package needs NetworkManager-devel and NetworkManager-glib-devel and those packages in turn need the rest of 0.9.7.0 packages and, of course, the NetworkManager-gnome package needs to be removed also. The only way I can see to build the network-manager-applet package is to: 1. stop NetworkManager 2. yum localinstall the 0.9.7.0 NetworkManager packages and remove the old gnome and gtk packages. 3. build network-manager-applet package and install with yum localinstall or rpm 4. start NetworkManaer I believe that this will work but is there any other (simpler) way? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
libnm-util reference manual
I am in the process of developing some patches to NetworkManager which implementingdhcp dynamic dns updating for dhcp6. The patches involve some small updating to the code in libnm-util. There is a reference manual for libnm-util. What is the process/procedure for doing the updates to that? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
On 09/18/2012 04:17 PM, Dan Williams wrote: On Tue, 2012-09-18 at 14:59 -0400, Gene Czarcinski wrote: On 09/18/2012 02:22 PM, Dan Williams wrote: On Tue, 2012-09-18 at 13:08 -0500, Dan Williams wrote: On Tue, 2012-09-18 at 13:19 -0400, Gene Czarcinski wrote: On 09/17/2012 02:36 PM, Gene Czarcinski wrote: On 09/17/2012 02:24 PM, Gene Czarcinski wrote: On 09/17/2012 12:05 PM, Jiri Popelka wrote: On 09/16/2012 09:55 PM, Gene Czarcinski wrote: BTW, from the info in the dhcp-options man-page, I believe that NetworkManager should be doing "send fqdn.fqdn" instead of "send host-name" for IPv4. This should be with a plain name ... not a qualified name. See the man-page. The story behind this is https://bugzilla.redhat.com/show_bug.cgi?id=694758#c20 (NetworkManager) https://bugzilla.redhat.com/show_bug.cgi?id=697877 (initscripts) OK, bug or feature? Well, me and the original reporter of those bugs had suggested to "send fqdn.fqdn" when $(hostname) was FQDN and "send host-name" otherwise, but Bill Nottingham (initscripts) decided to always "send host-name". So I thought it would be better for NM to stay consistent with initscripts. Read those BZs and if you think the behavior is wrong you could try to re-open them. I have not gone back to look into the history of what should or should not be sent. I only looked at what is said in the current (Fedora 17, dhcp-common-4.2.4-9.P1.fc17) dhcp-options man page. option fqdn.fqdn text; Specifies the domain name that the client wishes to use. This can be a fully-qualified domain name, or a single label. If there is no trailing ´.´ character in the name, it is not fully-qualified, and the server will generally update that name in some locally-defined domain. --- It also says that "options fqdn.hostname" and "option fqdn.domainname" should never be set. When I got things to work, there was a lot of options in the lease file in addition to fqdn. I am not sure exactly what needs to be specified except that for IPv6 if I specify "-F " on the dhclient command line, things work. For IPv7 "-H " seems to work. Regardless, as things now work I do not get dynamic dns update for IPv6 (works fine for IPv4). This has been with dnsmasq as the dns and dhcp server. I am not setting up testing on qemu/kvm/libvirt with a guest running named and dhcpd instead of dnsmasq. My expectation is that it will not do dynamic dns either. My reason for pushing this is that while using radvd to help with IPv6 address assignment works for a client-only situation, it soon falls apart when I have a bunch of systems referring to each other. For IPv4 using addresses only is painful, for IPv6 it is impractical. I believe that such situations will needs either a IPv6 dhcpd with DDNS to named or a dnsmasq. I do not know, there might be other packages out there but these seem to be common. https://bugzilla.gnome.org/show_bug.cgi?id=684242 I have duplicated the situation but instead of using dnsmasq for dns and dhcp services. I installed and configured named, dhcpd, and dhcpd6 on the server an started them. On the client, disable networking and stop the NettworkManager.service. Again, the small change in the ifup-eth network script to use "-F" instead of "-H" and on dhclient commandline for "-6" and "ifup eth0" works its magic. "host " now provides both IPv6 and IPv4 addresses. ISTR the problem here is that since you can't use -H and -F together, you have to pick one or the other. And how do you make that choice? Is it another checkbox in the UI that nobody should ever really have to click? Does the DHCP server not have a configuration option to handle DDNS using the 'send host-name' bits? THe manpage for dhclient says "the server will append the ddns-domainname or domain-name options, if any, to derive the fully qualified domain name of the client" but while that talks about DDNS, it's unclear whether that does any DDNS stuff. Ok, I see what's going on now. The ISC DHCP client has two modes: "adhoc" and "draft". The "adhoc" mode is now deprecated and apparently doesn't work with failover, while the "draft" mode is preferred. The "adhoc" mode used the hostname + a config option to construct the DDNS name, while the "draft" mode uses the FQDN and is preferred. So the question becomes: is anyone actually using the old "adhoc" mode, and would we break anyone by moving to using the FQDN option instead? That's the big question here. Plus, we're not just talking about the ISC DHCP client, we need to figure out what happens with (a) MS DHCP/DNS and (b) WiFi routers with built-in DDNS functionality. Couple of things to consider -- 1. You could make it a configuration option
Re: dhcp6 and fqdn support (for dns)
On 09/18/2012 02:22 PM, Dan Williams wrote: On Tue, 2012-09-18 at 13:08 -0500, Dan Williams wrote: On Tue, 2012-09-18 at 13:19 -0400, Gene Czarcinski wrote: On 09/17/2012 02:36 PM, Gene Czarcinski wrote: On 09/17/2012 02:24 PM, Gene Czarcinski wrote: On 09/17/2012 12:05 PM, Jiri Popelka wrote: On 09/16/2012 09:55 PM, Gene Czarcinski wrote: BTW, from the info in the dhcp-options man-page, I believe that NetworkManager should be doing "send fqdn.fqdn" instead of "send host-name" for IPv4. This should be with a plain name ... not a qualified name. See the man-page. The story behind this is https://bugzilla.redhat.com/show_bug.cgi?id=694758#c20 (NetworkManager) https://bugzilla.redhat.com/show_bug.cgi?id=697877 (initscripts) OK, bug or feature? Well, me and the original reporter of those bugs had suggested to "send fqdn.fqdn" when $(hostname) was FQDN and "send host-name" otherwise, but Bill Nottingham (initscripts) decided to always "send host-name". So I thought it would be better for NM to stay consistent with initscripts. Read those BZs and if you think the behavior is wrong you could try to re-open them. I have not gone back to look into the history of what should or should not be sent. I only looked at what is said in the current (Fedora 17, dhcp-common-4.2.4-9.P1.fc17) dhcp-options man page. option fqdn.fqdn text; Specifies the domain name that the client wishes to use. This can be a fully-qualified domain name, or a single label. If there is no trailing ´.´ character in the name, it is not fully-qualified, and the server will generally update that name in some locally-defined domain. --- It also says that "options fqdn.hostname" and "option fqdn.domainname" should never be set. When I got things to work, there was a lot of options in the lease file in addition to fqdn. I am not sure exactly what needs to be specified except that for IPv6 if I specify "-F " on the dhclient command line, things work. For IPv7 "-H " seems to work. Regardless, as things now work I do not get dynamic dns update for IPv6 (works fine for IPv4). This has been with dnsmasq as the dns and dhcp server. I am not setting up testing on qemu/kvm/libvirt with a guest running named and dhcpd instead of dnsmasq. My expectation is that it will not do dynamic dns either. My reason for pushing this is that while using radvd to help with IPv6 address assignment works for a client-only situation, it soon falls apart when I have a bunch of systems referring to each other. For IPv4 using addresses only is painful, for IPv6 it is impractical. I believe that such situations will needs either a IPv6 dhcpd with DDNS to named or a dnsmasq. I do not know, there might be other packages out there but these seem to be common. https://bugzilla.gnome.org/show_bug.cgi?id=684242 I have duplicated the situation but instead of using dnsmasq for dns and dhcp services. I installed and configured named, dhcpd, and dhcpd6 on the server an started them. On the client, disable networking and stop the NettworkManager.service. Again, the small change in the ifup-eth network script to use "-F" instead of "-H" and on dhclient commandline for "-6" and "ifup eth0" works its magic. "host " now provides both IPv6 and IPv4 addresses. ISTR the problem here is that since you can't use -H and -F together, you have to pick one or the other. And how do you make that choice? Is it another checkbox in the UI that nobody should ever really have to click? Does the DHCP server not have a configuration option to handle DDNS using the 'send host-name' bits? THe manpage for dhclient says "the server will append the ddns-domainname or domain-name options, if any, to derive the fully qualified domain name of the client" but while that talks about DDNS, it's unclear whether that does any DDNS stuff. Ok, I see what's going on now. The ISC DHCP client has two modes: "adhoc" and "draft". The "adhoc" mode is now deprecated and apparently doesn't work with failover, while the "draft" mode is preferred. The "adhoc" mode used the hostname + a config option to construct the DDNS name, while the "draft" mode uses the FQDN and is preferred. So the question becomes: is anyone actually using the old "adhoc" mode, and would we break anyone by moving to using the FQDN option instead? That's the big question here. Plus, we're not just talking about the ISC DHCP client, we need to figure out what happens with (a) MS DHCP/DNS and (b) WiFi routers with built-in DDNS functionality. Couple of things to consider -- 1. You could make it a configuration option 2. The problem is that right now dynamic updating of the dns (whether it is bind or dnsmasq or anything e
Re: dhcp6 and fqdn support (for dns)
On 09/17/2012 02:36 PM, Gene Czarcinski wrote: On 09/17/2012 02:24 PM, Gene Czarcinski wrote: On 09/17/2012 12:05 PM, Jiri Popelka wrote: On 09/16/2012 09:55 PM, Gene Czarcinski wrote: BTW, from the info in the dhcp-options man-page, I believe that NetworkManager should be doing "send fqdn.fqdn" instead of "send host-name" for IPv4. This should be with a plain name ... not a qualified name. See the man-page. The story behind this is https://bugzilla.redhat.com/show_bug.cgi?id=694758#c20 (NetworkManager) https://bugzilla.redhat.com/show_bug.cgi?id=697877 (initscripts) OK, bug or feature? Well, me and the original reporter of those bugs had suggested to "send fqdn.fqdn" when $(hostname) was FQDN and "send host-name" otherwise, but Bill Nottingham (initscripts) decided to always "send host-name". So I thought it would be better for NM to stay consistent with initscripts. Read those BZs and if you think the behavior is wrong you could try to re-open them. I have not gone back to look into the history of what should or should not be sent. I only looked at what is said in the current (Fedora 17, dhcp-common-4.2.4-9.P1.fc17) dhcp-options man page. option fqdn.fqdn text; Specifies the domain name that the client wishes to use. This can be a fully-qualified domain name, or a single label. If there is no trailing ´.´ character in the name, it is not fully-qualified, and the server will generally update that name in some locally-defined domain. --- It also says that "options fqdn.hostname" and "option fqdn.domainname" should never be set. When I got things to work, there was a lot of options in the lease file in addition to fqdn. I am not sure exactly what needs to be specified except that for IPv6 if I specify "-F " on the dhclient command line, things work. For IPv7 "-H " seems to work. Regardless, as things now work I do not get dynamic dns update for IPv6 (works fine for IPv4). This has been with dnsmasq as the dns and dhcp server. I am not setting up testing on qemu/kvm/libvirt with a guest running named and dhcpd instead of dnsmasq. My expectation is that it will not do dynamic dns either. My reason for pushing this is that while using radvd to help with IPv6 address assignment works for a client-only situation, it soon falls apart when I have a bunch of systems referring to each other. For IPv4 using addresses only is painful, for IPv6 it is impractical. I believe that such situations will needs either a IPv6 dhcpd with DDNS to named or a dnsmasq. I do not know, there might be other packages out there but these seem to be common. https://bugzilla.gnome.org/show_bug.cgi?id=684242 I have duplicated the situation but instead of using dnsmasq for dns and dhcp services. I installed and configured named, dhcpd, and dhcpd6 on the server an started them. On the client, disable networking and stop the NettworkManager.service. Again, the small change in the ifup-eth network script to use "-F" instead of "-H" and on dhclient commandline for "-6" and "ifup eth0" works its magic. "host " now provides both IPv6 and IPv4 addresses. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
On 09/17/2012 02:24 PM, Gene Czarcinski wrote: On 09/17/2012 12:05 PM, Jiri Popelka wrote: On 09/16/2012 09:55 PM, Gene Czarcinski wrote: BTW, from the info in the dhcp-options man-page, I believe that NetworkManager should be doing "send fqdn.fqdn" instead of "send host-name" for IPv4. This should be with a plain name ... not a qualified name. See the man-page. The story behind this is https://bugzilla.redhat.com/show_bug.cgi?id=694758#c20 (NetworkManager) https://bugzilla.redhat.com/show_bug.cgi?id=697877 (initscripts) OK, bug or feature? Well, me and the original reporter of those bugs had suggested to "send fqdn.fqdn" when $(hostname) was FQDN and "send host-name" otherwise, but Bill Nottingham (initscripts) decided to always "send host-name". So I thought it would be better for NM to stay consistent with initscripts. Read those BZs and if you think the behavior is wrong you could try to re-open them. I have not gone back to look into the history of what should or should not be sent. I only looked at what is said in the current (Fedora 17, dhcp-common-4.2.4-9.P1.fc17) dhcp-options man page. option fqdn.fqdn text; Specifies the domain name that the client wishes to use. This can be a fully-qualified domain name, or a single label. If there is no trailing ´.´ character in the name, it is not fully-qualified, and the server will generally update that name in some locally-defined domain. --- It also says that "options fqdn.hostname" and "option fqdn.domainname" should never be set. When I got things to work, there was a lot of options in the lease file in addition to fqdn. I am not sure exactly what needs to be specified except that for IPv6 if I specify "-F " on the dhclient command line, things work. For IPv7 "-H " seems to work. Regardless, as things now work I do not get dynamic dns update for IPv6 (works fine for IPv4). This has been with dnsmasq as the dns and dhcp server. I am not setting up testing on qemu/kvm/libvirt with a guest running named and dhcpd instead of dnsmasq. My expectation is that it will not do dynamic dns either. My reason for pushing this is that while using radvd to help with IPv6 address assignment works for a client-only situation, it soon falls apart when I have a bunch of systems referring to each other. For IPv4 using addresses only is painful, for IPv6 it is impractical. I believe that such situations will needs either a IPv6 dhcpd with DDNS to named or a dnsmasq. I do not know, there might be other packages out there but these seem to be common. https://bugzilla.gnome.org/show_bug.cgi?id=684242 Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
On 09/17/2012 12:05 PM, Jiri Popelka wrote: On 09/16/2012 09:55 PM, Gene Czarcinski wrote: BTW, from the info in the dhcp-options man-page, I believe that NetworkManager should be doing "send fqdn.fqdn" instead of "send host-name" for IPv4. This should be with a plain name ... not a qualified name. See the man-page. The story behind this is https://bugzilla.redhat.com/show_bug.cgi?id=694758#c20 (NetworkManager) https://bugzilla.redhat.com/show_bug.cgi?id=697877 (initscripts) OK, bug or feature? Well, me and the original reporter of those bugs had suggested to "send fqdn.fqdn" when $(hostname) was FQDN and "send host-name" otherwise, but Bill Nottingham (initscripts) decided to always "send host-name". So I thought it would be better for NM to stay consistent with initscripts. Read those BZs and if you think the behavior is wrong you could try to re-open them. I have not gone back to look into the history of what should or should not be sent. I only looked at what is said in the current (Fedora 17, dhcp-common-4.2.4-9.P1.fc17) dhcp-options man page. option fqdn.fqdn text; Specifies the domain name that the client wishes to use. This can be a fully-qualified domain name, or a single label. If there is no trailing ´.´ character in the name, it is not fully-qualified, and the server will generally update that name in some locally-defined domain. --- It also says that "options fqdn.hostname" and "option fqdn.domainname" should never be set. When I got things to work, there was a lot of options in the lease file in addition to fqdn. I am not sure exactly what needs to be specified except that for IPv6 if I specify "-F " on the dhclient command line, things work. For IPv7 "-H " seems to work. Regardless, as things now work I do not get dynamic dns update for IPv6 (works fine for IPv4). This has been with dnsmasq as the dns and dhcp server. I am not setting up testing on qemu/kvm/libvirt with a guest running named and dhcpd instead of dnsmasq. My expectation is that it will not do dynamic dns either. My reason for pushing this is that while using radvd to help with IPv6 address assignment works for a client-only situation, it soon falls apart when I have a bunch of systems referring to each other. For IPv4 using addresses only is painful, for IPv6 it is impractical. I believe that such situations will needs either a IPv6 dhcpd with DDNS to named or a dnsmasq. I do not know, there might be other packages out there but these seem to be common. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
On 09/15/2012 10:13 AM, Gene Czarcinski wrote: I am trying to set up an IPv6 virtual network using dnsmasq to support the dhcp and dns. Recently (the last couple of releases) dnsmasq has supported dhcp with updating dns. I have gotten it so that the IPv6 addresses are assigned correctly but I have been driving myself nuts trying to figure out why it does not update the dns with the IPv6 address. I have come to the conclusion that it is because NetworkManager does not send the fqdn. I am not sure if fqdn is required or if the hostname would be OK. However, in looking at some of the dhcp documentation for options, it appears that fqdn should be specified and not just the hostname. Before I turn in some bug reports and look at the code, is my understanding correct? I have done some additional testing. I suspected that something was missing from the NetworkMananger support for IPv6 dhcp. Here is what I did the prove it. 1. Stop NetworkManager. 2. Make sure that the ifcfg-eth0 file has DHCP_HOSTNAME== and DHCPV6C=yes are specified. 3. Slightly modify the ifup-eth network script to change the "-H" to "-F" on the "dhclient -6" line. 4. do "ifup eth0" 5 Use wireshark (or equivalent) to trace the packets on the interface. See that fqdn info is being passed whereas it was not when NetworkManager did everything. 6. With dnsmasq I now have IPv6 addresses added to the dns. In examining various documents but not doing any testing, I believe that dhcpd-v6 will need to info to support dynamic dns updating for IPv6 addresses. BTW, from the info in the dhcp-options man-page, I believe that NetworkManager should be doing "send fqdn.fqdn" instead of "send host-name" for IPv4. This should be with a plain name ... not a qualified name. See the man-page. OK, bug or feature? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
dhcp6 and fqdn support (for dns)
I am trying to set up an IPv6 virtual network using dnsmasq to support the dhcp and dns. Recently (the last couple of releases) dnsmasq has supported dhcp with updating dns. I have gotten it so that the IPv6 addresses are assigned correctly but I have been driving myself nuts trying to figure out why it does not update the dns with the IPv6 address. I have come to the conclusion that it is because NetworkManager does not send the fqdn. I am not sure if fqdn is required or if the hostname would be OK. However, in looking at some of the dhcp documentation for options, it appears that fqdn should be specified and not just the hostname. Before I turn in some bug reports and look at the code, is my understanding correct? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
A question about NetworkManager's use of dnsmasq
Just curious but ... I noticed that the dnsmasq for caching that NetworkManager starts has the command parameter "--keep-in-foreground" specified. Why? According to the dnsmasq doc: --keep-in-foreground or -k does: Do not go into the background at startup but otherwise run as normal. This is intended for use when dnsmasq is run under dae‐ montools or launchd. Just hoping to keep things simple and not introduce too much command line clutter. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: enabling use of dnsmasq
On 09/07/2012 04:39 PM, Dan Williams wrote: I am doing some testing of NM using dnsmasq for a caching nameserver: > > From another message: > >>3. Will use of dnsmasq be optional and configurable? > >It already is, you can enable or disable it via "dns=dnsmasq" in > >/etc/NetworkManager/NetworkManager.conf; and since recently, you can > >tweak the configuration using files in /etc/NetworkManager/dnsmasq.d. > >OK, the dns=dnsmasq works but how about the configuration tweak files in >/etc/NetworkManager/dnsmasq.d ? Out of curiosity, what sort of things do you want to tweak? If enough people need to tweak them, then perhaps we should add them in a more standardized format so that they still work if/when we get a mythical unbound plugin too. I am using qemu/kvm/libvirt to run a number of VMs for doing varuious testing including some security testing. The virtual stuff seems to have pretty good performance and my 6 AMD core processor with 16GB memeory and an SSD for root runs quite nicely. I can remember the names of the virtual machines but not necessarily the ip addresses. I would like to access vis ssh and scp those virtual guests from the host system by name ... by IP works. Now, the dnsmasq instances started by libvirt can be queried from the host and will respond. You can also specify a domain name (such as "virt") for the systems on that virtual network. I need to be able to specify something like server=/virt/192.168.122.1 I patched NetworkManager-0.9.4.0-9.git20120521.fc17 to add the "--conf-dir=/etc/NetworkManager/dnsmasq.d" and after fiddling with selinux I got things to work. There is another way which still involves running an instance of dnsmasq on the host's real NIC and passing "virt" queries up to 192.168.122.1 ... this also involves modifying the upstream dnsmasq to route "virt" domain queries back to the host. Using the caching dsnmasq is a lot simpler. When all is done, it works. I can "ssh test.virt" and I am in. BTW, doing this involves some updates to libvirt to add some additional parameters to the dnsmasq command line ... lack of these updates produce some "interesting" loops of dns packets looping through the network. The update adds "--local-// --domain-needed". I am now looking into doing something similar for the PTR queries ... IPV4 is not too bad but ipv6 is a lot more complicated. Does that scratch your itch Dan? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
enabling use of dnsmasq
I am doing some testing of NM using dnsmasq for a caching nameserver: From another message: 3. Will use of dnsmasq be optional and configurable? It already is, you can enable or disable it via "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf; and since recently, you can tweak the configuration using files in /etc/NetworkManager/dnsmasq.d. OK, the dns=dnsmasq works but how about the configuration tweak files in /etc/NetworkManager/dnsmasq.d ? I am on Fedora 17 with NetworkManager-0.9.4.0-9.git20120521.fc17 I suspect that I will need something a bit more recent. How about 0.9.5.96 from Fedora 18? Comments? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM, dnsmasq, and --conf-dir
On 09/01/2012 03:24 PM, Gene Czarcinski wrote:
OK, I have been doing some testing with NM's new use of dnsmasq. But,
I am running Fedora 17 and I needed the --conf-dir= capability Just
getting the 0.9.7.0 package from rawhide and rebuilding had far too
many other packages required to do that. However, it was pretty easy
to look at the code implementing "--conf-dir=" in the 0.9.7.0 and make
a patch for the current 0.9.4.0-9 and rebuild that. Works fine ...
sort of.
I am not putting in a bugzilla report on this because I am not sure
that it is not fixed elsewhere. The problems:
1. /etc/NetworkManager/dnsmasq.d does not exist and dnsmasq startup
fails. Ok, just do a mkdir. The NM spec file needs to be updated.
2. selinux did not like dnsmasq going into NM's files. This is what
ultimately fixed it (plus some restorecon usage).
module mypol3 1.0;
require {
type NetworkManager_etc_t;
type dnsmasq_t;
class dir { read search open };
}
#= dnsmasq_t ==
allow dnsmasq_t NetworkManager_etc_t:dir open;
# This avc is allowed in the current policy
allow dnsmasq_t NetworkManager_etc_t:dir { read search };
Just a heads up to maybe save some time.
Mmm ... it took a few more tries to get selinux correctly configured.
The above gets access to the directory.
Here is what was needed to get access to the file:
type NetworkManager_etc_t;
type dnsmasq_t;
class file { read getattr open };
}
#= dnsmasq_t ==
allow dnsmasq_t NetworkManager_etc_t:file open;
# This avc is allowed in the current policy
allow dnsmasq_t NetworkManager_etc_t:file { read getattr };
Gene
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
NM, dnsmasq, and --conf-dir
OK, I have been doing some testing with NM's new use of dnsmasq. But, I
am running Fedora 17 and I needed the --conf-dir= capability Just
getting the 0.9.7.0 package from rawhide and rebuilding had far too many
other packages required to do that. However, it was pretty easy to look
at the code implementing "--conf-dir=" in the 0.9.7.0 and make a patch
for the current 0.9.4.0-9 and rebuild that. Works fine ... sort of.
I am not putting in a bugzilla report on this because I am not sure that
it is not fixed elsewhere. The problems:
1. /etc/NetworkManager/dnsmasq.d does not exist and dnsmasq startup
fails. Ok, just do a mkdir. The NM spec file needs to be updated.
2. selinux did not like dnsmasq going into NM's files. This is what
ultimately fixed it (plus some restorecon usage).
module mypol3 1.0;
require {
type NetworkManager_etc_t;
type dnsmasq_t;
class dir { read search open };
}
#= dnsmasq_t ==
allow dnsmasq_t NetworkManager_etc_t:dir open;
# This avc is allowed in the current policy
allow dnsmasq_t NetworkManager_etc_t:dir { read search };
Just a heads up to maybe save some time.
Gene
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: enabling use of dnsmasq
On 08/31/2012 12:58 PM, Nathanael D. Noblet wrote: On 08/31/2012 10:29 AM, Gene Czarcinski wrote: I am doing some testing of NM using dnsmasq for a caching nameserver: From another message: >> 3. Will use of dnsmasq be optional and configurable? > It already is, you can enable or disable it via "dns=dnsmasq" in > /etc/NetworkManager/NetworkManager.conf; and since recently, you can > tweak the configuration using files in /etc/NetworkManager/dnsmasq.d. OK, the dns=dnsmasq works but how about the configuration tweak files in /etc/NetworkManager/dnsmasq.d ? I am on Fedora 17 with NetworkManager-0.9.4.0-9.git20120521.fc17 I suspect that I will need something a bit more recent. How about 0.9.5.96 from Fedora 18? I thought F18 had 0.9.7.0 - I've recompiled it for both F17 and F15 and it works great there for me. As of right now, F18 has 0.9.5.95 and rawhide has NetworkManager-0.9.7.0-1.git20120820.fc19 Were there any special dependencies to do a rebuild? That is, do you need some other packages from F18 or rawhide? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
enabling use of dnsmasq
I am doing some testing of NM using dnsmasq for a caching nameserver: From another message: >> 3. Will use of dnsmasq be optional and configurable? > It already is, you can enable or disable it via "dns=dnsmasq" in > /etc/NetworkManager/NetworkManager.conf; and since recently, you can > tweak the configuration using files in /etc/NetworkManager/dnsmasq.d. OK, the dns=dnsmasq works but how about the configuration tweak files in /etc/NetworkManager/dnsmasq.d ? I am on Fedora 17 with NetworkManager-0.9.4.0-9.git20120521.fc17 I suspect that I will need something a bit more recent. How about 0.9.5.96 from Fedora 18? Comments? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Use of dnsmasq for caching nameserver
On 08/27/2012 12:19 PM, Mathieu Trudel-Lapierre wrote: On Sat, Aug 25, 2012 at 5:05 PM, Gene Czarcinski wrote: [...] 1. Is it already in use? I am running "current" Fedora 17 and a "ps ax" shows no "extra" dnsmasq ... just all the ones for my virtual networks. It's not in use in Fedora yet. OK ... 18? 2. I also noticed that the NetworkManager dnsmasq is listening on 127.0.0.1. This could be a problem if the user (such as myself) wants to run a dnsmasq listening on 127.0.0.1. Yes. I have a patch ready to be sent to the mailing list to change that to 127.0.1.1 (could be anything else really), as what we use in Ubuntu. On further thought, this change to 127.0.1.1 may not be necessary. If I am running a system which is using NetworkManager to manage the networks but also is the DNS and dhcp services provider for the local network through dnsmasq, then I suspect that turning off the caching nameserver is going to be the best approach. I assume the NetworkManager will change /etc/resolv.conf to point to the caching nameserver and the real info for will be passed from NetworkManager or from the dhclient info to the dnsmasq(caching). All this sounds like it will work fine with the dnsmasq instantiations used by libvirtd ... they will pick up the info from /etc/resolv.conf and go through the caching name server. My interest in dnsmasq started because I wanted to run my own instantiation of dnsmasq so that I could access libvirtd's dnsmasqs. My objective is to use ssh and scp to access virtual guests by name from the host system. I can do it by IP address but DNS services exist for a reason. Because dnsmasq was forwarding more than it should, there was an excellent chance that i could create dns query loops ... not something I wanted to deal with. 3. Will use of dnsmasq be optional and configurable? It already is, you can enable or disable it via "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf; and since recently, you can tweak the configuration using files in /etc/NetworkManager/dnsmasq.d. 4. I noticed that you have all the paramters specified in the software. Based on my experience with libvirt, this makes it difficult to test any needed parameter changes. Suggention: have you considered having your own conf file and then specifying "--conf-file=" in the software? See above; I think just the absolutely required parameters should be on the command line, I think that's largely the case right now. Indeed. It looks like your approach is better than that of libvirtd ... but, they have other considerations that might have driven their approach ... one of those dnsmasq process for each virtual network ... I currently have 7 virtual networks defined and running on a single host. 5. Let me add that I believe choosing dnsmasq for the caching nameserver is a good choice. On the whole it works well and is not all that complicated. Depends if you run into those really obscure bugs. I think we've found quite a few already, so things should be looking good for the most part. Yes, indeed. While I believe that dnsmasq is doing a good job and, in some cases, a better one that bind (named), it still has some problems. Specifically, I have found that it forwards a lot of queries that, to me, make no sense for being forwarded. I was able to correct some of this with a patch to libvirt so that --local=// was always specified. can either be a domain name or a null string so that only plain-names are handled. I am looking at the dnsmasq code to correct the other condition where it forwards almost any plain-name [no domain] query. When "domain-needed" is specified, I believe that no plain-name queries should be forwarded. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Use of dnsmasq for caching nameserver
I was having some problems with libvirt's usage of dnsmasq (the command line parameters libvirtd was using). Too many queries were being forwarded. I have submitted a patch to libvirt for their part of the problem but dnsmasq is still leaking some queries that I believe should not be forwarded (not that bind/named is any better). While on the dnsmasq discussion list, I noticed that some patches had been submitted by Dan WIlliams to make NetworkManager's use of dnsmasq work better. So, this got me interested and a little searching of the NetworkManager mailing list and the rpm changelog showed that there was already at least some support in NetworkManager for dnsmasq. 1. Is it already in use? I am running "current" Fedora 17 and a "ps ax" shows no "extra" dnsmasq ... just all the ones for my virtual networks. 2. I also noticed that the NetworkManager dnsmasq is listening on 127.0.0.1. This could be a problem if the user (such as myself) wants to run a dnsmasq listening on 127.0.0.1. 3. Will use of dnsmasq be optional and configurable? 4. I noticed that you have all the paramters specified in the software. Based on my experience with libvirt, this makes it difficult to test any needed parameter changes. Suggention: have you considered having your own conf file and then specifying "--conf-file=" in the software? 5. Let me add that I believe choosing dnsmasq for the caching nameserver is a good choice. On the whole it works well and is not all that complicated. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: named startup & NetworkManager
On 08/09/2012 02:25 PM, Gene Czarcinski wrote: https://bugzilla.redhat.com/show_bug.cgi?id=837173 The above bug report concerns NetworkManager NIC device initialization and named. Yes, the bug is against bind but you should take a look at it since it directly involves NetworkManager. As I say in my comment, I have been able to reliably reproduce the problem as a virtual guest but not on real hardware (and I tried). The problem is that NetworkManager, named, and dhcpd are all started at roughly the same time (think at least within a couple seconds). dhcpd can handle the fact that when it iinitializes that there are no NICs available and when they do become available, is uses them. But, with respect to named, the fact that the NICs are not available makes it get everything pretty much wrong (lots and lots of error messages in the system log). And when the devices have been initialized by NetworkManager, named does not look again. The only way to handle it is to restart named after I can login. I am not familiar enough with how the new initialization (systemd) works so I do not know if there is an "easy" answer. I have submitted a report in the Fedora bugzilla -- https://bugzilla.redhat.com/show_bug.cgi?id=847452 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
named startup & NetworkManager
https://bugzilla.redhat.com/show_bug.cgi?id=837173 The above bug report concerns NetworkManager NIC device initialization and named. Yes, the bug is against bind but you should take a look at it since it directly involves NetworkManager. As I say in my comment, I have been able to reliably reproduce the problem as a virtual guest but not on real hardware (and I tried). The problem is that NetworkManager, named, and dhcpd are all started at roughly the same time (think at least within a couple seconds). dhcpd can handle the fact that when it iinitializes that there are no NICs available and when they do become available, is uses them. But, with respect to named, the fact that the NICs are not available makes it get everything pretty much wrong (lots and lots of error messages in the system log). And when the devices have been initialized by NetworkManager, named does not look again. The only way to handle it is to restart named after I can login. I am not familiar enough with how the new initialization (systemd) works so I do not know if there is an "easy" answer. Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bug or "feature" ??
On Monday 02 November 2009 16:21:17 Dan Williams wrote:
> On Mon, 2009-11-02 at 16:54 -0400, Gene Czarcinski wrote:
> > I notice that if I stop the NetworkManager service:
> > /etc/init.d/NetworkManager stop
> > that the interfaces started by NetworkManager are not always stopped.
> >
> > Note: this is a F12 qemu-kvm guest with multiple (two) NICs defined.
> >
> > Bug or "feature"??
>
> Feature. It allows you to do 'service NetworkManager restart' and have
> the connection survive. This is implemented for wired static and DHCP
> interfaces only and was requested quite a few times by people who run
> headless servers where you may need to update NM on-the-fly and not be
> kicked out when doing so. It's also necessary for NM to seamlessly take
> over a connection from the initrd where the rootfs is network mounted.
Did this feature get added to F12? I tried F11 and "stop" seems to shutdown
all of the interfaces started by NetworkManager.
I can understand the need for this feature but the unintended consequence is
that I now have to go through a lot of manual stuff to stop the interfaces.
Using /etc/init.d/network to stop everything is not much better since it also
stops the internal ("lo") network.
I am not sure what the right answer is.
Gene
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: need help
On Monday 02 November 2009 16:18:57 Dan Williams wrote: > On Mon, 2009-11-02 at 17:08 -0400, Gene Czarcinski wrote: > > I am not adverse to doing some coding to get functionality I want. The > > BZ report https://bugzilla.redhat.com/show_bug.cgi?id=510253 asks for an > > enhancement to NetworkManager to support specifying a DHCP hostname using > > the NetworkManager system-settings editor. Unfortunately for me, the > > editor is written using glade. > > Updated the bug; but before we start tossing in widgets, is it > sufficient to push the system's current persistent hostname out to the > DHCP server? Or are there really cases where the name pushed up to the > server is not the system's persistent hostname? > Unfortunately, using the system's persistent hostname (from /etc/sysconfig/hetwork) does not appear sufficient ... see the BZ report. Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
need help
I am not adverse to doing some coding to get functionality I want. The BZ report https://bugzilla.redhat.com/show_bug.cgi?id=510253 asks for an enhancement to NetworkManager to support specifying a DHCP hostname using the NetworkManager system-settings editor. Unfortunately for me, the editor is written using glade. While I played a little with glade when it first came out, the current glade implementation is very different. I am not about to manually edit the glade files to add the functionality. Can someone give me some "hints" as to how to approach modifying the the editor to add the functionality? That is, how should I run glade to change the gui and then what type of code do I need to add? I am sure it will be simple and obvious once I do it but right not it looks like a really steep hill to climb. Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
bug or "feature" ??
I notice that if I stop the NetworkManager service: /etc/init.d/NetworkManager stop that the interfaces started by NetworkManager are not always stopped. Note: this is a F12 qemu-kvm guest with multiple (two) NICs defined. Bug or "feature"?? Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
DEFROUTE support ... when?
DEFROUTE=yes|no support has been added to initscripts and is in rawhide (and I assume will be in F12) ... https://bugzilla.redhat.com/show_bug.cgi?id=528822 When will the DEFROUTE support be added to NetworkManager? https://bugzilla.redhat.com/show_bug.cgi?id=528281 The patch is in the BZ report and has been tested. Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Supporting dynamic dns updating of hostname
On Sunday 18 October 2009 11:59:59 Gene Czarcinski wrote: > Unfortunately, in order to set these variables for the hostname, you > currently need to use you favorite text editor such as vi. In the case > of a system connection (a connection available to all users), you can use > system-config- network to set the hostname value for dhcp. If a system > connection is converted to a user connection, then the hostname is > properly defined. > > Again, everything works. BUT, I consider it to be unreasonable to set the > hostname via to process described above. I should be able to set the value > in NM's connection-editor ... but I currently cannot do this. I consider > this a bug but (I believe others such as the developers) will consider it > an RFE (enhancement). > https://bugzilla.redhat.com/show_bug.cgi?id=510253 Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Supporting dynamic dns updating of hostname
One of the things that can be done if you run a dhcp service and a dns service is that you can dynamically update the dns (named) for your hostname with the ip address assigned by dhcpd. If you run dnsmasq, it will also dynamically update its dns with your hostname for the ip address supplied by dnsmasq's dhcp service. NetworkManager: On the client system (the one asking for dhcp to assign an ip address), this is supported by DHCP_HOSTNAME= in the /etc/sysconfig/network- scripts/ifcfg- file for a system connection. For a user connection, the variable is "dhcp-hostname" in the xml file of ~/.gconf/system/networking/connections/.../ipv4/ If the appropriate variable is set, then dynamic dns works and you hostname is entered into the dns database. This all workls today with NetworkManager. Sometime prior to Fedora 11, a /etc/dhclient-ethX.conf file was needed to fake things and get the hostname passed to the dhcpd server. This is no longer needed in Fedora 11 and, in Fedora 12, system-config-network no longer creates this file. Unfortunately, in order to set these variables for the hostname, you currently need to use you favorite text editor such as vi. In the case of a system connection (a connection available to all users), you can use system-config- network to set the hostname value for dhcp. If a system connection is converted to a user connection, then the hostname is properly defined. Again, everything works. BUT, I consider it to be unreasonable to set the hostname via to process described above. I should be able to set the value in NM's connection-editor ... but I currently cannot do this. I consider this a bug but (I believe others such as the developers) will consider it an RFE (enhancement). It is wishful thinking to get this into F12. Whatever my BZ report will be, it will be against rawhide with the expectation that it be done in F13 with (hopefully) backporting to F12 and F11. While doing a few lines of C code such as I did for DEFROUTE is not difficult, I am illiterate as far a glade is concerned and the connection-editor uses glade for its gui. I am more likely to screw things up than fix things with respect to glade ... I have no idea of where to begin as far as glade goes. Comments? Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not completely handle default route
On Tuesday 13 October 2009 17:05:56 Dan Williams wrote: > On Sun, 2009-10-11 at 22:44 +0200, Robert Vogelgesang wrote: > > On Sun, Oct 11, 2009 at 03:12:05PM -0400, Gene Czarcinski wrote: > > > See the attached patch in another email. My choice of parameter/option > > > is NM_NEVER_DEFAULT= for devices/NICs/connections that should never be > > > the default route. > > > > [...] > > > > > The code/logic change to use NM_ALLOWDEFAULT= rather than what I used > > > (NM_NEVER_DEFAULT_=) should be minor if that is preferred. > > > > I don't really care either if it'll be NEVERDEFAULT or ALLOWDEFAULT. > > > > But why be so humble and prefix this option with "NM_"? I'd rather avoid > > anything that could keep others (i. e. system-config-network and the > > networking init scripts) from using this option/concept; they could > > benefit from this as well. ;-) > > In the name of consistency, the Fedora PPP code has "DEFROUTE=no|yes" > which we should probably re-use for this instead of NM_NEVER_DEFAULT. > The mapping there is pretty clear. > > NM should also honor GATEWAYDEV if it's set, but never try to write it > back out. On write-out we should simply set DEFROUTE=no in the > connection's ifcfg. > > Gene, care to respin the patch with DEFROUTE? Patch re-spun and added the BZ report: https://bugzilla.redhat.com/show_bug.cgi?id=528281 Naturally, never-default is still used internally and in the ~.gconf/system/networking xml files. This also means that never-default has the opposite value from DEFROUTE ... never-default=true when DEFROUTE=no As I point out in the BZ report, this patch has been applied to "current" src.rpm for both F11 and F12-rawhide ... no changes needed. I still have a little reservation about using DEFROUTE. While DEFROUTE=no clearly means that a connection must not be used for the default route, DEFROUTE=yes means that the connection could be used as the default route but not necessarily ... consider a system with three NICs. Dan ... With this patch applied and if initscripts is updated (per your BZ report), that only leaves system-config-network. That is, shouldn't it also support DEFROUTE= ? Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] [Important] NM does not completely handle default route
On Monday 12 October 2009 12:13:20 Gene Czarcinski wrote: > On Sunday 11 October 2009 20:30:58 Gene Czarcinski wrote: > > 2. Since this seems to work fine on F12, I thought I would give a shot at > > F11. The patch applies with no changes on the latest NetworkManager > > updatre (git20090708). > > > > 3. On F11 (as compared to F12), the update does nothing! Not only that > > but GATEWAYDEV= does not do anything either. I tried adding > > NM_NEVER_DEFAULT=yes manually (with vi) and it does not recognize it ... > > or, at least, it has no effect. NM_NEVER_DEFAULT is also not set to > > "no" if the box is unchecked either. > > > > 4. I can set the DHCP Client ID and turn ONBOOT on and of but nothing > > happens with "never-default". > > > > 5. "never-default" does work is I change the connection to be a > > "private" connection (no available to all users). > > I looked into NM on F11 some more and, as far as I can see, the code in the > patch as well as the GATEWAYDEV code in ifcfg-rh/reader.c is never > executed. Looking at the differences between ifcfg-rh/* on F11 and F12, > the code differences are extensive. Someone more familiar with the > current NM on F11 may be able to figure out what is wrong but I consider > that it is not worth my time. > > I am satisfied that the patch fixes things on F12 (assuming the patch is > accepted). I have done some additional testing of the patch on both F12 and F11. Rebuilding the NM rpms with my patch applied to both F12-rawhide and F11 current versions, works on BOTH F11 and F12! On F12, the src.rpm used was "git20091002" and on F11 the src.rpm was "git20090708". In my original testing on F11 I forgot that nm-system-settings was still running the "old" code and thus it appeared to not work. Suggestion, when NetworkManager is "stopped", nm-system-settings should also be killed and when NetworkManager is "started", nm-system-settings should be started. I thought the idea of most updates (except the kernel) is that the system should be able to continue to run. The "safest" thing to do after a NetworkManager update is to also reboot. Anyway, the patch is good for F11 and F12 (and maybe F10 also). Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] NM does not completely handle default route
On Sunday 11 October 2009 20:30:58 Gene Czarcinski wrote: > 2. Since this seems to work fine on F12, I thought I would give a shot at > F11. The patch applies with no changes on the latest NetworkManager > updatre (git20090708). > > 3. On F11 (as compared to F12), the update does nothing! Not only that > but GATEWAYDEV= does not do anything either. I tried adding > NM_NEVER_DEFAULT=yes manually (with vi) and it does not recognize it ... > or, at least, it has no effect. NM_NEVER_DEFAULT is also not set to "no" > if the box is unchecked either. > > 4. I can set the DHCP Client ID and turn ONBOOT on and of but nothing > happens with "never-default". > > 5. "never-default" does work is I change the connection to be a "private" > connection (no available to all users). > I looked into NM on F11 some more and, as far as I can see, the code in the patch as well as the GATEWAYDEV code in ifcfg-rh/reader.c is never executed. Looking at the differences between ifcfg-rh/* on F11 and F12, the code differences are extensive. Someone more familiar with the current NM on F11 may be able to figure out what is wrong but I consider that it is not worth my time. I am satisfied that the patch fixes things on F12 (assuming the patch is accepted). Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] NM does not completely handle default route
On Sunday 11 October 2009 14:44:06 Gene Czarcinski wrote: > On Saturday 10 October 2009 17:56:36 Gene Czarcinski wrote: > > On Saturday 10 October 2009 17:32:42 Gene Czarcinski wrote: > > > OK, this is a followup to a lot of my previous email about NM handling > > > the default route when a system has multiple NICs. > > > > > > I have closed out my BZ report for Fedora 11 as WONTFIX -- > > > https://bugzilla.redhat.com/show_bug.cgi?id=523875 -- and have opened a > > > new report against rawhide -- > > > https://bugzilla.redhat.com/show_bug.cgi?id=528281 > > > > > > I do not expect that this problem will be fixed in time for F12 GA but > > > hope that it can be fixed post GA. > > > > > > I have been poking around the NM source code mainly with grep and > > > gedit. I believe it is possible/practical to fix things with any big > > > re-write (which I believe is neither practical or desirable). [sure is > > > a lot of code] I mainly looked at how GATEWAYDEV=, GATEWAY=, and > > > ONBOOT= (and their ~/.gconf/system/networking/ counterparts) where > > > handled. > > > > > > Some characteristics/constraints -- > > > > > > 1. Having a system with one or more NICs and no default route is a > > > valid configuration and should (must?) be supported by NM. > > > > > > 2. Regardless of having a default route or not, some connections should > > > never be the default route (the intent, I believe, of the current > > > implementation). > > > > > > 3. Having GATEWAYDEV=xxx in /etc/sysconfig/network will cause all NICs > > > other than xxx to be marked as "never-default". This is and should > > > continue to be supported. > > > > > > 4. Only if a NIC is marked as NOT for all users can I mark it for > > > "connection only" (never-default). This needs to be fixed. I should > > > be able to mark a NIC which is available to all users (an ifcfg-xxx > > > system configuration in /etc/sysconfig/network-scripts/) as a > > > "connection only" (never-default) NIC. > > > > > > 5. I should be able to mark a NIC as the default route device. I > > > think this is needed for completeness but am not sure it is really > > > required. > > > > > > 6. If two or more NICs with static IPs are configured with different > > > default route, I do not care ... this is a mis-configuration. > > > > > > 7. The problem is not really with NICs that have static IPs but with > > > those that use dhcp where each dhcp server supplies a default route. > > > > Oops ... I sent this partial message instead of saving the draft. To > > continue ... > > > > 8. system-config-network currently has a problem with GATEWAYDEV=xxx > > being in the /etc/sysconfig/network file and will delete it if you use > > s-c-n to change the NIC system configuration files. Any solution needs > > to avoid this problem. - > > What I propose is also something Dan mentioned ... add a new > > option/parameter to the ifcfg-xxx file. I tried adding "FOOBARBS=yes" > > to the file and this is left alone by system-config-network and ignored > > by NM. > > > > So, I propose adding a new option/parameter such as "DEFAULTGW=yes|no" to > > the system configuration file. > > > > Upon loading the file (in ifcfg-rh/reader.c), if DEFAULTGW=no is > > specified, then mark that connection as "never-default". > > > > When saving the file (applying updates), if the connection is > > "never-default", then set DEFAULTGW=no. > > > > A small problem occurs when I am changing a connection definition for > > "never- default" to allowing it for default. For now, I propose that a > > connection which is NOT "never-default" (that is, never-default is false > > in > > ~/.gconf/...), then we should set DEFAULTGW=? for now. > > > > As an initial attempt at a fix, I think this may be "good enough". Yes, > > having DEFAULTGW=yes have some meaning may be useful but ... ???. As > > described, I think this will only involve ifcfg-rh/reader.c and > > ifcfg-rh/writer.c. > > > > The patch to implement this should be fairly simple and I am going to > > give it a try. > > Attached is a proposed patch to "correct" the default route with system > config (ifcfg-xxx) files. > > I decided to follow the general
Re: NM does not completely handle default route
On Sunday 11 October 2009 16:44:56 Robert Vogelgesang wrote: > On Sun, Oct 11, 2009 at 03:12:05PM -0400, Gene Czarcinski wrote: > > See the attached patch in another email. My choice of parameter/option > > is NM_NEVER_DEFAULT= for devices/NICs/connections that should never be > > the default route. > > [...] > > > The code/logic change to use NM_ALLOWDEFAULT= rather than what I used > > (NM_NEVER_DEFAULT_=) should be minor if that is preferred. > > I don't really care either if it'll be NEVERDEFAULT or ALLOWDEFAULT. > > But why be so humble and prefix this option with "NM_"? I'd rather avoid > anything that could keep others (i. e. system-config-network and the > networking init scripts) from using this option/concept; they could > benefit from this as well. ;-) Efforts today seem to be in NetworkManager rather than manual "expert" stuff like system-config-network. Anyway, the patch is a "proposed patch" ... fine tuning by the developers. Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM does not completely handle default route
On Sunday 11 October 2009 14:44:25 Robert Vogelgesang wrote: > Hello, > > On Sat, Oct 10, 2009 at 05:56:36PM -0400, Gene Czarcinski wrote: > > On Saturday 10 October 2009 17:32:42 Gene Czarcinski wrote: > > > OK, this is a followup to a lot of my previous email about NM handling > > > the default route when a system has multiple NICs. > > > > > > I have closed out my BZ report for Fedora 11 as WONTFIX -- > > > https://bugzilla.redhat.com/show_bug.cgi?id=523875 -- and have opened a > > > new report against rawhide -- > > > https://bugzilla.redhat.com/show_bug.cgi?id=528281 > > > > > > I do not expect that this problem will be fixed in time for F12 GA but > > > hope that it can be fixed post GA. > > > > > > I have been poking around the NM source code mainly with grep and > > > gedit. I believe it is possible/practical to fix things with any big > > > re-write (which I believe is neither practical or desirable). [sure is > > > a lot of code] I mainly looked at how GATEWAYDEV=, GATEWAY=, and > > > ONBOOT= (and their ~/.gconf/system/networking/ counterparts) where > > > handled. > > > > > > Some characteristics/constraints -- > > > > > > 1. Having a system with one or more NICs and no default route is a > > > valid configuration and should (must?) be supported by NM. > > I think we should say MUST in this case. > > > > 2. Regardless of having a default route or not, some connections should > > > never be the default route (the intent, I believe, of the current > > > implementation). > > Agreed. > > > > 3. Having GATEWAYDEV=xxx in /etc/sysconfig/network will cause all NICs > > > other than xxx to be marked as "never-default". This is and should > > > continue to be supported. > > No. As you noted in your bug #528281, system-config-network removes this > option, and I agree with that behaviour. IMHO, GATEWAYDEV=xxx is an > old-time kludge, coming from times long ago where the networking init > scripts actually needed this option as a hint to get the default route > right. The networking init scripts are now in a much better shape, and > we shouldn't commit ourselves to support this option forever. > > GATEWAYDEV=xxx is not sufficient if you have three or more interfaces, > and only one of them should never get the default route. > > > > 4. Only if a NIC is marked as NOT for all users can I mark it for > > > "connection only" (never-default). This needs to be fixed. I should > > > be able to mark a NIC which is available to all users (an ifcfg-xxx > > > system configuration in /etc/sysconfig/network-scripts/) as a > > > "connection only" (never-default) NIC. > > Agreed. > > > > 5. I should be able to mark a NIC as the default route device. I > > > think this is needed for completeness but am not sure it is really > > > required. > > This would be overkill. Either you specify your gateway in the config > file, or get it from DHCP. If you have neither, you're lost, and such an > option wouldn't help in this case. > > > > 6. If two or more NICs with static IPs are configured with different > > > default route, I do not care ... this is a mis-configuration. > > This is a special case, but a valid configuration. Sure, you can have > only one default route at a given time, but if you want to switch between > two or more uplinks, or two different environments that don't support > DHCP, such a setup can make your life more comfortable. > > We just need clear semantics; "the most recently started interface > wins" would be fine, I guess. > > > > 7. The problem is not really with NICs that have static IPs but with > > > those that use dhcp where each dhcp server supplies a default route. > > Agreed. > > > Oops ... I sent this partial message instead of saving the draft. To > > continue ... > > > > 8. system-config-network currently has a problem with GATEWAYDEV=xxx > > being in the /etc/sysconfig/network file and will delete it if you use > > s-c-n to change the NIC system configuration files. Any solution needs > > to avoid this problem. > > As noted above, we don't actually need GATEWAYDEV=xxx, we need a way > to prevent some interfaces/connections from getting the default route, > and we only need this for connections that get their routes from DHCP > or some other peer, e. g. some VPN protocols. > > What I specifically don't like about GATEWAYDEV=xxx is that it only
Re: [patch] NM does not completely handle default route
On Saturday 10 October 2009 17:56:36 Gene Czarcinski wrote: > On Saturday 10 October 2009 17:32:42 Gene Czarcinski wrote: > > OK, this is a followup to a lot of my previous email about NM handling > > the default route when a system has multiple NICs. > > > > I have closed out my BZ report for Fedora 11 as WONTFIX -- > > https://bugzilla.redhat.com/show_bug.cgi?id=523875 -- and have opened a > > new report against rawhide -- > > https://bugzilla.redhat.com/show_bug.cgi?id=528281 > > > > I do not expect that this problem will be fixed in time for F12 GA but > > hope that it can be fixed post GA. > > > > I have been poking around the NM source code mainly with grep and gedit. > > I believe it is possible/practical to fix things with any big re-write > > (which I believe is neither practical or desirable). [sure is a lot of > > code] I mainly looked at how GATEWAYDEV=, GATEWAY=, and ONBOOT= (and > > their ~/.gconf/system/networking/ counterparts) where handled. > > > > Some characteristics/constraints -- > > > > 1. Having a system with one or more NICs and no default route is a valid > > configuration and should (must?) be supported by NM. > > > > 2. Regardless of having a default route or not, some connections should > > never be the default route (the intent, I believe, of the current > > implementation). > > > > 3. Having GATEWAYDEV=xxx in /etc/sysconfig/network will cause all NICs > > other than xxx to be marked as "never-default". This is and should > > continue to be supported. > > > > 4. Only if a NIC is marked as NOT for all users can I mark it for > > "connection only" (never-default). This needs to be fixed. I should be > > able to mark a NIC which is available to all users (an ifcfg-xxx system > > configuration in /etc/sysconfig/network-scripts/) as a "connection only" > > (never-default) NIC. > > > > 5. I should be able to mark a NIC as the default route device. I think > > this is needed for completeness but am not sure it is really required. > > > > 6. If two or more NICs with static IPs are configured with different > > default route, I do not care ... this is a mis-configuration. > > > > 7. The problem is not really with NICs that have static IPs but with > > those that use dhcp where each dhcp server supplies a default route. > > Oops ... I sent this partial message instead of saving the draft. To > continue ... > > 8. system-config-network currently has a problem with GATEWAYDEV=xxx being > in the /etc/sysconfig/network file and will delete it if you use s-c-n to > change the NIC system configuration files. Any solution needs to avoid > this problem. - > What I propose is also something Dan mentioned ... add a new > option/parameter to the ifcfg-xxx file. I tried adding "FOOBARBS=yes" to > the file and this is left alone by system-config-network and ignored by > NM. > > So, I propose adding a new option/parameter such as "DEFAULTGW=yes|no" to > the system configuration file. > > Upon loading the file (in ifcfg-rh/reader.c), if DEFAULTGW=no is specified, > then mark that connection as "never-default". > > When saving the file (applying updates), if the connection is > "never-default", then set DEFAULTGW=no. > > A small problem occurs when I am changing a connection definition for > "never- default" to allowing it for default. For now, I propose that a > connection which is NOT "never-default" (that is, never-default is false > in > ~/.gconf/...), then we should set DEFAULTGW=? for now. > > As an initial attempt at a fix, I think this may be "good enough". Yes, > having DEFAULTGW=yes have some meaning may be useful but ... ???. As > described, I think this will only involve ifcfg-rh/reader.c and > ifcfg-rh/writer.c. > > The patch to implement this should be fairly simple and I am going to give > it a try. Attached is a proposed patch to "correct" the default route with system config (ifcfg-xxx) files. I decided to follow the general approach used in the existing code which creates the "never-default" attribute for a NIC/connection. The only changes are to ifcfg-rh/reader.c and ifcfg-rh/writer.c. This change creates a new option/parameter for the ifcfg-xxx file in /etc/sysconfig/network- scripts/: NM_NEVER_DEFAULT=xxx On input (reader.c), if NM_NEVER_DEFAULT=yes in the ifcfg-xxx file or GATWAYDEV=xxx in /etc/sysconfig/network indicate that this device should never have the default route then never-defau
Re: NM does not completely handle default route
On Saturday 10 October 2009 17:32:42 Gene Czarcinski wrote: > OK, this is a followup to a lot of my previous email about NM handling the > default route when a system has multiple NICs. > > I have closed out my BZ report for Fedora 11 as WONTFIX -- > https://bugzilla.redhat.com/show_bug.cgi?id=523875 -- and have opened a new > report against rawhide -- > https://bugzilla.redhat.com/show_bug.cgi?id=528281 > > I do not expect that this problem will be fixed in time for F12 GA but hope > that it can be fixed post GA. > > I have been poking around the NM source code mainly with grep and gedit. I > believe it is possible/practical to fix things with any big re-write (which > I believe is neither practical or desirable). [sure is a lot of code] I > mainly looked at how GATEWAYDEV=, GATEWAY=, and ONBOOT= (and their > ~/.gconf/system/networking/ counterparts) where handled. > > Some characteristics/constraints -- > > 1. Having a system with one or more NICs and no default route is a valid > configuration and should (must?) be supported by NM. > > 2. Regardless of having a default route or not, some connections should > never be the default route (the intent, I believe, of the current > implementation). > > 3. Having GATEWAYDEV=xxx in /etc/sysconfig/network will cause all NICs > other than xxx to be marked as "never-default". This is and should > continue to be supported. > > 4. Only if a NIC is marked as NOT for all users can I mark it for > "connection only" (never-default). This needs to be fixed. I should be > able to mark a NIC which is available to all users (an ifcfg-xxx system > configuration in /etc/sysconfig/network-scripts/) as a "connection only" > (never-default) NIC. > > 5. I should be able to mark a NIC as the default route device. I think > this is needed for completeness but am not sure it is really required. > > 6. If two or more NICs with static IPs are configured with different > default route, I do not care ... this is a mis-configuration. > > 7. The problem is not really with NICs that have static IPs but with those > that use dhcp where each dhcp server supplies a default route. Oops ... I sent this partial message instead of saving the draft. To continue ... 8. system-config-network currently has a problem with GATEWAYDEV=xxx being in the /etc/sysconfig/network file and will delete it if you use s-c-n to change the NIC system configuration files. Any solution needs to avoid this problem. - What I propose is also something Dan mentioned ... add a new option/parameter to the ifcfg-xxx file. I tried adding "FOOBARBS=yes" to the file and this is left alone by system-config-network and ignored by NM. So, I propose adding a new option/parameter such as "DEFAULTGW=yes|no" to the system configuration file. Upon loading the file (in ifcfg-rh/reader.c), if DEFAULTGW=no is specified, then mark that connection as "never-default". When saving the file (applying updates), if the connection is "never-default", then set DEFAULTGW=no. A small problem occurs when I am changing a connection definition for "never- default" to allowing it for default. For now, I propose that a connection which is NOT "never-default" (that is, never-default is false in ~/.gconf/...), then we should set DEFAULTGW=? for now. As an initial attempt at a fix, I think this may be "good enough". Yes, having DEFAULTGW=yes have some meaning may be useful but ... ???. As described, I think this will only involve ifcfg-rh/reader.c and ifcfg-rh/writer.c. The patch to implement this should be fairly simple and I am going to give it a try. Before I go too far on this ... any comments?? Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM does not completely handle default route
OK, this is a followup to a lot of my previous email about NM handling the default route when a system has multiple NICs. I have closed out my BZ report for Fedora 11 as WONTFIX -- https://bugzilla.redhat.com/show_bug.cgi?id=523875 -- and have opened a new report against rawhide -- https://bugzilla.redhat.com/show_bug.cgi?id=528281 I do not expect that this problem will be fixed in time for F12 GA but hope that it can be fixed post GA. I have been poking around the NM source code mainly with grep and gedit. I believe it is possible/practical to fix things with any big re-write (which I believe is neither practical or desirable). [sure is a lot of code] I mainly looked at how GATEWAYDEV=, GATEWAY=, and ONBOOT= (and their ~/.gconf/system/networking/ counterparts) where handled. Some characteristics/constraints -- 1. Having a system with one or more NICs and no default route is a valid configuration and should (must?) be supported by NM. 2. Regardless of having a default route or not, some connections should never be the default route (the intent, I believe, of the current implementation). 3. Having GATEWAYDEV=xxx in /etc/sysconfig/network will cause all NICs other than xxx to be marked as "never-default". This is and should continue to be supported. 4. Only if a NIC is marked as NOT for all users can I mark it for "connection only" (never-default). This needs to be fixed. I should be able to mark a NIC which is available to all users (an ifcfg-xxx system configuration in /etc/sysconfig/network-scripts/) as a "connection only" (never-default) NIC. 5. I should be able to mark a NIC as the default route device. I think this is needed for completeness but am not sure it is really required. 6. If two or more NICs with static IPs are configured with different default route, I do not care ... this is a mis-configuration. 7. The problem is not really with NICs that have static IPs but with those that use dhcp where each dhcp server supplies a default route. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Thursday 08 October 2009 12:48:57 Gene Czarcinski wrote: > 1. On a qemu-kvm F12 guest, I tried manually setting GATEWAYDEV=eth1 and > this works! Not only is the default route correct but the "connection > only" box is now checked. At the very least, this gives me a work-around > until things are fixed. > I have the source rpm installed and had done "rpmbuild -bc" so I thought I would do a little grep-ing around and see what I could find. One of the things I did was "grep -i -n -r gatewaydev *". So I took a look (edited) at system- settings/plugins/ifcfg-rh/reader.c and, sure enough, the code segment looked it supported reading /etc/sysconfig/network to check for the GATEWAYDEV=xxx parameter and this works as my test showed. However, this is the ONLY reference to GATEWAYDEV. There is no code which supports writing (adding or removing) GATEWAYDEV=xxx to /etc/sysconfig/network. Perhaps this is why NM is not working properly. I am going to look at the code which does the gui connection-editor a bit more to see where it saves the "connection only" checkbox value and it does save it if I do not have the "Available to all users" checked. Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Wednesday 07 October 2009 12:52:58 Dan Williams wrote:
> On Tue, 2009-10-06 at 11:19 -0400, Gene Czarcinski wrote:
> > On Tuesday 06 October 2009 10:45:50 Gene Czarcinski wrote:
> > > On Tuesday 06 October 2009 10:03:45 Gene Czarcinski wrote:
> > > > On Monday 05 October 2009 17:43:42 Dan Williams wrote:
> > > > > On Mon, 2009-10-05 at 16:52 -0400, Gene Czarcinski wrote:
> > > > > > On Monday 05 October 2009 16:33:21 Gene Czarcinski wrote:
> > > > > > > I have not worked with koji before but I can give 134947 a try
> > > > > > > too.
> > > > > >
> > > > > > Downloaded and installed:
> > > > > >
> > > > > > Download/NetworkManager-0.7.996-4.git20091002.fc12.x86_64.rpm
> > > > > > Download/NetworkManager-glib-0.7.996-4.git20091002.fc12.x86_64.rp
> > > > > >m
> > > > > > Download/NetworkManager-gnome-0.7.996-4.git20091002.fc12.x86_64.r
> > > > > >pm
> > > > > >
> > > > > > Still does not work.
> > > > >
> > > > > Ok, are these system connections or user connections? For the ones
> > > > > where the "connection only" checkbox does not stick, is the
> > > > > "Available to all users" checkbox also set?
> > > >
> > > > Absolutely ... all connections are "System" interfaces with the
> > > > "Available to all users" checked. The interface I am trying to set
> > > > "connection only" may be a "private" network but it is a system-wide
> > > > definition.
> > >
> > > OK, something new.
> > >
> > > I unchecked "Available to all users", applied, and restarted eth0 (I
> > > have it set to not start automatically in ifcfg-eth0). I then edited
> > > and checked for "connection only". Not only did the box stay checked
> > > but it worked ... the default route was no to 192.168.122.1 on eth1.
> > >
> > > SO, the problem looks like it is only on system wide ("Available to all
> > > users") interfaces.
> > >
> > > I am going to go back to F11 and try this there too.
> >
> > Yes, yes ... F11 is the same.
> >
> > Unchecked the "Available to all users" box for the "private" network NIC
> > and then I could check the "connection only" box and the default route
> > was correct.
>
> Ok, this makes me think it's more of an issue in the ifcfg-rh backend.
> Unfortunately, the "connection only" thing is backed by a bit of
> ugliness in the ifcfg files; the device name (!) of the device that
> should receive the gateway is set in /etc/sysconfig/network like
> GATEWAYDEV=eth0, which is how it had always been done in a pre-NM and
> ifcfg-only world. NM attempts to preserve that compatibility, and when
> reading in connections, will match the DEVICE=XXX line in the actual
> ifcfg file with the GATEWAYDEV=XXX line in /etc/sysconfig/network, and
> if they *don't* match, that connection will never get the default route.
> There's a bug here apparently.
>
> This gets a bit hard, because device names aren't stable, and NM uses
> the persistent MAC address of the device instead of the device name in
> most cases. Also the fact that connections/ifcfgs don't *have* to be
> tied to a specific device, and the ifcfg-rh backend does not write out
> DEVICE= lines specifically for that reason. The ifcfg files are read
> long before the device might actually be plugged into the system too,
> which means we don't have any information to make that judgement at load
> time.
>
> So the best case is probably to treat GATEWAYDEV as legacy, and have a
> new key on a *per-ifcfg* basis that prevents that ifcfg from ever having
> the default route, like the checkbox states. The ifcfg-rh backend would
> still honor GATEWAYDEV if an ifcfg had the DEVICE=XXX line I guess.
> Thoughts? GATEWAYDEV simply isn't really flexible enough.
Progress! So, the "magic" parameter is GATEWAYDEV= in /etc/sysconfig/network
1. On a qemu-kvm F12 guest, I tried manually setting GATEWAYDEV=eth1 and this
works! Not only is the default route correct but the "connection only" box is
now checked. At the very least, this gives me a work-around until things are
fixed.
2. GATEWAYDEV= (or for that matter GATEWAY=) is poorly documented ... I could
never find any outside of some BZ reports and email messages. However, it has
been there in Fedora and Fedora Core as we
Re: Default Gateway with Manual Setting
On Tuesday 06 October 2009 10:45:50 Gene Czarcinski wrote:
> On Tuesday 06 October 2009 10:03:45 Gene Czarcinski wrote:
> > On Monday 05 October 2009 17:43:42 Dan Williams wrote:
> > > On Mon, 2009-10-05 at 16:52 -0400, Gene Czarcinski wrote:
> > > > On Monday 05 October 2009 16:33:21 Gene Czarcinski wrote:
> > > > > I have not worked with koji before but I can give 134947 a try too.
> > > >
> > > > Downloaded and installed:
> > > >
> > > > Download/NetworkManager-0.7.996-4.git20091002.fc12.x86_64.rpm
> > > > Download/NetworkManager-glib-0.7.996-4.git20091002.fc12.x86_64.rpm
> > > > Download/NetworkManager-gnome-0.7.996-4.git20091002.fc12.x86_64.rpm
> > > >
> > > > Still does not work.
> > >
> > > Ok, are these system connections or user connections? For the ones
> > > where the "connection only" checkbox does not stick, is the "Available
> > > to all users" checkbox also set?
> >
> > Absolutely ... all connections are "System" interfaces with the
> > "Available to all users" checked. The interface I am trying to set
> > "connection only" may be a "private" network but it is a system-wide
> > definition.
>
> OK, something new.
>
> I unchecked "Available to all users", applied, and restarted eth0 (I have
> it set to not start automatically in ifcfg-eth0). I then edited and
> checked for "connection only". Not only did the box stay checked but it
> worked ... the default route was no to 192.168.122.1 on eth1.
>
> SO, the problem looks like it is only on system wide ("Available to all
> users") interfaces.
>
> I am going to go back to F11 and try this there too.
Yes, yes ... F11 is the same.
Unchecked the "Available to all users" box for the "private" network NIC and
then I could check the "connection only" box and the default route was
correct.
Gene
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Tuesday 06 October 2009 10:03:45 Gene Czarcinski wrote:
> On Monday 05 October 2009 17:43:42 Dan Williams wrote:
> > On Mon, 2009-10-05 at 16:52 -0400, Gene Czarcinski wrote:
> > > On Monday 05 October 2009 16:33:21 Gene Czarcinski wrote:
> > > > I have not worked with koji before but I can give 134947 a try too.
> > >
> > > Downloaded and installed:
> > >
> > > Download/NetworkManager-0.7.996-4.git20091002.fc12.x86_64.rpm
> > > Download/NetworkManager-glib-0.7.996-4.git20091002.fc12.x86_64.rpm
> > > Download/NetworkManager-gnome-0.7.996-4.git20091002.fc12.x86_64.rpm
> > >
> > > Still does not work.
> >
> > Ok, are these system connections or user connections? For the ones
> > where the "connection only" checkbox does not stick, is the "Available
> > to all users" checkbox also set?
>
> Absolutely ... all connections are "System" interfaces with the "Available
> to all users" checked. The interface I am trying to set "connection only"
> may be a "private" network but it is a system-wide definition.
OK, something new.
I unchecked "Available to all users", applied, and restarted eth0 (I have it
set to not start automatically in ifcfg-eth0). I then edited and checked for
"connection only". Not only did the box stay checked but it worked ... the
default route was no to 192.168.122.1 on eth1.
SO, the problem looks like it is only on system wide ("Available to all
users") interfaces.
I am going to go back to F11 and try this there too.
Gene
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Monday 05 October 2009 17:43:42 Dan Williams wrote: > On Mon, 2009-10-05 at 16:52 -0400, Gene Czarcinski wrote: > > On Monday 05 October 2009 16:33:21 Gene Czarcinski wrote: > > > I have not worked with koji before but I can give 134947 a try too. > > > > Downloaded and installed: > > > > Download/NetworkManager-0.7.996-4.git20091002.fc12.x86_64.rpm > > Download/NetworkManager-glib-0.7.996-4.git20091002.fc12.x86_64.rpm > > Download/NetworkManager-gnome-0.7.996-4.git20091002.fc12.x86_64.rpm > > > > Still does not work. > > Ok, are these system connections or user connections? For the ones > where the "connection only" checkbox does not stick, is the "Available > to all users" checkbox also set? Absolutely ... all connections are "System" interfaces with the "Available to all users" checked. The interface I am trying to set "connection only" may be a "private" network but it is a system-wide definition. Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Monday 05 October 2009 15:01:59 Dan Williams wrote: > On Mon, 2009-10-05 at 14:37 -0400, Gene Czarcinski wrote: > > On Sunday 04 October 2009 01:56:25 Martyn J. Pearce wrote: > > > Apogolies if re-asked, I have searched the mailing-list archive to no > > > avail. > > > > > > I am running a new ubuntu install on a netbook (Eeepc surf), with wired > > > & wireless networking available, both domestic manually-configured > > > networks (no dhcp). I have added Manual profiles to both wired & > > > wireless. I cannot get the default gateway (192.168.0.12) to > > > configure, however. > > > > > > I add two routes in the route config panel; one for > > > 192.168.0.0/255.255.255.0 (no gateway), and one for 0.0.0.0/0.0.0.0 > > > (gateway 192.168.0.12). Having left the edit dialogue, and applied, > > > there is no difference to the routing table as displayed with route -n. > > > If I re-enter the routes edit panel, I find that it's collapsed the > > > routes into one, being 192.168.0.0/255.255.255.0 (gateway > > > 192.168.0.12); but there's no hint of the gateway in the route config. > > > > > > I have tried checking and unchecking the "use this connection only for > > > resources on its network" (I'm sure it should be unchecked, but I tried > > > both); it makes no difference. > > > > > > I'm sure I'm being stupid, could somebody take pity and enlighten me as > > > to what I'm doing wrong? > > > > > > I attach the relevant lines from /var/log/daemon.log (grep > > > NetworkManager), I've checked the one bug mentioned therein; that is > > > related to publishing of offline mode rather than setting of default > > > gateways. > > > > > > Thanks, > > > > > > [please cc: me on replies, I am not subscribed to the list] > > > > This may be related to the following -- > > https://bugzilla.redhat.com/show_bug.cgi?id=523875 > > I need to get around to testing that one out; is the connection that it > doesn't stay checked for a system connection? I can't imagine what > would be wrong if it's just a user connection. I have the problem on both F11 and F12 but lets stick to F12 for now. -->> Should I file a second BZ report for this bug with rawhide specified instead of F11? To me, the bug appears to be the same but that does not make it so. On my qemu-kvm F12 guest I have two NICs defined: eth0 on a "private" (non-NAT or host only) qemu network and eth1 on the "default" NAT qemu network which will give me access to my local network and ultimately the Internet. I am attaching the definition file for the "private" qemu network which goes in /etc/libvirt/qemu/networks/. As described, the default route is to eth0 whereas I want it to be on eth1. If I reverse the two definitions (easy to do with qemu-kvm), then the default is still eth0 but this time it is correct. [when fooling with NIC definitions, remember to delete /etc/udev/rules.d/70- persistent-net.rules so that ethX naming makes sense]. You will also neet to use system-config-network to get the definitions & MAC addresses correct. BTW, I do not run either networks or NetworkManager at bootup so that I can control what is going on. In all cases, I am using "System" definitions ... e.g., /etc/sysconfig/network- scripts/ifcfg-eth0 In all cases, the NIC I am trying to set the "connection only" checkbox is on the "private" network NIC. > > I've seen this problem on F12/rawhide but fixed it there, the cause in > F12 would be unrelated to anything in F11, which is what the bug was > filed against. They may be different but the result is the same. Gene private.xml Description: XML document ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Monday 05 October 2009 16:33:21 Gene Czarcinski wrote: > I have not worked with koji before but I can give 134947 a try too. Downloaded and installed: Download/NetworkManager-0.7.996-4.git20091002.fc12.x86_64.rpm Download/NetworkManager-glib-0.7.996-4.git20091002.fc12.x86_64.rpm Download/NetworkManager-gnome-0.7.996-4.git20091002.fc12.x86_64.rpm Still does not work. Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Monday 05 October 2009 15:33:38 Dan Williams wrote: > On Mon, 2009-10-05 at 15:03 -0400, Gene Czarcinski wrote: > > On Monday 05 October 2009 13:21:46 Dan Williams wrote: > > > That checkbox ensures that that connection (and thus any device that > > > has been activated using that connection) will not be the default > > > route. > > > > Nice in theory but this does not work in practice on with Fedora 11 or > > Fedora 12 -- https://bugzilla.redhat.com/show_bug.cgi?id=523875 > > > > As I see it, there is one and possible two problems: > > > > 1. The "connection only" does not stay checked (and, I assume, the > > appropriate parameter does not get set). > > > > 2. If "connection only" checkbox be made to work, is the default route > > set properly. > > > > IMHO, this is an important problem that needs fixing .. in at least F12 > > if not in F11. > > > > OK, there are only so many hours in a day and the maintainers/developers > > of NetworkManager have a lot to do ... and, from the looks of it, > > NetworkManager is a lot of code. > > > > So, I am willing to put some time in on this. I downloaded and installed > > the F12 source rpm. As I said, NetworkManager is a lot of code and I > > would prefer to spend my time constructively rather than learning about > > all of NetworkManager. Could someone provide some guidance as to where > > (what source files) I should be looking? > > Which specific NM SRPM? Ideally you have: > > http://kojipkgs.fedoraproject.org/packages/NetworkManager/0.7.996/4.git2009 > 1002.fc12/src/NetworkManager-0.7.996-4.git20091002.fc12.src.rpm > > You might also try to update to the packages here: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=134947 > > and see if you can reproduce the issue on F12, which would help. F12 > builds have had a fwe issues the past couple weeks that would have > prevented the "available to all users" checkbox from sticking, but which > are unrelated to anything in F11. > > Once we've confirmed versions, I can point you to the right places. I currently have the binary NetworkManager-0.7.996-3.git20090928.fc12.x86_64 installed on my qemu-kvm F12 guest I am using for testing. The source is NetworkManager-0.7.996-3.git20090928.fc12.src.rpm. I have gotten the problem on both F11 (with current updates) and F12-rawhide both as qemu-kvm guests since I can fiddle with the network definitions easier. I have not worked with koji before but I can give 134947 a try too. I have my F12 build environment on a F12-rawhide-current host and would then transport the results to the guests. I am C and C++ "literate" and have modified/built many rpms previously. Although the results on both F11 and F12 are the same, they do act a little differently. On F11 with the default network on eth0 and a private network on eth1, eth1 becomes the default. On F12 with the default network on eth0 and a private network on eth1, eth0 becomes the default and everything is OK. BUT, if I reverse the network definitions (eth0 is a private network and eth1 is the default (NAT) network), the it does not work because eth0 still becomes the default. In all cases, setting the "connection only" checkbox does not stay set. Question: if the checkbox did work, what parameter in what configuration file is suppose to be set? Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Monday 05 October 2009 13:21:46 Dan Williams wrote: > On Mon, 2009-10-05 at 13:07 -0400, John Mahoney wrote: > > On Sun, Oct 4, 2009 at 1:56 AM, Martyn J. Pearce > > wrote: > > Apogolies if re-asked, I have searched the mailing-list > > archive to no avail. > > > > I am running a new ubuntu install on a netbook (Eeepc surf), > > with wired & > > wireless networking available, both domestic > > manually-configured networks (no > > dhcp). I have added Manual profiles to both wired & > > wireless. I cannot get > > the default gateway (192.168.0.12) to configure, however. > > > > I add two routes in the route config panel; one for > > 192.168.0.0/255.255.255.0 > > (no gateway), and one for 0.0.0.0/0.0.0.0 (gateway > > 192.168.0.12). Having left > > the edit dialogue, and applied, there is no difference to the > > routing table as > > displayed with route -n. If I re-enter the routes edit panel, > > I find that > > it's collapsed the routes into one, being > > 192.168.0.0/255.255.255.0 (gateway > > 192.168.0.12); but there's no hint of the gateway in the route > > config. > > > > > > Did you try adding the Default gateway to the Addresses section of the > > ipv4 settings tab instead of the routes section. > > Also, If you have both wired and wireless interfaces active, I > > believe, it will always use the wired default route first if possible. > > The routes dialog doesn't take 0.0.0.0, because that's the default > route, and NM manages the default route. Here's what you do... > > Set up your IP address and static routes. By default, the wired device > will always get the default route. If there is a device (any device) > that you do *not* want to have the default route at any point, check the > "Use this connection only for resources on its network" checkbox in the > "Routes" dialog of the IPv4 page. > > That checkbox ensures that that connection (and thus any device that has > been activated using that connection) will not be the default route. Nice in theory but this does not work in practice on with Fedora 11 or Fedora 12 -- https://bugzilla.redhat.com/show_bug.cgi?id=523875 As I see it, there is one and possible two problems: 1. The "connection only" does not stay checked (and, I assume, the appropriate parameter does not get set). 2. If "connection only" checkbox be made to work, is the default route set properly. IMHO, this is an important problem that needs fixing .. in at least F12 if not in F11. OK, there are only so many hours in a day and the maintainers/developers of NetworkManager have a lot to do ... and, from the looks of it, NetworkManager is a lot of code. So, I am willing to put some time in on this. I downloaded and installed the F12 source rpm. As I said, NetworkManager is a lot of code and I would prefer to spend my time constructively rather than learning about all of NetworkManager. Could someone provide some guidance as to where (what source files) I should be looking? Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Default Gateway with Manual Setting
On Sunday 04 October 2009 01:56:25 Martyn J. Pearce wrote: > Apogolies if re-asked, I have searched the mailing-list archive to no > avail. > > I am running a new ubuntu install on a netbook (Eeepc surf), with wired & > wireless networking available, both domestic manually-configured networks > (no dhcp). I have added Manual profiles to both wired & wireless. I > cannot get the default gateway (192.168.0.12) to configure, however. > > I add two routes in the route config panel; one for > 192.168.0.0/255.255.255.0 (no gateway), and one for 0.0.0.0/0.0.0.0 > (gateway 192.168.0.12). Having left the edit dialogue, and applied, there > is no difference to the routing table as displayed with route -n. If I > re-enter the routes edit panel, I find that it's collapsed the routes into > one, being 192.168.0.0/255.255.255.0 (gateway 192.168.0.12); but there's > no hint of the gateway in the route config. > > I have tried checking and unchecking the "use this connection only for > resources on its network" (I'm sure it should be unchecked, but I tried > both); it makes no difference. > > I'm sure I'm being stupid, could somebody take pity and enlighten me as to > what I'm doing wrong? > > I attach the relevant lines from /var/log/daemon.log (grep NetworkManager), > I've checked the one bug mentioned therein; that is related to publishing > of offline mode rather than setting of default gateways. > > Thanks, > > [please cc: me on replies, I am not subscribed to the list] > This may be related to the following -- https://bugzilla.redhat.com/show_bug.cgi?id=523875 This may be one or two bugs ... (1) the "connection only" checkbox does not stay checked and (2) even if checked, will the default route be set properly. Obviously, this is correct routing is only a problem on a system with multiple NICs. Even with multiple NICs, a system may not see the problem because of the order that NICs are activated (and order differs on F11 and F12 systems). Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
