Bug 7760 - Can't do a dial up with PPP and chat/wvdial
Can't do a dial up with PPP and chat/wvdial
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: ppp (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-12-11 22:48 EST by rhopkins
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-13 20:51:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace output (482.61 KB, text/plain)
2000-02-29 11:43 EST, Nalin Dahyabhai
no flags Details

  None (edit)
Description rhopkins 1999-12-11 22:48:58 EST
Hi,
	I am currently having problems getting a dial-up connection in
RH 6.1 working.  I've tried to set up ppp0 through linuxconf, netcfg,
or wvdial and I get the same problem everytime.  What happens is that
when i start the connection using 'ifup ppp0' or using usernet, ppp
starts natrually and runs the chat script (or wvdial) and hangs when
the ATDT line is sent to the modem.  Here are my logs using chat and
wvdial:

chat:
-----
Dec  2 23:51:12 winyahbay ifup-ppp: pppd started for ppp0 on
/dev/modem at 115200
Dec  2 23:51:12 winyahbay modprobe: can't locate module char-major-108
Dec  2 23:51:12 winyahbay kernel: CSLIP: code copyright 1989 Regents
of the University of California
Dec  2 23:51:12 winyahbay kernel: PPP: version 2.3.7 (demand dialling)

Dec  2 23:51:12 winyahbay kernel: PPP line discipline registered.
Dec  2 23:51:12 winyahbay kernel: registered device ppp0
Dec  2 23:51:12 winyahbay pppd[2264]: pppd 2.3.10 started by root, uid
0
Dec  2 23:51:13 winyahbay chat[2277]: abort on (BUSY)
Dec  2 23:51:13 winyahbay chat[2277]: abort on (ERROR)
Dec  2 23:51:13 winyahbay chat[2277]: abort on (NO CARRIER)
Dec  2 23:51:13 winyahbay chat[2277]: abort on (NO DIALTONE)
Dec  2 23:51:13 winyahbay chat[2277]: abort on (Invalid Login)
Dec  2 23:51:13 winyahbay chat[2277]: abort on (Login incorrect)
Dec  2 23:51:13 winyahbay chat[2277]: send (ATZ^M)
Dec  2 23:51:13 winyahbay chat[2277]: expect (OK)
Dec  2 23:51:14 winyahbay chat[2277]: ATZ^M^M
Dec  2 23:51:14 winyahbay chat[2277]: OK
Dec  2 23:51:14 winyahbay chat[2277]:  -- got it
Dec  2 23:51:14 winyahbay chat[2277]: send (ATDTXXX-XXXX^M)
Dec  2 23:51:14 winyahbay chat[2277]: expect (CONNECT)
Dec  2 23:51:14 winyahbay chat[2277]: ^M

wvdial:
-------
Dec  2 23:56:31 winyahbay ifup-ppp: pppd started for ppp0 on
/dev/ttyS0 at 115200
Dec  2 23:56:31 winyahbay modprobe: can't locate module char-major-108
Dec  2 23:56:31 winyahbay pppd[2372]: pppd 2.3.10 started by root, uid
0
Dec  2 23:56:32 winyahbay WvDial: WvDial: Internet dialer version 1.40

Dec  2 23:56:32 winyahbay WvDial: Initializing modem.
Dec  2 23:56:32 winyahbay WvDial: Sending: ATZ
Dec  2 23:56:32 winyahbay WvDial: ATZ
Dec  2 23:56:33 winyahbay WvDial: OK
Dec  2 23:56:33 winyahbay WvDial: Modem initialized.
Dec  2 23:56:33 winyahbay WvDial: Sending: ATDT XXX-XXXX
Dec  2 23:56:33 winyahbay WvDial: Waiting for carrier.
Dec  2 23:56:33 winyahbay WvDial: ATDT XXX-XXXX

The next couple of lines in each log are the SIGHUP lines for the tools.
After it hangs i either have to hit the cancel button in usernet, or
kill ppp and ppp-watch if i start it any other way, to stop
everything, or it'll keep repeating itself over and over.

	Now, I had ppp and chat set up properly in RH 5.2 and 6.0, and
had it working properly then, but this time around i decided to
install it from scratch to check out the GNOME workstation install.
FYI, I have a Zoom 56K external modem hooked up to /dev/ttys0, and i
know the modem works right because i am able to dial out with the
modem using minicom.
Comment 1 Michael K. Johnson 1999-12-13 11:30:59 EST
Please upgrade to ppp-2.3.10-3 if you have not already done so.
Comment 2 rhopkins 1999-12-14 15:29:59 EST
yes, i did upgrade to ppp-2.3.10-3, and still nothing.  I also upgraded to the
latest rawhide initscript package (as of last week) after someone suggested to
try that, and still nothing.
Comment 3 Michael K. Johnson 1999-12-14 15:40:59 EST
OK, this is going to require an strace to fix.  It's not at all
obvious what is happening.

In /etc/sysconfig/network-scripts/ifup-ppp go near the bottom and
change the "exec /usr/sbin/pppd ..." instances to
"exec strace -f -o /tmp/ppp.trace /usr/sbin/pppd ..."
and then send me the resulting /tmp/ppp.trace via email.
Comment 4 rhopkins 1999-12-14 16:30:59 EST
Ok, i replaced the lines.  Now i get error msgs when i try to start it up.
Using usernet, it tells me 'Failed to start interface', and if i use 'ifup
ppp0' at a prompt it says 'Delaying ppp0 initialization.'
Comment 5 Michael K. Johnson 1999-12-15 09:46:59 EST
Do you have strace installed?
Comment 6 rhopkins 1999-12-15 15:04:59 EST
yes i do, and i even gave the full path name to it in the script, and still got
the error msgs.  I did do a strace run on wvdial straight from the command
line, so i know it works, but it wouldn't work in the script.
Comment 7 Michael K. Johnson 1999-12-15 15:38:59 EST
Is /tmp/ppp.trace created?
Comment 8 rhopkins 1999-12-15 17:04:59 EST
no, it isn't.
Comment 9 rhopkins 1999-12-18 16:57:59 EST
ok, stupid me, i got the script to run (had to change the file permissions),
and i got it to run with strace.  Still gave me an error msg:  "Failed to
activate ppp0 with error 1".  I was able to get a strace output, this is all i
got:

4019  execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "-
detach", "lock", "modem", "crtscts", "asyncmap", "00000000", "defaultroute", "us
epeerdns", "user", "morhop", "remotename", "ppp0", "/dev/modem", "115200", "ippa
ram", "ppp0", "linkname", "ppp0", "noauth", "connect", "/usr/sbin/chat  -
f /etc/sysconfig/network-scripts/chat-ppp0"], [/* 23 vars */]) = 0
Comment 10 rhopkins 2000-01-17 01:37:59 EST
ok, three things:

one:  someone suggested to me to try using kppp.  I did, no sych luck, still
hangs.

two:  took my box to my local LUG meeting.  Someone was able to get it to dial
out and hook up by using minicom to dial, then exiting w/o resetting the modem
and running pppd w/ no options.  Once we manually set defaultroute to ppp0, had
no problems pinging/doing DNS lookups, etc. to other hosts.

three: i did a strace of 'ifup ppp0' set up using chat and captured it.  Shall
I send it?
Comment 11 Nalin Dahyabhai 2000-01-31 07:42:59 EST
Yes, please send the output of strace.  Error 1 from pppd is a serious error,
such as running out of memory.  If you turn the volume on the modem high enough,
does it sound like the connection is picked up on the other end?  If so, does
the handshaking complete?
Comment 12 rhopkins 2000-01-31 09:29:59 EST
ok, im sending you the output of a strace i just did on ifup itself.  I let it
cycle three times before i crtl-c'd it.  this time it gave me an error of 32.
as far as the modem volume goes, it doesn't even pick up or open the line to
dial out. Watching the modem, I can see the lights as it initializes, but then
it does nothing but cycles like when you get a busy signal or some
other 'normal' dialing error.
Comment 13 Goran Pocina 2000-02-06 14:51:59 EST
I had the same problem under RedHat 6.1.  Another post suggested adding "noauth"
to /etc/ppp/options.  This allowed pppd to dial out, though I had to do some
work by hand to get a working routing table.
Comment 14 rhopkins 2000-02-06 16:40:59 EST
Just tried that, still no luck.
Comment 15 Nalin Dahyabhai 2000-02-07 16:50:59 EST
Looking at the output of the strace, I can see chat being started properly, the
modem responding properly to the ATZ init string, and the chat program
attempting to dial out.  At that point it appears that chat times out waiting
for a response from the modem.

If it doesn't start dialing, then the modem isn't receiving the command in a
form that it's expecting -- perhaps with a \n appended to the strings written
to the modem.

If it is dialing, and you can hear the handshake begin before chat times out,
you might try increasing the timeouts value passed to chat (with the -t flag)
to see if being more forgiving of delays helps things.
Comment 16 rhopkins 2000-02-07 23:42:59 EST
ok, the modem isn't dialing, so im gonna try the adding the '\n's.
Ok, in my chat-ppp0 file, i stuck a '\n' on both the 'atz' line and the 'atdt'
lines.  still no dialing.  the only difference this time is that chat logs the
actual sending of the 'atdt' to syslog.  The original way didn't log it.
Comment 17 Nalin Dahyabhai 2000-02-09 11:11:59 EST
Are you sure there isn't some kind of interrupt conflict here?  This sounds like
the sort of strangeness you get with those.

What kind of modem is this?  What do you get from ATI0, ATI1, ATI2, etc.?
Comment 18 rhopkins 2000-02-09 23:21:59 EST
Under /proc/interrupts, my serial driver is listed using IRQ 4, and
under /proc/ioports it is using memory range 02f8-02ff.

I have a Zoom 56K external modem, model # 2849

as far as the ati* commands, i get this (this was done in minicom, so i know
the modem works ok):

ati0:  56000
ati1:  255
ati2:  OK
ati3:  V.0516-K56_DLS-A Z201
ati4:  a007840284C6002F
       bC60000000
       r1005111151012000
       r3000111170000000
ati5:  022
ati6:  RCV56DPF L8570A Rev 9.10/9.10
ati98: FLASH PNP MSG DR
       V80 V8BIS
ati99: 000300A3
Comment 19 Nalin Dahyabhai 2000-02-29 11:43:59 EST
Created attachment 135 [details]
strace output
Comment 20 Nalin Dahyabhai 2000-02-29 12:11:59 EST
I hunted around Zoom's web site and found their hints sheet for Unix machines at
http://www.zoomtel.com/techsprt/linuxfiles/unix.txt
It suggests adding "&C1 &D2" to your modem init string.  You might also try
"S13=10", which will force the modem to accept commands terminated with just a
newline character.
Comment 21 rhopkins 2000-03-04 22:54:59 EST
ok, THAT DID IT!!!   seems i have to add an &F (restore to factory settings) to
the init string for it to dial... running 5.x and 6.0 i never had to do that.
Why is that?
Comment 22 Nalin Dahyabhai 2000-03-09 18:20:59 EST
The defaults used by wvdial (ATQ0 V1 E1 S0=0 &C1 &D2 S11=55 +FCLASS=0) are
probably causing problems with your modem.  (Not the "&C1 &D2" part, of course,
if that's helping things work properly.)  Other tools we ship usually use a
simple "ATZ" to reset the modem, and it certainly looks like one of these other
settings is causing things to not work.

Until (if ever) wvdial supports modem brand-specific settings, this'll have to
just be in my list of weird things to check when this turns up again.

Thanks!

Note You need to log in before you can comment on or make changes to this bug.