OIT Temporary Visitor Wireless Network Access (TVWNA, pronounced "tuna") provides short-term Internet connectivity to wireless devices brought by visitors to Princeton University.
The service is available in nearly all University buildings on the main campus; see OIT's Wireless Coverage Map.
TVWNA is intended to provide service to wireless devices belonging to short-term visitors. It provides service to a device on up to seven days within a calendar month. TVWNA is not intended to provide service to devices belonging to Princeton University faculty, staff, and students, or to longer-term visitors. It does not provide service to wired-only devices.
TVNWA should not be confused with Visitor IP (VIP) Service, a different service that provides Internet connectivity to wired devices brought by visitors to Palmer House (a University guest house).
To get started using TVWNA right away, you may follow these instructions:
A detailed list of these locations is not available, but a rough guide is available in OIT's Wireless Coverage Map.
The way you perform the steps above is different for every operating system; if you need a detailed step-by-step procedure for your computer's operating system, consult the instructions that accompany your operating system. The OIT KnowledgeBase contains configuration procedures for several common operating systems; see Wireless: OIT Visitor Wireless for short stays on campus using PUvisitor (FAQ).
The remainder of this document contains more details about TVWNA, as well as information that should assist you in troubleshooting any difficulties using the service.
A device must meet the following technical requirements to use TVWNA:
If registered devices try to use the service, they will not be able to associate to the Wireless Access Point (i.e. connect to the puvisitor network).
The service does not support computers with broken DHCP client software, clients with only BootP (not DHCP) software, or clients that require a static IP address or hostname.
Be aware that DHCP client software sometimes has bugs which do not pose a serious problem when the device is used with static IP addresses, but make the DHCP client unsuitable for use with services which use dynamically-allocated IP addresses, such as TVWNA. These bugs include, for example, those DHCP client bugs which lead a client to ignore DHCP lease expiration times. From time to time, some computer operating systems have such bugs. We have also found that nearly all physical appliances (printers, print servers, file servers, NATs, wireless access points, audio/video servers, etc.) have such bugs. (As noted below, TVWNA is not intended as a way to attach "servers" to the network.)
Our current convention for the Internet hostnames associated with TVWNA IP addresses is: tvwna-LETTER-NUMBER.princeton.org, where LETTER denotes which OIT DHCP server owns the TVWNA IP address. This convention may change in the future.
The Identify My Computer tool will identify the IP address and hostname your computer is currently using, and also tell you if it is a TVWNA IP Address.
We limit how long a particular client may use TVWNA. We do so to discourage abuse by clients whom TVWNA is not intended to service; to discourage faculty, staff, and students from using TVWNA as an alternative to registering devices in the Host Database. We also do so to help preserve an adequate supply of IP addresses for legitimate TVWNA clients.
A device may use TVWNA on any seven days within a single calendar month. We define "use" as any time during which the device was leased a TVWNA IP address. Any use on a day counts, regardless of the length of use on that day.
Once a device has used TVWNA on seven days within a calendar month, the device is declared a TVWNA Camper. (The device may use TVNWA throughout the seventh day; once the seventh day is over, it is declared a TVWNA Camper.)
A TVWNA Camper cannot use TVWNA during the remainder of that calendar month. The wireless hardware addresses of current TVWNA Campers appear in Devices Blocked from Temporary Visitor Wireless Network Access.
If a TVWNA Camper tries to use TVWNA, it will not be able to associate to the Wireless Access Point (i.e. connect to the puvisitor network).
You may determine how many days during the current month your device has used TVWNA; you will first need to discover your device's wireless hardware address. Look for that hardware address in Temporary Visitor Wireless Network Access Clients This Month.
If your device is currently using TVWNA, its hardware address will also appear in Current Temporary Visitor Wireless Network Access IP Address Assignments. And if your device has already been declared a TVWNA Camper, its hardware address will appear in Devices Blocked from Temporary Visitor Wireless Network Access.
At the start of each month, the list of TVWNA Campers is cleared. You can review historic lists of TVWNA Campers from several past months in Old TVWNA Campers.
If a device is declared a TVWNA Camper as a result of seven days of TVWNA usage during the first fifteen days of a month, and this happens for three months in a row, the device is declared a Persistent TVWNA Camper.
A Persistent TVWNA Camper cannot use TVWNA for a year. The year starts on the date the device was declared a Persistent TVWNA Camper.
If a Persistent TVWNA Camper tries to use TVWNA, it will not be able to associate to the Wireless Access Point (i.e. connect to the puvisitor network).
The wireless hardware addresses of current Persistent TVWNA Campers appear in Devices Blocked from Temporary Visitor Wireless Network Access. The date on which the device was declared a Persistent TVWNA Camper appears, along with the months of TVWNA Camping that contributed to the devices being so declared. A device is removed from the list one year after the date it was added.
Keep in mind that TVWNA is intended to serve short-term visitors to the Princeton University campus. Princeton University faculty, staff, and students are not expected to use TVWNA; they are expected to instead register their devices in the Princeton University Host Database. Princeton University faculty, staff, and students should not use TVWNA as a substitute for registering their devices in the Host Database and using the OIT network services intended for their use. Misuse of TVWNA by Princeton University faculty, staff, and students violates our acceptable use policy for the service; in such cases, the device may be blocked from further use of the service, and/or the matter may be referred to an appropriate University authority.
Long-term visitors are expected to be visiting at the invitation of some University staff or faculty member. That person (the University sponsor of the visitor) should register the device in the Princeton University Host Database, much like any other office device at the University.
TVWNA is intended to function as an "Internet Hot Spot," providing Internet connectivity to visitors. It's not intended to provide these visitors with access to services that should be available only to "on-campus devices" or "Princeton University" devices.
Accordingly, TVWNA clients enjoy the same access to the campus network as do devices elsewhere on the Internet. That means, for example, that they cannot access campus services specifically configured to serve only on-campus devices.
The IP addresses and DNS hostnames assigned to TVWNA clients are distinct from those assigned to devices registered in the Princeton University Host Database.
All the TVWNA Wireless Access Points are configured to provide a wireless network with the single network name: puvisitor. The network name is sometimes referred to as the SSID (Service Set Identity).
Any wireless client you wish to use with TVWNA should be configured to connect specifically to the network name puvisitor.
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 TVWNA. That will lead to a variety of difficulties for the wireless client. It will also cause your client to try sometimes to connect to puwireless networks; attempting to do so will interfere with your device's ability to connect to the puvisitor 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 puwireless. Those networks are part of OIT Wireless Service. A device that tries to connect to OIT Wireless Service and is not permitted to connect (because it is not eligible for OIT Wireless Service) will be unable to connect to TVWNA for two minutes. If your device periodically retries to connect to OIT Wireless Service, it will keep preventing itself from connecting to TVWNA. So if your device was previously configured to connect to any puwireless network(s) and still remembers those network(s), reconfigure your device to "forget" those network(s).
We use 802.11 "open" authentication, not 802.11 "shared" authentication.
Clients that can support 802.1x authentication should disable this when connecting to TVWNA. The service does not currently use 802.1x.
TVWNA does not use a network password (e.g. WEP key, WPA key, WPA2 key).
TVWNA supports moving from one Wireless Access Point's coverage area to another overlapping coverage area without restarting or reconfiguring the computer.
Our service is intended to provide service to clients which support a number of the IEEE 802.11 standards.
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.
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. As of September 2012, twenty of the largest academic and administrative buildings have been upgraded, and roughly half of the dormitories building have been upgraded. By September 2013, we expect to upgrade approximately a dozen more academic/administrative buildings and nearly all the remaining dormitories.
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 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 2.4 GHz services remain available everywhere we provide wireless service; this is one reason that all clients should continue to support 2.4 GHz.
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. As of September 2012, twenty of the largest academic and administrative buildings have been upgraded, and roughly half of the dormitories building have been upgraded. By September 2013, we expect to upgrade approximately a dozen more academic/administrative buildings and nearly all the remaining dormitories.
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 all clients 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.
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. Some locations have been upgraded to add support for 802.11a and 802.11n services. 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 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 four standards: 802.11b, 802.11g, 802.11a, and 802.11n. Support for 802.11b or 802.11g is a necessity. Support for 802.11a and 802.11n is not a necessity, but is desirable, because it will allow the client to automatically take advantage of our newer services as those services become more widely available on campus.
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 and 802.11n 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.
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.
We do not attempt to secure TVWNA using encryption technologies. Those encryption technologies that all wireless clients support (e.g. WEP using a shared key) are ineffective. Newer encryption technologies are not supported by many potential TVWNA clients, and even so, most of these technologies rely on there already being a different secret shared by each client and the network (e.g. an individual user's password), which is not available given that TVWNA customers are not "known".
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 to take steps to 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.)
For this reason, you should ensure that your device is not configured to try to simply connect to "all wireless networks" that it sees.
Similarly, if your device is configured to remember selected wireless networks it has connected to in the past, you should ensure that this list does not include the OIT Wireless Service networks; those network names all begin with puwireless.
In particular, Princeton University blocks certain kinds of traffic at our Internet connection, typically for security reasons. This includes, for example, NetBIOS-over-IP, SNMP, RPC portmapper, and NFS. Software that relies on blocked traffic will not be able to communicate with other devices on the Internet. (The most common software of this sort include Windows file and printer sharing, and some Microsoft email applications.)
If you need to access such services provided by your home institution, check with your home institution to see if they provide a way for Internet users such as you to connect to their network via VPN. We do not prevent TVWNA customers from establishing VPN connections to VPN servers on the Internet, and we do not block NetBIOS-over-IP, SNMP, RPC portmapper, and NFS traffic travelling over such VPN connections.
In particular, the current DHCP specification has evolved rapidly in recent years, so older client software may not work right. If the DHCP specification changes in the future, you may need to update the DHCP software on your computer so it may use TVWNA.
Some client DHCP implementations or configurations may have problems that are not apparent when they are only used in an environment where the same IP address is always assigned to a client. These clients then encounter problems when trying to use TVWNA.
When we discover a DHCP client that function in such a way as to interfere with TVWNA, we may declare the device ineligible for TVWNA. A list of devices that have been declared ineligible appears in Devices Ineligible for Temporary Visitor Wireless Network Access.
The most common DHCP client malfunctions of this sort include ignoring DHCP lease times (continuing to use an IP address after its lease has expired), or running multiple DHCP clients on a single interface (hardware address).
A list of devices ineligible for TVWNA appears in Devices Ineligible for Temporary Visitor Wireless Network Access. That document includes list of TVWNA Campers, Persistent TVWNA Campers, devices that have been declared ineligible for TVWNA due to other reasons, and devices that have been declared ineligible for all wireless services offered by OIT.
Sometimes devices are declared ineligible for TVWNA (or all wireless services offered by OIT) because they are infected or compromised, then attempt to break into other devices, or attack other Internet destinations.
Check the the Devices Ineligible for Temporary Visitor Wireless Network Access document to learn whether your device has been blocked, and why it has been blocked. If you don't find your device there, be sure to also check Devices Blocked from Temporary Unregistered Dormnet IP Address Service, Devices Blocked from Visitor IP Service, and Devices Blocked from Mobile IP Service, as devices blocked from those services also are blocked from TVWNA.
If at some later time, the blocked device is registered in the Host Database, it is possible (but not guaranteed) that OIT will attempt to contact someone responsible for the now-registered device, to advise them of the block. Such notification is not immediate; it may take three or more business days after the device is registered in the Host Database before such notification happens.
If you rely on any services or software that expect your computer to be using a specific IP address or Internet hostname, they may not work when your computer is using a temporary IP address and Internet hostname.
For example, if you subscribe to a commercial network service that only accepts your connection from your own corporate or home network (based upon IP address or Internet hostname), you may not be able to connect while you are using TVWNA. The same may be true if you use licensed software that is customized to only run if your computer is attached to your own corporate or home network.
Our current convention for the Internet hostnames associated with TVWNA IP addresses is: tvwna-LETTER-NUMBER.princeton.org, where LETTER denotes which OIT DHCP server owns the TVWNA IP address. This convention may change in the future.
While using TVWNA, you may use the Identify My Computer tool to discover the DNS hostname and IP address in-use by your computer.
Most often this is because the client's association attempt is rejected (e.g. the client is not eligible for the requested wireless service), and the client simply retries at a high rate. Other times this is because the client is succesfully associated to the Access Point, but has a poor quality connection, so it chooses to disconnect, then immediately tries to reconnect.
To reduce the impact these clients have on network service, OIT limits the frequency at which a wireless client may request an association to any single OIT Wireless Access Point. Currently, we allow a wireless client to request an association up to three times within a two-minute period for all wireless services (e.g. OIT Wireless Service or TVWNA) provided by the OIT Wireless Access Point. After three (successful or unsuccessful) association requests, that particular OIT Wireless Access Point will reject any further association requests from that particular wireless client for two minutes.
Even with this rate limit in place, wireless clients that continuously connect and disconnect at a very high rate on an ongoing basis day after day still place a high enough load on the service as to degrade service for other customers. Typically these problematic wireless clients lose connectivity within a few seconds of connecting, and reconnect immediately, and then lose connectivity again, round-the-clock. To maintain an acceptable service level for properly functioning clients, OIT may mark the problematic clients ineligible for wireless services provided by OIT.
Use of TVWNA by devices that should not use TVWNA (for example, devices belonging to Princeton University faculty, staff, and students, or to longer-term visitors) exacerbates this, reducing the number of TVWNA IP addresses available to legitimate short-term visitors. Devices belonging to Princeton University faculty, staff, and students, or to longer-term visitors to the network should be registered in the Princeton University Host Database; they should use OIT Wireless Service rather than TVWNA.
This is consistent with our policy that wireless is not the appropriate way to connect servers to the network. TVWNA is not intended as a place to attach servers to the Internet; it's geared to provide service to clients, not servers.
This is part of a mechanism to ensure that devices no longer eligible for TVWNA are eventually disconnected from the wireless network.
If your client is unable to connect to the puvisitor wireless network, or obtain an IP address, check for the following common problems:
Also verify that the hardware address does not appear in Devices Blocked from Temporary Unregistered Dormnet IP Address Service, Devices Blocked from Visitor IP Service, and Devices Blocked from OIT Mobile IP Service. (Ineligibility for any of those services makes a device ineligible to use TVWNA.)
So if there was a problem that prevented your client from connecting, and you have since corrected the problem, your client may not actually try to connect again even though it may appear to you that it is trying and failing. You may need to reboot the client to force it try anew.
In some cases, even rebooting may not help; to force the client to try anew, you may have to delete its definition for the wireless interface and re-enter it.
If you have questions or need assistance with any of the procedures in this document, please contact the OIT Support and Operations Center.