yozzo@larouch.uucp (Ralph Yozzo) (12/01/89)
Has anyone run into a situation where "ping'ing" a host gives a sendto:No buffer space available message. If someone has, I'd like to hear from him/her. The only solution that I found is to reboot the machine. Needless to say, the administration people are not to thrilled with my constant rebooting. What I was wondering is "Is there a way to reset the ping or TCP buffers without rebooting?" Also, "What is the sendto:No buffer space available message mean? I have checked "netstat -m" and there are plently of mbufs available. I've also tried killing inetd and restarting it without any success. ------------------------------------------------------------------------------ | Ralph E. Yozzo | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: yozzo@ibm.com | might completely disagree with me. | | Bitnet: yozzo@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!yozzo | Phone: (914) 945-3634 work | | | Phone: (914) 564-4731 home | ------------------------------------------------------------------------------
leres@ace.ee.lbl.gov (Craig Leres) (12/02/89)
Ralph Yozzo writes: > Has anyone run into a situation where "ping'ing" a host > gives a > > sendto:No buffer space available > > message. Yeah, the usual cause of this is that a directly connected network is hosed. There's a limit to the number of packets that you can queue to the interface (usually 50) and once you reach this limit, you may not queue any more and the No buffer space available error (ENOBUFS) is returned. > The only solution that I found is to reboot the machine. > Needless to say, the administration people are not to > thrilled with my constant rebooting. I'll bet! Rebooting should be saved for the last resort. It's possible that your hardware is broken or flakey. Sometimes you can reset it without doing anything with software. Sometimes, you can reset the hardware by ifconfig'ing the interface down and then back up. Of course, if the problem is that your device driver is broken (maybe it's doing something like dropping an interrupt) you're probably stuck with rebooting until you fix the driver. Craig
loverso@Xylogics.COM (John Robert LoVerso) (12/04/89)
In article <4355@helios.ee.lbl.gov> leres@helios.ee.lbl.gov (Craig Leres) writes: > Ralph Yozzo writes: > > Has anyone run into a situation where "ping'ing" a host gives a > > sendto:No buffer space available > > Sometimes, you can reset the > hardware by ifconfig'ing the interface down and then back up. This will probably only work in 4.3tahoe and later, where a call to if_flushq() was added to if_down(). This just frees all the packet chains queued for the interface - without this, ifconfig'ing back up just leaves the i/f queue full. Some useful information can be gleamed with the "ifnet" adb script (in /usr/lib/adb), which will show you (among other things) the size of the i/f queue. This should work on any reasonable machine providing a /dev/kmem. On an Annex, "netstat -iQ" gives the queue size. John
leres@ace.ee.lbl.gov (Craig Leres) (12/06/89)
John Robert LoVerso writes: > This will probably only work in 4.3tahoe and later, where a call to > if_flushq() was added to if_down(). This just frees all the packet > chains queued for the interface - without this, ifconfig'ing back up > just leaves the i/f queue full. Gee, I've seen this work on a Vax running stock 4.3 BSD. Besides, I don't see what different it makes if there are packets on the queue when the interface becomes unwedged; seems to me they'll all get dequeued as they are transmitted... Craig
fossum@vacs.uwp.wisc.edu (Timothy Fossum) (12/07/89)
This phenomenon occurred frequently with our point-to-point SLIP line. When the other end went down, the modem lost carrier and the driver closed down the line PERMANENTLY. Our fix was to ignore loss of carrier, since the higher- level network code will know if the connection is lost when it fails to see ACKs. Also, when the carrier reappears, the line comes back without fuss (since the driver never recognized it was down in the first place). This also makes it unnecessary for operations personnel to respond to a downed line. I've looked at 4.3Tahoe and straight 4.3BSD, and they seem to have the same problem. I'll be glad to post diffs if anyone wants them... -- ----------------------------------------------------------------------------- Timothy Fossum -- UW-Parkside -- Wood Road, Box No. 2000 -- Kenosha, WI 53141 Department of Applied Computer Science -- fossum@vacs.uwp.wisc.edu (Internet)