Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
On 18 Sep 1999, John Hasler wrote: Robert King writes: The modem responds fine from cu. I get an OK back from ATF. What does it do if you send it ATZ from cu? I get OK back. Try replacing ATZ with ATF in /etc/chatscripts/provider. OK, I'll try that after this session. (I'm connected from the slackware connection at the moment. I think it could be a problem with changes to pppd. At the point at which your problem occurs pppd isn't doing anything. It just connects chat to the serial port and waits. OK - so you're pretty sure this is a chat issue Robert King, Australian Environmental Studies, Griffith University, Australia 3875 6677 [EMAIL PROTECTED] http://www.ens.gu.edu.au/robertk/ statistician (n.) someone who can draw a mathematically precise line from an unwarranted assumption to a foregone conclusion. [anon.]
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
Robert King writes: OK - so you're pretty sure this is a chat issue It is possible that pppd isn't getting chat properly hooked to the serial port, but that seems unlikely. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
I just had a thought. Try changing the line '' ATZ to '' \dATZ The '\d' tells chat to pause for one second. The modem may need some time to get ready. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
Regarding my problem getting chat to do anything, even though the serial line is OK, evidenced by successful cu sessions and the ability to get pppd going on the slackware install on the same machine. On 19 Sep 1999, John Hasler wrote: I just had a thought. Try changing the line '' ATZ to '' \dATZ The '\d' tells chat to pause for one second. The modem may need some time to get ready. The same thing happens. /var/log/messages follows: Sep 20 11:54:22 castle syslogd 1.3-3#32: restart. Sep 20 11:54:22 castle kernel: klogd 1.3-3#32, log source = /proc/kmsg started. Sep 20 11:54:22 castle kernel: Inspecting /boot/System.map-2.2.10 Sep 20 11:54:22 castle kernel: Loaded 9268 symbols from /boot/System.map-2.2.10. Sep 20 11:54:22 castle kernel: Symbols match kernel version 2.2.10. Sep 20 11:54:22 castle kernel: Loaded 107 symbols from 10 modules. Sep 20 11:54:22 castle kernel: Linux version 2.2.10 ([EMAIL PROTECTED]) (gcc version e gcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)) #2 Wed Jun 16 00:23:31 EST 1999 Sep 20 11:54:22 castle kernel: Detected 233872887 Hz processor. Sep 20 11:54:22 castle kernel: Console: colour VGA+ 80x25 Sep 20 11:54:22 castle kernel: Calibrating delay loop... 233.47 BogoMIPS Sep 20 11:54:22 castle kernel: Memory: 62184k/65536k available (1688k kernel cod e, 408k reserved, 1100k data, 156k init) Sep 20 11:54:22 castle kernel: Checking if this processor honours the WP bit eve n in supervisor mode... Ok. Sep 20 11:54:22 castle kernel: VFS: Diskquotas version dquot_6.4.0 initialized Sep 20 11:54:22 castle kernel: CPU: Cyrix M II 3.5x Core/Bus Clock stepping 03 Sep 20 11:54:22 castle kernel: Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Sep 20 11:54:22 castle kernel: Checking 'hlt' instruction... OK. Sep 20 11:54:22 castle kernel: Checking for popad bug... OK. Sep 20 11:54:22 castle kernel: POSIX conformance testing by UNIFIX Sep 20 11:54:22 castle kernel: mtrr: v1.35 (19990512) Richard Gooch ([EMAIL PROTECTED]) Sep 20 11:54:22 castle kernel: PCI: PCI BIOS revision 2.10 entry at 0xfb310 Sep 20 11:54:22 castle kernel: PCI: Using configuration type 1 Sep 20 11:54:22 castle kernel: PCI: Probing PCI hardware Sep 20 11:54:22 castle kernel: Linux NET4.0 for Linux 2.2 Sep 20 11:54:22 castle kernel: Based upon Swansea University Computer Society NET3.039 Sep 20 11:54:22 castle kernel: NET4: Linux TCP/IP 1.0 for NET4.0 Sep 20 11:54:22 castle kernel: IP Protocols: ICMP, UDP, TCP, IGMP Sep 20 11:54:22 castle kernel: Starting kswapd v 1.5 Sep 20 11:54:22 castle kernel: Detected PS/2 Mouse Port. Sep 20 11:54:22 castle kernel: Real Time Clock Driver v1.09 Sep 20 11:54:22 castle kernel: tpqic02: Runtime config, $Revision: 1.10 $, $Date : 1997/01/26 07:13:20 $ Sep 20 11:54:22 castle kernel: tpqic02: DMA buffers: 20 blocks Sep 20 11:54:22 castle kernel: RAM disk driver initialized: 16 RAM disks of 4096K size Sep 20 11:54:22 castle kernel: loop: registered device at major 7 Sep 20 11:54:22 castle kernel: PCI_IDE: unknown IDE controller on PCI bus 00 device 78, VID=10b9, DID=5229 Sep 20 11:54:22 castle kernel: PCI_IDE: not 100% native mode: will probe irqs later Sep 20 11:54:22 castle kernel: PCI_IDE: simplex device: DMA disabled Sep 20 11:54:22 castle kernel: ide0: PCI_IDE Bus-Master DMA disabled (BIOS) Sep 20 11:54:22 castle kernel: PCI_IDE: simplex device: DMA disabled Sep 20 11:54:22 castle kernel: ide1: PCI_IDE Bus-Master DMA disabled (BIOS) Sep 20 11:54:22 castle kernel: hda: FUJITSU MPC3043AT, ATA DISK drive Sep 20 11:54:22 castle kernel: hdb: WDC AC2850F, ATA DISK drive Sep 20 11:54:22 castle kernel: hdd: GCD-R540, ATAPI CDROM drive Sep 20 11:54:22 castle kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Sep 20 11:54:22 castle kernel: ide1 at 0x170-0x177,0x376 on irq 15 Sep 20 11:54:22 castle kernel: hda: FUJITSU MPC3043AT, 4125MB w/0kB Cache, CHS=5 25/255/63 Sep 20 11:54:22 castle kernel: hdb: WDC AC2850F, 814MB w/64kB Cache, CHS=827/32/ 63 Sep 20 11:54:22 castle kernel: hdd: ATAPI 4X CD-ROM drive, 128kB Cache Sep 20 11:54:22 castle kernel: Uniform CDROM driver Revision: 2.55 Sep 20 11:54:22 castle kernel: Floppy drive(s): fd0 is 1.44M Sep 20 11:54:22 castle kernel: FDC 0 is a post-1991 82077 Sep 20 11:54:22 castle kernel: md driver 0.36.6 MAX_MD_DEV=4, MAX_REAL=8 Sep 20 11:54:22 castle kernel: scsi: fdomain Detection failed (no card) Sep 20 11:54:22 castle kernel: NCR53c406a: no available ports found Sep 20 11:54:22 castle kernel: sym53c416.c: Version 1.0.0 Sep 20 11:54:22 castle kernel: Failed initialization of WD-7000 SCSI card! Sep 20 11:54:22 castle kernel: IBM MCA SCSI: No Microchannel-bus support present - Aborting. Sep 20 11:54:22 castle kernel: EATA0: address 0x1f0 in use, skipping probe. Sep 20 11:54:22 castle kernel: EATA0: address 0x170 in use, skipping probe. Sep 20 11:54:22 castle kernel: DC390: 0 adapters found Sep 20 11:54:22 castle kernel: aec671x_detect: Sep 20 11:54:22
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
On 18 Sep 1999, John Hasler wrote: Robert King wrote: I'm fairly sure that the serial conifg is OK, as I can get out with cu -l /dev/ttyS1, but when I try to start pppd, it complains about cu having the serial line and won't let it at it. Odd. I just tried cu on this system and it complains that the line is in use. Pon works fine. Is there anything in /var/lock? This might be a bug in cu. There is nothing locking in /var/lock Aug 4 19:16:01 castle chat[621]: send (ATZ^M) Aug 4 19:16:01 castle chat[621]: expect (OK) Aug 4 19:16:46 castle chat[621]: alarm Aug 4 19:16:46 castle chat[621]: send (AT^M) Aug 4 19:16:46 castle chat[621]: expect (OK) Aug 4 19:17:31 castle chat[621]: alarm Aug 4 19:17:31 castle chat[621]: Failed Your modem is failing to respond. What happens when you send it 'ATZ' from cu? The modem responds fine from cu. I get an OK back from ATF. I can log in to another machine using cu. The only time the modem doesn't respond is when chat tries to talk to it. Please post your /etc/chatscripts/provider and /etc/ppp/peers/provider files. etc/chatscripts/provider: # This chatfile was generated by pppconfig 1.9.2beta2.0. # Please do not delete any of the comments. Pppconfig needs them. # # ispauth PAP # abortstring ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TON E' ABORT 'NO ANSWER' # modeminit '' ATZ # ispnumber OK-AT-OK ATDT33008100 # ispconnect CONNECT \d\c # prelogin # ispname # name deleted by me # isppassword # password delted by me # postlogin - etc/ppp/peers/provider: # This optionfile was generated by pppconfig 1.9.2beta2.0. # # hide-password noauth connect /usr/sbin/chat -v -f /etc/chatscripts/provider debug /dev/ttyS1 115200 defaultroute noipdefault user zzkylie remotename provider ipparam provider usepeerdns - Thanks for any light you can shed on this I think it could be a problem with changes to pppd. The version thats working is from my Dec 1996 slackware (from ppp 2.1.2b) robert. Robert King, Australian Environmental Studies, Griffith University, Australia 3875 6677 [EMAIL PROTECTED] http://www.ens.gu.edu.au/robertk/ statistician (n.) someone who can draw a mathematically precise line from an unwarranted assumption to a foregone conclusion. [anon.]
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
On Sat, 18 Sep 1999, Marcin Owsiany wrote: first thing: should there be any chat script at all if you authenticate using cu? (i've never used cu, so i may be wrong) Should the chat script try to reset the modem if it has already connected?? (the ATZ and AT) This is using pon on the new setup. I only use cu on the slackware setup because that's all that was available at the time. I tried installing wvdial one time and had similar problems. I thought maybe I have some weird hardware problem with the serial card, but this is a new one with the new motherboard, and the old one does exactly the same. I would try to edit /etc/chatscripts/provider to contain only one line: '' '' if I were you. On Sat, Sep 18, 1999 at 05:06:18PM +1000, [EMAIL PROTECTED] wrote: One thing that concerned me was that the kernel messages from dmesg don't mention the ppp0 device as happens on a working debian ppp machine I've seen. The relevant part of dmesg looks like this PPP: version 2.3.7 (demand dialling) PPP line discipline registered. and that's it. What is happening? this is how it looks like on my system (slink, 2.2.12): PPP: version 2.3.7 (demand dialling) PPP line discipline registered. registered device ppp0 PPP BSD Compression module registered PPP Deflate Compression module registered PPP: ppp line discipline successfully unregistered and as far as i can remember, the registered device ppp0 appears only after chat script has finished successfully: My friedns machine gets the registered device ppp0 during boot up and he doesn't start pppd at that stage. Sep 18 12:56:04 pecet pppd[166]: Serial connection established. Sep 18 12:56:05 pecet pppd[166]: Using interface ppp0 hope this helps, Marcin -- Marcin Owsiany [EMAIL PROTECTED] Robert King, Australian Environmental Studies, Griffith University, Australia 3875 6677 [EMAIL PROTECTED] http://www.ens.gu.edu.au/robertk/ statistician (n.) someone who can draw a mathematically precise line from an unwarranted assumption to a foregone conclusion. [anon.]
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
On Sat, 18 Sep 1999, Jesse Jacobsen wrote: --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I wonder if you've set up Debian to use /dev/cua1. It should use /dev/ttyS1 instead, since the cua- callout devices are being phased out. I thought I was asking it to use ttyS1, but where would this be for me to check? Thanks, Robert. Robert King, Australian Environmental Studies, Griffith University, Australia 3875 6677 [EMAIL PROTECTED] http://www.ens.gu.edu.au/robertk/ statistician (n.) someone who can draw a mathematically precise line from an unwarranted assumption to a foregone conclusion. [anon.]
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
Robert King writes: The modem responds fine from cu. I get an OK back from ATF. What does it do if you send it ATZ from cu? Try replacing ATZ with ATF in /etc/chatscripts/provider. I think it could be a problem with changes to pppd. At the point at which your problem occurs pppd isn't doing anything. It just connects chat to the serial port and waits. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
Robert writes: I thought I was asking it to use ttyS1 Robert You are. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
Hi, I'm typing this from my old slackware install. I connect on this installation using cu -l /dev/cua1 then negotiating my way through my ISP's login manually, then start pppd in another window, then quitting from cu. This worked fine whne this machine was a 486 and now works with a new motherboard cpu. I tried installing potato on the machine, and most things are going fine, except that sound isn't working on the new setup, and ppp won't work on it. I'm fairly sure that the serial conifg is OK, as I can get out with cu -l /dev/ttyS1, but when I try to start pppd, it complains about cu having the serial line and won't let it at it. As far as using pon, I get the following : Aug 4 19:16:00 castle kernel: PPP: version 2.2.0 (dynamic channel allocation) Aug 4 19:16:00 castle kernel: PPP Dynamic channel allocation code copyright 199 5 Caldera, Inc. Aug 4 19:16:00 castle kernel: PPP line discipline registered. Aug 4 19:16:00 castle kernel: registered device ppp0 Aug 4 19:16:00 castle pppd[620]: pppd 2.3.8 started by robert, uid 1000 Aug 4 19:16:01 castle chat[621]: abort on (BUSY) Aug 4 19:16:01 castle chat[621]: abort on (NO CARRIER) Aug 4 19:16:01 castle chat[621]: abort on (VOICE) Aug 4 19:16:01 castle chat[621]: abort on (NO DIALTONE) Aug 4 19:16:01 castle chat[621]: abort on (NO DIAL TONE) Aug 4 19:16:01 castle chat[621]: abort on (NO ANSWER) Aug 4 19:16:01 castle chat[621]: send (ATZ^M) Aug 4 19:16:01 castle chat[621]: expect (OK) Aug 4 19:16:46 castle chat[621]: alarm Aug 4 19:16:46 castle chat[621]: send (AT^M) Aug 4 19:16:46 castle chat[621]: expect (OK) Aug 4 19:17:31 castle chat[621]: alarm Aug 4 19:17:31 castle chat[621]: Failed Aug 4 19:17:32 castle pppd[620]: Exit. Aug 4 19:18:00 castle kernel: PPP: ppp line discipline successfully unregistere One thing that concerned me was that the kernel messages from dmesg don't mention the ppp0 device as happens on a working debian ppp machine I've seen. The relevant part of dmesg looks like this PPP: version 2.3.7 (demand dialling) PPP line discipline registered. and that's it. What is happening? ppp is a kernel module and the same problem happens with kernels 2.0.36 and 2.2.10 (from the debian packages) Help! Robert King, Australian Environmental Studies, Griffith University, Australia 3875 6677 [EMAIL PROTECTED] http://www.ens.gu.edu.au/robertk/ statistician (n.) someone who can draw a mathematically precise line from an unwarranted assumption to a foregone conclusion. [anon.]
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
I'm fairly sure that the serial conifg is OK, as I can get out with cu -l /dev/ttyS1, but when I try to start pppd, it complains about cu having the serial line and won't let it at it. Odd. I just tried cu on this system and it complains that the line is in use. Pon works fine. Is there anything in /var/lock? This might be a bug in cu. Aug 4 19:16:01 castle chat[621]: send (ATZ^M) Aug 4 19:16:01 castle chat[621]: expect (OK) Aug 4 19:16:46 castle chat[621]: alarm Aug 4 19:16:46 castle chat[621]: send (AT^M) Aug 4 19:16:46 castle chat[621]: expect (OK) Aug 4 19:17:31 castle chat[621]: alarm Aug 4 19:17:31 castle chat[621]: Failed Your modem is failing to respond. What happens when you send it 'ATZ' from cu? Please post your /etc/chatscripts/provider and /etc/ppp/peers/provider files. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
On 09/18/99 at 17:06:18, [EMAIL PROTECTED] wrote concerning ppp failure under debian (slakware with pppd 2.2 patch level 0 works): Hi, I'm typing this from my old slackware install. I connect on this installation using cu -l /dev/cua1 then negotiating my way through my ISP's login manually, then start pppd in another window, then quitting from cu. This worked fine whne this machine was a 486 and now works with a new motherboard cpu. I wonder if you've set up Debian to use /dev/cua1. It should use /dev/ttyS1 instead, since the cua- callout devices are being phased out. -- Jesse Jacobsen, Pastor [EMAIL PROTECTED] Grace Lutheran Church (ELS) http://www.jvlnet.com/~jjacobsen/ Madison, Wisconsin GnuPG public key ID: 2E3EBF13 pgpBvhkq2Q3G1.pgp Description: PGP signature
Re: ppp failure under debian (slakware with pppd 2.2 patch level 0 works)
On Sat, Sep 18, 1999 at 05:06:18PM +1000, [EMAIL PROTECTED] wrote: Hi, I'm typing this from my old slackware install. I connect on this installation using cu -l /dev/cua1 then negotiating my way through my ISP's login manually, then start pppd in another window, then quitting from cu. This worked fine whne this machine was a 486 and now works with a new motherboard cpu. I tried installing potato on the machine, and most things are going fine, except that sound isn't working on the new setup, and ppp won't work on it. I'm fairly sure that the serial conifg is OK, as I can get out with cu -l /dev/ttyS1, but when I try to start pppd, it complains about cu having the serial line and won't let it at it. As far as using pon, I get the following : Aug 4 19:16:00 castle kernel: PPP: version 2.2.0 (dynamic channel allocation) Aug 4 19:16:00 castle kernel: PPP Dynamic channel allocation code copyright 199 5 Caldera, Inc. Aug 4 19:16:00 castle kernel: PPP line discipline registered. Aug 4 19:16:00 castle kernel: registered device ppp0 Aug 4 19:16:00 castle pppd[620]: pppd 2.3.8 started by robert, uid 1000 Aug 4 19:16:01 castle chat[621]: abort on (BUSY) Aug 4 19:16:01 castle chat[621]: abort on (NO CARRIER) Aug 4 19:16:01 castle chat[621]: abort on (VOICE) Aug 4 19:16:01 castle chat[621]: abort on (NO DIALTONE) Aug 4 19:16:01 castle chat[621]: abort on (NO DIAL TONE) Aug 4 19:16:01 castle chat[621]: abort on (NO ANSWER) Aug 4 19:16:01 castle chat[621]: send (ATZ^M) Aug 4 19:16:01 castle chat[621]: expect (OK) Aug 4 19:16:46 castle chat[621]: alarm Aug 4 19:16:46 castle chat[621]: send (AT^M) Aug 4 19:16:46 castle chat[621]: expect (OK) Aug 4 19:17:31 castle chat[621]: alarm Aug 4 19:17:31 castle chat[621]: Failed Aug 4 19:17:32 castle pppd[620]: Exit. Aug 4 19:18:00 castle kernel: PPP: ppp line discipline successfully unregistere first thing: should there be any chat script at all if you authenticate using cu? (i've never used cu, so i may be wrong) Should the chat script try to reset the modem if it has already connected?? (the ATZ and AT) I would try to edit /etc/chatscripts/provider to contain only one line: '' '' if I were you. One thing that concerned me was that the kernel messages from dmesg don't mention the ppp0 device as happens on a working debian ppp machine I've seen. The relevant part of dmesg looks like this PPP: version 2.3.7 (demand dialling) PPP line discipline registered. and that's it. What is happening? this is how it looks like on my system (slink, 2.2.12): PPP: version 2.3.7 (demand dialling) PPP line discipline registered. registered device ppp0 PPP BSD Compression module registered PPP Deflate Compression module registered PPP: ppp line discipline successfully unregistered and as far as i can remember, the registered device ppp0 appears only after chat script has finished successfully: Sep 18 12:56:04 pecet pppd[166]: Serial connection established. Sep 18 12:56:05 pecet pppd[166]: Using interface ppp0 hope this helps, Marcin -- Marcin Owsiany [EMAIL PROTECTED]
