So, for my Christmas present to myself I got a Huawei E220 HSDPA modem – it’s one of the Vodafone-branded ones, but I reflashed it with the generic firmware. Anyway, it’s an awesome thing to have for a geek like me – I can be connected to the Internet at broadband speeds almost anywhere in the city. It’s particularly useful when i’m on campus, so I can avoid the dog-slow UCT internet connection.
Problem is, I’d like to stay connected to the UCT network as well so that I don’t use up my precious* data bundle for UCT services, and this requires a bit of custom routing magic. So I have a script:
#!/bin/sh
GATEWAY=137.158.32.97
route add -net 137.158.0.0/16 gw $GATEWAY
route add -net 192.48.253.0/24 gw $GATEWAY
route del default
route add default ppp0
137.158.0.0/16 and 192.48.253.0/24 are the UCT netblocks, and 137.158.32.97 is the router on the subnet that I’m mostly using at the moment. ppp0 is, of course, the name of the interface associated with the HSDPA connection.
The problems with this script currently are that I have to edit it to change the gateway for each subnet that I’m on, that I have to run it manually each time I connect, and that it doesn’t restore the original routing when I disconnect. The first and third problems should be reasonably easy to solve, but the second will probably require that I dig into the mysterious world of NetworkManager. (Cue dramatic music.)
*It’s ourssss, my preciousss… they wants to take it from us, the nasssty Vodacom…
Hi Adrian
192.48.253.0/24 is one of two IPv4 blocks that used to belong to UCT but have been transferred to TENET. The reason why the AfriNIC database still shows the block belonging to UCT is because TENET hasn’t updated it (they don’t seem interested in doing it either – chances are they still have a year-or-so-old open ticket for this in their RT).
UCT has 3 remaining IPv4 blocks, of which two are routed on the Internet: 137.158.0.0/16 and 196.24.192.0/18.
I can suggest a simpler solution for the second problem with your script: Change it to check if your Ethernet interface has a UCT IP address configured before it mangles your routes, and then move it into /etc/ppp/ip-up.d
Finally, note that connecting any host on the UCT LAN to the Internet directly (like, say, via an ADSL line) is not permitted by university policies. Of course, the problem of enforcing this policy with wireless broadband modems has no general solution (known to me).
Regards,
Simeon
Thanks for the info, Simeon.
Does the policy about separate connections really apply when it’s my own personal laptop? It’s not as if I’m trying to connect UCT-owned machines directly to the Net, nor am I trying to use UCT telephone lines for dialup or DSL. In fact, by using (and paying for) my own wireless broadband I’m removing traffic that would otherwise be travelling on the UCT network.
Or is it a virus/malware concern? In that case, well, I’m running Linux so it shouldn’t be a problem.
Anyway, as you say, the rule is quite unenforceable. So, for the record, this whole post is purely hypothetical and any resemblance to real life is accidental.