Have you checked the duplex settings on the card? I saw similar things
with my Ultra 5's connecting to Cisco switches because autonegotiation
wasn't working properly, and the U5's were setting themselves to
half-duplex. If I pushed enough traffic across the line when the
duplexes didn't match, they'd lock up. I don't know if it's a problem
with just the build-in ethernet or with U5's in general.
If you've got the ethtool package installed (apt-get install ethtool),
try running "ethtool eth0" and check to see if everything looks right.
I had to use ethtool to turn off autonegotiation and force full duplex
at boot.
Kristjan Onu wrote:
Also for what it's worth, I haven't seen such problems into a U5,
either with the Woody libssl or later 0.9.6 ones with v9 optimization.
I'm glad to hear others are successfully using U5s. I'm leaning toward
saying there's a hardware problem, but it must not be with the network
card since I've tried the built-in network card as well as a 3Com.
Can anyone suggest where else to look? (I think I've heard compiling a
kernel is a good way to test memory.) Any log files that might point
to faulty hardware?
One point I forgot to mention in my original post is that connecting
from the server back to itself (ie. ssh localhost) seems to work
without fail.
I mentioned my problem in an OpenSSH bug report
(http://bugzilla.mindrot.org/show_bug.cgi?id=538), and one person
asked if my server uses ssh-rand-helper. I don't know if Debian does
or not, could one of you please tell me.
