On 11/28/2012 03:31 PM, Simon Kelley 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.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,-1Best Regards, Vladislav GrishenkoYes, 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.
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 areused 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
