On Thu, 29 Sep 2005 14:37:05 -0400
Chris Smith <[EMAIL PROTECTED]> spake:
> On Thursday 29 September 2005 10:23 am, Bill wrote:
> > I am thinking pf on the dhcp server to those specific ip
> > addresses (wifi static ips) killing DHCP traffic. Since the AE
> > already has its own static IP and is set with dhcp info internally,
> > maybe it would decide its on its own and actually work like its set
> > up to
> >
> > Is this the best way to compensate?
>
> Sounds like a reasonable way.
>
> What gets me is why the wifi clients even see the DHCP server on the
> other side of the Airport - aren't they NATting, or at least routing? I
> thought you would need DHCPrelay to get through to the "main" server in
> this case. [disclaimer - I'm not an expert in this area]
The airports are not NAT'ing (we dont want them too), they are routing
I guess if you want to call it that.
> > Is there really a mysterious
> > DHCP signal that goes out and overrides stuff?
>
> Stuart mentioned "authoritative", which you can assign globally or to
> various sections (subnets, groups, etc).
> If the Airports are on a different subnet use a statement like this :
> ------------------------------------
> subnet 192.168.2.0 netmask 255.255.255.0 {
> not authoritative;
> }
> ------------------------------------
> in your conf. With no pool/range and a 'not authoritative' statement it
> shouldn't conflict with any authoritative DHCP servers on that subnet.
> But the DHCP server in the Airports probably don't have that kind of
> flexibility (maybe, to prevent rogue DHCP service, they turn off their
> DHCP servers and do DHCP relay automatically if they detect another
> server).
I have to do some more reading into authoratiative... It apparently
does a lot more than the man page lets on. but they are all on the
same subnet... phooey.
That is generally my feeling of what is going on. If i block it, then
they may give up on it.
> There may possibly be some other things that can be done with DHCPd v.3
> or better through vendor option space and substring detection, but the
> stock OpenBSD DHCPd, while most likely very secure, is lacking these
> features (very useful if you have to deal with Windows boxen).
I'd prefer to stick with the stock OpenBSD stuff when possible.
Well, in any case the plan for the next budget cycle is rethinking the
whole wifi plan for the campus. Right now its sort of legacy, add an
airport here, add a linksys here, add something else here... its a mess.
Thanks for the feedback!
> Chris
>
--
Bill Chmura
Director of Internet Technology
Explosivo ITG
Wolcott, CT
p: 860.621.8693
e: [EMAIL PROTECTED]
w. http://www.explosivo.com
