🚀 go-pugleaf

In article <2j20v9$3tt@harbinger.cc.monash.edu.au> mike@starbug.apana.org.au writes:
>Most people seem to have common symptoms: connecting and setting up
>the interface working fine, but tcp connections mysteriously 'dying'
>after a certain amount of time and/or data transfer.  I put my
>circumstances, since they seem to be fairly typical, although
>others may differ slightly, particularly some people seem to get
>tcp leak messages, whereas others do not.
>
I've had the same problem under 14w.  SLIP would run great for about
3 hours and then I'd suddenly lose carrier and the modem would hangup.
FTP transfers would work fine until the end of those 3 hours.  I was
only 'get'ting files though.  Haven't tried 'put'ting.  Will tomorrow

This was happening with a USR Sportster (The Gateway OEM).  I recently
switched from the loaner to a Zoom and haven't had any disconnections.
I don't have call waiting so that isn't a factor.  My longest connection
with the Zoom was ~7 hours and I was FTPing 15-20 megs of files.  Could
SLIP be hardware sensitive??

-- 
 /------------------------------+--------------------------------------\
| Carlo J. Calica               | Linux:  Choice of the GNU Generation  |
|     calica@cae.wisc.edu       | Dittos from the People's              | 
 \ University of Wisconsin      | Republic of Madison                  / 

In article <2j20v9$3tt@harbinger.cc.monash.edu.au> mike@starbug.apana.org.au writes:
>First, a description of my setup
>
>        80386-40, no co-pro
>        4Mb RAM
>        IDE HD, single controller, ext2 fs
>        vanilla serial board, 16450 uarts
>        ALPHA-pl14{p,x,z} pl15
>        gcc 2.5.7, libc 4.5.8, ld.so 1.3
>        net2debugged, latest 'route' from nic.funet.fi
>
>I have spoken to several people, and followed some discussion in the
>linux newsgroups, and it seems that very few people (if any) have
>SLIP successfully working with any kernels after about pl14u (it
>definitely broke somewhere between u and x inclusive).
>
>  ..... more details omitted
>
>Is this a known problem? Is there a fix? Do any people have SLIP
>working flawlessly under pl15?
>
>Any help appreciated.
>
> - Mike
>
>

For what it's worth I have a very similar setup except that I have libc 4.5.10
and a 16550A uart.  This works fine in all circumstances so far, including
getting files > 1Mb .  This MAY be an MTU problem somewhere down the line,
try reducing your MTU on sl0 to errr .. 950?  (1500 works OK here).

Graham
-- 
****************************************************************************
 Graham Adams - Takelap Systems Ltd. - gadams@ddrive.demon.co.uk
 tel: +44 (0)291 650357       bbs +44 (0)291 650567       fax: +44 (0)291 650500

Mike Battersby (ins122a@lindblat.cc.monash.edu.au) wrote:
: First, a description of my setup

:         80386-40, no co-pro
:         4Mb RAM
:         IDE HD, single controller, ext2 fs
:         vanilla serial board, 16450 uarts
:         ALPHA-pl14{p,x,z} pl15
:         gcc 2.5.7, libc 4.5.8, ld.so 1.3
:         net2debugged, latest 'route' from nic.funet.fi

: I have spoken to several people, and followed some discussion in the
: linux newsgroups, and it seems that very few people (if any) have
: SLIP successfully working with any kernels after about pl14u (it
: definitely broke somewhere between u and x inclusive).

Something changed for 14x and beyond. If you use dip, then try setting 
the mtu to 512, this seems to have fixed things here. 

BTW, This problem only showed with NNTP across a SLIP link, 
ftp etc worked ok with an MTU of 1500. 14x gave tcp memory leak messages.

Steven
 

ins122a@lindblat.cc.monash.edu.au (Mike Battersby) writes:

[about SLIP]

>For me, tcp connections will mysteriously stop trasmitting data. This is
>intermittent with 'telnet' and 'rlogin', and seemingly better (although
>perhaps this is only an illusion) with pl14z and pl15 over pl14x. 'ftp'
>connections, however, will *always* die after transferring <25k of data.
>They do not disconnect, but data ceases to come through (netstat still
>shows 'ESTABLISHED').  This only occurs when sending to the Linux box,
>...

I agree 100%, I was seeing precisely the same symptoms with mtu 1500.
However, with mtu 500 the predictable hang of tcp (for me after 26112 bytes)
has disappeared. Only intermittent (and not very frequent) hangs of
telnet and rlogin remain.

An interesting experiment is to try  ping -s nnnn  and see what happens.
(For me, with mtu 1500: ping -s S hangs after N packets:
	S	N
	485	54
	500	53
	600	45
	700	40
	800	35
	900	32
	1000	29
	1200	24
	1400	20
	1500	20
	1600	19
	3000	10
this shows clearly that the packet size is irrelevant, only the total
number of bytes transferred counts. On the other hand, ping -s 484
runs indefinitely (and the same holds for ping -s S with S < 484).)

Andries

linux@blzbub.demon.co.uk (Steven Fletcher) writes:
>Mike Battersby (ins122a@lindblat.cc.monash.edu.au) wrote:
>: First, a description of my setup
>
>:         80386-40, no co-pro
>:         4Mb RAM
>:         IDE HD, single controller, ext2 fs
>:         vanilla serial board, 16450 uarts
>:         ALPHA-pl14{p,x,z} pl15
>:         gcc 2.5.7, libc 4.5.8, ld.so 1.3
>:         net2debugged, latest 'route' from nic.funet.fi
>
>: I have spoken to several people, and followed some discussion in the
>: linux newsgroups, and it seems that very few people (if any) have
>: SLIP successfully working with any kernels after about pl14u (it
>: definitely broke somewhere between u and x inclusive).
>
>Something changed for 14x and beyond. If you use dip, then try setting 
>the mtu to 512, this seems to have fixed things here. 
>BTW, This problem only showed with NNTP across a SLIP link, 
>ftp etc worked ok with an MTU of 1500. 14x gave tcp memory leak messages.

Yes I do use dip, v3.3.7, and have been using the default mtu of 296,
as well as trying 500, both with no success. The problems are
generally only noticable with ftp, which always dies, although
occasionally telnet/rlogin will die also..

 - Mike

ins122a@lindblat.cc.monash.edu.au (Mike Battersby) writes:
<soul-rending description of SL/IP woes.

>So, I ask:

>Is this a known problem? Is there a fix? Do any people have SLIP
>working flawlessly under pl15?

Yeah, works fine for me.  Your problems remind me of MTU problems I was
having a while ago (MTU > 512 resulted in mysterious freezes) but with my
new modem (PPI PM14400FXMT) it all went away, and now I can set MTU to
1500 like the SL/IP server on the other end wants...

There was a discussion on the uiuc linux newsgroup about this regarding
prblems with the uiuc servers, I think the reason for the hangs was that
hardware flow control was not properly set up on the local modem...  But I
was using the pl15 code yesterday to telnet and read news simultaneously
with FTP'ing the new libc, gcc2.5.8, libg++, and a few other things, so I
think I gave it a good workout :)

There was an article in .help or .misc yesterday that pointed out that
the way the kernel handles MTU changed recently, mabye that is the cause
of your difficulties. 

-Ken
 
-- 
______________________________________________________________________________

Kenneth L. Hamer
khamer@uxa.cso.uiuc.edu

[ Re: All my problems ]

Fixed, all fixed !!!
A one line kernel patch to remove

       skb->lock = 1;

from ip.c fixed everything... Note that the just released pl15a also
has this fix!

Thanks to everyone for all thier help in sorting this out..

 - Mike

Mike Battersby (ins122a@aurora.cc.monash.edu.au) wrote:
: [ Re: All my problems ]

: Fixed, all fixed !!!
: A one line kernel patch to remove

:        skb->lock = 1;

: from ip.c fixed everything... Note that the just released pl15a also
: has this fix!

: Thanks to everyone for all thier help in sorting this out..

Bah.. ALl these problems with the standard networking in Linux..

Beta-4 is sitting there running REALLY REALLY well and stable..
I haven't had a crash AT ALL.. and ive been running beta-4 since
last week..

Hmm.. I wish someone would get the two camps to talk and get the
fixed code into the kernel.

-- 
root@lsupoz.apana.org.au   APANA Sydney UUCP regional hub (feeds available)
Anthony Rumble             Linux Support OZ (02) 418-8750 v.32bis - 3 lines
Voice (02) 418-8220	   For information on APANA mail info@apana.org.au

Try pl15a it should solve the problem.

Volkmar

--
==============================================================================
Volkmar Eich                                        Internet: ve@nils.rhein.de
Attenberger Strasse 44                              Telefon: (02248) 4825
53773 Hennef
Germany
==============================================================================

Anthony Rumble (smilie@lsupoz.apana.org.au) wrote:
: Mike Battersby (ins122a@aurora.cc.monash.edu.au) wrote:
: : [ Re: All my problems ]

: : Fixed, all fixed !!!
: : A one line kernel patch to remove

: :        skb->lock = 1;

: : from ip.c fixed everything... Note that the just released pl15a also
: : has this fix!

: : Thanks to everyone for all thier help in sorting this out..

: Bah.. ALl these problems with the standard networking in Linux..

: Beta-4 is sitting there running REALLY REALLY well and stable..
: I haven't had a crash AT ALL.. and ive been running beta-4 since
: last week..

: Hmm.. I wish someone would get the two camps to talk and get the
: fixed code into the kernel.

: -- 
: root@lsupoz.apana.org.au   APANA Sydney UUCP regional hub (feeds available)
: Anthony Rumble             Linux Support OZ (02) 418-8750 v.32bis - 3 lines
: Voice (02) 418-8220	   For information on APANA mail info@apana.org.au



Could someone explain to me what BETA-4 for is (exept from being a benavolent
planet in the rigus 12 system)


--



		Ron Smits
		ron@draconia.hacktic.nl
		Ron.Smits@Netherlands.NCR.COM

/*-( My opinions are my opinions, My boss's opinions are his opinions )-*/
/*-(                They might not be the same                         -*/