| « Upgraded Perl script to log into CCA/NAC | UCI Resnet is as incompetent as ever » |
UCI Resnet is back to being brain-dead
09/12/11
Way back in 2005, I wrote about UCI Resnet's completely brain-dead instructions to "set up" a router (actually, it would result in a complete screw up of the router.)
Obviously, they haven't learned from that episode. They are now requiring the same brain-dead setup again.
Like 6 years ago, this will be a complete failure, and will only result in lots and lots of problems, including rogue DHCP servers, each time such a misconfigured router is reset.
I see that in 6 years, UCI Resnet has not changed one bit. They are still bloody amateurs who should never be let near a network.
He who doesn't learn from history is damned to repeat it...
What makes this even more baffling is that in 2005, Ted Roberge of Resnet himself stated in a White Paper that this kind of router misconfiguration doesn't work...
Rogue DHCP servers. Although Resnet originally prohibited routers, this became an ?unenforceable? policy with the popularity of small home wireless routers. A combination of events caused many routers to be set up incorrectly, resulting in them becoming Rogue DHCP Servers. In an attempt to help residents set up their routers and still be able to register their computers, Resnet published guidelines on how to set them up as Access Points. This became a double edged sword. When configured correctly, they worked great. However, any reset, power failure, or disconnect resulted in the device defaulting back to its original configuration and then became a DHCP server. We removed all guidelines for configuring wireless routers and simply state that they must be set up in accordance with manufacturer instructions. We further went on to state that we would not support any routers, and removed all policies relating to the prohibition of routers on the network. We will not respond to any trouble call relating to home routers or wireless.
To sum it up: Never ever connect a LAN port to the wall plug. Always connect the WAN port to the wall plug. It is that simple.
8 comments
I’m a current grad in PV. Resnet has been absolutely unhelpful with my issue (configuring router for wireless, etc). I’ve called more than 10x in the past week.
Any advice? Who do I go to for help since they refused to tell me anything and just referred me back to their router reconfiguration website. UGHHH…
Thanks.
Hmm, I can’t really help much, I am long gone from UCI (I am still on some UCI mailing lists, though; that’s how I learned about this issue.)
I was active in the Palo Verde Residents Council (PVRC) 6 years back. That’s why I know all the stuff that was going on back then.
At that time, we fought tooth and nail with Resnet over the router configuration issue, but it took them getting a lecture from the real network professionals at UCI’s Office of Information Technology, http://www.oit.uci.edu/ to get things resolved.
And that was with most of the PVRC people in the Computer Science graduate program…
I personally would just ignore Resnet’s router configuration website, and follow the manufacturer configuration instructions. The manufacturer knows better than UCI Resnet how their device works and how it is configured correctly.
Of course, even though that would be the sensible, common sense thing to do, it would be at your own risk. Resnet and common sense are obviously two things that don’t quite fit together.
My hope is that eventually, they find back to reality…
Until then, your choices are basically to follow Resnet’s instructions and have tons of problems with your router, or to follow the manufacturer’s instructions and don’t have problems with the router, but potentially run into problems with Resnet. You’re unfortunately stuck between a rock and a hard place…
I can’t really give recommendations on what to do. I know what I would do, and I know that as a computer professional I would be able to fight Resnet on the technical merits (and win.) But for people without the technical expertise, it is just much harder to argue with Resnet. Maybe if you have acquaintances in ICS…
In any case, please make your voice heard. Let the PVRC know about your problems (pvrc at uci dot edu). They can make this issue more visible within the administration.
Good luck.
Thanks for your advice! I’ve been pulling out my hair trying to do as they say (and then later, have to do it all over again). I will definitely make a complaint to PVRC. I appreciate the help.
Hi Joe! I’m an EECS grad student here, and I’m interested in solving some of these sorts of issues.
Joe: “I personally would just ignore Resnet’s router configuration website, and follow the manufacturer configuration instructions.”
What makes you believe this will work? Usually, the manufacturer has you set it up with the WAN link facing the Internet and assigning its IP by DHCP. But this requires that the router itself must register with ResNet (or perform the interactive CCA web login - kinda hard to do from within the router!)
So unfortunately, it seems like for the vast majority of users, they are forced to follow ResNet’s configuration suggestions (connecting via a LAN port, disabling the router’s DHCP, etc.). FWIW, that has worked OK for me. I can probably help if others (Megan?) are having problems still.
On a more advanced note: Joe, do you have a good idea of what might be needed to update your Perl autologin script for the current ResNet configuration? I don’t think it works anymore. It seems like ResNet uses some kind of JavaScript sessions in addition to just HTTPS POST for login now…
No, the router doesn’t register with Resnet (although that’s possible with some routers where you can change the firmware, e.g., certain Linksys routers, using DD-WRT.)
You register with your computer behind the router. The issue is that only one machine, the first one that connects, behind the router has to register, because Resnet sees the same IP address from all computers behind the router. That’s what they don’t like, and that’s why they had this idea of using the LAN ports.
Your computer, or a router, gets an IP address way before you register. If your computer is connected directly, it gets an IP address before you even log in. Similar with routers. They get assigned an IP address from Resnet without registering, etc. They just can’t do anything with it until somebody behind the router has logged in with Resnet.
As for the Perl script, when I wrote it, I essentially analyzed what data the login website wants. I used wget to get the whole webpage, including headers. For session handling, cookies are usually used, which are in the header. If cookies are disabled, the server side usually sends the session id in the page as hidden variable.
Yeah, I guess I was wrong about the router thing. It does still work if you login from behind the router.
I think I figured out why the Perl script didn’t work, and it didn’t involve sessions or cookies. It was just a few parameters. I’ll verify it soon and post the changes if you’d like.
I happen to be using a couple of DD-WRT routers that I’m trying to login automatically from, allowing all my LAN to connect without trouble (then I might be able to kill CCA on my Windows PC!!!). Unfortunately, it doesn’t have Perl or OpenSSL installed by default, but I’m trying to figure out another solution. (Any ideas?) Perhaps I can compile my own C program.
I haven’t modified DD-WRT myself, since I always used a full-blown Linux machine with 2 NICs as router. But I do know that some people had modified their routers to login automatically.
Due to the limited free space in these routers, a compiled program would probably be best. A little C program, statically linked with the curl and openssl libraries. Of course, you’d have to set up a cross-compile environment for the processor in the Linksys routers. The DD-WRT wiki has info on that.
Oh, and I’d be happy to put your modified Perl script up.
I’m a PV resident, and I feel stuck between a rock and a hard place on this network configuration issue.
I didn’t have any issues making things work before with my router neutered into a mere access point, but now they’ve introduced some weird kind of wall-jack level isolation policy.
I think the intent was to quell fears that arose from being able to see your neighbors’ computers, but now the devices plugged into the wall in my living room can’t see the computers plugged into the wall (via the LAN ports on my router) in the next room over.
The only solution to this problem is to get everything on wireless, or run a long ugly cable through the home 
