From owner-freebsd-current@FreeBSD.ORG Mon Jun 16 07:03:58 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C0B837B401 for ; Mon, 16 Jun 2003 07:03:58 -0700 (PDT) Received: from accms33.physik.rwth-aachen.de (accms33.physik.RWTH-Aachen.DE [137.226.46.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F4143FA3 for ; Mon, 16 Jun 2003 07:03:57 -0700 (PDT) (envelope-from kuku@accms33.physik.rwth-aachen.de) Received: (from kuku@localhost) by accms33.physik.rwth-aachen.de (8.11.6/8.9.3) id h5GE3tJ28411 for freebsd-current@freebsd.org; Mon, 16 Jun 2003 16:03:55 +0200 Date: Mon, 16 Jun 2003 16:03:55 +0200 From: Christoph Kukulies Message-Id: <200306161403.h5GE3tJ28411@accms33.physik.rwth-aachen.de> To: freebsd-current@freebsd.org Subject: mpd, ng, Cisco VPN, resource leak X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2003 14:03:58 -0000 For months I'm trying to get back to a working VPN using mpd on a FreeBSD 4.4 client site and a Cisco VPN server on the peer end. With 5.0 and 5.1-current the network connection stopped working. I could work for a minute or so then the connection got hung. Trying to reconnect with a new ssh session got some message about 'resource deadlock avoided' and a subsequent ping to the peer side gets the onminous 'no buffers space available' or an additional : kuku@www$ ssh acc01 ssh: connect to host acc01 port 22: Connection refused kuku@www$ ping acs01 PING acc01 (138.134.123.12): 56 data bytes ping: sendto: Resource deadlock avoided ping: sendto: No buffer space available ping: sendto: No buffer space available ^C --- acc01 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss The connection refused occurs on the peer side where the previous ssh connection had succeeded. It's not that the sshd died. Rebooting my system allows be to connect again for a minute or 2 and then again the hang. How could I pinpoint the problem so that some knowing kernel/netgraph person will be available to find the cause? Is there a way to do a continous netstat -m or vmstat -m during a session setup? I mean other than writing it to a file in a shell while loop? -- Chris Christoph P. U. Kukulies kukulies@rwth-aachen.de