Thank you Simon for the explanation, that makes sense.
I did try manually adding the LAN IP to the interface visible from within
the container via "ip address add 192.168.1.2/24 dev eth0". That eliminates
the error message, and so I assume an offer was made, but the offer was not
received by the
This is obviously a large amount of work, so thanks very much for that.
To make use of it, I need to be able to see as clearly as possible what
is being changed, and why. To that end, I'd much rather have diff files
ten replacement files, but it's fairly easy to generate those for
myself. Having
I can't answer your question about if this has been fixed, as there's
not enough information to identify the problem or trigger the bug.
Can you provide proof-concept code, or even just packet captures of the
malformed packets that cause problems?
I've confused by the "dhcp to be unresponsive
On 13/12/2018 14:10, Craig Younkins wrote:
> First, thank you for dnsmasq!
>
> I'm among a number of people[1][2][3][4] having trouble using dnsmasq
> for DHCP when it is running in a docker container. Everyone seems to get
> "no address range available for DHCP request via eth0" in their log
>
Thanks both for this. Petr's more comprehensive patch is now in my tree.
Cheers,
Simon.
On 15/12/2018 09:43, Kevin Darbyshire-Bryant wrote:
>
>
>> On 14 Dec 2018, at 16:10, Petr Mensik wrote:
>>
>> Hi Kevin et al,
>>
>> sure, your fix is correct one. I just found one more place where
Ooops. My hand's up for that one. Patch applied. Thanks.
Cheers,
Simon.
On 12/12/2018 12:00, Kevin Darbyshire-Bryant wrote:
> Hi Simon,
>
> Another one fallen out of the openwrt tree shake :-)
>
> ipv6 ipset addresses weren’t being set correctly. patch attached
>
>
>
> Cheers,
>
>
On Thu, Dec 13, 2018 at 09:10:59AM -0500, Craig Younkins wrote:
> First, thank you for dnsmasq!
>
> I'm among a number of people[1][2][3][4] having trouble using dnsmasq for
> DHCP when it is running in a docker container. Everyone seems to get "no
> address range available for DHCP request via
