Kernel Woes: Comments, Please!
I am running two different machines, a two-year-old Gateway 300L business system and an HP Pavilion notebook I use for a network station, on occasion. This note concerns multitudinous ppp problems which, I believe, can be traced right down to the kernel. Both machines are currently running SuSE 9 Pro, though I have tried v9.1 & v9.2 on both ...with disastrous results. Details follow. It seems that both machines run ppp without problems unless and until upgraded --whether completely, or just the kernel. Even a kernel-2.4.21-266 upgrade causes all throughput to cease when connected to the internet. This is the case, also, when either box runs 9.1 or 9.2 'out of the box'. Upgrades within those two versions are no help. The only difference between SuSE 9 Pro and SuSE 9.1 or 9.2 is the fact that out of the box installations of both do not completely break ppp but the throughput is extremely sporadic compared to SuSE 9. Even getting e-mail is an extremely_lengthy process. In the latest test, I upgraded the kernel-2.4.21-99-default to kernel-2.4.21-266-default on each machine and, when I connected to the internet, there was a connection but absolutely no modem throughput. Attempts to get e-mail, surf the web or any other web activity resulted in errors rather than loading or downloading anything. The file, resolv.conf, contained the proper parameters, same as any stock installation of any of the three versions. The evidence is conclusive. I have been conducting these tests since SuSE 9 Pro was released on CD-Rs/DVDs, on through the next two successive releases. I believe that any kernel beyond v2.4.21-99 is broken. I have run the tests several times, with the exact same results. The tests have also been run using the exact same modem & setup parameters for that modem. Remember, I'm taking about two different machines from two different mfrs, and the exact same results using both or either. I would be most interested in observations prior to my reporting it to SuSE. Thanks! -- ..."Yogi" CH Namasté Yoga Studio
The Friday 2005-01-14 at 18:08 -0600, C Hamel wrote:
I am running two different machines, a two-year-old Gateway 300L business system and an HP Pavilion notebook I use for a network station, on occasion. This note concerns multitudinous ppp problems which, I believe, can be traced right down to the kernel. Both machines are currently running SuSE 9 Pro, though I have tried v9.1 & v9.2 on both ...with disastrous results. Details follow.
It seems that both machines run ppp without problems unless and until upgraded --whether completely, or just the kernel. Even a kernel-2.4.21-266 upgrade causes all throughput to cease when connected to the internet. This is the case, also, when either box runs 9.1 or 9.2 'out of the box'. Upgrades within those two versions are no help. The only difference between SuSE 9 Pro and SuSE 9.1 or 9.2 is the fact that out of the box installations of both do not completely break ppp but the throughput is extremely sporadic compared to SuSE 9. Even getting e-mail is an extremely_lengthy process.
I'll concur here. I have a P-IV machine with an external modem. When running SuSE 8.2 or older, I get downloads speeds around 5 kbytes per second, sustained. Soon after I upgraded to SuSE 9.1 last June, I noticed that the download speed was not constant, it varied a lot, from 6 kbytes to nothing, with long pauses, averaging around 1.5 kbytes per second. Mail download is a real pain: it may pause up to a minute or more, causing the pop connection to timeout, fail and repeat download, causing repeated mails. I have got to limit it to 30 emails at a time. This I reported in length time ago. No solution. I also tested with a knopix on CD, and the results were very similar (ie, very slow modem). I did all tests with the exact same hardware, and with two different ISPs. Currently I do my connections plugging my modem into an old pentium 130 machine, loaded with SuSE 7.3, which acts as access router for the fast P-IV machine with 9.1: then I get 5-6 kbytes per second. Definitely there is a problem with modem software (standard serial port modem), either the ppp daemon or the kernel, I don't know, and not limited to SuSE only. This was reported to feedback time ago, but it seems, as 9.2 appears to have the same problem, that it has not been solved; I wonder whether SuSE consider modem users should be ignored! :-/ -- Cheers, Carlos Robinson
On 01:37 Sat 15 Jan , Carlos E. R. wrote:
The Friday 2005-01-14 at 18:08 -0600, C Hamel wrote:
I am running two different machines, a two-year-old Gateway 300L business system and an HP Pavilion notebook I use for a network station, on occasion. This note concerns multitudinous ppp problems which, I believe, can be traced right down to the kernel. Both machines are currently running SuSE 9 Pro, though I have tried v9.1 & v9.2 on both ...with disastrous results. Details follow.
It seems that both machines run ppp without problems unless and until upgraded --whether completely, or just the kernel. Even a kernel-2.4.21-266 upgrade causes all throughput to cease when connected to the internet. This is the case, also, when either box runs 9.1 or 9.2 'out of the box'. Upgrades within those two versions are no help. The only difference between SuSE 9 Pro and SuSE 9.1 or 9.2 is the fact that out of the box installations of both do not completely break ppp but the throughput is extremely sporadic compared to SuSE 9. Even getting e-mail is an extremely_lengthy process.
I'll concur here. I have a P-IV machine with an external modem. When running SuSE 8.2 or older, I get downloads speeds around 5 kbytes per second, sustained. Soon after I upgraded to SuSE 9.1 last June, I noticed that the download speed was not constant, it varied a lot, from 6 kbytes to nothing, with long pauses, averaging around 1.5 kbytes per second. Mail download is a real pain: it may pause up to a minute or more, causing the pop connection to timeout, fail and repeat download, causing repeated mails. I have got to limit it to 30 emails at a time.
This I reported in length time ago. No solution.
I also tested with a knopix on CD, and the results were very similar (ie, very slow modem).
I did all tests with the exact same hardware, and with two different ISPs.
Currently I do my connections plugging my modem into an old pentium 130 machine, loaded with SuSE 7.3, which acts as access router for the fast P-IV machine with 9.1: then I get 5-6 kbytes per second.
Definitely there is a problem with modem software (standard serial port modem), either the ppp daemon or the kernel, I don't know, and not limited to SuSE only.
This was reported to feedback time ago, but it seems, as 9.2 appears to have the same problem, that it has not been solved; I wonder whether SuSE consider modem users should be ignored! :-/
I would say, 'ignore modem users at your peril' since ppp is available in the kernel & distro. If they want to pull it out & take the chance that people won't yell... go for it. What I didn't point out was, I have also used Gentoo & Knoppix and seen the same problem. -- ..."Yogi" CH Namasté Yoga Studio
C Hamel wrote:
I would say, 'ignore modem users at your peril' since ppp is available in the kernel & distro. If they want to pull it out & take the chance that people won't yell... go for it.
ppp is also used for other things than standard dialup modem connections. Have you tried running ppd with debug on - to see what is actually happening on the line? If your modems are not winmodems (where some of the modem work is "offloaded" to the CPU), there is no reason why the system should/could make the connection slower. To give people a chance to help you, we need to know some some basics - which kind of modem are you using? What is your connection speed to your provider? /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - sign up for your free 30-day trial now! http://www.spamchek.de/freetrial - jetzt für 30 Tage ausprobieren - kostenlos und unverbindlich! http://www.spamchek.dk/freetrial - 30 dages gratis prøvetid - helt uden forpligtelser!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2005-01-15 at 10:23 +0100, Per Jessen wrote:
I would say, 'ignore modem users at your peril' since ppp is available in the kernel & distro. If they want to pull it out & take the chance that people won't yell... go for it.
ppp is also used for other things than standard dialup modem connections.
True.
Have you tried running ppd with debug on - to see what is actually happening on the line?
Yes... it is permanently enabled since August. debug kdebug 1
If your modems are not winmodems (where some of the modem work is "offloaded" to the CPU), there is no reason why the system should/could make the connection slower.
No, mine is a standard serial port external modem, complete, and works pretty fast with SuSE versions up to 8.2 with the same ISP, phone lines, computer, and configuration. Let me see, I reported this in full time ago, this summer. A link to the thread: http://lists.suse.com/archive/suse-linux-e/2004-Jul/3411.html
To give people a chance to help you, we need to know some some basics - which kind of modem are you using? What is your connection speed to your provider?
Serial modem, standard hayes, 3COM usr robotics 56K. Connection string:
CONNECT 50666/ARQ/V90/LAPM/V42BIS
- --> Carrier detected. Starting PPP immediately.
Note that the speed reported there is the real speed, modem to outside,
not the speed of the serial port to the computer. I configured it that way
long ago.
The pppd log (not today) shows:
Nov 24 03:20:48 nimrodel pppd[23742]: Plugin passwordfd.so loaded.
Nov 24 03:20:48 nimrodel pppd[23742]: pppd 2.4.2 started by cer, uid 500
Nov 24 03:20:48 nimrodel pppd[23742]: using channel 6
Nov 24 03:20:48 nimrodel pppd[23742]: Using interface ppp0
Nov 24 03:20:48 nimrodel pppd[23742]: Connect: ppp0 <--> /dev/ttyS1
Nov 24 03:20:48 nimrodel pppd[23742]: sent [LCP ConfReq id=0x1
Carlos E. R. wrote:
No, mine is a standard serial port external modem, complete, and works pretty fast with SuSE versions up to 8.2 with the same ISP, phone lines, computer, and configuration.
OK, with respect to the SuSE versions, I'd ignore them. Yes, it seems to be perhaps the major/only noticable difference, but the difference has to be in pppd, maybe tcpip or the overall config.
Let me see, I reported this in full time ago, this summer. A link to the thread: http://lists.suse.com/archive/suse-linux-e/2004-Jul/3411.html
Sorry, I wasn't listening in at that time.
Serial modem, standard hayes, 3COM usr robotics 56K. Connection string: CONNECT 50666/ARQ/V90/LAPM/V42BIS - --> Carrier detected. Starting PPP immediately.
OK, looks good.
Jul 23 21:04:31 nimrodel kernel: PPP: VJ decompression error Jul 23 21:05:03 nimrodel kernel: PPP: VJ decompression error Jul 23 21:05:13 nimrodel kernel: PPP: VJ decompression error Jul 23 21:05:16 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:06 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:19 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:27 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:40 nimrodel kernel: PPP: VJ decompression error
Question - do you see the same when you run this on your other box? If not, are the configs exactly the same? pppd version? Try the other serial port - just in case this is a hardware problem.
You can see the seconds do match the resets, or seem to... so I disabled that compression in /etc/ppp/peers/ppp: noccp # because ccp gives errors in the log.
noccp disables the ccp negotation completely - try 'novj' just disable VJ header compression. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - sign up for your free 30-day trial now!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2005-01-16 at 09:39 +0100, Per Jessen wrote:
Carlos E. R. wrote:
No, mine is a standard serial port external modem, complete, and works pretty fast with SuSE versions up to 8.2 with the same ISP, phone lines, computer, and configuration.
OK, with respect to the SuSE versions, I'd ignore them. Yes, it seems to be perhaps the major/only noticable difference, but the difference has to be in pppd, maybe tcpip or the overall config.
I could perhaps try compiling the pppd from SuSE 8.2 and put it in 9.1, if that is doable. As to the configuration, I upgraded from 8.2 to 9.1, so most of the configuration is the same, and with 8.2 it worked. What configuration file(s) are you thinking of? I use wvdial to control the connection, called from a console. I don't know if this is related, but I discovered a bug in wvdial or pppd, a memory leak of some kind, reported in the security list; let me see [...] yes, I see strings like this printed in the xterm console where I call wvdial: --> Using interface ppp0 --> pppd: ovider --> pppd: ovider --> pppd: ovider --> Authentication (CHAP) started I asked once here about those "ovider" things. I even searched the sources for that string: no match. After I changed or updated something, the string changes: --> pppd: Inherits --> pppd: Inherits And changes again as I change the wvdial config file. On a Spanish Knoppix 3.4 live CD, that I used to test the problem, the message was "espera". All those messages are strings in the /etc/wvdial.conf file: Provider= Teleline <---- ovider [Dialer teleline] Inherits= Dialer lteleline <---- Inherits [Dialer Espera] Inherits= Dialer NoDesvio Phone= *43# Provider=LLamada en Espera activada <----- case for Espera does not match, the one below does, in a coment :-o [Dialer NoContestador] --> # Desactiva el contestador, pero no da comunicando. Quizas haya que desactivar la llamada en espera tb Inherits= Dialer NoDesvio Provider=Contestador desactivado Notice that I used the exact same /etc/wvdial.conf file in the Knoppix, and it is the same one I used in 8.2, 8.1, 7.3, 7.1, 6.4, 6.1... etc, except normal phone changes and such as years passed by. So I think that something in pppd or wvdial has a memory leak or overflow of some sort, and instead of printing whatever it should it prints instead those strings that overwrote who knows what. I have noticed this behavior on some other peoples computers, I'm not the only one to report it: but of course, the messages varies. I consider that to be a possibly serious problem - any memory leak/overflow is potentially serious, but nobody commented on it in the security list.
Let me see, I reported this in full time ago, this summer. A link to the thread: http://lists.suse.com/archive/suse-linux-e/2004-Jul/3411.html
Sorry, I wasn't listening in at that time.
Well, I'm happy you are now :-)
Serial modem, standard hayes, 3COM usr robotics 56K. Connection string: CONNECT 50666/ARQ/V90/LAPM/V42BIS - --> Carrier detected. Starting PPP immediately.
OK, looks good.
Jul 23 21:04:31 nimrodel kernel: PPP: VJ decompression error Jul 23 21:05:03 nimrodel kernel: PPP: VJ decompression error Jul 23 21:05:13 nimrodel kernel: PPP: VJ decompression error Jul 23 21:05:16 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:06 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:19 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:27 nimrodel kernel: PPP: VJ decompression error Jul 23 21:07:40 nimrodel kernel: PPP: VJ decompression error
Question - do you see the same when you run this on your other box? If not, are the configs exactly the same? pppd version?
I'm just firing it up to check.
[...]
wvdial.conf is mostly the same, copied from one to the other. Stupid mode
1 or 0, some providers disabled, a comment somewhere... I can equate them
both easily before testing today.
7.3 has pppd 2.4.1, and 9.1 has 2.4.2 - I thought the versions would be
much more different, several years have passed :-o
Ah, no, I don't see the VJ errors in 7.3. Its "/etc/ppp/peers/wvdial" file
goes looks this:
noauth
name wvdial
debug
defaultroute
replacedefaultroute
and 'wvdial-pipe' (I don't know what this one is for) shows:
noauth
name wvdial
debug
plugin passwordfd.so
defaultroute
replacedefaultroute
The 7.3 log goes like this (long lines):
Jan 16 14:42:13 telperion pppd[2026]: Plugin passwordfd.so loaded.
Jan 16 14:42:13 telperion pppd[2026]: pppd 2.4.1 started by cer, uid 500
Jan 16 14:42:13 telperion pppd[2026]: Perms of /dev/ttyS1 are ok, no 'mesg n' neccesary.
Jan 16 14:42:13 telperion pppd[2026]: using channel 1
Jan 16 14:42:13 telperion pppd[2026]: Using interface ppp0
Jan 16 14:42:13 telperion pppd[2026]: Connect: ppp0 <--> /dev/ttyS1
Jan 16 14:42:13 telperion pppd[2026]: sent [LCP ConfReq id=0x1
Try the other serial port - just in case this is a hardware problem.
Will do. But I doubt it, I had 8.2 there before and it worked fine. Nevertheless, I'll try. First I'll try the novj option you mention below.
You can see the seconds do match the resets, or seem to... so I disabled that compression in /etc/ppp/peers/ppp: noccp # because ccp gives errors in the log.
noccp disables the ccp negotation completely - try 'novj' just disable VJ header compression.
I'll do it in /etc/ppp/peers/wvdial - I hope it uses this one, not
/etc/ppp/peers/ppp:
plugin passwordfd.so
noauth
name wvdial
debug
#nopcomp
#novjccomp
#noccp
novj
I'll do a connection right now, and check.
[...]
I see the errors:
Jan 17 01:17:16 nimrodel pppd[9421]: rcvd [LCP EchoRep id=0xe magic=0xd28f2d2b]
Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [Compressed data] 00 09 82 14 ee 4b c0 85 ...
Jan 17 01:17:18 nimrodel pppd[9421]: sent [CCP ResetReq id=0x9]
Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [CCP ResetAck id=0x9]
and it is slow (mostly because of pauses):
cer@nimrodel:~> date ; time wget --timeout=90 --waitretry=10 "http://old.spamassassin.org/released/Mail-SpamAssassin-2.63.tar.bz2"
Mon Jan 17 01:16:53 CET 2005
--01:16:54-- http://old.spamassassin.org/released/Mail-SpamAssassin-2.63.tar.bz2
=> `Mail-SpamAssassin-2.63.tar.bz2.3'
Resolving old.spamassassin.org... 64.142.3.173
Connecting to old.spamassassin.org[64.142.3.173]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 738,442 [application/x-bzip2]
18% [===============> ] 137,233 1.95K/s ETA 05:20
Ah! The "weird string" is now:
--> pppd: Dialer ltiscali
--> pppd: Dialer ltiscali
--> pppd: Dialer ltiscali
--> pppd: Dialer ltiscali
Which is certainly one of the strings in wvdial.conf. Another weird thing,
is that, while in 7.3 I work with "Stupid Mode= 1", in 9.1 I have to have
it at 0, or it doesn't connect:
Jan 17 01:08:07 nimrodel pppd[9375]: CHAP authentication failed
Jan 17 01:08:07 nimrodel pppd[9375]: sent [LCP TermReq id=0x4 "Failed to authenticate ourselves to peer"]
Granted, the provider could have changed something today, but I don't
think so, it is Sunday. I'll keep that log.
I'll modify again /etc/ppp/peers/wvdial:
#nopcomp
novjccomp
noccp
novj
and retry.
[...]
Weird... the "weird string" has disappeared! :-O
Speed is about the same:
cer@nimrodel:~> date ; time wget --timeout=90 --waitretry=10 "ftp://ftp.rediris.es/sites2/ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/sharutils-4.2c-710.10.i586.rpm"
Mon Jan 17 01:31:40 CET 2005
--01:31:40-- ftp://ftp.rediris.es/sites2/ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/sharutils-4.2c-710.10.i586.rpm
=> `sharutils-4.2c-710.10.i586.rpm'
Resolving ftp.rediris.es... 130.206.1.5
Connecting to ftp.rediris.es[130.206.1.5]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /sites2/ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586 ... done.
==> PASV ... done. ==> RETR sharutils-4.2c-710.10.i586.rpm ... done.
[ <=> ] 23,168 1.76K/s
[ <=> ] 59,368 2.93K/s
[ <=> ] 82,536 3.01K/s
[ <=> ] 106,115 1.79K/s
01:32:33 (2.04 KB/s) - `sharutils-4.2c-710.10.i586.rpm' saved [106115]
real 0m52.867s
user 0m0.002s
sys 0m0.003s
An average of 2.04 KB/s. In the SuSE 7.3 I can get 5 or 6. And the log is:
Jan 17 01:26:58 nimrodel pppd[11663]: Plugin passwordfd.so loaded.
Jan 17 01:26:58 nimrodel pppd[11663]: pppd 2.4.2 started by cer, uid 500
Jan 17 01:26:58 nimrodel pppd[11663]: using channel 3
Jan 17 01:26:58 nimrodel pppd[11663]: Using interface ppp0
Jan 17 01:26:59 nimrodel pppd[11663]: Connect: ppp0 <--> /dev/ttyS1
Jan 17 01:26:59 nimrodel pppd[11663]: sent [LCP ConfReq id=0x1
[ALL SNIPPED] I note that you are using wvdial. I am using cinternet (kinternet is the frontend). We are both having the same trouble, so I really wonder if it is the dialer at fault. ..."Yogi" CH Namasté Yoga Studio
The Sunday 2005-01-16 at 19:47 -0600, C Hamel wrote:
[ALL SNIPPED] I note that you are using wvdial. I am using cinternet (kinternet is the frontend). We are both having the same trouble, so I really wonder if it is the dialer at fault.
Those programs do very little, regarding our problem. Important, but little. They just dial up, and as soon as they see the ppp prompt, they pass control over to pppd, with the appropriate options. Then, it is pppd who negotiates and transmit every thing. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
I could perhaps try compiling the pppd from SuSE 8.2 and put it in 9.1, if that is doable.
I would go for the latest pppd instead - 2.4.3 - from http://ppp.samba.org. But don't do it right now.
As to the configuration, I upgraded from 8.2 to 9.1, so most of the configuration is the same, and with 8.2 it worked. What configuration file(s) are you thinking of?
The pppd conf would be critical here. /etc/ppp/options.* /etc/ppp/peers/*
I use wvdial to control the connection, called from a console.
Uh, I don't know wvdial - when I used pppd dial-up I always used diald for dial-on-demand.
[...] yes, I see strings like this printed in the xterm console where I call wvdial:
--> Using interface ppp0 --> pppd: ovider --> pppd: ovider --> pppd: ovider --> Authentication (CHAP) started
It should be possible to call pppd directly - "pppd /dev/ttySx". That will use the following config files: /etc/ppp/options, ~/.ppprc and /etc/ppp/options.ttySx Unless you do "pppd call xxxxx" which will make it use /etc/ppp/peers/xxxxxx. There is something not quite right - maybe in the script - I don't know if wvdial generates a connect script or something? I'd like to try calling pppd directly from the command-line - that is about as basic as it gets.
I see the errors:
Jan 17 01:17:16 nimrodel pppd[9421]: rcvd [LCP EchoRep id=0xe magic=0xd28f2d2b] Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [Compressed data] 00 09 82 14 ee 4b c0 85 ... Jan 17 01:17:18 nimrodel pppd[9421]: sent [CCP ResetReq id=0x9] Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [CCP ResetAck id=0x9]
OK, it seems something IS obviously wrong with the compression. Could be on your side, could be on your providers side. So back to "noccp" and "novj".
An average of 2.04 KB/s. In the SuSE 7.3 I can get 5 or 6. And the log is:
There was a lot of text here - I'm getting a little lost. Have we now established that with compression disabled (due to errors) in 9.1, you get 1-2kbyte/s , but with compression enabled in 7.3/8.2, you get 5-6kbyte/s ?
Well... More ideas? Do you think I could use the old pppd daemon, recompiling it? The kernel has changed, but I could try, if you think it is possible. :-?
I don't think it's really necessary, but if you do upgrade, I would go for the latest 2.4.3. Sorry, like I said, I got a little lost in all of this: On the system where you get the good speed (7.3? 8.2?) what happens if you disable compression? (or is compression also disabled there?) Do you see any VJ errors on that system? What speed do you get with and without compression? /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - sign up for your free 30-day trial now!
On 12:37 Tue 18 Jan , Per Jessen wrote:
Carlos E. R. wrote:
I could perhaps try compiling the pppd from SuSE 8.2 and put it in 9.1, if that is doable.
I would go for the latest pppd instead - 2.4.3 - from http://ppp.samba.org. But don't do it right now.
As to the configuration, I upgraded from 8.2 to 9.1, so most of the configuration is the same, and with 8.2 it worked. What configuration file(s) are you thinking of?
The pppd conf would be critical here. /etc/ppp/options.* /etc/ppp/peers/*
I use wvdial to control the connection, called from a console.
Uh, I don't know wvdial - when I used pppd dial-up I always used diald for dial-on-demand.
[...] yes, I see strings like this printed in the xterm console where I call wvdial:
--> Using interface ppp0 --> pppd: ovider --> pppd: ovider --> pppd: ovider --> Authentication (CHAP) started
It should be possible to call pppd directly - "pppd /dev/ttySx". That will use the following config files: /etc/ppp/options, ~/.ppprc and /etc/ppp/options.ttySx
Unless you do "pppd call xxxxx" which will make it use /etc/ppp/peers/xxxxxx.
There is something not quite right - maybe in the script - I don't know if wvdial generates a connect script or something? I'd like to try calling pppd directly from the command-line - that is about as basic as it gets.
I see the errors:
Jan 17 01:17:16 nimrodel pppd[9421]: rcvd [LCP EchoRep id=0xe magic=0xd28f2d2b] Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [Compressed data] 00 09 82 14 ee 4b c0 85 ... Jan 17 01:17:18 nimrodel pppd[9421]: sent [CCP ResetReq id=0x9] Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [CCP ResetAck id=0x9]
OK, it seems something IS obviously wrong with the compression. Could be on your side, could be on your providers side. So back to "noccp" and "novj".
An average of 2.04 KB/s. In the SuSE 7.3 I can get 5 or 6. And the log is:
There was a lot of text here - I'm getting a little lost. Have we now established that with compression disabled (due to errors) in 9.1, you get 1-2kbyte/s , but with compression enabled in 7.3/8.2, you get 5-6kbyte/s ?
Well... More ideas? Do you think I could use the old pppd daemon, recompiling it? The kernel has changed, but I could try, if you think it is possible. :-?
I don't think it's really necessary, but if you do upgrade, I would go for the latest 2.4.3.
Sorry, like I said, I got a little lost in all of this: On the system where you get the good speed (7.3? 8.2?) what happens if you disable compression? (or is compression also disabled there?) Do you see any VJ errors on that system? What speed do you get with and without compression?
/Per Jessen, Zürich
On my HP notebook I discovered that I could increase the modem throughput by adding <user> to the following groups: uucp, wheel, modem. Now, I cannot say that the last two are definitely necessary but I *do* know that when I was using Gentoo all three were recommended to make the modem work properly. Unfortunately, the external modem I am using isn't cooperating as it did in Gentoo. The throughput is increased dramatically from 'nothing' but is still now what it ought to be relative to SuSE 9. I shared the above info w/Carlos & he informed me that it didn't make a difference on his box, unfortunately. Also, in the event you may have missed it, simply upgrading the kernel in SuSE 9 *totally_breaks* the modem throughput. Reverting to the 1st-installed kernel un-breaks it. I am not saying that pppd or some other component may not also be contributing to the problem, however. -- ..."Yogi" CH Namast Yoga Studio
The Tuesday 2005-01-18 at 12:37 +0100, Per Jessen wrote:
Carlos E. R. wrote:
I could perhaps try compiling the pppd from SuSE 8.2 and put it in 9.1, if that is doable.
I would go for the latest pppd instead - 2.4.3 - from http://ppp.samba.org. But don't do it right now.
Depends on the version SuSE 9.2 uses. If it is that one, it will probably fail. Hamel? What pppd version does 9.2 use?
As to the configuration, I upgraded from 8.2 to 9.1, so most of the configuration is the same, and with 8.2 it worked. What configuration file(s) are you thinking of?
The pppd conf would be critical here. /etc/ppp/options.* /etc/ppp/peers/*
I'll check. 7.3 has now: debug noauth crtscts lock modem asyncmap 0 nodetach lcp-echo-interval 30 lcp-echo-failure 4 lcp-max-configure 60 lcp-restart 2 idle 600 noipx 9.1 has: noipdefault debug kdebug 1 noauth crtscts lock modem asyncmap 0 nodetach lcp-echo-interval 30 lcp-echo-failure 4 lcp-max-configure 60 lcp-restart 2 idle 600 noipx file /etc/ppp/filters Both are the default files that come with its respective SuSE versions, except for the debug tokens. The filters file refered above contains one active line: active-filter 'outbound and not icmp[0] == 3 and not tcp[13] & 4 != 0' Then, in 9.1 the file peers/wvdia applies: plugin passwordfd.so noauth name wvdial debug novjccomp noccp novj
I use wvdial to control the connection, called from a console.
Uh, I don't know wvdial - when I used pppd dial-up I always used diald for dial-on-demand.
[...] yes, I see strings like this printed in the xterm console where I call wvdial:
--> Using interface ppp0 --> pppd: ovider --> pppd: ovider --> pppd: ovider --> Authentication (CHAP) started
It should be possible to call pppd directly - "pppd /dev/ttySx". That will use the following config files: /etc/ppp/options, ~/.ppprc and /etc/ppp/options.ttySx
Unless you do "pppd call xxxxx" which will make it use /etc/ppp/peers/xxxxxx.
There is something not quite right - maybe in the script - I don't know if wvdial generates a connect script or something? I'd like to try calling pppd directly from the command-line - that is about as basic as it gets.
It is just a chat equivalent, with "intelligence". wvdial calls pppd with the following options: 6440 pts/5 Ss 0:00 \_ bash 8723 pts/5 S+ 0:00 | \_ /bin/sh /home/cer/bin/mywvdial steleline 8728 pts/5 S+ 0:00 | \_ /usr/bin/wvdial steleline 8729 pts/5 S 0:00 | \_ /usr/sbin/pppd 115200 modem crtscts defaultroute usehostname -detach user LOGINNAME noipdefault call wvdial idle 85 logfd 6 I used chat and pppd years ago, I forgot how to use it. But I don't think that is the problem.
I see the errors:
Jan 17 01:17:16 nimrodel pppd[9421]: rcvd [LCP EchoRep id=0xe magic=0xd28f2d2b] Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [Compressed data] 00 09 82 14 ee 4b c0 85 ... Jan 17 01:17:18 nimrodel pppd[9421]: sent [CCP ResetReq id=0x9] Jan 17 01:17:18 nimrodel pppd[9421]: rcvd [CCP ResetAck id=0x9]
OK, it seems something IS obviously wrong with the compression. Could be on your side, could be on your providers side. So back to "noccp" and "novj".
Right, done.
An average of 2.04 KB/s. In the SuSE 7.3 I can get 5 or 6. And the log is:
There was a lot of text here - I'm getting a little lost.
I can imagine - I'm used to reading logs ;-)
Have we now established that with compression disabled (due to errors) in 9.1, you get 1-2kbyte/s , but with compression enabled in 7.3/8.2, you get 5-6kbyte/s ?
The speeds with compression enabled/disabled seem to be roughly the same (tests below) on each computer. The 9.1 gets from 1.5 to 3 depending on the day or who knows what, and the 7.3 (and 8.2 before updating that machine) seems to get over 5 KB/s, and can maintain it over long downloads - with some exceptions, of course, providers are not perfect.
Well... More ideas? Do you think I could use the old pppd daemon, recompiling it? The kernel has changed, but I could try, if you think it is possible. :-?
I don't think it's really necessary, but if you do upgrade, I would go for the latest 2.4.3.
I'll have a look.
Sorry, like I said, I got a little lost in all of this: On the system where you get the good speed (7.3? 8.2?) what happens if you disable compression? (or is compression also disabled there?) Do you see any VJ errors on that system? What speed do you get with and without compression?
Let's see - this run with compression on the 7.3 machine, 5.22 KB/s during a 100 Kbyte download - and there are no errors in the log: cer@nimrodel:~> date ; time wget --timeout=90 --waitretry=10 "ftp://ftp.rediris.es/sites2/ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/sharutils-4.2c-710.10.i586.rpm" Tue Jan 18 19:22:05 CET 2005 --19:22:05-- ftp://ftp.rediris.es/sites2/ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/sharutils-4.2c-710.10.i586.rpm => `sharutils-4.2c-710.10.i586.rpm.3' Resolving ftp.rediris.es... 130.206.1.5 Connecting to ftp.rediris.es[130.206.1.5]:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /sites2/ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586 ... done. ==> PASV ... done. ==> RETR sharutils-4.2c-710.10.i586.rpm ... done. [ <=> ] 11,584 9.18K/s [ <=> ] 23,168 6.90K/s [ <=> ] 36,200 5.81K/s [ <=> ] 52,128 5.48K/s [ <=> ] 68,056 5.32K/s [ <=> ] 81,088 4.27K/s [ <=> ] 101,360 5.45K/s [ <=> ] 106,115 5.45K/s 19:22:28 (5.22 KB/s) - `sharutils-4.2c-710.10.i586.rpm.3' saved [106115] I had disabled compression for that run, but I see in the log that it ignored me. Let's try again [...] yes, got it, had to use /etc/ppp/options. Average speed for the same download was 5.13 KB/s, roughly the same. [ <=> ] 7,240 6.16K/s [ <=> ] 20,272 4.70K/s [ <=> ] 40,544 4.80K/s [ <=> ] 57,920 5.32K/s [ <=> ] 73,848 5.31K/s [ <=> ] 89,776 5.17K/s [ <=> ] 102,808 5.13K/s [ <=> ] 106,115 5.13K/s 19:36:06 (5.13 KB/s) - `sharutils-4.2c-710.10.i586.rpm.4' saved [106115] Compression at the tcp/ip layer or ppp layer I don't think can affect much on a good modem, because they do compression in hardware: 1st run CONNECT 50666/ARQ/V90/LAPM/V42BIS 2nd run CONNECT 50666/ARQ/V90/LAPM/V42BIS -- Cheers, Carlos Robinson
Carlos E. R. wrote:
I would go for the latest pppd instead - 2.4.3 - from http://ppp.samba.org. But don't do it right now.
Depends on the version SuSE 9.2 uses. If it is that one, it will probably fail.
pppd 2.4.3 works just fine. I've recently used it in some ADSL/ATM experiments.
I'll check. 7.3 has now:
[snip]
9.1 has:
[snip]
file /etc/ppp/filters
Try commenting this out - just to see what effect it has (if any). The configs look exactly the same except for this line. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - getting rid of spam and virus - once and for all!
The Tuesday 2005-01-18 at 12:37 +0100, Per Jessen wrote:
Carlos E. R. wrote:
I could perhaps try compiling the pppd from SuSE 8.2 and put it in 9.1, if that is doable.
I would go for the latest pppd instead - 2.4.3 - from http://ppp.samba.org. But don't do it right now.
I have downloaded ppp-2.4.3.tar.gz, because I'm convinced there is a bug in the SuSE supplied ppp code somewhere, and SuSE has not solved it. But I'm at a loss about how to compile it. The README.linux says: The PPP protocol consists of two parts. One is a scheme for framing and encoding packets, the other is a series of protocols called LCP, IPCP, PAP and CHAP, for negotiating link options and for authentication. This package similarly consists of two parts: a kernel module which handles PPP's low-level framing protocol, and a user-level program called pppd which implements PPP's negotiation protocols. The kernel module assembles/disassembles PPP frames, handles error detection, and forwards packets between the serial port and either the kernel network code or the user-level program pppd. IP packets go directly to the kernel network code. So once pppd has negotiated the link, it in practice lies completely dormant until you want to take the link down, when it negotiates a graceful disconnect. The README file says: This software consists of two parts: - Kernel code, which establishes a network interface and passes packets between the serial port, the kernel networking code and the PPP daemon (pppd). This code is implemented using STREAMS modules on Solaris, and as a line discipline under Linux. - The PPP daemon (pppd), which negotiates with the peer to establish the link and sets up the ppp network interface. Pppd includes support for authentication, so you can control which other systems may make a PPP connection and what IP addresses they may use. So... I understand that the pppd daemon only does the initial negotiation. The transmission is done by the kernel modules, the important part, and that's the part that must have the problem, I think. The problem is that the ./configure and the make phase do not create the kernel modules. In fact, that section is commented out: #kernel: # cd linux; ./kinstall.sh and script kinstall.sh does not exist anywhere. How on earth do I go on to compile this little beast? Perhaps copying the ppp-2.4.3/modules/ files over to /usr/src/linux/drivers/net, changing the filenames as I see fit, and then recompiling the kernel in whole? The files are: ppp-2.4.3/modules/ found in kernel /usr/src/linux/drivers/net/? bsd-comp.c Yes deflate.c no if_ppp.c no ppp.c no ppp_ahdlc.c no ppp_comp.c no ppp_mod.h no vjcompress.c no no ppp_async.c no ppp_deflate.c no ppp_generic.c no ppp_mppe_compress.c The file names do not match. I can not go that way :-( Or perhaps downgrade the kernel to the one that came in the DVD, that apparently works (I haven't tried yet), and throwing all updates down the chute? :-/ -- Cheers, Carlos Robinson
Carlos E. R. wrote:
The problem is that the ./configure and the make phase do not create the kernel modules. In fact, that section is commented out:
That's fine. The ppp code in the kernel is most probably very current. You just need to get the pppd daemon built. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - sign up for your free 30-day trial now!
The Thursday 2005-01-20 at 09:57 +0100, Per Jessen wrote:
The problem is that the ./configure and the make phase do not create the kernel modules. In fact, that section is commented out:
That's fine. The ppp code in the kernel is most probably very current.
No, it is not. For example the bsd_comp.c file has diferent versions: * From: bsd_comp.c,v 1.3 1994/12/08 01:59:58 paulus Exp * $Id: bsd-comp.c,v 1.21 2004/01/17 05:47:55 carlsonj Exp $ Thats TEN years diference! I only compare that one because it is only one with matching names in both trees. If it is the same file... because i don't really know where the kernel modules come from. And also, I think that is is the kernel code that has the bug. Tomorrow I'm going to downgrade my SuSE 9.1 to the original kernel vmlinuz-2.6.4-52-default instead of the current vmlinuz-2.6.5-7.111.19-default, to check if, as Hamel says, it works. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
For example the bsd_comp.c file has diferent versions:
* From: bsd_comp.c,v 1.3 1994/12/08 01:59:58 paulus Exp * $Id: bsd-comp.c,v 1.21 2004/01/17 05:47:55 carlsonj Exp $
They're two different files. The bsd-comp.c from the pppd package is not for a Linux kernel module, AFAICT.
Thats TEN years diference! I only compare that one because it is only one with matching names in both trees. If it is the same file... because i don't really know where the kernel modules come from.
Generally they are part of the kernel source tree generally. Only if you're building something special which hasn't been merged yet, or where the manufacturer doesn't want it merged into the kernel, would you build the modules external to the kernel.
And also, I think that is is the kernel code that has the bug. Tomorrow I'm going to downgrade my SuSE 9.1 to the original kernel vmlinuz-2.6.4-52-default instead of the current vmlinuz-2.6.5-7.111.19-default, to check if, as Hamel says, it works.
It's certainly possible, but a longshot I would say. But you are on 2.6 - I'm only using 2.4 for the time being, so I can't really comment. However, if you plan to report/help fix a kernel-bug, I would suggest you use a vanilla-kernel, i.e. not a SuSE-special. Let us know how it goes. /Per Jessen, Zürich -- http://www.spamchek.com/freetrial - sign up for your free 30-day trial now!
On 10:23 Sat 15 Jan , Per Jessen wrote:
C Hamel wrote:
I would say, 'ignore modem users at your peril' since ppp is available in the kernel & distro. If they want to pull it out & take the chance that people won't yell... go for it.
ppp is also used for other things than standard dialup modem connections. I know that... <LOL> ...it was a [sort of...?] joke.
Have you tried running ppd with debug on - to see what is actually happening on the line? If your modems are not winmodems (where some of the modem work is "offloaded" to the CPU), there is no reason why the system should/could make the connection slower.
That is what I thought, as well. Actually, for some reason, the debug didn't occur to me. That'd be a good deal. I'll reinstall 9.2 & try it.
To give people a chance to help you, we need to know some some basics - which kind of modem are you using? What is your connection speed to your provider?
The modem is a 3Com 3c882 ISDN modem. Before anyone says it isn't suported, I'll also add that it requires no special treatment to work... simply an AT&F, and the proper baud setting in YaST. The connection speed to the provider is 115200, as set in YaST. There is more, too, which may be of interest: there are times when I get the error, "No response to 4 echo-requests" in var/log/messages, yet my ISP tells me that according to their logs I just hung up. Another error found in /var/log/messages was, "Responded to our own echo-request!" This, too, spans all three versions from 9 Pro to the present version, but at least makes version 9 usable, compared to versions 9.1 & 9.2 which are nearly unusable because of the added slow to nil modem throughput. Many thanks for the 'push'. :-) -- ..."Yogi" CH Namasté Yoga Studio
C Hamel wrote:
To give people a chance to help you, we need to know some some basics - which kind of modem are you using? What is your connection speed to your provider? The modem is a 3Com 3c882 ISDN modem. Before anyone says it isn't suported, I'll also add that it requires no special treatment to work... simply an AT&F, and the proper baud setting in YaST. The connection speed to the provider is 115200, as set in YaST.
It's an external modem yeah? So to your system it's just another modem. Yes, you possibly need some special init-strings, but as far as pppd is concerned, it doesn't matter.
There is more, too, which may be of interest: there are times when I get the error, "No response to 4 echo-requests" in var/log/messages, yet my ISP tells me that according to their logs I just hung up. Another error found in /var/log/messages was, "Responded to our own echo-request!" This, too, spans all three versions from 9 Pro to the present version, but at least makes version 9 usable, compared to versions 9.1 & 9.2 which are nearly unusable because of the added slow to nil modem throughput.
Like I wrote in my response to Carlos, try comparing the pppd versions, and the configs. That's where the difference is to be found, if any. Also, if a ppp connection appears to be running, only incredibly slowly, it is usually because it's busy (re-)negotiating something or other. In your case with an external ISDN modem, we'll just have to assume that the ISDN setup works - I'm assuming there is little chance of tracing anything in the modem itself? We're also using ISDN - have been for almost 10 years, but we've always used internal ISDN TA cards, so Ihave little to no experience with external ISDN modems. /Per Jessen, Zürich -- http://www.spamchek.co.uk/freetrial - sign up for your free 30-day trial now!
On 09:47 Sun 16 Jan , Per Jessen wrote:
C Hamel wrote:
To give people a chance to help you, we need to know some some basics - which kind of modem are you using? What is your connection speed to your provider? The modem is a 3Com 3c882 ISDN modem. Before anyone says it isn't suported, I'll also add that it requires no special treatment to work... simply an AT&F, and the proper baud setting in YaST. The connection speed to the provider is 115200, as set in YaST.
It's an external modem yeah? So to your system it's just another modem. Yes, you possibly need some special init-strings, but as far as pppd is concerned, it doesn't matter. Yes. External. I tried many differing INIT strings, googled, contacted tech support, the whole nine yards. The one INIT that seemed to work the best was also the simplest: AT &F.
There is more, too, which may be of interest: there are times when I get the error, "No response to 4 echo-requests" in var/log/messages, yet my ISP tells me that according to their logs I just hung up. Another error found in /var/log/messages was, "Responded to our own echo-request!" This, too, spans all three versions from 9 Pro to the present version, but at least makes version 9 usable, compared to versions 9.1 & 9.2 which are nearly unusable because of the added slow to nil modem throughput.
Like I wrote in my response to Carlos, try comparing the pppd versions, and the configs. That's where the difference is to be found, if any. Also, if a ppp connection appears to be running, only incredibly slowly, it is usually because it's busy (re-)negotiating something or other.
Right now, the two boxes having the problem are running SuSE 9 Pro --*no* updates, since any update totally breaks it. That means the versions are identical. The settings for the machines is also identical. I read your msg to Carlos, BTW.
In your case with an external ISDN modem, we'll just have to assume that the ISDN setup works - I'm assuming there is little chance of tracing anything in the modem itself? We're also using ISDN - have been for almost 10 years, but we've always used internal ISDN TA cards, so Ihave little to no experience with external ISDN modems.
Never played w/an internal card. Fact is, one of the boxes is a notebook so that puts the kibosh on that. The 3Com is a router, if that matters, and is incredibly stable most the time on SuSE 9 ...with the exception of the echo-request thing, which is intermittent. -- ..."Yogi" CH Namasté Yoga Studio
participants (3)
-
C Hamel
-
Carlos E. R.
-
Per Jessen