Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm getting the following (sometimes) when I continuously ping (I'm doing so because my interface goes down randomly):
ping: sendmsg: no buffer space available
which originates from ENOBUFS coming back due to
132 ENOBUFS No buffer space available
An operation on a transport endpoint or pipe was not performed because the system lacked sufficient buffer space or because a queue was full.
How can I allocate sufficient buffer space or make sure the queue does not become full...?
This is a severe problem as the box is currently unusable as a server (or for anything else network related) due to its interface going down randomly with the above error.
I've found that the only way to get the box talking again is to ifdown / ifup the eth0 interface with ifconfig - nothing else works.
Just thought I'd report that it seems I've got this mitigated further or maybe licked in total!
It seems the buffer overflows I was experiencing was caused by a too long transmission queue length. I've changed the transmission queue length to 500 instead of the default 1000 by doing:
/sbin/ifconfig eth0 169.254.255.20 netmask 255.255.255.0 broadcast 169.254.255.255 txqueuelen 500 up
Now, if I run ifconfig I no longer have dropped packets:
Previously I had dropped packets indicated with a queue length of 1000. For the record, this is on a Gigabyte GA945PL-S3 motherboard with FC6 with a custom compiled 2.6.18.1 kernel with the
NIC as indicated by lspci. I'm running the RealTek Linux driver for this card.
I further also massively increased certain buffersizes that were autotuned by the kernel. I've not tested if the queue length was the deciding factor (it works, so I want to leave it as it is!) but I also did this:
Ok, I've dropped trying to get the Realtek RTL-8168B/8111 based Gigabit NIC on my GA-PL945-S3 motherboard working with Linux. I've disabled it in the BIOS and put in an older RTL-8139 based PCI NIC. Everything is working fine now, so my kernel and network setup IS fine. It is most probably a buggy linux driver from Realtek for the RTL-8168B/8111 NIC used onboard on this motherboard.
NOTE TO ALL - the R100v5.tgz driver from Realtek for the RTL-8168B/8111 gigabet ethernet adapter does not seem to work for Linux for the 2.6.18.1 kernel on the GA-945PL-S3 motherboard... causes ENOBUFS error.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.