You could try running something like ssh -n remuser remhost kill -HUP -1. This would not create a login, so it might bypass the 1 login/user limitation.
If this does not work, then you might have to find someone who does have access, then run su remuser with your password from that person's account. Then you'd be able to run kill -HUP -1.
Apparently this issue is already known to the Ubuntu folks. Got to hand it to 'em!
For starters: the quick work around. You can get your system running again by slowing down the ethernet to 10 mpbs like this:
sudo ethtool -s eth0 speed 10 autoneg off
(Note the mii-tool does NOT work with this ethernet chip)
I actually don't have a confirmed fix yet, but apparently no one does. I chose to answer this question because the nature of this problem is something people need to be aware of.
According to the Ubuntu bug report, this is a hardware fault that
randomly affects only some recent Intel ethernet chips. Not some
models, but certain chips. Meaning there's no way to tell which ones
are good and which aren't. At a minimum, the 82579V (my chip) and the
82579LM are affected, Ubuntu team has confirmed those. Who knows how
many other models are affected.
It may be wise to avoid motherboards that use Intel ethernet chips, at
least until the extent of the problem is fully understood.
So it appears this actually is a hardware bug, after all. There are rumors that you can download, compile, and install the latest intel driver, which contains a permanent software workaround. The download is here, compile and install are left as an exercise for the reader.
I'm curious what this software workaround is, and whether it permanently reduces any functionality or performance. There must be some tradeoff, right? Unfortunately I was unable to experiment with this myself, since I needed to get this motherboard sent back within the return window.
Ubuntu bug reports be found here and here. Many thanks to the awesome Ubuntu team! They really do great things for Linux hardware compatibility.
What surprised me most about this is that I was apparently among the first to come across this issue. The Ubuntu bug reports above are still active as of this writing. Is no one using Linux on Sandy Bridge yet? Am I the only person left on the planet with 10/100 network hardware? Perhaps the most likely reason is that the Intel ethernet hardware problem only recently manifested itself.
-- Eric
Best Answer
You have the symptoms of an MTU problem: some TCP connections freeze, more or less reproducibly for a given command or URL but with no easily discernible overall pattern. A telltale symptom is that interactive ssh sessions work well as long as you don't run commands with large output. See Can't access select https sites on Linux over PPPoE for an explanation.
OpenVPN has several MTU-related option — search for “mtu” in the manual. I don't have enough experience to be confident as to which option you need to change. (It's even possible that you can change something in the Wimax modem configuration.) The most likely option to change is
mssfix: try lowering the value until it fixes the problem. The default is 1450; something like around 1400 might fix your problem. Tryopenvpn --fragment 1200 -mssfix; if it helps, increase the value until it starts breaking.