"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, linux-questions-only@ssc.com
Starshine Technical Services, http://www.starshine.org/

Another (Lose)-Modem

From Barbara Ercolano on 20 Sep 1998

Hi James, I saw your "Answer Guy" page and I thought that maybe if you spare a few minutes you might help me with solving my connection problem. I have recently installed redhat linux on my PC and i am now trying to set up an internet connection. I have the chatscript the ppp-on and the ppp-off script the thing is that when i try to run the ppp-on nothing happens .

The syslog file says:

....kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
....kernel: PPP line discipline registered
....kernel: registered device ppp0
....pppd[243]: pppd 2.2.0 started by root, uid 0
....chat[244]: timeout set to 5 seconds

This is where the chat script sets a timeout.

....chat[244]: sent (ATZ^M)
....chat[244]: alarm

This is where the timeout occurs.

....pppd[243]: Connect script failed
....chat[244]: Failed
....pppd[243]: Exit.
....kernel: PPP: ppp line discipline successfully unregistered

Just from this I know that your ATZ is getting no response. That suggests that there is not a Hayes compatible modem on the other end of the connection. Either you're pointing this at the wrong device (it's going to your serial mouse)-- or you have a WINMODEM!

'winmodems' are NOT hayes compatible devices. They are little chunks of cheap hardware that can be used with proprietary (MS Windows only) drivers to emulate a modem --- and a measure cost in your system's CPU cycles.

this is my chatscript (/etc/ppp/chatscript)

TIMEOUT 5
"" ATZ
OK ATDT08450798888
ABORT 'NO CARRIER'
ABORT BUSY
ABORT 'NO DIALTONE'
ABORT WAITING
TIMEOUT 45
CONNECT ""
"ogin:" uk,ppp,myusername
"ssword:" password

Good, you sanitized it. It's not good to send usernames and passwords to public discussion fora.

this is my /usr/sbin/ppp-on script:

#!/bin/sh
#
# ppp-on - Set up a PPP link
#

CFG_DIR=/etc/ppp
LOCKDIR=/var/lock

DEVICE=cua1

MYIP=0.0.0.0

if [ -f $LOCKDIR/LCK..$DEVICE ]; then
   echo "PPP device is locked"
   exit 1
fi

/usr/sbin/pppd -d /dev/$DEVICE 38400 connect "/usr/sbin/chat -v -f
$CFG_DIR/chatscript" defaultroute $MYIP: && exit 0

echo "PPP call failed"
exit 1

this is my /usr/sbin/ppp-off script

#!/bin/sh
#
# ppp-off - Take down a PPP link
#

if [ "$1" = "" ]; then
   DEVICE=ppp0
else
   DEVICE=$1
fi


if [ -r /var/run/$DEVICE.pid ]
then
   kill -INT `cat /var/run/$DEVICE.pid`

   if [ ! "$?" = "0" ]; then
      rm -f /var/run/$DEVICE.pid
      echo "ERROR: Removed stale pid file"
      exit 1
   fi
   echo "PPP link $DEVIVE terminated"
   exit 0
fi

echo "ERROR: PPP link is not active on $DEVICE"
exit 1

This is all much too elaborate. I'd just use a command like:

pppd file /etc/ppp/myisp.options

... and let it contain all the other options specific to this ISP.

pppd will read the global options file (/etc/ppp/options) which in most cases should just contain the "lock" directive.

this is my /etc/ppp/options file:

0.0.0.0:
/dev/cua1

The cua* devices are deprecated. Use ttyS* instead.

lock
crtscts
defaultroute
asyncmap 0
mtu 296
mru 296

this is my etc/resolv.conf

search netcomuk.co.uk
nameserver 194.42.224.130 194.42.224.131

This is irrelevent to getting the modem to dial (chat). Also it is interesting that you sanitized your login name and password but left in this identifier.

Oddly enough you can use just about any nameserver on the Internet --- not just the one that your ISP provides. I've occasionally used the nameserver from one of my former employers when setting up a new machine at a customer site --- just long enough to have DNS to 'dig' up the more appropriate and closer nameservers (which should all have names or CNAMES of the form: ns*.foo.org in my not-so-humble-opinion).

This is all i can think of... mmhhh. I am not sure this is relevant but i tried to run minicom as well and that didn't work either, I mean it seems to be getting stuck... anuway... i hope you can help me...

If you can't get a boring old terminal emulation package like 'minicom', 'ckermit' talking to your modem --- then it is quite relevant to your problems running SLIP, PPP, fax, or anything else to that modem. The simplest think you can do to a modem is send it an ATZ and get an OK response. If you can't do that --- the modem (or your serial port, or your way of talking to the serial port) isn't working.

Thanks a lot for your time
love
Barbara

No problem. Please, chuck that winmodem and get a real, Hayes compatible.

O.K. It's not a Winmodem

From Barbara Ercolano on 20 Sep 1998

By their nature winmodems must be internal. Since you have an external modem (and a Hayes (TM) brand one at that) we can rule out that as the culprit.

This leads us to the next possibility. I mentioned that it might be a problem between the OS and your serial hardware.

If you are using the correct /dev/ttyS* node --- then the next mostly likely problem is an interrupts conflict.

Is this a (PnP) "Plug and Pray" system? (Reboot and get into the CMOS setup program to look for those features). If so, try disabling that and setting all of your COM and printer ports to manually selected, non-conflicting ranges.

One of the bugaboos about Linux and most other Unix variants is that they tend not tolerate IRQ's conflicts the way that MS-DOS and Win 95 might. (This tendency in DOS and Windows probably leads to some of the intermittent hands and that you see with those OS'). So, you should not set your COM2 and COM3 ports on the same IRQ.

First, read the Linux Serial HOWTO. It will go into excruciating detail about the topic. Next play with commands like 'statserial' and 'setserial' and look at the /proc/interrupts and /proc/ioports psuedo-files. Also the boot up messages might help.

Also I think i have got the right port ttyS1 (cua1) for COM2... I have tried running minicom, and the init string appeared whith my cursor at the end of it, so i pressed enter and nothing happened after that (I should have got OK, shouldn't I?) I tried to enter my username and password (even though no login prompt appeared), and again nothing really happened I saw the modem blink but that's about it, so i exited minicom without resetting and looked at the syslog file... it said something about the line not being 8-bit clean and that bit 7 was set to zero.... all this has

I'm glad you looked in the syslog --- I don't think I remembered to suggest that in my earlier response.

This could be a cabling or IRQ problem. Make sure that the modem cable is a good one. I used to see problems with cheap cables that didn't have all of the handshaking lines connected and things like that.

Yes, I was wrong to assume that it was a winmodem (I've been getting too many of those recently) but it looks like I'm still on the right track. There is some problem with Linux's ability to talk to the device --- in this case it's either having trouble talking to the serial port --- or the cable isn't relaying that to the modem. Or, it is still possible that you just have the wrong ttyS* port. Try the others, ttyS0 through ttyS3 for good measure. (If your modem is working on one of those --- skip that one).

Yet More on the Serial Port (it's not a WinModem) thing...

From Barbara Ercolano on 21 Sep 1998

Hi ... it's me again , still tryin'... I've just done

cat /proc/interrupts

and this is what i've got:

0: 646864 timer 1: 2933 keyboard 2: 0 cascade 4: 2457 +serial 8: 1 +rtc 13: 0 matherror 14: 71407 +ide0

now the question is , shouldn't i get two lines saying serial if my modem was correctly installed??? The 4: 2457 + serial line is the mouse isn't it?

Yes. You probably should have another line there. But what about the rest of the suggestions in the Serial-HOWTO. Did you read through that?

It used to say something about doing a 'dmesg' command or viewing syslog's /var/log/messsages shortly after a reboot --- with an example of the sorts of lines you should see from the kernel.

The dmesg command is to "display" (actually *re-display*) message that were generated during the boot sequence. All those messages that tell you what your kernel "found."

If this port works under DOS, Windows, et al, then you might use the "MSD.EXE" (Microsoft Diagnostics) package to tell you where DOS is finding the port. You can also use the "procinfo" command (from Linux) to get handy one page summaries of some system diagnostics and performance stats (including how many interrupts have been recieved and handled by kernel on each IRQ).

It may be that your serial port is set at a reasonable (non-conflicting) IRQ --- but that it's at one that the kernel doesn't probe by default.

To fix that you'd use the 'setserial' command to associate a give /dev/ttyS* device with an IRQ and set other characteristics on the line. It's also possible, though less likely, that you might have to use the stty command to set yet other characteristics of the tty lines.

Maybe this is where my problem is... what do you think? And if this is the problem , what do i need to do?

Try reading that HOWTO. It's a bit long --- but I'd just end up retyping most of it at this point anyway. Also read the man pages for 'setserial' and 'stty' and play with them a little bit.

Since you seem to have a serial mouse --- try putting the mouse on that other serial port, and changing your start scripts (/etc/rc.d/$whatever) to have gpm, and X use that.

Actually on most Linux systems there's a symlink under /dev/ from "mouse" -> ttyS1 or -> psaux or whatever, and anther from "modem" -> ttyS* (or to the deprecated cua* "callout" ports). So, when you move a mouse or modem to a different serial port, you usually only have to change those symlinks according (just 'rm' the symlink and create a new one or use the 'ln -sf $device mouse' command.

cheers
Barbara

I hope we get closer this time. Do you have a local users group or other local guru to tap into for some in person and hands on expertise?

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 33 October 1998

	floppy	autocad	scsi	samba_pdc	virthost
	emacs_cc	ipmasq	tty	shuffle	connect
	hostavail	desqview	catch22	thanks2	typo