Hi,
the wireless itself is not the big problem, most of your devices (Mac) will be the problem (BTDTGNS). And my wild guess is that mobile phones will also be mostly iphones, plus some ipads.
ZyXEL has good WLAN controllers, as does LANCOM. Both have very good products for the money. No need - IMHO - to look into $isco.
As for the iOS problem, read on here:
http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address.html
#m
Hi
I personally feel more then devices what matters is topology in deployment.
I have used Cisco AP's and they are pretty much fine.
Ubnt - true used lot more for outside wifi deployment specially for point
to point (and multipoint links).
You need to do a bit of site survey to get idea of how many AP's you really
need. Remember it's open spectrum and running different bands from adjacent
AP's, you get really high capacity. With more AP's you can eventually
re-use lot of spectrum running them at low power till an extent it doesn't
effect coverage.
Hope that will help.
a WLAN controller will help you detect rogue APs, rescan the area and also changing frequencies/channels in use (depending on configuration, etc.).
but this will not replace a site survey. 
and it will not prevent you from having Macs on your network.
#m
As for the iOS problem, read on here:
http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address.html
That's the iOS issue - out of curiosity, what's the Mac issue?
Regards,
Tim.
That's a poorly maintained device issue. The good news is the DHCP requests for those devices (if you log them) commonly include information about the device owner, e.g.:
Jan 15 16:56:35 nat dhcpd[1046]: DHCPACK on 10.0.0.168 to 18:e7:f4:5c:b1:d7 (MATTS-IPOD-3) via eth0
or
client-hostname "iPhone-Touch";
client-hostname "Her-iPod";
client-hostname "iPad";
client-hostname "Amys-iPod";
Also, citing a single software release with a defect can be done for any platform.
http://support.microsoft.com/kb/928233
These issues are commonly solved by upgrading to the most recent release of software. Reading the princeton article says setting your lease time to 3600 seconds seems to workaround the problem from the network side. I'm personally not convinced of the value of very short lease times (less than an hour). Even IPv6 privacy addresses stay around longer than that.
MacOS Kernel (11.2.0)
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
Linux Kernel (3.1.1)
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.default.temp_valid_lft = 604800
net.ipv6.conf.default.temp_prefered_lft = 86400
FreeBSD 9.0-RELEASE (GENERIC)
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
- Jared
Less than an hour, perhaps not.
On small residential networks, though -- generally, anything where the
router (which will need to get rebooted occasionally) *is* the DHCP server --
I tend to set the timeout to 30-60 minutes, to reduce the race window between
when a router is rebooted, and when a new device shows up and conflicts
because it's given an IP another device still thinks it owns.
Cheers,
-- jra
Jay Ashworth <jra@baylink.com> writes:
From: "Jared Mauch" <jared@puck.nether.net>
network side. I'm personally not convinced of the value of very short
lease times (less than an hour)Less than an hour, perhaps not.
On small residential networks, though -- generally, anything where the
router (which will need to get rebooted occasionally) *is* the DHCP server --
I tend to set the timeout to 30-60 minutes, to reduce the race window between
when a router is rebooted, and when a new device shows up and conflicts
because it's given an IP another device still thinks it owns.
Another thing that works (in environments where you can get away with
it) is an enormous dhcp pool and super long leases with
walking-the-whole-space behavior and persistent-across-reboots
behavior on the part of the DHCP server.
The built-in server on the Mikrotik platforms will do this.
Configuring a /16 worth of 1918 space with a 3 week lease for a
campground that typically hosts 1 week long events has handily dodged
the issue for me. Admittedly this is a corner case...
-r