[Dnsmasq-discuss] interface+macvlan on same network confuses dnsmasq v2.66rc2

Simon Kelley simon at thekelleys.org.uk
Thu Nov 7 11:41:33 GMT 2013


On 05/11/13 08:52, Gui Iribarren wrote:
> On 10/22/2013 08:20 PM, Simon Kelley wrote:
>> On 22/10/13 17:17, Gui Iribarren wrote:
>>> On 10/22/2013 05:45 PM, Simon Kelley wrote:
>>>> On 21/10/13 20:31, Gui Iribarren wrote:
>>>>> Hello Simon!
>>>
>
>>> Then, do you think there's any chance of getting that arp trick point to
>>> 'anygw'?
>>
>> Yes, depending on the results of the dhcp-broadcast thing.
>
> Indeed, setting dhcp-broadcast solved (workarounded?) the issue :D

OK, that's good.
>
> i'll do some tcpdumps, and you mentioned you'd be interested in "arp"
> output, anything else?

Another experiment: Please try applying the attached patch, and see if 
that makes things work _without_ dhcp-broadcast.

Explanation: the extra code explicitly tells the kernel which interface 
to send the reply packet on, in the same was it does in the broadcast 
case, rather than letting the kernel deduce it from the destination.

I guess this will work, in which case I'll be in a dilemma, since I'm 
not confident it will never break thing in other cases.



Cheers,

Simon.

>
> cheers!
>
>>>
>>> i'll try dhcp-broadcast later today
>>> what would be the downsides / cons of having dhcp-broadcast permanently
>>> enabled? maybe some broken clients?
>>
>> Just a bit more load on clients from the broadcasts. Unless your network
>> is HUGE, I doubt it's noticable.
>>
>> Cheers,
>>
>> Simon.
>>
>>>
>>> thanks a lot!
>>>
>>> gui
>>>
>>>> For an unconfigured
>>>> client (ie doing DHCPDISCOVER) dnsmasq ends up knowing the MAC address
>>>> of the client and its IP address, but the client _doesn't_ know that IP
>>>> address, and so can't respond to a ARP request. To get round this,
>>>> dnsmasq populates the ARP table on the server directly with the IP
>>>> address, MAC address and interface. Then it send the OFFER packet to
>>>> the
>>>> IP address and the kernel knows how to route it. I think that you
>>>> "interesting" setup may be confusing this process. In the second
>>>> instance, I suspect that the crucial thing that makes it work is not
>>>> the
>>>> presence of a lease in the lease-file, but a correct ARP-table entry
>>>> from the previous activity.
>>>>
>>>> Certainly, a few more experiments, and looking at the output of
>>>>
>>>> arp -a
>>>>
>>>> would be instructive.
>>>>
>>>>
>>>> Looking again - there are more clues:
>>>>
>>>> ### the OFFER it's sending is a funny mix:
>>>> ### it is sent *from* br-lan MAC and IP (192.168.11.129)
>>>>
>>>> That may be the MAC address thing I talked about, or it may be
>>>> something
>>>> else. Another experiment: try setting
>>>>
>>>> --dhcp-broadcast
>>>>
>>>> and see what happens then.
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Simon
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Simon.
>>>>
>>>> _______________________________________________
>>>> Dnsmasq-discuss mailing list
>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>>
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20131107/d6540bf1/attachment.ksh>


More information about the Dnsmasq-discuss mailing list