From owner-freebsd-hackers Wed Nov 18 13:11:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA07293 for freebsd-hackers-outgoing; Wed, 18 Nov 1998 13:11:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from detlev.UUCP (tex-107.camalott.com [208.229.74.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06971 for ; Wed, 18 Nov 1998 13:10:26 -0800 (PST) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id PAA01204; Wed, 18 Nov 1998 15:09:17 -0600 (CST) (envelope-from joelh) To: Ivan Villalobos Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Telnetd keepalive question... References: <19981117223552.AAA600@mailmtx.acnet.net@denpmfe.acnet.net> From: Joel Ray Holveck Date: 18 Nov 1998 15:09:15 -0600 In-Reply-To: Ivan Villalobos's message of "Tue, 17 Nov 1998 16:36:12 -0600" Message-ID: <86g1bgiu84.fsf@detlev.UUCP> Lines: 77 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I need to know how to tweak this parameters. As I understand it, I have > three options: > 1.- Tweak the firewall's TCP timeout. > 2.- Tweak FreeBSD's tcp.keepalives. > 3.- Tweak telnetd's keepalives. > I do not want to go for options 1 & 2 since it would affect not only my > session but all my traffic. So I figured that the right thing to do is to > tweak telnetd's keepalive. Why do you want your other TCP traffic to not send keepalives? That would seem to be needed for such a firewall (which is, IMHO, broken anyway). > Now, does anybody know what the "1" means in this line?, taken from > /usr/src/libexec/telnetd/telnetd.c > int keepalive = 1; > I also figured this would be the line to mess with, right? No, this is how you already want things. First off, are you sure that keepalive packets aren't being sent, and just being ignored by your firewall? (If your firewall is 4.2 based, then you may need to turn on TCP_COMPAT_42 in your kernel config to account for a bug in the keepalive handling code.) A tcpdump may or may not show keepalive packets. (The following is based on Nov 8th's -current.) keepalive is on by default [telnetd.c line 134]; telnetd -n will turn it off [307]. The keepalive handling is done by the kernel at telnetd's request [501]. The kernel itself does the keepalive handling, mostly in /sys/inet/tcp_timer.c. A description of the process is in tcp_timer.h line 74. The variables that control keepalive handling are under net.inet.tcp in sysctl, and prefaced with tcp_ in source code. (Note that the timers are initialized in terms of PR_SLOWHZ, which means that they are measured in half second increments. I have written the actual times here.) These are: tcp_keepinit (TCPTV_KEEP_INIT, net.inet.tcp.keepinit) [75s] Time before failing a connection when it is first opened tcp_keepidle (TCPTV_KEEP_IDLE, net.inet.tcp.keepidle) [2hr] Time before probing an idle connection with keepalives tcp_keepintvl (TCPTV_KEEPINTVL, net.inet.tcp.keepintvl) [75s] Time between unacknowledged keepalive probes tcp_keepcnt (TCPTV_KEEPCNT) [8] Number of probes sent before dropping a connection The description in tcp_timer.h mistakenly refers to TCPT_MAXIDLE, which is undefined. The correct variable name is tcp_maxidle, which is initialized to tcp_keepcnt*tcp_keepintvl. Your solution, therefore, appears to be to set tcp_keepidle to 13 minutes (ie, 15 minutes minus TCP's maximum segment lifetime of two minutes). Adding the command sysctl -w tcp.inet.tcp.keepidle=1800 to your /etc/rc.local should do the trick. This will affect the keepalive handling of any socket which has keepalives turned on. Presently, the keepalive timeouts are on a per-system rather than a per-socket basis. Note that sockets that do not turn on keepalives will not be affected. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message