<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffcc">
You showed that your range also had 172.16.8.0 in it, that is valid
but may cause some clients to behave "funny".<br>
<br>
On 31/08/10 17:32, Simon Hobson wrote:
<blockquote cite="mid:p06240809c8a2cece9115@simon.thehobsons.co.uk"
type="cite">dorian wrote:
<br>
<br>
<blockquote type="cite">Aug 31 15:34:26 [dhcpd] DHCPDISCOVER from
00:23:6c:73:b3:29 (AMs-iPhone)
<br>
via br0
<br>
Aug 31 15:34:26 [dhcpd] DHCPOFFER on 172.16.221.214 to
00:23:6c:73:b3:29
<br>
(AMs-iPhone) via br0
<br>
Aug 31 15:34:33 [dhcpd] DHCPDISCOVER from 00:19:d2:97:ca:81
(N0336) via br0
<br>
Aug 31 15:34:33 [dhcpd] DHCPOFFER on 172.16.215.48 to
00:19:d2:97:ca:81
<br>
(N0336) via br0
<br>
Aug 31 15:34:34 [dhcpd] DHCPREQUEST for 192.168.1.101 from
<br>
00:23:6c:2b:08:eb via br0: wrong network.
<br>
Aug 31 15:34:34 [dhcpd] DHCPNAK on 192.168.1.101 to
00:23:6c:2b:08:eb
<br>
via br0
<br>
Aug 31 15:34:34 [dhcpd] DHCPDISCOVER from 00:23:6c:73:b3:29
(AMs-iPhone)
<br>
via br0
<br>
Aug 31 15:34:34 [dhcpd] DHCPOFFER on 172.16.221.214 to
00:23:6c:73:b3:29
<br>
(AMs-iPhone) via br0
<br>
...
<br>
so it is clearly visible that in case of the failure there is no
<br>
DHCPACK packets.
<br>
</blockquote>
<br>
Actually, that log snippet shows no such thing. There is only ONE
DHCP-Request, to which the server responds with a DHCP-Nack as the
requested address is not valid. There are no more Requests from
clients and hence there should be no more Acks to go with them.
<br>
What I do see are a number of DHCP-Offers which don't result in a
DHCP-Request from clients. You need to be looking at why this is
the case - are you sure there are no other (probably rogue)
servers on the subnet ?
<br>
<br>
<br>
<br>
<blockquote type="cite">2. the dhcpd.leases file size is the
reason (or is it the only reason)?
<br>
</blockquote>
<br>
No, it won't even be related to the problem - unless you are
running out of disk space or have other storage problems.
<br>
<br>
The leases file is a log file - the server only ever appends to
it, and during operations it never reads from it. It is only ever
read during startup when it reads each lease in turn and populates
it's internal tables. Even then, it does not (I assume) read the
file into memory - it just has to parse each lease as it munches
through the file.
<br>
<br>
To avoid the file growing ever larger, the server will
periodically clean up. It does this by writing out it's current
in-memory tables to a new leases file, and swapping it into place
by renaming the original file and then renaming the new file into
place.
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>