Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/30/2012 05:23 PM, Gene Czarcinski wrote: On 11/30/2012 04:18 PM, Simon Kelley wrote: On 30/11/12 21:03, Gene Czarcinski wrote: On 11/30/2012 12:45 PM, Simon Kelley wrote: On 30/11/12 17:20, Gene Czarcinski wrote: On 11/30/2012 11:32 AM, Simon Kelley wrote: On 30/11/12 15:54, Gene Czarcinski wrote: On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. I'd expect it. The code you instrumented gets run whenever a new address event happens, which is whenever an address is added to an interface. Every time a new virtual network interface is started is a good proxy for that. The dnsmasq code isn't very discriminating, it updates it's idea of which interfaces hace which addresses, and then does a minute of fast advertisements on all of them. It might be possible to only do the fast advertisements on new interfaces, but implementing that isn't totally trivial. Yes, I doubt very much if it would be trivial. However, I do not believe that this is the basic problem. When the problem occurs, one of the networks suddenly attempts to work with the real NIC rather than the virtual one defined in its config file. I slightly changed the IPv4 and IPv6 addresses defined for this network and the problem went away. I have also just seen the problem happen on another system which also had that virtual address defined. BTW, these configurations all use interface= and bind-dynamic rather than the old bind-interface with listen-address= specified for each specified IPv4 and IPv6 address. I had not noticed the problem previously. Why it occurs at all with just this specific address is puzzling. The configuration in which causes problems is: -- # dnsmasq conf file created by libvirt strict-order domain-needed domain=net6 expand-hosts local=/net6/ pid-file=/var/run/libvirt/network/net6.pid bind-dynamic interface=virbr11 dhcp-range=192.168.6.128,192.168.6.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/net6.leases dhcp-lease-max=127 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net6.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/net6.addnhosts dhcp-range=fd00:beef:10:6::1,ra-only - When I changed all the 6 to 160, the problem, disappeared. And there is another network defined almost the same with 8 instead of 6 and I have had no problems with it. The real NIC is configured as a DHCP client for both IPv4 and IPv6. It is assigned nailed addresses of 192.168.17.2/24 and fd00:dead:beef:17::2. And I just discovered why crazy stuff is happening (but I do not know what causes it) ... the P33p1 NIC has: inet6 fd00:beef:10:6:3285:a9ff:fe8f:e982/64 scope global dynamic Is that the real NIC? Yes, p33p1 is the real NIC. This is going to be a real PITA to debug because I believe part of the problem is a race condition. NetworkManager has this really long dance it goes through to bring up the IPv6 interface. But, I do not have any proof of that and as I just proved to myself, getting things to repeat are going to be difficult. At this point I am not sure that bind-dynamic was related. I went through the syslogs I still have and the first occurrence was on 8 November. That is well before bind-dynamic was integrated in. Attached are some limited copies of syslogs that I thought you might find of interest. It seems like the strangeness seem to happen right after I update libvirt and libvirtd is restarted which then gets dnsmasq started. If I cannot get this figured out and fixed, I will need to disable use of dnsmasq for RA service and fall back on radvd. Frustrating .. so close and yet
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 01/12/12 14:54, Gene Czarcinski wrote: On 11/30/2012 05:23 PM, Gene Czarcinski wrote: On 11/30/2012 04:18 PM, Simon Kelley wrote: On 30/11/12 21:03, Gene Czarcinski wrote: On 11/30/2012 12:45 PM, Simon Kelley wrote: On 30/11/12 17:20, Gene Czarcinski wrote: On 11/30/2012 11:32 AM, Simon Kelley wrote: On 30/11/12 15:54, Gene Czarcinski wrote: On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. I'd expect it. The code you instrumented gets run whenever a new address event happens, which is whenever an address is added to an interface. Every time a new virtual network interface is started is a good proxy for that. The dnsmasq code isn't very discriminating, it updates it's idea of which interfaces hace which addresses, and then does a minute of fast advertisements on all of them. It might be possible to only do the fast advertisements on new interfaces, but implementing that isn't totally trivial. Yes, I doubt very much if it would be trivial. However, I do not believe that this is the basic problem. When the problem occurs, one of the networks suddenly attempts to work with the real NIC rather than the virtual one defined in its config file. I slightly changed the IPv4 and IPv6 addresses defined for this network and the problem went away. I have also just seen the problem happen on another system which also had that virtual address defined. BTW, these configurations all use interface= and bind-dynamic rather than the old bind-interface with listen-address= specified for each specified IPv4 and IPv6 address. I had not noticed the problem previously. Why it occurs at all with just this specific address is puzzling. The configuration in which causes problems is: -- # dnsmasq conf file created by libvirt strict-order domain-needed domain=net6 expand-hosts local=/net6/ pid-file=/var/run/libvirt/network/net6.pid bind-dynamic interface=virbr11 dhcp-range=192.168.6.128,192.168.6.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/net6.leases dhcp-lease-max=127 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net6.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/net6.addnhosts dhcp-range=fd00:beef:10:6::1,ra-only - When I changed all the 6 to 160, the problem, disappeared. And there is another network defined almost the same with 8 instead of 6 and I have had no problems with it. The real NIC is configured as a DHCP client for both IPv4 and IPv6. It is assigned nailed addresses of 192.168.17.2/24 and fd00:dead:beef:17::2. And I just discovered why crazy stuff is happening (but I do not know what causes it) ... the P33p1 NIC has: inet6 fd00:beef:10:6:3285:a9ff:fe8f:e982/64 scope global dynamic Is that the real NIC? Yes, p33p1 is the real NIC. This is going to be a real PITA to debug because I believe part of the problem is a race condition. NetworkManager has this really long dance it goes through to bring up the IPv6 interface. But, I do not have any proof of that and as I just proved to myself, getting things to repeat are going to be difficult. At this point I am not sure that bind-dynamic was related. I went through the syslogs I still have and the first occurrence was on 8 November. That is well before bind-dynamic was integrated in. Attached are some limited copies of syslogs that I thought you might find of interest. It seems like the strangeness seem to happen right after I update libvirt and libvirtd is restarted which then gets dnsmasq started. If I cannot get this figured out and fixed, I will need to disable use of dnsmasq for RA service and fall back on radvd. Frustrating .. so
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 30/11/12 15:54, Gene Czarcinski wrote: On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. I'd expect it. The code you instrumented gets run whenever a new address event happens, which is whenever an address is added to an interface. Every time a new virtual network interface is started is a good proxy for that. The dnsmasq code isn't very discriminating, it updates it's idea of which interfaces hace which addresses, and then does a minute of fast advertisements on all of them. It might be possible to only do the fast advertisements on new interfaces, but implementing that isn't totally trivial. Cheers, Simon. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 30/11/12 17:20, Gene Czarcinski wrote: On 11/30/2012 11:32 AM, Simon Kelley wrote: On 30/11/12 15:54, Gene Czarcinski wrote: On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. I'd expect it. The code you instrumented gets run whenever a new address event happens, which is whenever an address is added to an interface. Every time a new virtual network interface is started is a good proxy for that. The dnsmasq code isn't very discriminating, it updates it's idea of which interfaces hace which addresses, and then does a minute of fast advertisements on all of them. It might be possible to only do the fast advertisements on new interfaces, but implementing that isn't totally trivial. Yes, I doubt very much if it would be trivial. However, I do not believe that this is the basic problem. When the problem occurs, one of the networks suddenly attempts to work with the real NIC rather than the virtual one defined in its config file. I slightly changed the IPv4 and IPv6 addresses defined for this network and the problem went away. I have also just seen the problem happen on another system which also had that virtual address defined. BTW, these configurations all use interface= and bind-dynamic rather than the old bind-interface with listen-address= specified for each specified IPv4 and IPv6 address. I had not noticed the problem previously. Why it occurs at all with just this specific address is puzzling. The configuration in which causes problems is: -- # dnsmasq conf file created by libvirt strict-order domain-needed domain=net6 expand-hosts local=/net6/ pid-file=/var/run/libvirt/network/net6.pid bind-dynamic interface=virbr11 dhcp-range=192.168.6.128,192.168.6.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/net6.leases dhcp-lease-max=127 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net6.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/net6.addnhosts dhcp-range=fd00:beef:10:6::1,ra-only - When I changed all the 6 to 160, the problem, disappeared. And there is another network defined almost the same with 8 instead of 6 and I have had no problems with it. The real NIC is configured as a DHCP client for both IPv4 and IPv6. It is assigned nailed addresses of 192.168.17.2/24 and fd00:dead:beef:17::2. And I just discovered why crazy stuff is happening (but I do not know what causes it) ... the P33p1 NIC has: inet6 fd00:beef:10:6:3285:a9ff:fe8f:e982/64 scope global dynamic Is that the real NIC? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/30/2012 12:45 PM, Simon Kelley wrote: On 30/11/12 17:20, Gene Czarcinski wrote: On 11/30/2012 11:32 AM, Simon Kelley wrote: On 30/11/12 15:54, Gene Czarcinski wrote: On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. I'd expect it. The code you instrumented gets run whenever a new address event happens, which is whenever an address is added to an interface. Every time a new virtual network interface is started is a good proxy for that. The dnsmasq code isn't very discriminating, it updates it's idea of which interfaces hace which addresses, and then does a minute of fast advertisements on all of them. It might be possible to only do the fast advertisements on new interfaces, but implementing that isn't totally trivial. Yes, I doubt very much if it would be trivial. However, I do not believe that this is the basic problem. When the problem occurs, one of the networks suddenly attempts to work with the real NIC rather than the virtual one defined in its config file. I slightly changed the IPv4 and IPv6 addresses defined for this network and the problem went away. I have also just seen the problem happen on another system which also had that virtual address defined. BTW, these configurations all use interface= and bind-dynamic rather than the old bind-interface with listen-address= specified for each specified IPv4 and IPv6 address. I had not noticed the problem previously. Why it occurs at all with just this specific address is puzzling. The configuration in which causes problems is: -- # dnsmasq conf file created by libvirt strict-order domain-needed domain=net6 expand-hosts local=/net6/ pid-file=/var/run/libvirt/network/net6.pid bind-dynamic interface=virbr11 dhcp-range=192.168.6.128,192.168.6.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/net6.leases dhcp-lease-max=127 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net6.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/net6.addnhosts dhcp-range=fd00:beef:10:6::1,ra-only - When I changed all the 6 to 160, the problem, disappeared. And there is another network defined almost the same with 8 instead of 6 and I have had no problems with it. The real NIC is configured as a DHCP client for both IPv4 and IPv6. It is assigned nailed addresses of 192.168.17.2/24 and fd00:dead:beef:17::2. And I just discovered why crazy stuff is happening (but I do not know what causes it) ... the P33p1 NIC has: inet6 fd00:beef:10:6:3285:a9ff:fe8f:e982/64 scope global dynamic Is that the real NIC? Yes, p33p1 is the real NIC. This is going to be a real PITA to debug because I believe part of the problem is a race condition. NetworkManager has this really long dance it goes through to bring up the IPv6 interface. But, I do not have any proof of that and as I just proved to myself, getting things to repeat are going to be difficult. At this point I am not sure that bind-dynamic was related. I went through the syslogs I still have and the first occurrence was on 8 November. That is well before bind-dynamic was integrated in. Attached are some limited copies of syslogs that I thought you might find of interest. It seems like the strangeness seem to happen right after I update libvirt and libvirtd is restarted which then gets dnsmasq started. If I cannot get this figured out and fixed, I will need to disable use of dnsmasq for RA service and fall back on radvd. Frustrating .. so close and yet so far! Gene Nov 30 09:41:14 condor dbus[954]: [system] Successfully activated service 'org.freedesktop.PackageKit' Nov 30 09:49:18 condor
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 30/11/12 21:03, Gene Czarcinski wrote: On 11/30/2012 12:45 PM, Simon Kelley wrote: On 30/11/12 17:20, Gene Czarcinski wrote: On 11/30/2012 11:32 AM, Simon Kelley wrote: On 30/11/12 15:54, Gene Czarcinski wrote: On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. I'd expect it. The code you instrumented gets run whenever a new address event happens, which is whenever an address is added to an interface. Every time a new virtual network interface is started is a good proxy for that. The dnsmasq code isn't very discriminating, it updates it's idea of which interfaces hace which addresses, and then does a minute of fast advertisements on all of them. It might be possible to only do the fast advertisements on new interfaces, but implementing that isn't totally trivial. Yes, I doubt very much if it would be trivial. However, I do not believe that this is the basic problem. When the problem occurs, one of the networks suddenly attempts to work with the real NIC rather than the virtual one defined in its config file. I slightly changed the IPv4 and IPv6 addresses defined for this network and the problem went away. I have also just seen the problem happen on another system which also had that virtual address defined. BTW, these configurations all use interface= and bind-dynamic rather than the old bind-interface with listen-address= specified for each specified IPv4 and IPv6 address. I had not noticed the problem previously. Why it occurs at all with just this specific address is puzzling. The configuration in which causes problems is: -- # dnsmasq conf file created by libvirt strict-order domain-needed domain=net6 expand-hosts local=/net6/ pid-file=/var/run/libvirt/network/net6.pid bind-dynamic interface=virbr11 dhcp-range=192.168.6.128,192.168.6.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/net6.leases dhcp-lease-max=127 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net6.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/net6.addnhosts dhcp-range=fd00:beef:10:6::1,ra-only - When I changed all the 6 to 160, the problem, disappeared. And there is another network defined almost the same with 8 instead of 6 and I have had no problems with it. The real NIC is configured as a DHCP client for both IPv4 and IPv6. It is assigned nailed addresses of 192.168.17.2/24 and fd00:dead:beef:17::2. And I just discovered why crazy stuff is happening (but I do not know what causes it) ... the P33p1 NIC has: inet6 fd00:beef:10:6:3285:a9ff:fe8f:e982/64 scope global dynamic Is that the real NIC? Yes, p33p1 is the real NIC. This is going to be a real PITA to debug because I believe part of the problem is a race condition. NetworkManager has this really long dance it goes through to bring up the IPv6 interface. But, I do not have any proof of that and as I just proved to myself, getting things to repeat are going to be difficult. At this point I am not sure that bind-dynamic was related. I went through the syslogs I still have and the first occurrence was on 8 November. That is well before bind-dynamic was integrated in. Attached are some limited copies of syslogs that I thought you might find of interest. It seems like the strangeness seem to happen right after I update libvirt and libvirtd is restarted which then gets dnsmasq started. If I cannot get this figured out and fixed, I will need to disable use of dnsmasq for RA service and fall back on radvd. Frustrating .. so close and yet so far! I wonder if the virbr* interfaces are bridged to the real NICs, such that when a prefix is advertised on the
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/30/2012 04:18 PM, Simon Kelley wrote: On 30/11/12 21:03, Gene Czarcinski wrote: On 11/30/2012 12:45 PM, Simon Kelley wrote: On 30/11/12 17:20, Gene Czarcinski wrote: On 11/30/2012 11:32 AM, Simon Kelley wrote: On 30/11/12 15:54, Gene Czarcinski wrote: On 11/29/2012 04:18 PM, Simon Kelley wrote: On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? The good news is that libvirt is working again (I must have done a git-pull in the middle of an update). Thus, I am not seeing the large numbers of RTR-ADVERT. Yes, I am seeing the new log message and I have a question about that. Every time a new virtual network interface is started, something must be doing some type of broadcast because all of the dnsmasq instances (the new one and all the old ones) suddenly wake up and issue a flurry of RA packets and related syslog messages. To kick the flurry off, there one of the new unsolicited syslog messages from each dnsmasq instance. Is this something you would expect? Is this normal? The libvirt folks they are not doing it. I'd expect it. The code you instrumented gets run whenever a new address event happens, which is whenever an address is added to an interface. Every time a new virtual network interface is started is a good proxy for that. The dnsmasq code isn't very discriminating, it updates it's idea of which interfaces hace which addresses, and then does a minute of fast advertisements on all of them. It might be possible to only do the fast advertisements on new interfaces, but implementing that isn't totally trivial. Yes, I doubt very much if it would be trivial. However, I do not believe that this is the basic problem. When the problem occurs, one of the networks suddenly attempts to work with the real NIC rather than the virtual one defined in its config file. I slightly changed the IPv4 and IPv6 addresses defined for this network and the problem went away. I have also just seen the problem happen on another system which also had that virtual address defined. BTW, these configurations all use interface= and bind-dynamic rather than the old bind-interface with listen-address= specified for each specified IPv4 and IPv6 address. I had not noticed the problem previously. Why it occurs at all with just this specific address is puzzling. The configuration in which causes problems is: -- # dnsmasq conf file created by libvirt strict-order domain-needed domain=net6 expand-hosts local=/net6/ pid-file=/var/run/libvirt/network/net6.pid bind-dynamic interface=virbr11 dhcp-range=192.168.6.128,192.168.6.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/net6.leases dhcp-lease-max=127 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net6.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/net6.addnhosts dhcp-range=fd00:beef:10:6::1,ra-only - When I changed all the 6 to 160, the problem, disappeared. And there is another network defined almost the same with 8 instead of 6 and I have had no problems with it. The real NIC is configured as a DHCP client for both IPv4 and IPv6. It is assigned nailed addresses of 192.168.17.2/24 and fd00:dead:beef:17::2. And I just discovered why crazy stuff is happening (but I do not know what causes it) ... the P33p1 NIC has: inet6 fd00:beef:10:6:3285:a9ff:fe8f:e982/64 scope global dynamic Is that the real NIC? Yes, p33p1 is the real NIC. This is going to be a real PITA to debug because I believe part of the problem is a race condition. NetworkManager has this really long dance it goes through to bring up the IPv6 interface. But, I do not have any proof of that and as I just proved to myself, getting things to repeat are going to be difficult. At this point I am not sure that bind-dynamic was related. I went through the syslogs I still have and the first occurrence was on 8 November. That is well before bind-dynamic was integrated in. Attached are some limited copies of syslogs that I thought you might find of interest. It seems like the strangeness seem to happen right after I update libvirt and libvirtd is restarted which then gets dnsmasq started. If I cannot get this figured out and fixed, I will need to disable use of dnsmasq for RA service and fall back on radvd. Frustrating .. so close and yet so far! I wonder if the virbr* interfaces are bridged
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/28/2012 03:31 PM, Simon Kelley wrote: On 25/11/12 18:39, Gene Czarcinski wrote: On 11/25/2012 01:10 PM, Vladislav Grishenko wrote: Hi Gene, Instead of deprecating/turning-off logging by facility, it would be better to have ability to tune loglevel for each sysbsystem. Like following: where 0 means log-level=dhcp,dhcpv6,6,dns,7,ra,-1 Best Regards, Vladislav Grishenko Yes, that is indeed a good idea, I have no intention of deprecating logging but I also do not want a large amount of information-less clutter in the syslog which may hide something that is important. The RTR-ADVERT messages being issued every 3 to 5 seconds with separate messages for each virtual interface that is started is a bit much. But they're only that frequent for the first minute. After that they're every 10 minutes, I think. Something is definitely not working correctly. I do not know if you have a qemu/kvm setup so duplicating the conditions that way will not work. Attached is a piece of syslog (before I patched things to suppress the messages). BTW, I also have no idea why anything is being done with p33p1 ... that is the real NIC on that system. I have also attached the dnsmasq conf file for that interface. I am willing to try any testing. Unless I can get things to work as they are suppose to, user reception of using dnsmasq to handle RA will get support somewhere between zero and none :-) I have taken a look at the code and (I hope) I just do not understand how things are really working. If log-dhcp is specified (command line or conf-file), OPT_LOG_OPTS is set. A little grepping resulted in rfc3315.c and rfc2131.c as issuing messages with log6_packet() and log_packet() respectively. Sounds good, the test can be done in a central place. But, looking more closely, the only thing OPT_LOG_OPTS does is determine the form of the syslog message ... not if it is being issued. And, of course, there are other calls to my_syslog() scattered throughout. BTW, warning or at least error message should always be issued. It is all the info massages that are becoming overwhelming. Certainly there should be a lot of messages to support debugging and the code should always be compiled in. But, when things are working well it is better to have most of those messages inhibited so that some warning or error message will be seen. I see the RTR_ADVERT messages as being equivalent to the logs of DHCP request and replies - they are at a minimum level which allows tracking of the history of interaction with a client. The DHCP logs, at least have equivalents in most DHCP servers. It's important to know which prefixes are being advertised, since that's a function of quite a lot of configuration: not just dnsmasq config, but kernel-level interface configuration too. Cheers, Simon. 3. Similar to radvd, should there be some dnsmasq parameters which are used to specify how often RAs will be issued? There could be, but only if it makes sense to tune that for network performance, not just prettifying the logs. The philosophy in dnsmasq has always been to hide useless tuning settings and try and let people configure what they want to do, not control every field of every packet. I be no-one uses that option in radvd ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss # dnsmasq conf file created by libvirt strict-order domain-needed domain=net6 expand-hosts local=/net6/ pid-file=/var/run/libvirt/network/net6.pid bind-dynamic interface=virbr11 dhcp-range=192.168.6.128,192.168.6.254 dhcp-no-override dhcp-leasefile=/var/lib/libvirt/dnsmasq/net6.leases dhcp-lease-max=127 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/net6.hostsfile addn-hosts=/var/lib/libvirt/dnsmasq/net6.addnhosts dhcp-range=fd00:beef:10:6::1,ra-only RTR-ADVERT2.msgs.gz Description: GNU Zip compressed data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 29/11/12 16:06, Gene Czarcinski wrote: Something is definitely not working correctly. I do not know if you have a qemu/kvm setup so duplicating the conditions that way will not work. Attached is a piece of syslog (before I patched things to suppress the messages). BTW, I also have no idea why anything is being done with p33p1 ... that is the real NIC on that system. I have also attached the dnsmasq conf file for that interface. I am willing to try any testing. Unless I can get things to work as they are suppose to, user reception of using dnsmasq to handle RA will get support somewhere between zero and none :-) Another theory: a netlink NEWADDR event (ie assigning an address to a network interface) triggers the one minute of rapid advertisements. Maybe something on your system is doing that regularly? Can you try adding a logging line next to the call to ra_start_unsolicited() in nl_async() in netlink.c, to see how often that gets called? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/29/2012 11:28 AM, Simon Kelley wrote: On 29/11/12 16:06, Gene Czarcinski wrote: Something is definitely not working correctly. I do not know if you have a qemu/kvm setup so duplicating the conditions that way will not work. Attached is a piece of syslog (before I patched things to suppress the messages). BTW, I also have no idea why anything is being done with p33p1 ... that is the real NIC on that system. I have also attached the dnsmasq conf file for that interface. I am willing to try any testing. Unless I can get things to work as they are suppose to, user reception of using dnsmasq to handle RA will get support somewhere between zero and none :-) Another theory: a netlink NEWADDR event (ie assigning an address to a network interface) triggers the one minute of rapid advertisements. Maybe something on your system is doing that regularly? Can you try adding a logging line next to the call to ra_start_unsolicited() in nl_async() in netlink.c, to see how often that gets called? OK, rebuilt dnsmasq with the patch to limit RTR-ADVERT out and a patch added to issue a syslog message when ra_start_unsolicted is done. It is installed on two systems which also run virtualization. They are both fairly new AMD-cpu systems and I have not had any problems with clocks. One virtual network started on each and no other dnsmasq instances. I do wonder if this rapid issuing also takes place with radvd but has never been noticed because it does not issue log messages. BTW, on a system which does not have virtualization installed (because it cannot run it) but does have dnsmasq doing its thing including DHCPv6, there are RTR-ADVERT messages about every eight minutes per interface. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/29/2012 02:08 PM, Gene Czarcinski wrote: On 11/29/2012 11:28 AM, Simon Kelley wrote: On 29/11/12 16:06, Gene Czarcinski wrote: Something is definitely not working correctly. I do not know if you have a qemu/kvm setup so duplicating the conditions that way will not work. Attached is a piece of syslog (before I patched things to suppress the messages). BTW, I also have no idea why anything is being done with p33p1 ... that is the real NIC on that system. I have also attached the dnsmasq conf file for that interface. I am willing to try any testing. Unless I can get things to work as they are suppose to, user reception of using dnsmasq to handle RA will get support somewhere between zero and none :-) Another theory: a netlink NEWADDR event (ie assigning an address to a network interface) triggers the one minute of rapid advertisements. Maybe something on your system is doing that regularly? Can you try adding a logging line next to the call to ra_start_unsolicited() in nl_async() in netlink.c, to see how often that gets called? OK, rebuilt dnsmasq with the patch to limit RTR-ADVERT out and a patch added to issue a syslog message when ra_start_unsolicted is done. It is installed on two systems which also run virtualization. They are both fairly new AMD-cpu systems and I have not had any problems with clocks. One virtual network started on each and no other dnsmasq instances. I do wonder if this rapid issuing also takes place with radvd but has never been noticed because it does not issue log messages. BTW, on a system which does not have virtualization installed (because it cannot run it) but does have dnsmasq doing its thing including DHCPv6, there are RTR-ADVERT messages about every eight minutes per interface. Have you ever felt really sick on a Friday but decided to wait until Monday to see a Doctor and then, On Monday, when you see the Doctor neither he nor you can find anything wrong. Well, I am not sure what was happening when I was getting all of those RTR-ADVERT messages but they appear to be normal now. 1. Only a few ra-unsolicited occurred. 2. Although they start out frequent it settles down to about once every none to ten minutes. 3. Starting another virtual network get the first one to get frequent again but, after a while, they both settle down to about nine minutes. 4. I have not noticed any stuff with the real (p33p1) NIC. Note: 1. During the last month or so there have been some system updates including the kernel. 2. Also over the last month or two I have been running leading edge development versions of libvirt and NetworkManager. Right now all I can do is let it run and keep an eye on it. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/29/2012 02:56 PM, Gene Czarcinski wrote: On 11/29/2012 02:08 PM, Gene Czarcinski wrote: On 11/29/2012 11:28 AM, Simon Kelley wrote: On 29/11/12 16:06, Gene Czarcinski wrote: Something is definitely not working correctly. I do not know if you have a qemu/kvm setup so duplicating the conditions that way will not work. Attached is a piece of syslog (before I patched things to suppress the messages). BTW, I also have no idea why anything is being done with p33p1 ... that is the real NIC on that system. I have also attached the dnsmasq conf file for that interface. I am willing to try any testing. Unless I can get things to work as they are suppose to, user reception of using dnsmasq to handle RA will get support somewhere between zero and none :-) Another theory: a netlink NEWADDR event (ie assigning an address to a network interface) triggers the one minute of rapid advertisements. Maybe something on your system is doing that regularly? Can you try adding a logging line next to the call to ra_start_unsolicited() in nl_async() in netlink.c, to see how often that gets called? OK, rebuilt dnsmasq with the patch to limit RTR-ADVERT out and a patch added to issue a syslog message when ra_start_unsolicted is done. It is installed on two systems which also run virtualization. They are both fairly new AMD-cpu systems and I have not had any problems with clocks. One virtual network started on each and no other dnsmasq instances. I do wonder if this rapid issuing also takes place with radvd but has never been noticed because it does not issue log messages. BTW, on a system which does not have virtualization installed (because it cannot run it) but does have dnsmasq doing its thing including DHCPv6, there are RTR-ADVERT messages about every eight minutes per interface. Have you ever felt really sick on a Friday but decided to wait until Monday to see a Doctor and then, On Monday, when you see the Doctor neither he nor you can find anything wrong. Well, I am not sure what was happening when I was getting all of those RTR-ADVERT messages but they appear to be normal now. 1. Only a few ra-unsolicited occurred. 2. Although they start out frequent it settles down to about once every none to ten minutes. 3. Starting another virtual network get the first one to get frequent again but, after a while, they both settle down to about nine minutes. 4. I have not noticed any stuff with the real (p33p1) NIC. Note: 1. During the last month or so there have been some system updates including the kernel. 2. Also over the last month or two I have been running leading edge development versions of libvirt and NetworkManager. Right now all I can do is let it run and keep an eye on it. I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 29/11/12 20:31, Gene Czarcinski wrote: I spoke too quickly. The cause of the problem is libvirt related but I am not sure what just yet. I was running a libvirt that had a lot of stuff on it but seemed to work OK. Then, earlier today I update to a point that appears to be somewhat beyond the leading edge and, although I was not getting any RTR-ADVERT messages, it turned out that there were/are big-time problems running qemu-kvm. So, back off/downgrade to the previous version. Qemu-kvm now works but the RTR-ADVERT messages are back. This may be a bit time-consuming to debug! Are you seeing the new log message in netlink.c? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 25/11/12 18:39, Gene Czarcinski wrote: On 11/25/2012 01:10 PM, Vladislav Grishenko wrote: Hi Gene, Instead of deprecating/turning-off logging by facility, it would be better to have ability to tune loglevel for each sysbsystem. Like following: where 0 means log-level=dhcp,dhcpv6,6,dns,7,ra,-1 Best Regards, Vladislav Grishenko Yes, that is indeed a good idea, I have no intention of deprecating logging but I also do not want a large amount of information-less clutter in the syslog which may hide something that is important. The RTR-ADVERT messages being issued every 3 to 5 seconds with separate messages for each virtual interface that is started is a bit much. But they're only that frequent for the first minute. After that they're every 10 minutes, I think. I have taken a look at the code and (I hope) I just do not understand how things are really working. If log-dhcp is specified (command line or conf-file), OPT_LOG_OPTS is set. A little grepping resulted in rfc3315.c and rfc2131.c as issuing messages with log6_packet() and log_packet() respectively. Sounds good, the test can be done in a central place. But, looking more closely, the only thing OPT_LOG_OPTS does is determine the form of the syslog message ... not if it is being issued. And, of course, there are other calls to my_syslog() scattered throughout. BTW, warning or at least error message should always be issued. It is all the info massages that are becoming overwhelming. Certainly there should be a lot of messages to support debugging and the code should always be compiled in. But, when things are working well it is better to have most of those messages inhibited so that some warning or error message will be seen. I see the RTR_ADVERT messages as being equivalent to the logs of DHCP request and replies - they are at a minimum level which allows tracking of the history of interaction with a client. The DHCP logs, at least have equivalents in most DHCP servers. It's important to know which prefixes are being advertised, since that's a function of quite a lot of configuration: not just dnsmasq config, but kernel-level interface configuration too. Cheers, Simon. 3. Similar to radvd, should there be some dnsmasq parameters which are used to specify how often RAs will be issued? There could be, but only if it makes sense to tune that for network performance, not just prettifying the logs. The philosophy in dnsmasq has always been to hide useless tuning settings and try and let people configure what they want to do, not control every field of every packet. I be no-one uses that option in radvd ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
Hi Gene, Instead of deprecating/turning-off logging by facility, it would be better to have ability to tune loglevel for each sysbsystem. Like following: where 0 means log-level=dhcp,dhcpv6,6,dns,7,ra,-1 Best Regards, Vladislav Grishenko ++ Recording or ignoring certain messages is the function of a syslog daemon. If people are annoyed by certain log messages, they can resolve that within syslog. Having said that, I agree that highly granular configurability of logging within dnsmasq would be useful, but setting loglevel by dnsmasq function (e.g. dhcp, dns, etc.) may not be the answer. As Gene said, errors and warnings should always be logged. Maybe the essence of the problem is simply that the loglevel for RA type messages is at an inappropriate level (e.g., is at notice (5) or info (6) loglevel when maybe it should be at debug (7) loglevel. I think that may be enough of a solution. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/26/2012 03:22 PM, John Brendler wrote: Hi Gene, Instead of deprecating/turning-off logging by facility, it would be better to have ability to tune loglevel for each sysbsystem. Like following: where 0 means log-level=dhcp,dhcpv6,6,dns,7,ra,-1 Best Regards, Vladislav Grishenko ++ Recording or ignoring certain messages is the function of a syslog daemon. If people are annoyed by certain log messages, they can resolve that within syslog. You are correct and most of the time too many messages is a matter of proper filtering. However, you need something to differentiate messages also. Having said that, I agree that highly granular configurability of logging within dnsmasq would be useful, but setting loglevel by dnsmasq function (e.g. dhcp, dns, etc.) may not be the answer. As Gene said, errors and warnings should always be logged. I believe that dnsmasq makes good use of WARNING, ERR, and CRIT messages but INFO amy be a bit overpopulated. When you are troubleshooting, there is no such thing as too many messages but I do believe that there needs to be a little more to differentiate all of the INFO messages. Maybe the essence of the problem is simply that the loglevel for RA type messages is at an inappropriate level (e.g., is at notice (5) or info (6) loglevel when maybe it should be at debug (7) loglevel. I think that may be enough of a solution. Now, as far as the RA related messages, the problem really boils down to the RTR-ADVERT messages and those should be LOG_DEBUG. Making that change would scratch my itch. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/26/2012 04:18 PM, Gene Czarcinski wrote: On 11/26/2012 03:22 PM, John Brendler wrote: Hi Gene, Instead of deprecating/turning-off logging by facility, it would be better to have ability to tune loglevel for each sysbsystem. Like following: where 0 means log-level=dhcp,dhcpv6,6,dns,7,ra,-1 Best Regards, Vladislav Grishenko ++ Recording or ignoring certain messages is the function of a syslog daemon. If people are annoyed by certain log messages, they can resolve that within syslog. You are correct and most of the time too many messages is a matter of proper filtering. However, you need something to differentiate messages also. Having said that, I agree that highly granular configurability of logging within dnsmasq would be useful, but setting loglevel by dnsmasq function (e.g. dhcp, dns, etc.) may not be the answer. As Gene said, errors and warnings should always be logged. I believe that dnsmasq makes good use of WARNING, ERR, and CRIT messages but INFO amy be a bit overpopulated. When you are troubleshooting, there is no such thing as too many messages but I do believe that there needs to be a little more to differentiate all of the INFO messages. Maybe the essence of the problem is simply that the loglevel for RA type messages is at an inappropriate level (e.g., is at notice (5) or info (6) loglevel when maybe it should be at debug (7) loglevel. I think that may be enough of a solution. Now, as far as the RA related messages, the problem really boils down to the RTR-ADVERT messages and those should be LOG_DEBUG. Making that change would scratch my itch. This is likely unnecessary but here is the patch. Gene diff -urp dnsmasq-2.64rc1-orig.1/src/radv.c dnsmasq-2.64rc1/src/radv.c --- dnsmasq-2.64rc1-orig.1/src/radv.c 2012-11-14 09:12:56.0 -0500 +++ dnsmasq-2.64rc1/src/radv.c 2012-11-26 16:30:16.352050345 -0500 @@ -420,7 +420,7 @@ static int add_prefixes(struct in6_addr opt-prefix = *local; inet_ntop(AF_INET6, local, daemon-addrbuff, ADDRSTRLEN); - my_syslog(MS_DHCP | LOG_INFO, RTR-ADVERT(%s) %s, param-if_name, daemon-addrbuff); + my_syslog(MS_DHCP | LOG_DEBUG, RTR-ADVERT(%s) %s, param-if_name, daemon-addrbuff); } } } ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/24/2012 11:20 AM, Gene Czarcinski wrote: OK, I am using both ra-only and enable-ra in a couple of libvirt dnsmasq instances. 1. I am getting a lot of clutter in syslog. How about using log-dhcp to also enable all of the RTR-ADVERT messages. There are a lot of them but they really provide little if any useful information. That is, add: if (option_bool(OPT_LOG_OPTS)) 2. I am getting a lot of RTR-ADVERT messages. I know it is suppose to start off frequently but then slow up to a much less frequent period (intervals of seconds). I thought this was a problem but then I looked into radvd and it also issues advertisements often so I assume things are working properly. However, I am concerned that all those syslog messages will lead others to suspect a problem where there is none. 3. Similar to radvd, should there be some dnsmasq parameters which are used to specify how often RAs will be issued? OK, I am going to slightly increase the scope of this. Simon, how receptive are you to adding a couple of new options to enable/disable some logging. 1. log-ra to enable RA logging which, by default, is disabled. This would be its own option and not related to log-dhcp. 2. log-dhcp-renew to enable the log messages about renewing DHCP requests which would, by default, be disabled. The messages from both of these currently run as if they were disabled. Since I am running/testing using dnsmasq's RA services, I first noticed all of the RA related messages and would like them to be normally suppressed. Apparently other libvirt users noticed the dhcp-renew messages and don't wish to see them either. If you are receptive, I will do the heavy lifting but I would like to see this in 2.64 if there is possibly enough time. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RA support in dnsmasq
On 11/25/2012 01:10 PM, Vladislav Grishenko wrote: Hi Gene, Instead of deprecating/turning-off logging by facility, it would be better to have ability to tune loglevel for each sysbsystem. Like following: where 0 means log-level=dhcp,dhcpv6,6,dns,7,ra,-1 Best Regards, Vladislav Grishenko Yes, that is indeed a good idea, I have no intention of deprecating logging but I also do not want a large amount of information-less clutter in the syslog which may hide something that is important. The RTR-ADVERT messages being issued every 3 to 5 seconds with separate messages for each virtual interface that is started is a bit much. I have taken a look at the code and (I hope) I just do not understand how things are really working. If log-dhcp is specified (command line or conf-file), OPT_LOG_OPTS is set. A little grepping resulted in rfc3315.c and rfc2131.c as issuing messages with log6_packet() and log_packet() respectively. Sounds good, the test can be done in a central place. But, looking more closely, the only thing OPT_LOG_OPTS does is determine the form of the syslog message ... not if it is being issued. And, of course, there are other calls to my_syslog() scattered throughout. BTW, warning or at least error message should always be issued. It is all the info massages that are becoming overwhelming. Certainly there should be a lot of messages to support debugging and the code should always be compiled in. But, when things are working well it is better to have most of those messages inhibited so that some warning or error message will be seen. Gene -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Gene Czarcinski Sent: Sunday, November 25, 2012 9:31 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] RA support in dnsmasq On 11/24/2012 11:20 AM, Gene Czarcinski wrote: OK, I am using both ra-only and enable-ra in a couple of libvirt dnsmasq instances. 1. I am getting a lot of clutter in syslog. How about using log-dhcp to also enable all of the RTR-ADVERT messages. There are a lot of them but they really provide little if any useful information. That is, add: if (option_bool(OPT_LOG_OPTS)) 2. I am getting a lot of RTR-ADVERT messages. I know it is suppose to start off frequently but then slow up to a much less frequent period (intervals of seconds). I thought this was a problem but then I looked into radvd and it also issues advertisements often so I assume things are working properly. However, I am concerned that all those syslog messages will lead others to suspect a problem where there is none. 3. Similar to radvd, should there be some dnsmasq parameters which are used to specify how often RAs will be issued? OK, I am going to slightly increase the scope of this. Simon, how receptive are you to adding a couple of new options to enable/disable some logging. 1. log-ra to enable RA logging which, by default, is disabled. This would be its own option and not related to log-dhcp. 2. log-dhcp-renew to enable the log messages about renewing DHCP requests which would, by default, be disabled. The messages from both of these currently run as if they were disabled. Since I am running/testing using dnsmasq's RA services, I first noticed all of the RA related messages and would like them to be normally suppressed. Apparently other libvirt users noticed the dhcp-renew messages and don't wish to see them either. If you are receptive, I will do the heavy lifting but I would like to see this in 2.64 if there is possibly enough time. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
