Date: Fri, 2 Jun 2000 15:48:00 +1200 From: Dave Preece <dave.preece@kbgroup.co.nz> To: freebsd-questions@freebsd.org Subject: No login day. Serious hassle. Message-ID: <67B808B0DD93D211ABEE0000B498356B2B4EA4@internet.kbgroup.co.nz>
next in thread | raw e-mail | index | archive | help
Since it doesn't (as yet) involve any source code I thought I'd send this here and not to -hackers. Headache central. I run sshd and connect to my box through SecureCRT (an actually very good ssh client for Win32). Came in this morning and it wouldn't login. We could connect at layer 4, and some daemon and backgroud software I left running is fine, but not login as such. Since I mess around with firewalls a lot and locking myself out is not uncommon, I have a (shite) console connected to the serial port and can get a root login from here. So I got inetd up (normally disabled) and normal telnetd going and tried to connect again. The client connects instantly, but then takes ages (like, a minute) to get a login prompt. Not good, but at least I'm in. Once in, I waded through /var/log and could find nothing. Running ethereal onto a new telnet session showed what was happening (kinda): The three way handshake was completed and telnet opened the batting with the "Do suppress go ahead" command, which was acked. Then nothing for 75 seconds. It then continues and goes through to the ack for "Login:" within 0.5 seconds, as to be expected. Quite why, I don't know. I've seen a similar problem to this before, but on that occasion I had the default router set to an address not on the local subnet, and fixing that solved the login problem. On a hunch I decided to have a look at the arp cache with arp -a, which didn't seem to want to complete (ctrl-C'd it), then arp -na completed and appeared to solve all my problems. Everything goes fine, but there is still a significant gap (1.5 seconds) from "do suppress go ahead" to the next command. So, while I am 'fixed', I still have no idea what went wrong or why. It seems there was some kind of corruption in the arp cache that was causing a timeout to happen much the same as when I did something stupid with the default router. Is this the case? What can I do to prevent it? And why did it render sshd totally unable to login? A bit confused, but protective of uptime. Dave :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67B808B0DD93D211ABEE0000B498356B2B4EA4>