The University of Tasmania has student wireless Internet access, a network called UConnect. (Great pun.) This network has sucked by varying amounts over the three and a half years I've spent there as a student.
It's some sort of 802.1X beastie. Setting it up on GNU/Linux is mostly a trial-and-error affair. My current settings are WPA2 Enterprise security, PEAP authentication, MSCHAPv2 inner authentication, and an AusCERT-certified identity whose root certificate isn't included in any normal root certificate packs.
They don't actually tell you what the settings are. The current way you're supposed to set it up on Windows or Mac OS X is to run some java-ish program which asks you for your administrator password and proceeds to mess with your settings such that it should work. Furthermore, if you're running Windows and it can't detect antivirus software it forces you to install McAfee Antivirus before it will mess with your settings. But that's okay, because McAfee is awesome.
Nonetheless it can be made to authenticate and have your computer on the University network. At this point you have access to the Internet, sort of. You can make DNS requests, or open TCP connections to destination ports 80, 110 and 443. Previously you had to explicitly go through proxy.utas.edu.au to get your web traffic out, but this year they brought in transparent proxies (edit: Not true. See comments). This is a minor improvement, but still doesn't do much for my IMAPS email, Google Talk, or anything else I want to do.
The general technique I've used for this other traffic is an ssh tunnel to my computer at home, using corkscrew where necessary to get through an HTTPS proxy. ssh -D will set up a SOCKS proxy on the local computer, causing all connections to be made via the remote computer (my computer at home). All I have to do is tell pidgin and Thunderbird and possibly firefox to use a SOCKS proxy at localhost and I can use the Internet how I like.
I wish I could say that having negotiated all these challenges I can relax and concentrate on my studies. This year they introduced a new problem: connections drop out. After some random interval of normally 2-30 seconds most TCP connections will stop having packets go either way. New connections continue as normal. I have no idea what routing problem is responsible for this but it's damn annoying.
Even HTTP requests can be affected by this. Sometimes I'll load a wikipedia page and half the maths images won't load. There is one little bit of respite: if a connection lasts for longer than about 30 seconds, it will tend to live more or less forever. Weird. This gives me a solution to web browsing: I keep on trying to establish an ssh tunnel to my home computer, and once one has managed to stay established for over half a minute, I can start using it to do web browsing through the SOCKS proxy.
This is where I've been at for the last seven or eight weeks but it's getting seriously frustrating killing ssh connections until I manage to establish a tunnel which stays up. I wanted a program to automate this process. Let's make a lot of ssh connections, poke them every ten seconds for half a minute, then grab one that's still alive and start another channel with that ssh TCP connection.
This can be facilitated using the ssh ControlMaster option (-M -S). Each of the simultaneous connections puts a socket in /tmp. Then when I want to use a particular TCP connection I launch another ssh process with -S to indicate the socket to use and also with the -D option which enables the SOCKS proxy behaviour on that connection. Then I want that first background connection to hang around until I'm done with the second, then die automatically.
So I've written a program that does just that: urlyconnect. If you're at UTAS you too might find it useful. I've tested its functionality on Debian and Ubuntu GNU/Linux but I see no reason why it shouldn't run on a Mac. If you use Ubuntu, note carefully the instructions in the README about the required version of OpenSSH.
Well, that's that done. Time to go and do something related to my degree.
6 Comments
The old proxies are still there and although they have the old proxy issues it doesn't however have the tcp dropout, so go for whichever is less of a pain to you I guess.
Interesting. I think I heard about that and forgot about it again... ah well. Good to know.
I recall that corkscrew also often required more than one attempt, so I think I'm still ahead in required effort.
Good job sir, sounds like it's more painful than ever!
"this year they brought in transparent proxies". Er... not according to the people who implemented it...
Fair enough, I'll stand corrected: I did assume transparent proxies. It seemed likely that some sort of infrastructure (download monitoring, whatever) required a proxy since we had one in the first place. It could well be NAT and nothing more. Mea culpa.
Either way it's not really important. Something between the laptops and the Internet is causing the connections grief, so that's what I've tried to work around.
I would be interested to know if this is still a problem. We (ITR) have made some changes recently which may have an impact on this issue. We cannot test this ourselves as we have not been able to recreate the problem.
I should add that there is still a second problem with UConnect which is currently being investigated.