Wireless+Networking

Why hasn't the system been working?
> Wireless-capable smartphones and devices like the iPod touch are frustrating to manage--each LAN in BCPA only has a certain number of IP addresses, and non-BCPS wireless devices can quickly fill up the scope, resulting in invalid IP addresses 169.254.#.# and "IP Address conflict with another system" messages. At the moment, it seems non-BCPS wireless devices' MAC addresses must be manually denied connections to the network, rather than requiring all devices to authenticate (//tried at beginning of 2008-2009 school year?//). > > During the summer (2009), BCPS Networking is going to subdivide each school's DCHP, creating two LANS--one for wired communication, and one for wireless. This means that wired networking should work brilliantly, at least. It may mean that some form of authentication will be put back into place for wireless networking, and/or that a new image will be released in September 2009 which will better manage simultaneously wired and wireless devices (a.k.a. teacher laptops). Let the crossing of the fingers begin.
 * **DHCP Scope, separate VLAN needed for wireless**

> A clever solution to wireless frustrations was to purchase a router--or bring in an old one from home. //Unfortunately, because of the way that IP addresses are assigned on our network, these non-BCPS network devices cause the wired network to be very unstable--they give out fake IPs (169.254.#.#) faster than our network can assign real ones (10.6.108-111.#). Your computer's impatient.// Leave your home devices at home, for overall network stability--and several other reasons... > 01/21/09 - [|Email Appeal]: //devices may be smashed, users also...// > 01/23/09 - see BCPS [|Superintendent's Bulletin], #474: //What's mine is mine and what's yours is...also mine// >
 * **Invalid IP Addresses: Rogue Wireless contribution**


 * **Meru Virtual Cell** didn't work when multiple __models__ of Access Points (APs) - the connections in the ceilings of many classrooms which allow laptops to connect to the school's network. //This was a known problem, but the company __believed__ that it would not be a problem, as long as [|Virtual Cell]was "turned off." They have since determined otherwise. A newer model controller and a software update are required when more than one model of AP exist on the same controller. An alternate solution would be to add another controller, and move all __new__ APs to the __new__ controller. This is also expensive and involves licensing, IP address issues, etc.//

> Certain versions of the Baltimore County Public Schools image attempted to connect __both__ the wired ethernet __and__ the wireless to the same IP address. This should never happen. Unless you are currently running image 6.9.5 or higher (//you can tell when you computer first boots--there's a BCPS screen that has the image number in the upper-right-hand corner),// your laptop's networking may or may not work properly if __both__ the wired and the wireless are trying to get an IP address. > > Try turning the wireless network switch on the left edge of your laptop off. > > //In Electrical diagrams, a **O** signifies a broken circuit--off--and a line **|** is on...push the switch towards the back of the laptop to disable the wireless network adapter (turn it off). If you want to turn the wireless back on, just pull the switch towards the front edge--it doesn't click into place (will slide towards the middle). You should notice the green "WiFi" light turn on (below the LCD screen, to the right of the Power light).//
 * **Invalid IP Addresses, Image issues**

> Because of the materials used to construct hallway ceramic tiles (//possibly recycled spacecraft heat-shielding)//, and floors (//lead joists?//), wireless signals don't spread as gracefully throughout the building as originally believed. Meru AP150s have especially limited range (80-100 feet max). A combination of upgrading AP150s to AP311s, moving existing devices, etc. was necessary to provide decent wireless connectivity building-wide. The best way to determine if networking frustrations are due to coverage is to use [|wireless survey software] to create a [|coverage map].
 * **Inadequate wireless coverage**

Play-By-Play
05/20/09 - DHCP scopes full, multiple-VLAN solution needed (//long-term [2 summers] BCPS Networking project)// 05/13/09 - basic math + inventory = not enough IP addresses, TSS Ticket #13223 05/06/09 - new controller installed 05/04/09 - DHCP scopes OK? TSS Ticket #12489 closed 03/09/09 - loaner installed!! Testing, testing... 03/08/09 - controller not scheduled to arrive until 03/23/09... 03/05/09 - not yet arrived, company PM will inquire and return call 02/25/09 - controller damaged in transit, replacement should arrive week of 03/02/09... 02/18/09 - PO # assigned (//BCPS Purchasing//), controller ordered, company Projector Manager will call to schedule installation 02/12/09 - quote, PO submitted, controller to be ordered 01/30/09 - checkup with subcontractor (//...our wireless network is missing [|this component])// 01/20/09 - TSS: Rogue Wireless contribution explained (169.254.#.# addresses given out by rogue wireless routers) 01/15/09 - Fusion Networking installed 7 new Access Points, ran cabling 01/13/09 - Decision to break-up installation scheduled for 01/15/09, to order new Network Controller, and test the solution 01/13/09 - Meru Engineer: solution to AP conflict has been found 01/08/09 - installation request and directions forwarded to Networking subcontractor 01/08/09 - PO approved, # assigned, forwarded to Networking subcontractor 01/05/09 - Approved by Principal, bookkeeper sent PO for County approval 01/04/09 - Networking subcontractor sent quote 12/23/08 - solution finally narrowed down to network system hardware conflict