[Dnsmasq-discuss] dropped dhcp6 packet logging revisited

[Simon Kelley]

On 23/10/12 17:32, Gene Czarcinski wrote:
> The thread was getting way too long so I have started a new one.
>
>> Simon, now that I have given it some thought, dhcp6_packet() should
>> never see any dhcpv6 packets except those which it should see. If it
>> does see a packet which it must drop, that implies things are not
>> configured properly.
>>
>> For example, if I specify a network in --dhcp-range which happens to be
>> on eth0 and then put eth0 in one of the exclude lists, something is
>> wrong.
>>
>> If --interface and/or --bind-interfaces were not specified and the
>> device name associated dhcpv6 packet does not match the device name
>> associated with a --dhcp-range that was specified, this is an error.
>>
>> It might be appropriate to add my_syslog() warnings when such things
>> occur.
>>
>> Comments?
>>
>
>>
>> If I understand you correctly the logging code is there already:
>>
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/rfc3315.c;h=9297d52bbd5d13f63810f67b2114704c7b2e9d11;hb=HEAD#l107
>>
>
> I looked over the code and I believe we are mis-communicating.
>
> What you pointed to is involved with the dhcp6_reply().
>
> In dhcp6.c/dhcp6_packet(), there are a number of tests performed which
> can result in a return way before you get to doing dhcp6_reply().
>
> First, let me assume that there are multiple instances of dnsmasq
> running with each on a separate interface/ip6-subnet. Also, none of
> these were started with interface= specified so, therefore,
> bind-interfaces is meaningless.
>
> I also assume that a received dhcp6 packet is sent to only one instance
> ... in the absence of any other information, this could be any of the
> dnsmasq instances, but it will be only one.
>
> If a packet is passed to one of the dnsmasq instances but should really
> have gone to another instance, then that first instance should return
> before processing (one or more of the tests would determine that the
> packet was not for that instance) and the packet will be
> ignored/dropped. It is these events I would like to see logged.
>
> Now, such logging could produce many messages to syslog. If such logging
> is added, then perhaps there should be some special dnsmasq parameter
> that has to be specified.
>
> I am going to add some code to do such logging because it seems I need
> some proof that the problem exists. I have no idea why, but there
> appears to be reluctance on the part of the libvirt developers to accept
> adding the interface= parameter to dnsmasq. I believe that, even with my
> limited testing, I have seen the problem occur.
>


By all means instrument the code to chase this issue. In general, these 
log messages would not be useful: it's not an error to be dropping these 
packets.

As an example, the production configuration I use on my main server has

--dhcp-except=<interface connected to my cablemodem>

That will be throwing away all the DHCP interactions between the client 
on the server and my cable-providers infrastructure, and any broadcast 
interactions with other subscribers on the same network segment. I don't 
want to see those, I don't want log-spam about them, and I certainly 
don't want dnsmasq replying to them.


Cheers,

Simon.