Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!swrinde!cs.utexas.edu!uwm.edu!ogicse!usenet.ee.pdx.edu!pdxgate!parsely!agora!implode!davidg From: davidg@implode.rain.com (David Greenman) Newsgroups: comp.os.386bsd.bugs Subject: Re: Ping problem Message-ID: <C6rIt5.1wp@implode.rain.com> Date: 9 May 93 13:58:16 GMT Article-I.D.: implode.C6rIt5.1wp Organization: Delta Systems, Portland, OR. Lines: 37 wittlin@sci.kun.nl (Aleksander Wittlin) writes: >I get a strange message from ping ( 486 8Mb, 0.1+patchkit 0.2.2 + we0 ): >ping machine.xx.xx >ping: wrote machine.xx.xx 64 chars, ret -1 >ping: sendto: No buffer space available Since several people have asked me questions about this problem in email, it seems appropriate that I should post a response to the net. In my last response about this, I made an assumption that the problem is related to SLIP, even though nothing was said about it in the original posting...well... I just looked through the code that I released, and it appears that I'm mistaken - the release to the world of the SLIP driver *does* have the check for queue depth. It does, however, return ENOBUFS when the queue max is reached. What this means is that whenever the traffic on the SLIP net gets real high (as in *many* active connections), this problem will show itself. The solution should be the same, though - increase the ifq_maxlen parameter from the default of 50 to something somewhat higher. This assumes that the problems you are having are transient. If instead they last for an extended period, this would suggest that the packets are backing-up in the queue for other reasons (like CTS being off for long periods of time in the case of SLIP). I wouldn't recommend changing this system wide - rather I would try testing a change with individual devices. The variable if_snd.ifq_maxlen (in the ifnet structure, I believe) is what gets checked, and it is usually initialized in /sys/net/if.c. SLIP is an exception to this, though - it inits this variable itself (hardcoded to 50). Another thing you could try would be to increase the SLIP MTU. Note that because the MCLBYTES param is normally 1024 bytes, that the MTU will never exceed this (in fact the kernel will panic if the SLIP MTU is set to more than about 950). It is likely that the interim release of 386BSD (0.1.5) will have this changed to 2048. With it at 1024, even ethernet traffic is forced to use small packets - in some cases fragmenting them to 1024 and 500 (approx). What I've said above might not have anything to do with your specific problem. :-) So take it as advisory. -DG