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.
Cheers,
Simon.
On 04/01/20
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 r
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 (dns
Hi All,
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 server.
The test steps are the following:
1.
Magic, thank you.
The fix, to a high level of confidence, is
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a90f09db4cc635941a32b973b57e58c662569625
and the problem involved querying for a SRV record for
_bookmarkdavs._tcp.p48-bookmarks.icloud.com
which returns NXDOMAIN, as it shoul
Hi,
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[2695]: DHCPSOLICIT(eth1)
00:01:00:01:23:c8:76:d7:00:50:56:bd:57:ed
Jan 9 01:57:20 dnsmasq-dhcp[2695]
On 09.01.19 08:14, john doe wrote:
On 1/8/2019 11:31 AM, smicha wrote:
Hi John,
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 infin