"No buffer space available" problem. FreeBSD 4.7, mpd 3.17

Максим Чеусов chmax at kras.ru
Thu May 6 02:33:22 PDT 2004


Thursday, May 6, 2004, 4:28:29 PM, you wrote:

I tryed increase NMBCLUSTER, it didn't help.
How can i check if my connection work properly?


VEL> CMIIW, I once had the same problem, but in my other console the system said
VEL> about increasing my NMBCLUSTER value. So I did two things, perhaps you can
VEL> do the same. Do `arp -d -a' to clean up ARP cache, and Try increasing your
VEL> nmbcluster, if its value is not big enough. Try `sysctl -a | grep
VEL> nmbcluster' and look at its value. I use `65535'. This value cannot be
VEL> change interactively from shell, you must edit /boot/loader.conf and add
VEL> kern.ipc.nmbclusters=<value>. BUT other there's a possibility that the
VEL> connection was currently unstable, or down, or got network outage.

VEL> A couple days ago i've got next problem with my ISP (before everything
VEL> were ok). When connection to the VPN server is established then I can't
VEL> ping anything through the tunel even VPN server (192.168.10.1):

VEL> 64 bytes from 192.168.10.1: icmp_seq=503 ttl=64 time=0.634 ms
VEL> 64 bytes from 192.168.10.1: icmp_seq=504 ttl=64 time=0.689 ms 
VEL> 64 bytes from 192.168.10.1: icmp_seq=505 ttl=64 time=0.645 ms 
VEL> 64 bytes from 192.168.10.1: icmp_seq=506 ttl=64 time=0.664 ms 
VEL> ping: sendto: Resource deadlock avoided 
VEL> ping: sendto: Resource deadlock avoided 
VEL> ping: sendto: No buffer space available 
VEL> ping: sendto: No buffer space available 
VEL> ping: sendto: No buffer space available 
VEL> ping: sendto: No buffer space available 
VEL> ping: sendto: No buffer space available 
VEL> ping: sendto: No buffer space available 
VEL> ping: sendto: No buffer space available 

VEL> In moment when mdp connetction established ping response is over.
VEL> There is tcpdump -i ng0:
VEL> tcpdump: listening on ng0
VEL> 12:23:40.489990 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:41.499975 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:42.509985 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:43.519997 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:44.530011 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:45.540022 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:46.550046 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:47.560053 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:48.570068 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:49.580084 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:50.590127 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:51.600118 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:52.610151 192.168.100.102 > 192.168.10.1: icmp: echo request
VEL> 12:23:53.620149 192.168.100.102 > 192.168.10.1: icmp: echo request

VEL> Seems like nothing can get through the tunnel.
VEL> netstat -m:
VEL> 196/1328/3328 mbufs in use (current/peak/max):
VEL>         193 mbufs allocated to data 
VEL>         3 mbufs allocated to packet headers 
VEL> 192/236/832 mbuf clusters in use (current/peak/max) 
VEL> 1304 Kbytes allocated to network (52% of mb_map in use) 
VEL> 652 requests for memory denied 
VEL> 15 requests for memory delayed 
VEL> 29 calls to protocol drain routines 

VEL> Looks like no any problem here.
VEL> I'v red someting similar about Cisco VPN servers, but solution that
VEL> were given did'n help me.

VEL> ifconfig:
VEL> xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
VEL>         options=3<rxcsum,txcsum> 
VEL>         inet 192.168.10.12 netmask 0xffffff00 broadcast 192.168.10.255
VEL>         ether 00:01:02:ca:0c:24 
VEL>         media: Ethernet autoselect (100baseTX <full-duplex>) 
VEL>         status: active 
VEL> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
VEL>         inet 192.168.0.10 netmask 0xffffffc0 broadcast 192.168.0.63
VEL>         ether 00:a0:c9:69:91:8a 
VEL>         media: Ethernet autoselect (100baseTX <full-duplex>) 
VEL>         status: active 
VEL> lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 
VEL> faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500 
VEL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 
VEL>         inet 127.0.0.1 netmask 0xff000000 
VEL> ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 
VEL> sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552 
VEL> ng0:
VEL> flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu
VEL> 1500 
VEL>         inet 192.168.100.102 --> 192.168.10.1 netmask 0xffffffff 

>>mpd.comf:
VEL> default: 
VEL>         load vpn 
VEL> vpn: 
VEL>         new -i ng0 ciscovpn pptp192 
VEL>         set bundle authname "*******" 
VEL>         set ipcp ranges 192.168.100.102 192.168.10.1 
VEL>         set iface up-script /usr/local/etc/mpd/iface-up.sh 
VEL>         load vpnpptp 
VEL>         open 
VEL> vpnpptp: 
VEL>         set bundle disable compression 
VEL> #       set bundle no crypt-reqd 

VEL>         set bundle enable compression 
VEL>         set ccp yes mppc 
VEL>         set ccp yes mpp-e40 
VEL>         set ccp yes mpp-e128 
VEL>         set bundle enable crypt-reqd 
VEL>         set ccp yes mpp-stateless 

VEL>         set iface idle 0 
VEL>         set ipcp disable vjcomp 
VEL>         set ipcp enable req-pri-dns req-sec-dns 
VEL>         set link max-redial 1 
VEL>         set link keep-alive 0 0 
VEL>         set link disable pap chap 
VEL>         set link disable acfcomp protocomp 
>> end

>>mpd.links
VEL> pptp192: 
VEL>         set link type pptp 
VEL>         set pptp peer 192.168.10.1 
VEL>         set pptp enable originate outcall 
>> end


>>iface-up.sh
VEL> #!/bin/sh 

VEL> iface=$1 
VEL> proto=$2 
VEL> localip=$3 
VEL> remoteip=$4 
VEL> vpn_private_ip=192.168.10.1

VEL> ifconfig $iface $proto $localip $vpn_private_ip netmask 0xffffffff
VEL> ifconfig $iface mtu 1500 
VEL> route flush 
VEL> route add default -interface $iface 
>> end

VEL> And there is nothing strange in mpd.log also
VEL> As far as I know on the ISP side is mdp-3.17 and FreeBSD too.
VEL> And there is no any problems whith XP box.





More information about the freebsd-net mailing list