Re: mpd, ng, Cisco VPN, resource leak

Hi Christoph

On Monday 16 June 2003 16:03, Christoph Kukulies wrote:
> 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_at_www$ ssh acc01
> ssh: connect to host acc01 port 22: Connection refused
> kuku_at_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?

I know exactly what you are talking about. I had the same problems here.

Please have a look at http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn/ .

That (partly) solved the problems for me, however I have to set the routes to 
the subnets behind the VPN-server manually after establishing a connection to 
the VPN-server via mpd. 

If I set the routes in the mentioned script, the routingtable seems to be ok, 
but setting the routing entrys this way leads to the same problems you 
already mentioned. I have no idea whats wrong and why I have to set them 
manually.

Perhaps we can figure out this minor last problem together.

Best Regards,

Markus

-- 
GPG Pub-Key    : http://www.phoenix-systems.de/mbrueffer.asc
GPG Fingerprint: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4
GPG Key ID     : 0x78F8A8D4