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
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]
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 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.
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
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
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