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
