skip to content

IT Help and Support

University Information Services

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 legacy "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 UDN 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 UDN (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.

The addresses used may or may not have DNS registrations against them.

From the IP address, there is no way to distinguish between a user from the Collegiate University 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, UDN-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 UDN (the University network), they will be SNATed behind one of the University's public IPv4 ranges.

UDN-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: 8th May 2019

UIS Service Desk

Phone padded  Service status line: (01223 7)67999
Website  Sign up for SMS/email status alerts
Website  Read major IT incident reports

UIS bITe-size bulletin

A regular newsletter aimed at the University's IT community, highlighting service and project news from UIS.

Sign up >

Latest news

macOS Ventura release

30 September 2022

Apple will soon be releasing macOS Ventura. Following its release, they will drop support for macOS Catalina (10.15). All users running macOS Catalina are encouraged to upgrade to one of the following supported operating systems: macOS Ventura (when released) macOS 12 Monterey (compatible computers:

Change to display names in Lookup from 06 October 

30 September 2022

What is happening From 06 October, UIS will be updating the Display name records in Lookup to use people’s Preferred first name initials. This supports a user-friendly move toward using everyone’s preferred names, rather than their Registered name. If you have personally set your own Display name in Lookup, you will not be...

Streaming Media Service: transcoding temporarily suspended

26 September 2022

We have temporarily suspended the transcoding of media uploaded to the Streaming Media Service (SMS) while we undertake some remedial work. Please do not try to upload new media to the SMS at this time. Transcoding of media already uploaded to the SMS will continue once the work is complete. This work does not affect...