Bug#542633: linux-image-2.6.26-2-openvz-686 version 2.6.26-22 also fixes this kernel bug!
Hello, Maximilian and all, package linux-image-2.6.26-2-openvz-686 version 2.6.26-22 fixes bug 571457 ! Thanks! So, in my opinion as the original reporter, bug 571457 can be considered obsolete. As I'm not 100% sure about proper procedure, I leave the actual closing to you Debian maintainers. For the record: The present Lenny version 2.6.26-21lenny4 of that package still has the bug. Gory details: > please test the 2.6.26-22 upload to stable proposed uploads, > see instructions on how to install > http://www.de.debian.org/releases/proposed-updates I tried that yesterday, but it didn't work for me. Poking into the Debian mirrors, I found that the 64bit version was present, but the 32bit I need not yet. So I guess I was monitoring the Debian build while it happened. A few hours later, the front-door approach with aptitude still did not work, but I found linux-image-2.6.26-2-openvz-686_2.6.26-22_i386.deb below http://ftp.de.debian.org/debian/pool/main/l/linux-2.6/ . So I installed that with raw dpkg -i . Result: Bug no longer present. The results with this Debian kernel are quite comparable to what I have seen with the openvz upstream kernel, as reported in my earlier mail. Regards, > thanks for feedback on it. you're welcome, and thank you all for providing fine software, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#571457: This kernel bug is Debian-specific, not present in openvz upstream Kernel.
This bug is Debian specific: The endless looping inside the kernel system call is not present in a current openvz upstream kernel. I'm refering to Debian bug 571457 which, according to Maximilian, is probably the same as bug 542633 . The details: I had filed an upstream bug report http://bugzilla.openvz.org/show_bug.cgi?id=1443 . In that bug's discussion, Pavel Emelyanov asked me to verify whether the bug was present in their git kernel. So I grabbed their kernel source git clone git://git.openvz.org/pub/linux-2.6.26-openvz openvz-git-kernel For configuration, I used Debian's linux-image-2.6.26-2-openvz-686, Version 2.6.26-21lenny4 as my baseline, via cp /boot/config-2.6.26-2-openvz-686 .config I compiled the sources via make-kpkg --initrd kernel_image (which didn't at first work. The directory permissions of /usr/src had infected my git directory with g+s, and, after a long time of churning, make-kpkg decided it didn't like that.) The good news: After booting into that kernel, my example runs fine as expected! No more endless looping and CPU cycle eating. Instead, a mere 20 milliseconds user time consumed by the server. The Perl client is through in 1.5 seconds real runtime. For comparison, directly on the host machine (a somewhat dated box), the server's user stays the same, the client's real is about 0.1 seconds faster. After two runs on a freshly started openvz client, I get 511 tcpsndbuf fail counts grep tcpsnd /proc/user_beancounters tcpsndbuf 0 70400 7 15511 which was to be expected. Regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#571457: OpenVZ TCP/IP socket write hangs - is this Debian bug 542633 ?
Hello, Maximilian, I would like to ask you whether you think the following bug is the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542633 "openvz: [UBC]: Endless loop in __sk_stream_wait_memory." I had a reproducible "stops working" with a Subversion server running on an OpenVZ guest. After some investigation, this turned out to be nothing Subversion-specific. I was able to reproduce with a minimal client / server pair. What I know about "my" bug: * A write system call to a TCP/IP connection socket hangs, it does not return to the application, * the process doing the write consumes what CPU cycles it can get, as reported by "top", * killing the other side of the TCP/IP connection does not result in the "connection reset by peer" condition as it should, * instead, the write simply continues to consume all CPU cycles it can get, for all I know, indefinitely until I kill the process, * the bug seems to appear if the sender writes fast, faster than the network or the client can consume, * putting big chunks of data into a single write call does not seem to be strictly necessary to reproduce the problem, but it does make the problem appear more easily, * the problem can be made to appear a write or two later by raising the tcpsndbuf UBC. For more details, I have filed http://bugzilla.openvz.org/show_bug.cgi?id=1443 on this issue. This also has my client / server pair with which I have been able to reproduce this bug. I have also filed the Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571457 on the same issue, originally against Subversion, now I have reassigned it to the OpenVZ image I have been using. Would you kindly tell me whether this bug is the same as Debian bug 542633 ? Do you think this is Debian specific, or does it also concern OpenVZ upstream? Regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#571457: I meant svnserve, not svnadmin.
Hello, I wrote "svnadmin" a few times in my previous mail, but I meant "svnserve" each time. I apologize for any confusion that may have been caused by this! Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#571457: svnserve hangs, burning CPU cycles, under low TCP sendbuffer.
Package: subversion Version: 1.6.9dfsg-1 X-Debbugs-CC: d...@subversion.apache.org Hello, Subversionists, I have a subversion repository with a single revision, consisting of a single roughly 10 MB file with random data. I use svnserve to serve that repository. I use a client to access the svnserve over the network, via "svn co". (The client happens to be Ubuntu's 1.6.5dfsg-1ubuntu1, in case that matters.) The server is an openvz guest. When, on the corresponding host, I set vzctl set NNN --tcpsndbuf 415k:715k or lower (my guess is the first number is the one that matters), the checkout starts, there is some initial network traffic, but then svnadmin starts to eat up all CPU cycles it can get and no further progress is made, until I kill the svnadmin process manually on the server. Just killing the client does not seem to stop the waste of CPU cycles on the server. When I increase the tcpsndbuf above that value, there is no problem. However, when I check in a much larger file into the repository (I do that directly, using file:/// - access), and try to check out again (using svnserve), the problem reappears. This is quite reproducibly, with svnadmin as a standalone daemon as well as svnadmin running under inetd. For the latter case, I made no precise experiments about the --tcpsndbuf numbers. This is the summary. I have written three mails yesterday and today to the d...@subversion.apache.org mailing list, but have not received any answers there yet. There is lots of nitty-gritty background information in those mails, which, hopefully, you'll be able to find here: http://mail-archives.apache.org/mod_mbox/subversion-dev/201002.mbox/browser Regards, and thank you for providing fine software, Andreas P.S.: I ask the Debian bug tracking system to forward a copy of this mail to the SVN dev mailing list. This contains two pieces of information not available in my previous mails to that list: * The bug is reproducible with the latest subversion software version I can easily install, short of compiling myself. * The client I'm using is, and always has been, 1.6.5dfsg-1ubuntu1. I think I misquoted it to be 1.5 in one of my earlier mails. I apologize if this caused any confusion! -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 577 996-26 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram DV-RATIO - "Kompetenz und Zuverlässigkeit seit 1980" signature.asc Description: OpenPGP digital signature
Bug#518133: closed by Aurelien Jarno (Re: Bug#518133: libc6-xen: nosegneg not selected when running in OpenVZ under Xen)
Hello, Aurelian, thank you for that piece of information. > You should either ask the company providing you kernel to fix the pseudo > hwcap nosegneg value, or edit /etc/ld.so.conf.d/libc6-xen.conf and > replace 'hwcap 1 nosegneg' by 'hwcap 0 nosegneg'. I have tried that "hwcap 0 nosegneg" bit. That one does NOT help. That established, do you still think there a good chance that the other part of your counsel does help, that is, upgrading to a more recent kernel? For the record, as an ugly workaround, what does get rid of the messages is: Move the plain versions to the side and replace them with symbolic links into the i686/nosegneg directory. Something along those lines (while 156 is stopped): cd /var/lib/vz/private/156/lib mkdir wrong-version-moved-to-the-side for f in `cd i686/nosegneg; echo *` do test -f $f && mv $f wrong-version-moved-to-the-side && ln -s i686/nosegneg/$f . done Regards Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 559 1617 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 Jahre DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#518133: libc6-xen: nosegneg not selected when running in OpenVZ under Xen
Package: libc6-xen Version: 2.7-18 Severity: normal Hello, this bug report is about improving libc6's "I'm under Xen" - detection. The situation "OpenVZ guest below Xen domU as OpenVZ host" should be detected, and libc6-xen should be used in this situation. This has been working fine under Etch, but fails to work in a mixed Etch host / Lenny guest environment. Here are the details: I rent a Xen domU guest from some hosting company. That Xen guest is running a kernel supplied by myself, from some package ovzkernel-xen_2.6.18-54.1_i386.deb, 32 bit. I did not get that kernel from any official Debian source. I think I originally obtained it from http://download.openvz.org/debian/ , but I'm not absoultely sure. If so, the kernel is no longer available there. Privately, I still have that .deb archive I originally used to install the kernel. That Xen guest runs Debian Etch, with libc6-xen version 2.3.6.ds1-13etch9+b1, and shows no problems. I use that Etch installation as an OpenVZ host. So virtualization on top of virtualization, Xen guest = OpenVZ host. (Roughly, the Xen virtualization is for economics, the OpenVZ virtualization is for security. It's been working out very nicely for me thus far.) Most of my OpenVZ guest instances also run under Debian Etch at this point in time, again with no problems. I want to update this entire setup to Lenny. For my first stab at that, I upgraded just one OpenVZ guest to Lenny. This is guest 156. I have, of course, been installing the new libc6-xen version 2.7-18 in 156. As far as visible from within, the OpenVZ guest seems to be running fine. But one level below, at the OpenVZ host machine, I keep seeing log messages ... kernel: 4gb seg fixup, process ... (pid ...), cs:ip ... I interpret this as Xen is complaining that the libc6-xen is not being used, but the plain vanilla libc6 is. Checking the process ids, I found that the processes that use the wrong libc6 always belong to the Lenny VZ guest 156. Shutting down 156 makes the problem disappear. (But, obviously, the services 156 is intended to provide also disappear). I doublechecked with "ls -u", and indeed, 156 is using the wrong version of libc. The correct ones have not been read for several weeks: vzhost:/var/lib/vz/private/156/lib# ls -ltu i686/nosegneg/libc*so libc*so -rwxr-xr-x 1 root root 1294572 2009-03-04 10:43 libc-2.7.so -rw-r--r-- 1 root root 38296 2009-03-04 10:39 libcrypt-2.7.so -rwxr-xr-x 1 root root 1425828 2009-02-20 14:11 i686/nosegneg/libc-2.7.so -rw-r--r-- 1 root root 185816 2009-02-20 14:11 i686/nosegneg/libcidn-2.7.so -rw-r--r-- 1 root root 38296 2009-02-20 14:11 i686/nosegneg/libcrypt-2.7.so -rw-r--r-- 1 root root 185816 2009-02-20 14:11 libcidn-2.7.so This problem does not occur with the Etch libc6-xen version. For comparison, my Etch VZ guest 153 has that version, and it is being used. On that machine, it is the plain vanilla libc version that has not been read for several weeks: vzhost:/var/lib/vz/private/153/lib# ls -ltu libc*so tls/i686/cmov/libc*so -rw-r--r-- 1 root root 1253680 2009-03-04 11:18 tls/i686/cmov/libc-2.3.6.so -rw-r--r-- 1 root root 21868 2009-03-04 10:58 tls/i686/cmov/libcrypt-2.3.6.so -rwxr-xr-x 1 root root 1147548 2009-02-11 22:51 libc-2.3.6.so -rw-r--r-- 1 root root 181684 2009-02-11 22:51 libcidn-2.3.6.so -rw-r--r-- 1 root root 21868 2009-02-11 22:51 libcrypt-2.3.6.so -rw-r--r-- 1 root root 185780 2009-02-11 22:51 tls/i686/cmov/libcidn-2.3.6.so Regards, and thank you for providing fine software, Andreas The following information is about 156: -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-53.1.19.el5.028stab053.14xen (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-xen depends on: ii libc6 2.7-18 GNU C Library: Shared libraries libc6-xen recommends no packages. libc6-xen suggests no packages. -- no debconf information -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 559 1617 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 Jahre DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#275164: Sympa no longer available here - need to orphanate bugs.
Hello, Paul and all, it's been more than four years since I've filed my last Debian bug report on sympa. Shortly afterwards, my company has discontinued the use of that software. I frankly don't want to spend the time of messing with it again, just to support my ol' bug reports from back then. Plenty of other issues are dearer to my heart (and my boss's) to occupy my time then those. So, in effect, I orphan bugs 149285, 275001, 275012, 275147, and 275164. May they find some kind soul that actually uses sympa and can check the validity. Paul, a big thank you for finally attending to those old ones! Sorry I'm of no better help to the cause here. Best regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO NORDWEST GmbH andreas.krue...@dv-ratio.com GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO NORDWEST GmbH Tel: +49 (0)211 / 577 996-0 Fax: +49 (0)211 / 559 1617 http://www.dv-ratio.com <http://www.dv-ratio.com> Sitz der Gesellschaft Habsburgerstraße 12, 40547 Düsseldorf Registergericht Düsseldorf HRB 34330 USt-IdNr.: DE811321837 Steuer-Nr.: 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 Jahre DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#348641: TCP keepalive within redir
Hello, Daniel, to continue the discussion started at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348641 (and I've also added Nigel and Sammy to the CC): > It sounds like you're suggesting that redir use TCP keepalive > settings. Yes. > Have you considered using socat for your purposes? At this point, I no longer need to solve that particular problem that I used redir for. Should I ever have a problem like this again, and most such problems I tend to solve these days do involve TCP keepalive, I will strongly consider socat. Thank you for the suggestion! But you're loosing a customer here... ;-) > You may also be interested in libkeepalive: In my opinion, libkeepalive somewhat of a temporary hack. Good to have around in an emergency. But it definitely has a smell to it. But again, thank you for pointing that out. > Given these other options, if you still feel that this functionality > belongs in redir, please followup here and we'll sort it out. I take you on that offer: Yes. I still do feel that way. Firstly, let me make a case that TCP-keepalive is useful. For me, TCP connection redirection solves all kinds of little network problems. In the consumer end of these day's internet, dynamic IP is there to stay. UMTS and similar wireless communication is on it's way in. In general, there is a lot of connectivity that's offered on the market. Much of that is intended, by the providers, for "client" use. But that same network connectivity can be used be the creative for "server" service, too. To do so, one needs a little imagination, redir functionality, and some bridge-head-box out fixed-IP netland. Plus TCP-keepalive. Dynamic IP demands it. Wireless demands it. The ubiquitous NAT demands it. In all of these cases, "client" connections are somewhat flaky. That by itself is often not a big problem. It can be fixed if I hasten to rebuild the connection quickly, each time, after it came done. But in order to be able to do so, I need to find out about connection death. Which is exactly what I need TCP keepalive (or something like it) for. Personally, I use the ssh port forwarding functionality all the time. Almost literally "all the time", one particular such forwarding runs straight from my /etc/inittab ;-) . And I find something like "-o ServerAliveInterval=20 -o ServerAliveCountMax=7" essential in most such operations. Secondly, why would I expect this functionality particularily in redir? Well, of that I'm not entirely sure. It depends. How does redir position itself, in particular in comparison with socat? That one I'm not in a position to answer. That's up to Sammy, or Nigel, or you, or whoever presently "owns" redir. That said, I can make a suggestion. My suggestion would be: Redir focus is on the plain TCP/IP case. And redir does that case well. Whereas socat, in comparision, tries to cover all things socket (and even some things file descriptor), tries to be more universal, tries to be a jack-of-all-trades. But may not do any single one thing quite as well. This suggestion fits what I find. Redir already supports FTP proxy, which socat doesn't. Redir already supports bandwidth throttling, which socat doesn't. In my opinion, TCP keepalive is an issue that also belongs to redir and should be implemented by it. I would expect redir to do TCP keepalive, and would be surprised that socat does it, too. - Not the other way round, as is presently te case. This particular features generates quite a few command line options, yes. But it would not bloat the code much, could be implemented in a few hours (do you want me do do it?). And has less overall impact than either bandwidth throttling or FTP proxy did. Another difference between the two, by the way: Redir is much easier on the paranoid user. The source code of redir is about 1/8 of that of socat (in lines of code), and it is much easier to review. In my opinion, TCP keepalive simply fits extremely well into redir's present profile. Regards, Andreas -- Dr. Andreas Krüger, Berater, DV-RATIO Nordwest GmbH [EMAIL PROTECTED] GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 Sitz der Gesellschaft: Leostrasse 31, 40545 Düsseldorf, Germany Tel.: +49 211 577 996-0, Fax: +49 211 559 1617 Registergericht Düsseldorf HRB 34330 Ust-IdNr.: DE811321837, Steuer-Nr. 809/44031 Geschäftsführung: Günter Gerstmann Prokura: Trudbert Vetter, Uwe Wolfram 25 JAHRE DV-RATIO "ein Vierteljahrhundert Zuverlässigkeit" signature.asc Description: OpenPGP digital signature
Bug#348641: redir: Options to keep idle connection open with no-data packets.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: redir Version: 2.1-2.1 Severity: wishlist I am frequently using ssh with "-L" or "-R" for port forwarding. The general setup here includes NAT routers. I have seen problems with connection stability. Apparently, when no data was transmitted for some time, the NAT router would forget about the connection, essentially killing it. I now regularly use ssh options such as - -o ServerAliveInterval=20 -o ServerAliveCountMax=7 Those helped me out. They cause ssh to regularly transmit "no data" packets when the connection would otherwise be idle. In this way, the NAT state of the connection is kept alive. I have now set up a connection for my users using redir. There are reports about connection instabilities. The situation is not easy to debug, but we may be running into the same kind of problem that I have seen with ssh. I suggest that redir is augmented with options similar to the ssh ones. I understand that it is more difficult for redir to implement this feature than it was for ssh, as there is a ssh protocol, while redir is forced to speak plain TCP/IP. But I remember that it is possible, at the TCP/IP level, to send packets that contain no data, but ask the receiver to acknowledge the pacpacket. If that recollection is correct, implementing the feature should be possible. I would like the proposed options to differentiate: It should be possible to keep the client connection open, the server connection, or both. So two options. Each option gives the number of seconds of idleness after which a no-data packet is sent. As is true in the ssh case, after some number of packets have not been ack'ed, both parts of the redired connection should shut down. Those numbers should be configurable, again separately for client and server. So two more options, four in all. Regards, and thank you for providing fine software Andreas Krüger - -- Dr. Andreas Krüger, [EMAIL PROTECTED] GPG/PGP Fingerprint 8063 4A9B 362D 4220 A546 14C1 EA19 AADC FD44 5EB7 DV-RATIO Nordwest GmbH, Tel.: +49 211 577 996-0, Fax: +49 211 559 1617 Leostraße 31, 40545 Düsseldorf, Germany - -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages redir depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzfgT6hmq3P1EXrcRAmtTAJ9+NNYd3762YHk43K6A4KdoY9mcPwCfV8PJ A6bPRgpY/860hQ7XVRT1Itk= =ITyV -END PGP SIGNATURE-
