Still cant connect to my ISP
I seem to have trouble getting recognised by my ISP Can anyone point out to an ignorant novice what is going on here, and how to fix it. How do I inform myself about "signal 15" & "exit code 19" etc Where does the "[09]" in the "EARLY LOG" come from ? I have installed 8.2 personal - I haven't come across any other problems yet ##### EARLY LOG ################################### SuSE Meta pppd (smpppd-ifcfg), Version 1.00 on linux. We are disconnected. trying to connect to smpppd connect to smpppd We are disconnected. We are connecting. pppd: Plugin passwordfd.so loaded. pppd: --> WvDial: Internet dialer version 1.42 pppd: --> Initializing modem. pppd: --> Sending: ATZ pppd: ATZ pppd: OK pppd: --> Sending: AT&C1&D2 pppd: AT&C1&D2 pppd: OK pppd: --> Sending: ATM1 pppd: ATM1 pppd: OK pppd: --> Modem initialized. pppd: --> Sending: ATDT086707070 pppd: --> Waiting for carrier. pppd: ATDT086707070 pppd: CONNECT 115200 pppd: --> Carrier detected. Waiting for prompt. pppd: [09] pppd: login: pppd: --> Looks like a login prompt. pppd: --> Sending: kkeith pppd: kkeith pppd: Password: pppd: --> Looks like a password prompt. pppd: --> Sending: (password) pppd: --> Don't know what to do! Starting pppd and hoping for the best. pppd: Serial connection established. pppd: Using interface ppp0 pppd: Connect: ppp0 <--> /dev/ttyS0 We are disconnecting. pppd: Terminating on signal 15. We are disconnecting. We are disconnected. pppd died: non-normal exit ###### LATER LOG ################################## (I went back to set-up and enabled "stupid Mode") SuSE Meta pppd (smpppd-ifcfg), Version 1.00 on linux. We are disconnected. trying to connect to smpppd connect to smpppd We are disconnected. We are connecting. pppd: Plugin passwordfd.so loaded. pppd: --> WvDial: Internet dialer version 1.42 pppd: --> Initializing modem. pppd: --> Sending: ATZ pppd: ATZ pppd: OK pppd: --> Sending: AT&C1&D2 pppd: AT&C1&D2 pppd: OK pppd: --> Sending: ATM1 pppd: ATM1 pppd: OK pppd: --> Modem initialized. pppd: --> Sending: ATDT086707070 pppd: --> Waiting for carrier. pppd: ATDT086707070 pppd: CONNECT 115200 pppd: --> Carrier detected. Chatmode finished. pppd: Serial connection established. pppd: Using interface ppp0 pppd: Connect: ppp0 <--> /dev/ttyS0 pppd: No response to PAP authenticate-requests pppd: Connection terminated. pppd: Hangup (SIGHUP) We are disconnected. pppd died: Authentication error (exit code 19) Thanks keith
On Thursday 29 April 2004 21.47, Keith Keesing wrote:
I seem to have trouble getting recognised by my ISP
Can anyone point out to an ignorant novice what is going on here, and how to fix it.
Is this a regular, public ISP, or something private, like a company dial-up? In my experience with dial-up connections, there are two things to try. Either with or without stupid mode, and since you have tried both I have to ask: does this work with the generic dial-up in windows or is this something where they distribute special software to connect?
How do I inform myself about "signal 15" & "exit code 19" etc
signal 15 is SIGTERM, the signal that gets sent to programs when you, for example, hit ctrl-C on the command line. The possible signals can be listed by running "kill -l", and they are also described in 'info kill' pppd's exit codes are described in 'man pppd'. 19 is listed as 19 We failed to authenticate ourselves to the peer.
On Thursday 29 April 2004 14:47, Keith Keesing wrote:
I seem to have trouble getting recognised by my ISP
Can anyone point out to an ignorant novice what is going on here, and how to fix it.
<snip> I have 8.2 also, and if I remember right, you might want to create a blank resolv.conf text file in /etc (that's the correct spelling too...resolv.conf). I think this will solve the problem. I'll try and see if there was anything else that was needed or anything that needed to be in the file. John
The Friday 2004-04-30 at 07:47 +1200, Keith Keesing wrote:
I seem to have trouble getting recognised by my ISP
Can anyone point out to an ignorant novice what is going on here, and how to fix it.
No enough info - I'll try.
How do I inform myself about "signal 15" & "exit code 19" etc
Assuming they come form pppd, man pppd.
pppd: CONNECT 115200 pppd: --> Carrier detected. Waiting for prompt. pppd: [09] pppd: login: pppd: --> Looks like a login prompt. pppd: --> Sending: kkeith pppd: kkeith pppd: Password: pppd: --> Looks like a password prompt. pppd: --> Sending: (password) pppd: --> Don't know what to do! Starting pppd and hoping for the best. pppd: Serial connection established. pppd: Using interface ppp0 pppd: Connect: ppp0 <--> /dev/ttyS0
That's simptomatic of needing stupid mode enabled.
###### LATER LOG ################################## (I went back to set-up and enabled "stupid Mode")
SuSE Meta pppd (smpppd-ifcfg), Version 1.00 on linux. ... pppd: Using interface ppp0 pppd: Connect: ppp0 <--> /dev/ttyS0 pppd: No response to PAP authenticate-requests
No autentification to PAP - maybe it wants CHAP instead and you have it dissabled - and if your server is MS-like, it will want CHAP-MS What program are you using to connect? Im not familiar with smpppd-ifcfg, I use wvdial directly.
pppd: Connection terminated. pppd: Hangup (SIGHUP) We are disconnected. pppd died: Authentication error (exit code 19)
Right, code 19, see man pppd: 15 The link was terminated because the peer is not responding to echo requests. 19 We failed to authenticate ourselves to the peer. -- Cheers, Carlos Robinson
Keith Keesing wrote:
I seem to have trouble getting recognised by my ISP
Can anyone point out to an ignorant novice what is going on here, and how to fix it.
How do I inform myself about "signal 15" & "exit code 19" etc
Where does the "[09]" in the "EARLY LOG" come from ?
I have installed 8.2 personal - I haven't come across any other problems yet
##### EARLY LOG ###################################
SuSE Meta pppd (smpppd-ifcfg), Version 1.00 on linux. We are disconnected. trying to connect to smpppd connect to smpppd We are disconnected. We are connecting. pppd: Plugin passwordfd.so loaded. pppd: --> WvDial: Internet dialer version 1.42 pppd: --> Initializing modem. pppd: --> Sending: ATZ pppd: ATZ pppd: OK pppd: --> Sending: AT&C1&D2 pppd: AT&C1&D2 pppd: OK pppd: --> Sending: ATM1 pppd: ATM1 pppd: OK pppd: --> Modem initialized. pppd: --> Sending: ATDT086707070 pppd: --> Waiting for carrier. pppd: ATDT086707070 pppd: CONNECT 115200 <===================================XX pppd: --> Carrier detected. Waiting for prompt.
Here's your problem - the connect at 115200. You should be connecting at 57600. The 115200 is the speed your computer talks to your modem. What actually is happening in your case is that the two modems are not talking to each other, or your computer doesn't understand what the modem is trying to pass to it and, therefore, the connection times out. Check in YaST (that is, the part where the info re your modem and your ISP is set up) that the modem to computer baud rate is set to 115200; however, in /etc/wvdial.conf BAUD should be set to 57600. (If you are using kppp then set the rate there to 57600.) 115200 is the baud rate at which the computer and the modem talk to each other. 57600 is the (maximum) baud rate your modem can talk to your ISP's modem. Cheers. -- I am not young enough to know everything.
The Friday 2004-04-30 at 18:15 +1000, Basil Chupin wrote:
pppd: CONNECT 115200 <===================================XX pppd: --> Carrier detected. Waiting for prompt.
Here's your problem - the connect at 115200.
Not really. There are two speeds to note, and they can be different. One is the speed from the computer to the modem, and it is quite correct to set it a 115200 - I'll explain later. Then there is the speed at which the local modem connects to the remote modem, and this is negotiated while the connection is established - it is not set by the user directly (not normally). The maximum for a V90 modem is 57600: speeds between 45000..52000 are normal. However, V90 can use compression; this will not work if you limit the speed at which the computer feeds data to the modem. That's the reason why the computer can (and should) connect with the modem at 115200 cps. The modem should really report the real speed at which it is connecting to the remote, but this is usually configurable - somehow, but I can't remember how.. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
The Friday 2004-04-30 at 18:15 +1000, Basil Chupin wrote:
pppd: CONNECT 115200 <===================================XX pppd: --> Carrier detected. Waiting for prompt.
Here's your problem - the connect at 115200.
Not really.
There are two speeds to note, and they can be different. One is the speed from the computer to the modem, and it is quite correct to set it a 115200 - I'll explain later.
Then there is the speed at which the local modem connects to the remote modem, and this is negotiated while the connection is established - it is not set by the user directly (not normally). The maximum for a V90 modem is 57600: speeds between 45000..52000 are normal.
However, V90 can use compression; this will not work if you limit the speed at which the computer feeds data to the modem. That's the reason why the computer can (and should) connect with the modem at 115200 cps.
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast. A connect speed of 115200 simply indicates that the settings are wrong and the modem is reporting the DCE speed and not the actual connect speed of the 2 modems. (Depending on the modem, one can control the connect speed using the S37 register together with the (AT)N parameter - and have the connect speed reported using the (AT)W paramteter; however, one cannot go above the prescribed 57600 connect speed although, of course, one can deliberately connect at a lower rate (essential if the phone line(s) are bad). But I don't think it is necessary to go into all this in Keith's case :-) ,) I admit that in my reply to Keith I was just a bit sloppy - but I was tryng to get the message across that the settings (computer to modem at 115200 [provided that the modem can actually accept this speed] baud and modem-to-ISP at 57600) have to be checked to solve his problem. The compression you mention above can only apply to data which can actually be compressed, but even if it is compressed it can still only get transmitted at the theoretical upper limit of 57600 bps; and being compressed it *appears* that it is being transmitted quicker. An example of data which can be compressed is a text document (an ASCII document); an example of something which cannot be compressed is a zip-ped file or, in Linux terms, a *.gz file because these are already compressed. Something else which cannot be compressed is a *.jpg file - which one sees all the time on websites - because, again, it is already compressed. (The MNP5 protocol, the data compression protocol, can actually be a pain in the behind because it will compress/uncompress data whether or not the data requires it and therefore can slow down the flow of data. I normally switch it off (it's normally ON by default in modems) with the AT%C0 command).)
The modem should really report the real speed at which it is connecting to the remote, but this is usually configurable - somehow, but I can't remember how..
Again depending on the modem, the S95 register together with the (AT)W parameter will do this Cheers. -- I am not young enough to know everything.
The Sunday 2004-05-02 at 16:36 +1000, Basil Chupin wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast.
I know. I work(ed) in that field. :-) However, as I said, there are two serial connections involved with a modem, and the first one, from computer to modem, can be quite higher, and is in fact recommended to be higher. For example, this is my configuration: nimrodel:~ # setserial -a /dev/modem /dev/modem, Line 1, UART: 16550A, Port: 0x02f8, IRQ: 3 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test And I can assure you it works. The actual connection speed (local modem to exchange router (modem)) was reported the last time as: ATDT908200290 CONNECT 50666/ARQ/V90/LAPM/V42BIS
A connect speed of 115200 simply indicates that the settings are wrong and the modem is reporting the DCE speed and not the actual connect speed of the 2 modems.
Not necessarily wrong: it is simply reporting the speed of the serial port from the computer to the local modem, which is not useful - but not necessarily wrong.
The compression you mention above can only apply to data which can actually be compressed, but even if it is compressed it can still only get transmitted at the theoretical upper limit of 57600 bps; and being compressed it *appears* that it is being transmitted quicker.
More or less :-) The speed on the line, is of course, limited to the connection speed (bytes per second). However, the observed dataflow speed by the system can be higher if, as you say, the data can be compressed - for example, normal mail can -. For this to work, however, the serial port of the computer has to be higher than the modem to modem connect speed. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
The Sunday 2004-05-02 at 16:36 +1000, Basil Chupin wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast.
I know. I work(ed) in that field. :-)
[rest pruned] Ah, this is a case of the converted preaching to the converted :-). I'll let you field the statement from Brad (re the venerable Monsieur Baudot :-)). Cheers. -- I am not young enough to know everything.
On Mon, 2004-05-03 at 10:53, Basil Chupin wrote:
Carlos E. R. wrote:
The Sunday 2004-05-02 at 16:36 +1000, Basil Chupin wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast.
I know. I work(ed) in that field. :-)
[rest pruned]
Ah, this is a case of the converted preaching to the converted :-).
I'll let you field the statement from Brad (re the venerable Monsieur Baudot :-)).
`*8> I didn't send that response to the list. Only to you. I don't like publicly responding to something that may be interpreted as an embarrasment so I repond privately. -- Brad Shelton On Line Exchange http://www.ole.net Phone: 313-526-1111 Fax: 313-526-3333
Brad Shelton wrote:
On Mon, 2004-05-03 at 10:53, Basil Chupin wrote:
Carlos E. R. wrote:
The Sunday 2004-05-02 at 16:36 +1000, Basil Chupin wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast.
I know. I work(ed) in that field. :-)
[rest pruned]
Ah, this is a case of the converted preaching to the converted :-).
I'll let you field the statement from Brad (re the venerable Monsieur Baudot :-)).
`*8>
I didn't send that response to the list. Only to you.
I don't like publicly responding to something that may be interpreted as an embarrasment so I repond privately.
An apology is therefore appropriate - with an explanation. My message filter throws all messages with (SLE) in the Subject line into this forum, and I also display on the screen VERY abbreviated Header information (Subject and From only) so to me all messages in this forum are non-private. Following your message I've made more of the Header info visible so that I won't make this boo-boo again. But, as you will see, the contents of your message have not been posted in this forum. Cheers. -- I am not young enough to know everything.
The Wednesday 2004-05-05 at 15:04 +1000, Basil Chupin wrote:
My message filter throws all messages with (SLE) in the Subject line into this forum, and I also display on the screen VERY abbreviated Header information (Subject and From only) so to me all messages in this forum are non-private. Following your message I've made more of the Header info visible so that I won't make this boo-boo again.
If you use procmail, I have a recipe that will separate in three folders: suse-linux-e Only the list dups The CC copy priv direct email and it never fails. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
The Wednesday 2004-05-05 at 15:04 +1000, Basil Chupin wrote:
My message filter throws all messages with (SLE) in the Subject line into this forum, and I also display on the screen VERY abbreviated Header information (Subject and From only) so to me all messages in this forum are non-private. Following your message I've made more of the Header info visible so that I won't make this boo-boo again.
If you use procmail, I have a recipe that will separate in three folders:
suse-linux-e Only the list dups The CC copy priv direct email
and it never fails.
No, I use Thunderbird (and Firebird) but I will see if these settings can be applied in Thunderbird. Cheers. -- I am not young enough to know everything.
The Friday 2004-05-07 at 01:18 +1000, Basil Chupin wrote:
If you use procmail, I have a recipe that will separate in three folders:
suse-linux-e Only the list dups The CC copy priv direct email
and it never fails.
No, I use Thunderbird (and Firebird) but I will see if these settings can be applied in Thunderbird.
I use the following - I suppose it can be modified for most kinds of filters - except the formail part: :0 # it is a mail to robin1 mailbox * whatever - depends on your setup { # Add a Reply-To to this mail list, and move to the correct file. :0f * ^X-Mailinglist: suse-linux-e | /usr/bin/formail -bfi "Reply-To:suse-linux-e@suse.com" :0 a: $HOME/Mail/lists/suse-linux-e # process other lists #... # handle CCs :0 * ^TO_suse-linux-e@suse.com $HOME/Mail/lists/in_dups # same for all lists # handle direct email - any thing not clasified yet, is a direct email :0 $HOME/Mail/lists/in_elresto } -- Cheers, Carlos Robinson
The Tuesday 2004-05-04 at 00:53 +1000, Basil Chupin wrote:
I know. I work(ed) in that field. :-)
[rest pruned]
Ah, this is a case of the converted preaching to the converted :-).
I starting to get the impression that we were saying the same with diferent words.
I'll let you field the statement from Brad (re the venerable Monsieur Baudot :-)).
Ouch ;-) -- Cheers, Carlos Robinson
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast. Maybe my memory isn't so great but I thought that's what they said about
Basil Chupin wrote: previous hurdles (9600). Damon Register
Damon Register wrote:
Basil Chupin wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast.
Maybe my memory isn't so great but I thought that's what they said about previous hurdles (9600).
Damon Register
I think they also said that when the 300 baud modem came out :-). And when the first steam engine train was being tested it was stated that man would not survive if the train reached a speed of 20 mph :-). Interestingly, a man here in one of our states (South Australia I believe) came up with a modem which will do over 100,000 bps over the current phone lines (it was successfully tested), but it seems that it has not got off the ground. My supposition for this is that the broadband pushers wouldn't be able to make as many shekels if such a modem went into production. (Just like some 20+ years ago a man in the state of Victoria invented a setup which totally prevented the front wheels of a vehicle from going out of alignment even if the vehicle was driven at full speed into the kerb. His invention was bought by one of the car companies (I won't mention which one) -- and that is the last time anyone ever saw it again.) (OK, OK, all this is off-topic I know. I shall desist.) Cheers. -- I am not young enough to know everything.
The Tuesday 2004-05-04 at 03:01 +1000, Basil Chupin wrote:
Interestingly, a man here in one of our states (South Australia I believe) came up with a modem which will do over 100,000 bps over the current phone lines (it was successfully tested), but it seems that it has not got off the ground. My supposition for this is that the broadband pushers wouldn't be able to make as many shekels if such a modem went into production.
My guess would be that it would not be economical now that we have ADSL, that is even faster, and that needs new equipment on the local exchanges - and those investments have to be paid. I don't suppose they are over happy at installing even newer equipment. However... noting the large distance that some phone lines have to cover in your country (rural phones), and that ADSL will not work over... I think 5 km is the limit (even 2 is difficult), I suppose that a 100,000 bps modem is interesting. It would probably need special equipment at the local exchange, I think. -- Cheers, Carlos Robinson
Damon Register wrote:
Basil Chupin wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast.
Maybe my memory isn't so great but I thought that's what they said about previous hurdles (9600).
Damon Register
I believe that for US phones, 9600 is about at the baud limit. However, and not to be to pedantic, baud is not the correct term. Modems operate at a certain BPS (bits/sec.), which is not the same as baud. This is due to compression that allows a higher bitrate than baud rate. -- Jim Sabatke Hire Me!! - See my resume at http://my.execpc.com/~jsabatke Do not meddle in the affairs of Dragons, for you are crunchy and good with ketchup.
Jim Sabatke wrote:
Damon Register wrote:
Basil Chupin wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast.
Maybe my memory isn't so great but I thought that's what they said about previous hurdles (9600).
Damon Register
I believe that for US phones, 9600 is about at the baud limit.
In our country (Australia) the telco officially only guarantees satisfactory results of up to 2400 bps (on a standard phone line).
However, and not to be to pedantic, baud is not the correct term. Modems operate at a certain BPS (bits/sec.), which is not the same as baud. This is due to compression that allows a higher bitrate than baud rate.
Baud/baud rate is the transmission rate between 2 modems measured in bits per second (bps). But what confuses the picture more is the fact that since there are 8 bits + 2 stop bits in a transmitted word/byte (character), dividing the bps by 10 gives you the number of BYTES/chars trasmitted per second which is also termed bps. (For example, if you are using kinternet in SuSE and look at the Date Rate flow monitor you'll see the rate shown as, say, 4.0kb/s and not 40,000 bps.) Confusion reigns :-). Cheers. -- I am not young enough to know everything.
The Monday 2004-05-03 at 10:33 -0700, Jim Sabatke wrote:
I believe that for US phones, 9600 is about at the baud limit. However, and not to be to pedantic, baud is not the correct term. Modems operate at a certain BPS (bits/sec.), which is not the same as baud. This is due to compression that allows a higher bitrate than baud rate.
Er... baud is not the same as bit rate, true, but it has nothing to do with compression. Baud (after J.M. Baudot) measures the signaling rate, ie, the rate at which transmission-line changes are occurring. For example, if we can play with 4 phase shifts of the signal, and two amplitudes, we can transmit 8 values per change (0..7), ie, 3 bits, per change. Thus, at a frequency of 2400 Hz, we have 2400 bauds but 19200 bits per second. (Don't take me too seriously, it has been years since I do these numbers). The physical limits mentioned by the telephone companies come from several things. Time ago, the limit was the bandwidth of the analog equipment (specially for long distance using frequency multiplex). Now days, the limit is that the signal is digitized at 1 byte x 8 KHz And we are digressing a lot off topic, I suppose. O:-) -- Cheers, Carlos Robinson
The Monday 2004-05-03 at 11:20 -0700, Damon Register wrote:
It is physically not possible to connect on a dial-up connection above 57600 baud - nor can data flow faster than the theoretical 57600 baud simply because this is the upper limit of the beast. Maybe my memory isn't so great but I thought that's what they said about
Basil Chupin wrote: previous hurdles (9600).
No, there is a physical limit at precisely 57600 bit per second (not baud) in north america and a few other countries (Japan?), and 64 kps elsewhere (the ISDN speed). The reason is that the analog signal used on the local loop side is digitized on entry to the exchange at that rate (8 kilo samples per second of 1 byte each). It is not possible to transmit more over any digital transmission system designed for a precise data rate. Notice that the ISP rack might not be placed at your local exchange, but could be at hundreds of miles farther up: after all, once digitized, there is no degradation of signals. However... It is of course possible to be faster over the wires (local loop) using special equipment: that is, after all, what is done with ADSL, that can reach 1 megabit per second (depending on line quality and distance). -- Cheers, Carlos Robinson
participants (8)
-
Anders Johansson -
Basil Chupin -
Brad Shelton -
Carlos E. R. -
Damon Register -
Jim Sabatke -
John -
Keith Keesing