[bsdcan-volunteers] the wireless network

[Dan Langille]

Nate Montague wrote:

> So Dan, do you know the answers to any of these?  How about any of the
> bsdcan-volunteers?

Does this answer much?  It was written by David Maxwell who ran the 
wireless for 2006.

Network setup information for BSDCan
====================================

Wireless configuration principles
=================================

Why these details aren't documented on the net somewhere I don't know
but this information is partly from trial and error and partly from
advice from Bob Beck.

Hosts will roam between APs provided that the SSID does not change.
Existing connections will silently break if IP addresses change, and
applications don't recover well.

Configure the wireless network as follows:

APs in bridge mode, not serving DHCP, with a statically assigned
management IP.  AP should be assigned channel 1, 6, or 11, with channel
selections such that APs located closest to each other are on different
channels.
	I.e. if all the AP locations were in a straight-line, assign 1,
	6, 11, 1, 6, 11 (repeat) if the APs were in rooms on alternate
	sides of a corridor, assign 1 (top), 6 (bottom), 11 (top),
	1(bottom), 6 (top) etc.  if the rooms are very small and close
	together, see if it's possible to cover to rooms with one AP,
	since higher AP density might be a lose if there's too much
	crosstalk.

	NOTE: also test for the presence of third-party APs, such as the
	university's network, and attempt to incorporate those in the
	channel selection design.

Notes on APs
============

The most stable APs  to date have been BSD laptops with 200mw cards and
high gain antennas.  Higher-end embedded BSD platforms have also worked
well.

WRAP 2 boards from NetGate, running Monowall crashed frequently -
unknown whether hardware or software was at fault.

Linksys APs seem to work 'well enough' during the main conference, but
people have complained that they provide intermittent conductivity when
the number of users is high.  (Especially in the FreeBSD DEV Summit) the
Linksys APs seem to do better in bridging mode than NAT/AP mode,
presumably due to lower overhead.

If I'm remembering correctly the Linksys APs have a quirk that's good to
be aware of. When using a linksys in NAT/AP mode, connect the network to
the uplink port. When using a Linksys in bridge mode, connect the
network to one of the four hub ports.

Backend server
==============

For a backend server configure a BSD host with NA(P)T, and a DHCP
server.  Due to high network utilization, configure the NA(P)T for at
least 10 to 20 times the default number of state entries, in order to
not break connections due to full state tables.

Configure the AP facing interface with a subnet larger than a single C
class network.

Since the backend server will been NA(P)Ting all the traffic from the AP
flat bridged network VLAN to the university provided conductivity VLAN,
it requires at least two ethernet ports and must be located near two
ethernet wall jacks.  Know the MAC addresses for the two interfaces to
make sure the university configures the correct VLAN on the correct
port.

Since the backend server is a single point of failure, having an easy to
maintain configuration such as a permanent keyboard and monitor, and a
location accessible to the network operator is highly desirable.

Wired ports
===========

In the classrooms there are two ethernet jacks available, one inside the
podium and one on top of the podium.  To access the Jack in the podium
you will need the university AV representative to card swipe the podium
to unlock it.  It is best to leave the Jack on top of the podium
available for presenters to plug in a laptop.  If the Jack is
malfunctioning, use a switch to allow the working Jack to serve the AP
and a presenter.

The university no longer provides wired ports in the upper mezzanine,
they have been removed.

A switch is also appreciated at the front of the room for the FreeBSD
DEV Summit, since some developers will not have working wireless cards.

University logistics
====================

While it is worth sending an e-mail to university IT services in
advance, in the past they have been unresponsive until the day of the
conference, and it has never been possible to do any configuration in
advance of the evening before the conference.

Since the conference rooms are in use for other classes at times, IT
staff will not have configured the ports in advance.  On the morning of
the conference you can expect one or all of the network jacks to be
incorrectly configured.  The university wires all jacks to a VLAN
capable switch and manually moves ports onto the desired VLAN at event
start time.

If ping testing on a port fails, leave a device attached to the port,
and call IT services and provide its MAC address and Jack number.  IT
services can use the MAC to identify which port the Jack actually
belongs to, and then move it to the correct VLAN.

In 2006, the university offered to house the server in a machine room at
the north end of the large glass walled computer lab.  However the
computer lab is not staffed on the weekend, and access to that machine
room would require a call to someone off-site and a delay for them to
get to the site, which was considered unacceptable.  The machine room
house the server during weekdays, and was then moved to a classroom on
Friday night.  The classroom had a swipe cardlock, and cards were
provided to select BSDCan staff. The classroom was down the hall to the
north from the computer lab.  The classroom had other classes on during
the week, so housing the server they are for the entire duration of the
conference was not possible either.  Naturally the server relocation
also required coordination with university IT staff to assign the ports
in the classroom to the appropriate VLANs to allow the server to
function in its new location.



-- 
Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/