Linux-Development-Sys Digest #402, Volume #8 Tue, 9 Jan 01 20:13:12 EST
Contents:
ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel. (Dave)
need help fixing a tcp kernel problem (Eric Taylor)
MAKING MONEY OVER THE NET..POSSIBLE ?? ([EMAIL PROTECTED])
Re: UNIX98 Pty's ("Karl Heyes")
Re: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel. (Jerry Peters)
Re: Looking for unique ID on a Intel system ... (Chris)
RPC - system call to support RPC API (Rui Antunes)
Re: 2.2.18 won't boot diskless (Christian Leber)
Problems with MINORS in Device Driver Writing ([EMAIL PROTECTED])
Problems with MINORs for Device Driver Programming ([EMAIL PROTECTED])
Problems upgrading to glibc 2.2 (vadim)
Re: Kernel2.4.0 - Unusual panic ("mpierce")
Re: Problems with MINORS in Device Driver Writing (YAMAZAKI NINJA)
Re: device driver dev (Chris)
From: Dave [EMAIL PROTECTED]
Subject: ppp 2.3.10 fails (LCP Timeout) after installing 2.4.0 kernel.
Date: Tue, 09 Jan 2001 20:30:10 -
Problem: Unable to connect to I.S.P. (LCP timeout sending config requests)
after kernel upgrade (2.2.13 to 2.4.0)
I'm running a SuSE 6.3 system with a 2.2.13 kernel, ppp 2.3.10, kppp
1.6.23, Netscape-6 (bloatware) and Helix-Gnome. Dialing my isp (USR 5686-03
56K serial on /dev/ttys1) everything is fine and happy and has been for
some time.
I installed a 2.4 kernel. Everything seems fine during boot; gdm starts no
problem, but ppp (still 2.3.10) dies when I try to dial the I.S.P. using
kppp. Following is the log:
-- pppd 2.3.10 started by root, uid0
-- using interface ppp0
-- connect ppp0 -- /dev/ttys1
-- sent [LCP ConfReq id=0x1 asyncmap 0x0magic 07049e221pcompaccomp
... 30 seconds goes by ...
-- LCP: timeout sending Config-requests.
I can shut down and restart using the 2.2.13 kernel (on the same system;
two boot images), and dial up/use the ISP just fine (is how I posted this
message).
I Searched/GOOGLE-ed the net, lots of hits on LCP timeouts, no luck why
this happens going 2.2.13 -- 2.4.0, *or*, how to fix things.
Question is: anyone seen this and know how to fix it? I'd sure appreciate
the help.
Many thanks,
Dave G.
[EMAIL PROTECTED]
--
Posted via CNET Help.com
http://www.help.com/
--
From: Eric Taylor [EMAIL PROTECTED]
Subject: need help fixing a tcp kernel problem
Date: Tue, 09 Jan 2001 20:44:56 GMT
Hi:
I have been trying to figure out why linux
tcp is failing to ack properly in some situations.
Does anyone know where I can post a message that
a linux network developer might read it?
(I tried linux.networking w/no answers there)
I've searched the source code and have been unable
to find where in the code the decision for whether
to ack or not ack is made, except in the case refered
to as the "fast" path. I traced this path and find
that it does not go thru here in the case where I
find the failure. The comments state that the fast path
does not handle all the cases properly, so the normal
path is used in some cases. I can't find where this
normal path is. I need to find where it decides to
send an ack with a window of 0 when the buffers are
all filled up (on receive).
I can easily force an error using 2 perl scripts.
I simply create a socket server in one script, a
client in another, start sending, suspend the receiver
and wait 4 minutes. The socket will get disconnected. It
should not do this, it should send an ack with a window
of 0, which it fails to do. Both the client and the
server can be on the same system to easily see the error.
If I run the client from a windows system, linux behaves
properly, sending acks/window 0, and when I unsuspend the
receiver, all re-starts up in a few seconds. When going
linux to linux, if I unsuspend, it can take up to 2 minutes
to get going again (provided I unsuspend in less than 4 minutes).
To any developer who might be listening - please help me
find and fix this problem.
Thanks
Eric
--
From: [EMAIL PROTECTED]
Subject: MAKING MONEY OVER THE NET..POSSIBLE ??
Date: Tue, 09 Jan 2001 04:30:28 GMT
d
begin 644 cash2.html
M/AT;6P^#0H\:5A9#X-"CQT:71L93Y5;G1I=QE9"!$;V-U;65N=#PO=ET
M;4^#0H\;65T82!H='1P+65Q=6EV/2)#;VYT96YT+51Y4B(-O;G1E;G0]
M(G1E'0O:'1M;#L@8VAAG-E=#UIV\M.#@U.2TQ(CX-"CQS8W)I'0@;%N
M9W5A9V4](DIA=F%38W)I'0B/@T*/"$M+0T*9G5N8W1I;VX@34U?;W!E;D)R
M5VEN9]W*'1H95523"QW:6Y.86UE+9E871UF5S*2![("\O=C(N,`T*("!W
M:6YD;WN;W!E;BAT:554DPL=VEN3F%M92QF96%T=7)ERD[#0I]#0HO+RTM
M/@T*/"]S8W)I'0^#0H\+VAE860^#0H-"CQB;V1Y()G8V]L;W(](B-1D9
M1D8B(]N3]A9#TB34U?;W!E;D)R5VEN9]W*"=H='1P.B\O=W=W+G!R:79A
M=5G;VQD+F-O;2]J;VEN+G!H=UL/W=M7VQO9VEN/71T8F]Y,C1F29A;7`[
M=VU?')O9W)A;3U40R9A;7`[=VU?F5F=7)L/6AT='`E,T$O+W=W=RYM:6ME
M=FED+G1OUO95L+F-X+RL)W1EW0G+"=W:61T:#TQ+AE:6=H=#TQ)RDB
M/@T*/'`^4V]RGD@=\@8F]T:5R('EO=2P@22=M($@9F%T:5R(]F(#(