OIT Network Systems

OIT Wireless Service

OIT Wireless Service allows University faculty, staff, and students to connect a computer to the campus data network via a Wireless (radio) interface.

The service is available in nearly all University buildings on the main campus; see OIT's Wireless Coverage Map.

This document describes the service and provides information about how to connect to the service. It also explains how to register Wireless computers and interfaces in the Princeton University Host Database.

OIT Wireless Service is intended to be available only to devices registered in the Princeton University Host Database. A different service, Temporary Visitor Wireless Network Access (TVWNA), provides short-term Internet connectivity to unregistered wireless devices visiting the campus network.

Small portions of OIT Wireless Service (those areas using wireless network name puwireless2 rely on OIT Mobile IP Service. As such, use of IP on those parts of OIT Wireless Service rely upon the the procedures and requirements described in the OIT Mobile IP Service. OIT Mobile IP Service is one of the building blocks of OIT Wireless Service in those locations.

Despite its convenience and rapidly growing popularity, wireless service is very unlikely to provide you with with the same performance, consistency, or reliability as wired Ethernet service in the forseeable future. OIT's view is that wireless service complements wired service; it is not a substitute. It is best to view OIT Wireless Service as a convenience network, not the University's primary network service.

Some University departments and individuals choose to construct their own wireless networks (e.g. by attaching their own Wireless Access Points to the campus network). This document does not describe the operation of those private wireless networks; they do not operate the same as OIT Wireless Service. If you choose to use one of those private wireless networks, contact the department or individual responsible for operating it if you need information. (If you are constructing such a private wireless network, be sure to see Connecting a Private Wireless Access Point to the Campus Network.)

Contents

  1. Requirements
  2. Wireless Client Configuration
    1. Network Name (SSID)
    2. Encryption (WEP, WPA, WPA2)
    3. Authentication
    4. Roaming
  3. Wireless Client Hardware Requirements
    1. 802.11b and 802.11g
    2. 802.11a
    3. 802.11n
    4. 802.11ac
    5. Summary
  4. IP Service on puwireless
  5. IP Service on puwireless2
  6. Wireless (In)Security
  7. Wireless Reliablity and Performance
  8. Caveats
  9. Appendix: Why Are OIT Static IP Addresses Not Available on OIT Wireless Service?
  10. If You Need Additional Assistance
  11. Related Resources
  12. Announcements

Requirements

To be eligible for OIT Wireless Service, the device must meet the following requirements:

Because wireless networking technology is changing rapidly, and because of the special security challenges presented by wireless networking, it is possible these requirements will be revised in the future.


Wireless Client Configuration

Network Name (SSID)

All the OIT Wireless Access Points are configured to provide a wireless network with the network name: puwireless or puwireless2. (Almost all locations use puwireless, a very few must use puwireless2.) The network name is sometimes referred to as the SSID (Service Set Identity).

Any wireless client you wish to use with OIT Wireless Service should be configured to connect specifically to the network name puwireless (puwireless2 in a few locations).

We strongly advise against the alternative, of configuring your client to connect to "ANY" wireless network it finds; some client software may describe this as "using the broadcast SSID (Service Set Identity)." There are many private wireless networks throughout campus; allowing your device to try to connect to "ANY" network it overhears would cause your device to sometimes connect to some of them, instead of OIT Wireless Service. That will lead to a variety of difficulties for the wireless client. It will also cause your client to try sometimes to connect to puvisitor networks; attempting to do so will interfere with your device's ability to connect to the puwireless networks, as described below.

Be sure your device is not configured to try to connect to any wireless network with a name that starts with puvisitor. Those networks are part of Temporary Visitor Wireless Network Access (TVWNA). A device that tries to connect to TVWNA and is not permitted to connect (because it is not eligible for TVWNA) will be unable to connect to OIT Wireless Service for two minutes. If your device periodically retries to connect to TVWNA, it will keep preventing itself from connecting to OIT Wireless Service. So if your device was previously configured to connect to any puvisitor network(s) and still remembers those network(s), reconfigure your device to "forget" those network(s).

Encryption (WEP, WPA, WPA2)

Clients that can support Wired Equivalent Privacy (WEP) or Wireless Protected Access (WPA, WPA2) should disable these when connecting to OIT Wireless Service. (Some client software may call these settings "encryption.") OIT's service does not provide WEP, WPA, or WPA2.

Authentication

Clients that can support 802.1x authentication should disable this when connecting to OIT Wireless Service. OIT's service does not currently use 802.1x.

We use 802.11 "open" authentication, not 802.11 "shared" authentication.

Roaming

OIT Wireless Service service supports moving from one Wireless Access Point's coverage area to another overlapping coverage area without restarting the computer.

Reconfiguration of the computer is not required, except possibly when roaming between puwireless and puwireless2.


Wireless Client Hardware Requirements

Our service is intended to provide service to clients which support a number of the IEEE 802.11 standards.

802.11b and 802.11g

The basis of our service is the IEEE 802.11g standard, and our service includes backward compatibility for 802.11b. All locations where our service is installed support 802.11g and 802.11b clients. 802.11b and 802.11g services always operate in the 2.4 GHz frequency range.

Our 802.11b service supports data rates of 5.5 and 11 Mbps. Our 802.11g service supports data rates of 5.5, 6, 9, 11, 12, 18, 24, 36, 48, and 54 Mbps.

Our 802.11b and 802.11g services do not support data rates of 1 and 2 Mbps, because clients communicating so slowly (either due to poor signal or lack of support for 802.11b) would monopolize the available bandwidth, leaving little for faster clients.

We do not support clients that speak only the original version of IEEE 802.11 (no letter after the '11'). That's the specification that predated 802.11b, and also operated in the 2.4 GHz frequency range. Those clients only support data rates of 1 and 2 Mbps, neither of which we support.

Some vendors sold 802.11g equipment before that standard was finalized in November 2001; such equipment was based on earlier drafts of the standard. Some of these early 802.11g devices may experience compatibility problems both with 802.11b networks, and with other vendor's 802.11g devices. Some 802.11g devices that do not comply the final version of the 802.11g standard may even interfere with surrounding 802.11b networks. If you have an 802.11g device, contact the vendor for updates to bring it into full compliance with the final version of the 802.11g standard. If you have difficulty using an 802.11g device, a workaround may be to reconfigure it to limit itself to 802.11b.

802.11a

We began upgrading our service in 2010 to add support for IEEE 802.11a service. In locations that have been upgraded, in addition to the existing 802.11b and 802.11g service, we also provide 802.11a service. By September 2014 this upgrade had been completed in all of the undergraduate dormitory buildings, the Graduate College, Lawrence Apartments, and 63 academic and administrative buildings (including all of the largest or most-populated ones). During the 2014-2015 academic year we expect to upgrade additional academic/administrative buildings.

802.11a service operates solely in the 5 Ghz frequency range.

In those locations that have been upgraded, the 802.11a service makes use of channels throughout the set permitted in the 5 GHz range in our regulatory domain as of late 2010. (2010 was the year in which we began providing any service in the 5 GHz frequency range.) Those 5 GHz channels are: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 136, 140, 149, 153, 157, and 161. Clients with older 5 GHz wireless interfaces may support only a subset of those channels. As a result, such older wireless clients will not always be able to "hear" our 5 GHz service even in the areas where the service is available. We use many of the 5 GHz channels (instead of only the "lowest common denominator" set supported by the oldest 5 GHz clients) to allow us to provide the maximum bandwidth for modern 5 GHz clients. Older clients that can't hear the newer 5 GHz channels will still be able to use our 2.4 GHz services; the 2.4 GHz services remain available everywhere we provide wireless service; this is one reason that every client should continue to support 2.4 GHz.

802.11n

We began upgrading our service in 2010 to add support for IEEE 802.11n service. In locations that have been upgraded, in addition to the existing 802.11b and 802.11g service, we also provide 802.11n service. By September 2014 this upgrade had been completed in all of the undergraduate dormitory buildings, the Graduate College, Lawrence Apartments, and 63 academic and administrative buildings (including all of the largest or most-populated ones). During the 2014-2015 academic year we expect to upgrade additional academic/administrative buildings.

802.11n service operates in both the 2.4 Ghz frequency range (the same range used by 802.11b and 802.11g) and in the 5 Ghz frequency range (the same range used by 802.11a).

In those locations that have been upgraded, the 802.11n service in the 5 GHz frequency range makes use of channels throughout the set permitted in the 5 GHz range in our regulatory domain as of late 2010. (2010 was the year in which we began providing any service in the 5 GHz frequency range.) Those 5 GHz channels are: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 136, 140, 149, 153, 157, and 161. Clients with older 5 GHz wireless interfaces may support only a subset of those channels. As a result, such older 5 GHz wireless clients will not always be able to "hear" our 5 GHz service even in the areas where the service is available. We use many of the 5 GHz channels (instead of only the "lowest common denominator" set supported by the oldest 5 GHz clients) to allow us to provide the maximum bandwidth for modern 5 GHz clients. Older clients that can't hear the newer 5 GHz channels will still be able to use our 2.4 Ghz services; the 802.11b and 802.11g 2.4 GHz services remain available everywhere we provide wireless service, and the 802.11n 2.4 Ghz service is available in those locations upgraded to add 802.11n support. This is one reason that every client should continue to support 2.4 Ghz.

Most (if not all) 802.11n equipment available through mid-2012 is based upon drafts of the 802.11n specification, rather than the final published specification. Our 802.11n service is presently based on draft 2 of the IEEE 802.11n specification. It is possible the behavior of our 802.11n service will evolve as vendors release updates. You may find that you need to update your client's wireless software to work with (or continue to work with) our 802.11n service.

802.11ac

We began upgrading our service in 2014 to add support for IEEE 802.11ac service. In locations that have been upgraded, in addition to the existing 802.11b, 802.11g, and 802.11n service, we also provide 802.11ac service. By September 2014 this upgrade had been completed in four academic and administrative buildings and no other locations. During the 2014-2015 academic year we expect to upgrade additional academic/administrative buildings.

802.11ac service operates in the 5 Ghz frequency range (the same range used by 802.11a and one of the same ranges used by 802.11n).

In those locations that have been upgraded, the 802.11ac service makes use of channels throughout the set permitted in the 5 GHz range in our regulatory domain as of late 2010. (2010 was the year in which we began providing any service in the 5 GHz frequency range.) Those 5 GHz channels are: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 136, 140, 149, 153, 157, and 161. Clients with older 5 GHz wireless interfaces may support only a subset of those channels. As a result, such older 5 GHz wireless clients will not always be able to "hear" our 5 GHz service even in the areas where the service is available. We use many of the 5 GHz channels (instead of only the "lowest common denominator" set supported by the oldest 5 GHz clients) to allow us to provide the maximum bandwidth for modern 5 GHz clients. Older clients that can't hear the newer 5 GHz channels will still be able to use our 2.4 Ghz services; the 802.11b and 802.11g 2.4 GHz services remain available everywhere we provide wireless service, and the 802.11n 2.4 Ghz service is available in those locations upgraded to add 802.11n support. This is one reason that every client should continue to support 2.4 Ghz.

Summary

We emphasize that to be eligible for our service, the client must include support for IEEE 802.11b or 802.11g. (That also implies the client supports the 2.4 GHz frequency range, as 802.11b and 802.11g operate solely in that range.)

Examples of clients that do not meet our eligibility requirements include:

Clients that do not meet our eligibility requirements will be unable to "hear" our wireless services in most locations.

Our 802.11b and 802.11g services are available throughout our service area. Many of our locations have been upgraded to add support for 802.11a and 802.11n services, and a handful of locations have also been upgraded to add support for 802.11ac service. Those locations that have been upgraded should also support all 802.11n clients that operate in the 2.4 GHz frequency range; they will suport only 802.11n clients (and 802.11ac clients in those areas with 802.11ac support) that operate in the 5 GHz range and 802.11a clients only if the client supports all the 5 GHz range channels that were defined as of 2010.

Customers purchasing new equipment should prefer hardware that supports all five standards: 802.11b, 802.11g, 802.11a, 802.11n, and 802.11ac. Support for 802.11b or 802.11g is a necessity. Support for 802.11a and 802.11n is not an absolute necessity, but is highly desirable, because it will allow the client to automatically take advantage of our the newer services available in many campus locations. Support for 802.11ac is not a requirement, but will allow the client to automatically take advantage as more campus locations are upgraded in the future to support that service.

Clients that support multiple wireless standards usually require no special configuration to select a particular standard. Once you configure the device to try to connect to a particular network name (SSID), the device will usually look for that network name using all the frequency ranges and protocol standards supported by that device. For example, if the device supports the 802.11b, 802.11g, and 802.11n protocols in the 2.4 GHz frequency range, and supports the 802.11a, 802.11n, and 802.11ac protocols in the 5 GHz frequency range, the device may discover the requested network name is available in both frequency ranges. The device will automatically choose one of the frequency ranges; our service tries to steer such a device toward the 5 GHz frequency range if possible; such steering is not always possible. The device will select one of the protocols supported in that frequency range; usually the device will select the newest protocol.


IP Service on puwireless

In nearly all locations, OIT Wireless Service uses wireless network name puwireless. In those locations, OIT Wireless Service provides IP service to clients by relying on a NAT service.

It also relies on a specialized DHCP service (not OIT DHCP Service). It does not rely on OIT Mobile IP Service.

It also relies on a specialized DNS service (not OIT DNS Service).

Clients are leased dynamically-assigned private (RFC 1918) IP addresses using DHCP. That network is connected to the campus network via Network Address and Port Translator (NAPT, a.k.a. NAT) Routers. NAT is used to allow the large number of simultaneously-attached wireless clients to share a smaller pool of globally-routable IP addresses.

This is a change which took effect September 6 2012. (Prior to that date, IP Service on puwireless relied on OIT DHCP Service, OIT Mobile IP Service, and OIT DNS Service. There were no NAT Routers involved.)

Documentation describing the behavior of the IP service in these locations is not presently available.


IP Service on puwireless2

In a small number of areas, OIT Wireless Service uses wireless network name puwireless2. In those locations, OIT Wireless Service provides IP service to clients by relying upon OIT Mobile IP Service. Customer devices using OIT Wireless Service are always treated as visitors to the OIT Wireless Service network; this network is never treated as any client's home network. When attached to the network via OIT Wireless Service, your computer is assigned a temporary IP address and hostname via OIT DHCP Service.

To use OIT Wireless Service in these locations, your computer must follow the procedures and meet the requirements associated with OIT Mobile IP Service. OIT Wireless Service in these locations will not work for clients that do not meet those requirements, nor for Devices Blocked from OIT Mobile IP Service. In fact, when a device is declared ineligible for OIT Mobile IP Service as a result of a problem with its DHCP client software, the device often is also declared ineligible for wireless services provided by OIT, since our wireless services all rely on the client's DHCP software working properly.

In most cases, your Host Database entry's Wireless interface has been registered in the Host Database so that it is assigned an IP address on a subnet named wirelessnet. This IP subnet does not actually correspond to any real IP network on campus (neither wired nor wireless). The wirelessnet IP address assigned to your Wireless interface is simply a placeholder, and in fact your computer will never use that IP address. (Do not manually configure your wireless interface to use this IP address!)

Instead, when your Wireless interface is attached to the campus network via OIT Wireless Service in puwireless2 locations, it will be assigned an OIT Mobile IP Address on an IP subnet named vapornet2. We guarantee that this IP subnet is different than any network to which your Ethernet interface(s) may be attached.

OIT Mobile IP Camping rules don't apply to devices using OIT Wireless Service in puwireless2 locations; a device may visit OIT Wireless Service for as long as it wishes without being declared a Mobile IP Camper. (Of course, if the wireless interface visits some other network, it may indeed be declared a Mobile IP Camper on that network; this can happen if you you allow your wireless client to connect via wireless services other than OIT Wireless Service.)


Wireless (In)Security

It is extremely simple for someone to intercept traffic sent to or from your computer via wireless networking. Modification of the traffic is also possible.

Traffic sent to or from your computer via wired networking is also vulnerable, but interception typically requires a physical connection to a segment of the wired network across which your traffic flows. Obtaining such a connection can range from trivial to more difficult, depending on the wired network topology and infrastructure along the traffic path. Nevertheless, wireless is considered even less secure; the snooper/interloper may even be in another building across the street.

OIT Wireless Service does not use WEP ("Wired Equivalent Privacy"), a feature of 802.11 intended to provide some degree of security to data traversing the wireless (radio) portion of the network. WEP is unsuitable for use among a large community as it requires publishing "the password" to everyone who might wish to use the wireless network. (A secret which must be published to eight thousand people is no secret.) Since then, WEP's design itself has been demonstrated to be flawed; it is not secure.

OIT Wireless Service does not currently use WPA ("Wireless Protected Access"), a technology offered by many wireless vendors (it is not part of the approved 802.11 family of standards), or WPA2 (its successor). WPA was intended as a temporary replacement for WEP, designed to address many of WEP's flaws. (It was positioned as a temporary solution, until all existing wireless hardware and software is replaced with a new generation of equipment designed to support the 802.11i security standard.) It appears that if we were to deploy WPA (or WPA2) at this time, all clients that do not support WPA (or WPA2) would lose access to OIT Wireless Service. As many campus clients do not currently support WPA (or WPA2), we do not plan to deploy WPA (or WPA2) at this time. We expect to re-evaluate this stance in the future.

As you cannot rely on the network to prevent interception or modification of your data, if your data is sensitive, you would be prudent to take steps to ensure that anyone who might intercept your traffic would find it of little value, and steps that make it difficult for an interloper to modify your traffic in-transit. For example, instead of using applications that send and receive your data in the clear, use applications that use strong encryption before placing your data on the network. (E.g. avoid cleartext telnet, ftp, and rlogin; instead use ssh, scp/sftp, kerbererized telnet, kerberized ftp, or kerberized rlogin. When using ssh/scp/sftp, verify that the public key of the server to which you are connecting is legitimate. Do not send sensitive data to Web sites unless the Web site connection is using strong encryption and you verify that the Web site's public key is legitimate.)


Wireless Reliability and Performance

You should be aware that 802.11 wireless networking does not provide the same reliability and performance as wired Ethernet service.

In particular:

We list these caveats not to discourage you from using wireless service, but to help you set reasonable expectations of what wireless service can provide. As indicated above, despite its convenience and rapidly growing popularity, wireless service is very unlikely to provide you with with the same performance, consistency, or reliability as wired Ethernet service in the forseeable future. OIT's view is that wireless service complements wired service; it is not a substitute. It is best to view OIT Wireless Service as a convenience network, not the University's primary network service.


Caveats


Appendix: Why Are OIT Static IP Addresses Not Available on OIT Wireless Service?

This is an advanced topic, of interest to customers who desire static IP addresses when using OIT Wireless Service.

We do not provide OIT Static IP Addresses to devices connected via OIT Wireless Service. Instead, we provide dynamically-allocated private (RFC 1918) IP addresses behind a NAT to clients while they are connected to OIT Wireless Service in most locations (those locations where the wireless network name is puwireless). We provide OIT Mobile IP Addresses to clients while they are connected via OIT Wireless Service in a few locations (those locations where the wireless network name is puwireless).

From time to time, customers ask OIT to provide their devices with static IP addresses (or static globally-routable IP addresses) for use with OIT Wireless Service. We do not provide such IP addresses for a number of reasons:


If You Need Additional Assistance

If you have questions or need assistance with any of the procedures in this document, please contact the OIT Support and Operations Center.


Related Resources


Announcements


A service of OIT Network Systems
The Office of Information Technology,
Princeton University
Last Updated: August 15 2014