skip to primary navigationskip to content

UniOfCam technical information

Technical details on how the UniOfCam browser-based wireless service is implemented at the University of Cambridge. It is intended for technical staff, both within and outside Cambridge.

This page gives technical details on how the UniOfCam browser-based wireless service is implemented at the University of Cambridge. It is intended for technical staff, from both within Cambridge and outside, to understand how it operates.

Unlike eduroam at Cambridge, the UniOfCam service is only provided on access points provided by the central University Wireless Service.


Wireless protocols

The UniOfCam service operates on an SSID called "UniOfCam" from wireless access points on the central University Wireless Service.

This SSID is "open" (with no authentication/authorisation at the wireless level) and no encryption.


Users can authenticate to UniOfCam through a "captive-portal" web page by Raven username/password or "visitor ticket" using the information provided in a web page which users are redirected to, when they try and access an unencrypted web page (via HTTP on port 80).

Note that if the only access is made through HTTPS or other protocols (such as SSH, IMAP or FTP) then no web page can be presented and the user will be unaware their traffic is blocked.  However, most modern operating systems test connectivity to the internet via HTTP upon connection to the wireless network and prompt for authentication details, if it fails.

Port blocks

Some data traffic on the UniOfCam wireless service is blocked as a security measure.

The following describe the port blocks in place after the user has authenticated and been authorised to use the service.  Until that point, all ports are blocked save those required for authentication.

Note that the service does not have any specific restrictions in place to prevent printing using Microsoft or other protocols (e.g. IPP).  If you find that this does not work it may be that the local institution has its own rules preventing it (e.g. DS-Print has exceptions to allow TCP/139 to its servers from the University Wireless Service, but these are not specific to either the University WiFi service or eduroam: more DS-Print itself).

Local, institutional, rules may also apply elsewhere.  If an institution has a block on inbound traffic (e.g. TCP/139 into a department on the CUDN routers) then you may find that you cannot reach certain resources in that institution. Changes to these can be requested by institutions, or made to their own firewalls, as relevant.

Outbound to Janet / the internet

Outbound traffic is permitted by default.  Only a small number of ports are blocked:

Protocol Port number(s)
TCP 25 (SMTP) 
135-139 (MS RPC) 
445 (SMB)
UDP 135-139 (MS RPC) 
445 (SMB)

Outbound to CUDN (University network)

All permitted.


Traffic to the client is all blocked (although the firewall is stateful, so allows responses to connections originated by the client).

IP addresses

Clients will receive IPv4 addresses from one of the University's IP ranges.

There is no IPv6 support at the present time and it is not expected to be offered due to technical limitations of a browser-based service.

Multicast is not currently enabled.

From the IP address, there is no way to distinguish between a user from Cambridge or an external visitor with a ticket.

Current configuration

The current configuration of IP addresses is described below - we strongly advise that these are not used for access control on services but are provided for situations where this may be appropriate.

Currently, CUDN-wide private ranges are used for client IP addresses - these are RFC1918 addresses which are routed around the University network without translation.  When they leave the CUDN (the University network), they will be SNATed behind one of the University's public IPv4 ranges.

CUDN-wide private addresses Public addresses used for SNAT

It should be noted that this configuration can be changed without warning.

Note that the ranges for the eduroam service are different.


As with most "hotspot" wireless services, at a wireless level, data traffic on the UniOfCam service is not encrypted, authenticated or secured in any way, allowing it to be intercepted, changed or blocked.

However, the use of secure applications or protocols (e.g. HTTPS rather than HTTP, IMAPS rather than IMAP, SSH rather than telnet) will secure the traffic against these attacks, even if the intermediate network (e.g. the wireless network) is not, itself, secure.  The vast majority of modern services are secured by default, especially where personal data, passwords or sensitive information (such as credit card details) is requested.

Last updated: 19 February 2018

UIS Service Status

Phone padded  Service status line: (01223) 463085
Website padded  Sign up for SMS/email status alerts

Getting help

UIS Service Desk
General support queries

  Phone padded  (01223 7) 62999

UAS Service Desk
Administrative staff queries

  Phone padded  (01223 3) 32999

Other IT service desks