larryd@bnrmtl.bnr.ca (Larry Dunkelman) (04/04/91)
I have slip running between a 5820 and 3100 running Ultrix 4.0. It has been working fine until today. All of a sudden, I started to get the following : /etc/ping eden sendto: no buffer space available ping: wrote eden 64 chars, ret=-1 . . . ftp, telnet all give the same results. What buffer space is it referring to ? What does one do at this point? I posted a question a few days ago about restarting 'slip' but I didn't get any replies. It seems that after a failure with slip, the only way to get things going again is to reboot both machines. This is quite painful when one of the machines is being used by hoards of people. Any help would be most appreciated. Larry larryd!bnrmtl@larry.mcrcim.mcgill.edu
mra@searchtech.com (Michael Almond) (04/04/91)
In article <1991Apr3.210534.10734@scrumpy@.bnr.ca> larryd!bnrmtl@larry.mcrcim.mcgill.edu (Larry Dunkelman) writes: > >All of a sudden, I started to get the following : > >/etc/ping eden >sendto: no buffer space available >ping: wrote eden 64 chars, ret=-1 The only solution I found, like you, is to reboot the system. I suspect that garbaged packets are causing problems. -- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. mra@searchtech.com 4725 peachtree corners cir., suite 200 uupsi!srchtec!mra norcross, georgia 30092 (404) 441-1457 (office)
toivo@uniwa.uwa.oz (Toivo Pedaste) (04/04/91)
larryd@bnrmtl.bnr.ca (Larry Dunkelman) writes: >I have slip running between a 5820 and 3100 running Ultrix 4.0. It has >been working fine until today. All of a sudden, I started to get >the following : >/etc/ping eden >sendto: no buffer space available >ping: wrote eden 64 chars, ret=-1 >. >. >. I suppose I'll contribute some of my ignorance on the matter. When we were running slip across a 2400 baud line this would occur at times, in that case if you offed the interface for a while it would eventually go away. On a couple of 9600 baud lines that were connected directly to a uVax the problem didn't seem to occur, however when we moved one of these lines onto a Decserver it started happening regularly. My guess as to what is happening is the the buffer space refered to is a per interface limit on the number of data buffers outstanding and the message occurs when the data is being sent faster than it is able to be transmitted. There is a problem that this condition is not recovered from, possibly due to a bug in the networking code that doesn't usually show up because it is generally possible to transmit onto the ethernet faster than to send data into the network software. I have query outstanding with Dec support on the matter, since it was Dec that suggested the slip via decserver configuration would work. -- Toivo Pedaste ACSNET: toivo@uniwa.uwa.oz WARCC, INTERNET: toivo@uniwa.uwa.oz.au University of Western Australia Phone: (09) 380 2605
larryd@toby.bnr.ca (Larry Dunkelman) (04/05/91)
In article <1991Apr4.105809.12887@uniwa.uwa.oz> toivo@uniwa.uwa.oz (Toivo Pedaste) writes: . . >My guess as to what is happening is the the buffer space refered to is >a per interface limit on the number of data buffers outstanding and >the message occurs when the data is being sent faster than it is able >to be transmitted. There is a problem that this condition is not recovered >from, possibly due to a bug in the networking code that doesn't usually show >up because it is generally possible to transmit onto the ethernet faster >than to send data into the network software. > When I first got slip up, I transmitted a 21MB file. It was transferred in about 7 hours (9.6K baud line) with an effective transfer rate of 0.86K bytes / second. Not one packet error. Both systems were idle (except for the ftp). My problems started when one of the systems had some load. That doesn't correlate well with your hypothesis but I have nothing better to offer. It wouldn't be so bad if I could restart slip without rebooting both systems. By the way, does anyone know what the meaning of 'mtu' is (netstat -i) ? For my slip interface (sl0) I get a 'mtu' of 1006. Larry larryd!bnrmtl@larry.mcrcim.mcgill.edu ^^^^^ this is not named after me; its friends are mo and curly.
D. Allen [CGL]) (04/09/91)
>>/etc/ping eden >>sendto: no buffer space available >>ping: wrote eden 64 chars, ret=-1 Yes, we get this sometimes on VS3100 Ultrix 3.1 VAX as well when we temporarily unplug the Ethernet. We have to push the reset button and reboot to recover. -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
vince@bcsaic.UUCP (Vince Skahan) (04/11/91)
In article <1991Apr9.143251.3737@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >>>/etc/ping eden >>>sendto: no buffer space available >>>ping: wrote eden 64 chars, ret=-1 > >Yes, we get this sometimes on VS3100 Ultrix 3.1 VAX as well when we >temporarily unplug the Ethernet. We have to push the reset button and >reboot to recover. >-- >-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu > [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada if you give some qualifiers to ping/ you can work around it. /etc/ping hostname 56 1 (1 set of 56 byte packets) -- Vince Skahan vince@atc.boeing.com ...uw-beaver!bcsaic!vince (what is there in the construction of mobile homes that seems to attract tornadoes ??? )
jim@finnigan.UUCP (Jim Watt) (04/11/91)
The following (from Van Jacobson's installation notes on CSLIP) may well be relevant: |> (a) If you don't have the network code from the 4.3-tahoe bsd release, |> get and install it -- Earlier TCP's are almost unusable over serial |> lines because of problems with timeouts and buffer overflow. |> (The code is available for anonymous ftp from ucbarpa.berkeley.edu, |> files pub/4.3/tcp.tar and inet.tar.) I've been experimenting with dialupIP (highly recommended, available from uunet via anonymous FTP), and am seeing massive retransmissions under heavy load. The reason dialupIP is worth looking at is that you *REALLY CAN* make and break SLIP connections with it! The package was done by BBN, and is very well documented. There are a few gotchas about "vax" versus "ultrix" in some of the conditional code, but if you've been having trouble with DEC's SLIP, take a look! Jim -- James G. Watt Voice: +1 408 433 4800 Finnigan Corporation 355 River Oaks Pkwy. San Jose CA 95134-1991 jim@finnigan.uucp ...!ames!claris!wattres!finnigan!jim