ping: sendto: No buffer space available

pcace

Dabbler
Joined
Jan 10, 2022
Messages
15
Hi there, i have a problem with my TrueNAS instance:
it does not have internet access - but is reacable from LAN. since this error is not there always its hard for me to even find a way how to narrow the problem down. I think it has to do with my openvpn client installation - but i am not too sure.
Is this a known error? the only thing i can figure out is that there is some kind of buffer error:

ping: sendto: No buffer space available

What can i do to fix this? Any Idea?

Here is my ovpn client config. normally everything works fine. very strange!

Cheers and thanks!


Maybe that helps?
root@hugo[~]# netstat -m
322/4748/5070 mbufs in use (current/cache/total)
256/2464/2720/997810 mbuf clusters in use (current/cache/total/max)
256/2021 mbuf+clusters out of packet secondary zone in use (current/cache)
1/563/564/498904 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/147823 9k jumbo clusters in use (current/cache/total/max)
0/0/0/83150 16k jumbo clusters in use (current/cache/total/max)
596K/8367K/8963K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
406 sendfile syscalls
385 sendfile syscalls completed without I/O request
31 requests for I/O initiated by sendfile
198 pages read by sendfile as part of a request
3839 pages were valid at time of a sendfile request
0 pages were valid and substituted to bogus page
0 pages were requested for read ahead by applications
329 pages were read ahead by sendfile
0 times sendfile encountered an already busy page
0 requests for sfbufs denied
0 requests for sfbufs delayed
root@hugo[~]# ping google.de
root@hugo[~]# sysctl net.inet.tcp.reass ; vmstat -z | egrep "FREE|mbuf|tcpre"
net.inet.tcp.reass.queueguard: 16
net.inet.tcp.reass.new_limit: 0
net.inet.tcp.reass.maxqueuelen: 100
net.inet.tcp.reass.cursegments: 0
net.inet.tcp.reass.maxsegments: 62416
ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
mbuf_packet: 256, 6385980, 256, 2021,270545385, 0, 0
mbuf: 256, 6385980, 68, 2725,1048435126, 0, 0
mbuf_cluster: 2048, 997810, 2277, 443, 28336, 0, 0
root@hugo[~]# ifconfig
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
ether ac:22:0b:50:2f:ca
inet 192.168.1.60 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=1<PERFORMNUD>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=0<> metric 0 mtu 33160
groups: pflog
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 10.8.0.9 --> 10.8.0.1 netmask 0xffffff00
inet6 fddd:xxxx:xxxx:xxxx::1007 prefixlen 64
groups: tun
nd6 options=1<PERFORMNUD>
Opened by PID 48719
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:fe:47:21:d9:00
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto stp-rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 1 priority 128 path cost 20000
groups: bridge
nd6 options=1<PERFORMNUD>
root@hugo[~]#
 

Attachments

  • Bildschirmfoto 2022-02-14 um 20.38.20.png
    Bildschirmfoto 2022-02-14 um 20.38.20.png
    1.1 MB · Views: 135
Last edited:

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
No buffer space is a common issue with certain types of ethernet cards, including Realtek, often when the link state is flapping, but sometimes "just 'cuz". Try "ifconfig re0 down; ifconfig re0 up" to clear the condition. If this clears it, inspect the logs to see if you are getting kernel link state flapping messages.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
See for ex

 

pcace

Dabbler
Joined
Jan 10, 2022
Messages
15
Hmm, i did look at the logs for the last days and could not find any up downs.
But i also enabled kernel - autotune. it sounded like the right thing to do ;)
Why does it say its not safe to use?
Cheers and Thanks for Help!
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
I don't even know what the point of autotune is. They added it to try to automatically tweak stuff, but some of the tweaks are just wrong, everybody including the developers have said not to use it at one point or another, and yet it is still there in the system after all these years.
 

pcace

Dabbler
Joined
Jan 10, 2022
Messages
15
Hi There, i am back with the same Problem as before.
I really cannot figure the Problem out: i have installed a new Network card, and do get the same errors again, but only when enabling the openVPN client. Its seems very strange:
first everything works (for around a day), then i do get the same behavior again: i have access to lan without any problem, but have no connection outside. the problem seems to be the buffer problem from before:

PING google.de (142.251.36.227): 56 data bytes
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
the weird thing is, that i can ping internally without any problem!?:
ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=1.476 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.576 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.694 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.963 ms

when i turn of the openvpn client, everything imidiately works.
How can i figure out waht the Problem is?

Cheers,

Pcace

Here is the syslog:
 
Last edited:
Top