To recap the setup:

Earth Sciences Room

2x Linksys WRT54G wireless routers, one acting as gateway / DHCP server / NAT server

Observatory Meeting Room

1xBelkin wireless router

Lecture Theatre

3x Linksys WRT54G - channels 1, 5, 13 ESSID 'interop'

I tried to spread the boxes out physically as much as possible, one at the front of the Lecture Theatre in the centre and the other two on either side of the room

Day 1

1 unit acting as Gateway providing NAT and DHCP services on 192.168.3.* in the range 192.168.3.100-250 for the 3 boxes in the Lecture Theatre

Day 2

Same as day one, but in addition providing services for the box in the Hoyle Committee Room too once I'd realised I could request the required ports to be patched through to each other (The sysadmins were very helpful at the IoA which made the whole job a lot easier - big thanks to Sue and Hardip who were onsite and also to Andy for his help beforehand)

Hoyle Committee Room

next door to the Lecture Theatre so wireless range overlap

1x Belkin wireless router - channel 9 ESSID 'interop'

Day 1

Router acting as Gateway providing NAT and DHCP services on 192.168.3.* in the range 192.168.3.5-99 (although initially in the range 192.168.3.2-99 which I think caused IP duplication issues with the Lecture Theatre next door (192.168.3.2 & 3 were IP addresses of the non-DHCP providing boxes)) on ESSID interop

Day 2

See Day 2 in Lecture Theatre above

Issues

Coverage in Earth Sciences seemed OK from anecdotal evidence, if anyone attending any of the sessions in this room could confirm or deny this along with rough numbers of attendees at the time it would be good. Ditto for the Observatory Meeting Room

The main building - ie Lecture Theatre, Committee Room plus foyer was more problematical. On the first day, apart from the initial duplicate IP issue which may have been caused by the slight overlap in IP addresses with the committee room next door the main problem in the Lecture Theatre seemed to be obtaining an IP address. Once this had happened, performance was OK, anecdotally, can anyone confirm or deny this? I wasn't sure if this might be because of client latops switching between the WAPs in the Lecture Theatre and the one next door. To test this, on the second day I added the WAP in the committee room to the subnet next door. I didn't hear of any IP address issues (again, let me know if you noticed any) but the same problem of getting an IP address was there. On both days the connection did drop sporadically to some clients (but not all at the same time - anyone?)

"Next Time"

Looking at the allocated DHCP list on the web interface of the showed a maximum of ~40 IP addresses at any one time that I managed to see. Refreshing this page every few seconds showed different IP addresses so I'm not sure whether the box could handle >40 or just not display them. Either way, it wasn't coping with something. One suggestion made by KeithNoddle^? was to configure all 4 boxes as DHCP servers allocating non-overlapping IP addresses, something like:

Box 1: 192.168.3.1 - allocates 192.168.3.5-55

Box 2: 192.168.3.2 - allocates 192.168.3.56-106

Box 3: 192.168.3.3 - allocates 192.168.3.107-157

Box 4: 192.168.3.4 - allocates 192.168.3.158-208

Note that only one of the boxes would be acting as gateway, the others would just be using their switched ports and not their "internet" ports. Another thing to note is that we now have (as we did at the time of the conference) potentially 4 x 54Mb/s = 216Mb/s of traffic going into a 100Mb/s network connection.

I'd be more inclined to stop the WAPs doing anything other than supply wireless and patch them through to a dedicated NAT / DHCP / Firewall machine which did as much work as possible, leaving the WAPs to concentrate on what they're supposedly good at. If we're going to provide a wireless service for future events in other venues (I suspect not, but who knows...) and could have the co-operation of the local sysadmins then a small form factor server (or possibly even a laptop with two gigabit ethernet ports) plus a gigabit switch would be the route I would choose. In retrospect I wonder if we would have been better simply patching our 802.11g WAPs through to the existing wireless gateway machine at the IoA, just replacing the 2 802.11b WAPs which are currently used. However, I don't know the spec of that machine so this may not be feasible for ~120 people. I'd also log network traffic - we had a security alert from the main Cambridge Uni network people, which wasn't traceable as the main WAP didn't have logging enabled and was turned off overnight, wiping all logs from RAM.

-- GaryGilchrist - 01 Oct 2007