[ previous ] [ next ] [ threads ]
 
 From:  "David Burgess" <apt dot get at gmail dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] dhcp server problem
 Date:  Fri, 23 Feb 2007 16:05:35 -0700
On 2/23/07, Lee Sharp <leesharp at hal dash pc dot org> wrote:
>
> David Burgess wrote:
> > So an occasional client has a problem obtaining an IP address from our
> > m0n0wall dhcp server. I've searched the archives and my problem appears
> to
> > be unique in some respects.
> >
> > Configuration:
> > m0n0wall version 1.3b1, built Dec 16
> > 1.6 GHz cpu
> > 512 MB ram
> > reported memory usage: 16%
> > LAN: nvidia Gbit (nve0) 100baseTX full duplex
> > WAN: intel pro 1000GT (em0) 100baseTX full duplex
> >
> > Problem:
> > We have ~190 client machines/home routers on our m0n0wall lan and from
> time
> > to time a client will not be able to get a dhcp lease from the m0n0wall.
> I
> > can verify that this has occurred with at least one WinXP client and
> more
> > than one WRT54G client. In all known instances the client is not new,
> and
> > formerly received an IP address from the m0n0wall dhcp server.
> >
> > Successful workarounds:
> > -In some cases multiple attempts to renew over a few hours are
> eventually
> > successful. No known explanation.
> > -Giving the client a valid static IP address resolves the issue and
> > restores
> > client access to network
> >
> > Supplementary information:
> > -Not seeing any cores in /etc or /usr/local/captiveportal
> > -Not seeing any messages indicating that any log, file system or device
> is
> > full
> > -Unsuccessful attempts to renew a client's IP address do not create any
> > entries in the dhcp log
> > -Problem occurs to clients both with and without entries in the dhcp
> > server's static mapping table
> >
> > Any insight? If I need to post content from status.php, please name
> > specific
> > sections, as some of these sections are hugely long and probably not
> > relevant, I'm guessing, such as "ipnat -lv".
>
> The few times I have seen this have been ARP table screwups.  This can
> be very common with wireless as clients move from switch (AP) to switch.
>   I would start by segmenting the network.  If you can, divide wireless
> and wired.
>
>                         Lee




Hm. Our entire network is wireless with multiple access points connected
wirelessly. The only situation I can think of that would fit your
explanation is when a client moves from one AP to another, which happens
occasionally. Would that cause the problem?

If so, then what is the solution? Is there some way to flush the ARP table,
or manually update an ARP entry from either the router or the client side?

Thanks.
db