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 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  01223 332999

UIS bITe-size bulletin

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

Sign up >  |  Back issues

UIS Service Status

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

RSS Feed Latest news

Wi-Fi network maintenance 07:00–09:00 Wednesday 18 September

Sep 12, 2019

The University’s wireless service will be unavailable for significant periods between 07:00 and 09:00 on Wednesday 18 September while we carry out essential maintenance work.

Wi-Fi upgrade on Tuesday 10 September between 07:00 and 09:00

Sep 09, 2019

There will be short interruptions to the wireless service on Tuesday 10 September between 07:00 and 09:00 as we implement an upgrade to the operating system. We'll do our best to minimise any disruption.

View all news