Date: Sun, 15 Apr 2001 12:36:43 -0700 From: Dima Dorfman <dima@unixfreak.org> To: Joachim =?iso-8859-1?Q?Str=F6mbergson?= <watchman@ludd.luth.se> Cc: doc@FreeBSD.ORG Subject: Re: Suggested adendum to FAQ section 3.22 Message-ID: <20010415193643.3E84A3E2F@bazooka.unixfreak.org> In-Reply-To: <3AD6B215.189906@ludd.luth.se>; from watchman@ludd.luth.se on "Fri, 13 Apr 2001 10:00:21 %2B0200"
next in thread | previous in thread | raw e-mail | index | archive | help
Joachim =?iso-8859-1?Q?Str=F6mbergson?= <watchman@ludd.luth.se> writes: > Problem discussion: > ------------------- > First off - a question: Wouldn't the same problem affect ftp, http and > ping to the same host - that is a name resolution problem should affect > all connection types, not only telnet or ssh, no? Not necessarily. Only certain services try to do a reverse lookup when someone connects. Most HTTP servers, for example, do not. Nevertheless, you have a point that services other than ssh and telnet can be affected; I'll change the wording of the question to reflect that. > For me I had the behaviour described in 3.22. The problem was that the > sites I tried to connect to belonged to some of the bigger sites on the > net, and the DNSs I use are also among the bigger ones (my ISP is the > biggest ISP in the country). It was also pretty easy to do a name lookup > and find the correct name and IP-number for the hosts I tried to SSH or > Telnet to. > > Furthermore, ftp worked nicely, whereas telnet to port 21 didn't. > Running ktrace while running ssh and telnet suggested common libraries. > The solution found was to do a buildworld/installworld so that libraries > and binaries were updated. Now, ssh and telnet runs fine. > > > Analysis of my faulty ways: > --------------------------- > (1) I had used -O3 optimization for the last version of system upgrade. > Yes, this is BAD. No, it won't happen again. This could very well be the > reason for the behaviour. > > (2) I update the cvs-tree and make buildworld on a weekly basis, but > update the system very much more rarely. The kernel however have been > updated due to added HW and such things. Since the kernel sources have > been updated, some problems due to kernel and system is out of sync > might be responsible. I understand where you're coming from with this, but I don't think it's appropriate to try to document every possible mode of failure. That's sort of like documenting the fact that the network cable must be plugged in in order for this stuff to work! If we did that, we'd be too busy changing all of the questions with the latest way to break the system instead of writing new and more useful documents. The answer attempts to describe the most common solution to the stated problem as derived from reading -questions. It can't possibly mention every single thing that could go wrong, and mentioning just some of the more obscure things isn't going to help anything. I understand that it might help a few other people, but I simply don't think it's worth it. Regards, Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010415193643.3E84A3E2F>