We’ve had a large number of reports of customers experiencing problems with ResNet Wireless and Eduroam. The symptoms being that it your computer asks for your username and password. Some times it will accept them, but it often takes multiple attempts to get anywhere.

We’re actively investigating the issue, and we’ve been poring through mountains of log files trying to work out what’s going on.

Workarounds:
The ResNet Wired service is not affected by this problem at all, so if you plug your laptop into the wall you’ll have a nice fast stable connection that doesn’t repeatedly ask for your password.

For Eduroam, we don’t currently have a workaround other than “wait for 15 minutes then try again” as the problem appears to move to another location every so often and if you wait a bit then try again it may work better.

Update 2012-02-10 16:06:
We’ve managed to replicate the problem on a machine in the office, and we *seem* to have fixed the problem with that machine (it’s a bit early to tell, but I’ve connected/disconnected several times with no problems)

We’ve released a new version of the setup wizard with a couple of tweaks, which should help. You can re-run the wizard by connecting to the “ResNet-Setup” wireless network and then going to http://go.resnet.bris.ac.uk wizard in your web browser.

Update 2012-02-13 10:50:
OK, so the new wizard only appears to have fixed things for my laptop in the office and not anyone elses. This rules out client side certificate issues. We’ve got a few more leads that we’re following up from deeper in the network infrastructure. More news as we get it.

Update 2012-02-13 12:20:
The problem appears to be even more widespread than we thought, and is potentially affecting some eduroam clients as well. We’re currently working closely with the core networking team to identify a course of action.

Update 2012-02-13: 14:00:
We’ve hit a point with this problem where the next step is to escalate it to Cisco (the vendor that makes our wireless networking kit) So we’re in the process of raising a ticket with their support team. Our best advice at this point is to use the ResNet Wired network instead where at all possible.

Update 2012-02-15:
Just a quick update to say we haven’t forgotten about this problem and we are still pursuing it. We are currently waiting for Cisco to get back to us.

Update 2012-02-16:
I think it’s safe to say we’ve got enough detailed information to go on for now, so there’s no need to email the service desk. We’ll update this blog post again when we have some news about a fix.

Update 2012-02-20:
We now think this is a known bug in the firmware version our wireless controllers are running. By all accounts it only surfaces if the controllers have been running for quite some time (as ours have) and a restart of the controllers should temporarily alleviate the problem.

Coincidentally there is a wireless maintenance slot scheduled for tomorrow morning, so we’re planning to restart things during that slot. Upgrading the firmware is a larger job though and needs some planning. There’s a meeting happening tomorrow which will determine when that upgrade can happen. More news about that tomorrow.

Update 2012-02-28:
We believe that the upgrades done this morning have fixed the problem. If you continue to have problems with ResNet wireless, please contact the IT Service Desk and we’ll investigate.

Because of essential maintenance to one of the university database servers, the following services will be unavailable between 21:00 and 21:30, Monday 13th February. This work is to fix the underlying cause of the problems we experienced before Christmas.

For the duration of the work, the following ResNet services will be unavailable: