On 09.01.19 08:14, john doe wrote:
On 1/8/2019 11:31 AM, smicha wrote:
thanks for your reply.
I did some tests with your hints.
On 7.1.2019 17:41, john doe wrote:
Some hints from dnsmasq.conf:
# Give the machine which says its name is "bert" IP address
# 192.168.0.70 and an
Its a very simple topology, I have tried to recreate the entire setup on a
different test bed. I still see the same issue:
root@Ubuntu4242:~# tail -f /tmp/dnsmasq
Jan 9 01:57:20 dnsmasq-dhcp: DHCPSOLICIT(eth1)
Jan 9 01:57:20
I have performed several test and already have opened one thread about this
issue. I have seen unexpected behavior on android when DHCPv4 client tries to
reuse a previously allocated network address and this address is unavailable on
The test steps are the following:
On 04/01/2019 06:25, Sandeep K M wrote:
> Hi Simon,
> Thanks a lot for your prompt reply.
> Attached are the packet captures:
> 1. Packets exchanged between client and relay (client-relay.pcap)
> 2. Packets exchanged between relay and server (relay-server.pcap)
> 3. strace of dnsmasq
Magic, thank you.
The fix, to a high level of confidence, is
and the problem involved querying for a SRV record for
which returns NXDOMAIN, as it
My guess is that the two copies of dnsmasq that are configured to do
DHCP are using the same leases file, which is an all-bets-are-off
situation. Using the --dhcp-leasefile option to give them separate files
will at least give you a chance of making your config work.
RFC1531 is twice obsoleted. The current definition of DHCP is RFC2131,
which says, in para 3.2.
The client times out and retransmits the DHCPREQUEST message if
the client receives neither a DHCPACK nor a DHCPNAK message. The
client retransmits the DHCPREQUEST according to the