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

The Answer Guy

By James T. Dennis, [email protected]
Starshine Technical Services, http://www.starshine.org/

[We seem to be coming in at the middle of this thread, but I don't see where the previous might be found. We'll have to make do with what's been quoted here, Sorry, readers! -- Heather]

ANOTHER MODEM PROB

From CodeWaRi0r on 18 Aug 1998

nope.. im sure i dont have a winmodem. actually, I have to modems on my computer .. one winmodem on COM1 and a regular modem by BOCA on COM3.. ok.. just help me out with one more thing and ill be out of your hair ok.. ive established that i dont have a winmodem.. i start up X. run the modem configurer (this program makes a link between /dev/modem and cua2.. or so it says... i just select the COM port and press ok and thats it. Am i missing a step here?)

It could also be an IRQ conflict --- on a conventional PC COM1 and COM3 share IRQ's with COM4 and COM2 respectively.

I don't know how you're sure that you don't have a winmodem --- unless it's external, or you've been able to connect to it under DOS or Linux with standard AT commands.

However, I'll assume for the moment that this is the case.

I would leave X completely out of this for now. I wouldn't use any "modem configurator" (that's just one more piece of junk between me and the troubleshooting).

One way to do this testing is to run minicom or C-Kermit to connect to the modem, Then you should be able to type AT commands directly to the modem and get responses back. Before you do this, look at the nodes under the /dev/ directory with the 'ls -l' command. Make sure that they look something like:

lrwxrwxrwx   1 root     uucp            5 Jul 13 16:52 /dev/modem -> ttyS2
crw-rw----   1 root     uucp       4,  64 Aug 18 15:17 /dev/ttyS0
crw-rw----   1 root     uucp       4,  65 Aug 18 15:17 /dev/ttyS1
crw-rw----   1 root     uucp       4,  66 Nov 30  1997 /dev/ttyS2
crw-rw----   1 root     uucp       4,  67 Nov 30  1997 /dev/ttyS3

.... where the "modem" entry is a symlink to the appropriate serial port (ttyS2 for a normal PC's COM3).

You should also make sure that the permissions on most of your communications software are such that it is run by 'root' (such as pppd) or is at least SGID 'uucp' (you could chgrp all these to 'modem', create a 'modem' group, etc --- I use 'uucp' since that is an older Unix convention).

So, an 'ls -l' of your minicom, kermit, uucico, pppd, chat, should look something like this:

-rwxr-sr-x   1 root     uucp       119280 Nov 30  1997 /usr/bin/minicom
-r-sr-sr-x   1 uucp     uucp       395148 Nov 30  1997 /usr/lib/uucp/uucico
-r-xr-sr-x   1 root     uucp       632609 Feb 10  1997 /usr/local/bin/kermit
-rwsr-x---   1 root	dialout	    83856 Nov 30  1997 /usr/sbin/pppd
-rwxr-xr-x   1 root     bin	    12224 Nov 30  1997 /usr/sbin/chat

Note that minicom, uucico and kermit are SGID uucp --- they don't need higher privileges. uucico is the actual communications engine for the uucp suite --- it's normally only called by the uucp command, but it needs access to some directories (usually /var/spool/uucp* or /usr/spool/uucp*) to work properly. So we make it SUID to the uucp user as well as SGID to the uucp group.

You can ignore all of those details for pppd since it must be run as root (in order to set IP addresses and add routing entries). Here I've set it to be in the 'dialout' group --- so that I can restrict who can execute this (thus limiting who could try to use exploits on pppd to gain 'root' privileges). This is a simple and far too uncommon way to narrow the security holes on a system.

Note that the 'chat' program gets no special permissions. It is invoked by pppd which is already running as 'root' --- and thus, it needs no "extra" privileges.

TIMEOUT 5
"" ATZ
OK ATDT6161038
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT WAITING
TIMEOUT 45
CONNECT "" 
TIMEOUT 5
"ogin:" blah
"assword:" blah 

Aha! That's your problem. You aren't supposed to run 'chat' directly. You are supposed to run pppd, and let it invoke the 'chat'. This is due to some technical internals about how file descriptors are inherited.

The 'chat' program writes to its 'stdout' file descriptor and expects input (modem responses) from it's 'stdin' For that to work you have to provide it with suitable open standard files. One way to do that would be to type:

chat -V "" "ATZ" "OK" < /dev/modem > /dev/modem

... which engages in the simplest meaningful dialog that I know of with a Hayes compatible modem. It simply "waits for an empty string" (nothing), sends an ATZ, and waits for an "OK"

The -V switch here tells 'chat' to "be versbose to 'stderr' which will, in this case, by our console/terminal.

On my system that command returns:

AT&FS2=255

... and an exit value (errorlevel) of 0 (no-error). This isn't exactly the output I would expect from my interpretation of the man page. But it's close enough (it suggests that my modem returns this string when it recieves an ATZ comment --- which suggests that this modem is translated ATZ into "AT&F" (return to factory zettings), and setting the S2 register to 255).

If I issue the command:

chat -V "" "ATZ" "OK" < /dev/ttyS3 > /dev/ttyS3

... (a serial line with no modem attached) I get no output and a return error of 3.

In any event you need to let pppd start your 'chat' command. The way to do that is to provide pppd with a suitable "options" file.

In my case I have multiple PPP accounts (some with customers, some with ISP's). So I create an /etc/ppp/options file that just consists of one line:

lock

... and I create different supplemental options files that contain the details specific to a given provider.

For example one looks pretty much like:

asyncmap 0
crtscts
defaultroute
mtu 296		mru 296
modem /dev/modem 57600
connect "/usr/sbin/chat -f /etc/ppp/options.myisp"

I'll skip the first several lines (you can read the PPP-HOWTO and/or the pppd man pages for details about those) and focus on the last couple of lines.

The modem directive tells pppd to use serial line settings (ioctls?, stty) that's appropriate for a modem. The other option would be "local" (use a null modem cable or some sort of network connection). This has purely to do with how the line is "conditioned" and how the handshaking lines are handled.

The /dev/modem parameter tells it which device to open (and thus what file descriptors to pass to the command that will be invoked via the "connect" directive.

The 57600 is simply the speed to which pppd should should set the serial line (I presume this is also used at part of an 'stty' like function call).

The last line is the "connect" directive. It tells pppd what command to invoke to deal with the modem.

So, you then invoke pppd with a command like the following:

pppd file /etc/ppp/options.myisp

... this processes the "global" options in /etc/ppp/options and then the options that you've specifed with the file directive.

Many examples I've see specify many of the options one the command line. For example it's pretty common to see a command like:

pppd modem /dev/modem 57600 file /usr/local/etc/ppprc

... which should be reasonably comprehensible once you understand that pppd basically interprets all its command line in the same way as it processes directives in it's options files. Carefully reading the 'man' page should clarify what order and precedence affect the processing of all of these directives and options. For example, you have to be sure to avoid any conflicting options ~/.ppprc (just get rid of any such file unless you know what you're doing with it).

Another simple testing trick is to use 'minicom' to dial the phone and establish your connection (log in). Then use the "Quit without Resetting the Line" option (using the [Ctrl]+[A], [Q] key sequence). This should dump you out of minicom and back to a shell prompt without disconnecting your modem. (It is then possible to invoke pppd on that line --- using an alternative version of the ISP options file without any "connect" directive).

That trick doesn't work with kermit --- it won't exit without resetting the communications line. From what Frank de la Cruz tells me you can't use C-Kermit as a replacement for 'chat' because of this. Basically he says it violates some programming standards to do this. (I still don't understand that --- but it's not currently a priority to me. If someone understands it and wants to explain --- write an article and send me a copy).

but the modem doesnt respond... i know its weird.. but i just dont think linux knows its there.. is the "linking" i do in X all that's necessary? or am i missing something?

The problem is that you haven't understood the PPP-HOWTO. I can sympathize with that --- I spent quite a few hours banging my head on it (at least an earlier version of it).

However, try reading it again.

There are several GUI and dialog driven frontends to configure your PPP connection for you. I've never used any of them (they didn't exist back when I was doing my head banging). In any event a search of the Linux Software Map using Boutell's search page (http://www.boutell.com/lsm) on the term PPP will give a list of several of these and a couple dozen related samples and utilities. There are KDE, Motif, and Tk interfaces (among others).

You could try a few of those to see if any of them works for you. You should also be able to get your ISP to help. If they refuse to help with Linux/Unix ppp technical support --- consider getting a new ISP.

The question doesn't bother me. No apologies are necessary for that. If I seemed grumpy, it's because I don't like to see this sort of "hakkerboyz" text. I don't think it's cool and I do find it difficult to read. It is only a bit less offensive than GETTING MESSAGES IN ALL CAPS.

People who won't take the time to use reasonable punctuation and spelling in their questions cause me to wonder why I should take the time to answer them. I'm sure that many don't even pause to wonder; they just hit the delete key and move on.

I have no idea how old you are, or why you choose to write this way. Perhaps you have some very good reasons --- and perhaps you think I'm some sort of pedantic curmudgeon. You're welcome to hold and share that opinion (and I'll even agree with part of it).

However, one of the few liberties I take in this column is the opportunity to occasional jump up on my soapbox and express my opinion. The evidence is that some of my readers find at least some of my tirades amusing, even (according to some reports) "inspiring."

For those that don't like it --- I can only say "Well, I did at least attempt to answer the question." (I don't remember of any occasion where I just flamed someone without answering their question. I just won't say "RTFM" --- I'll at least say which "FM" to "R").

Anyway, I hope that the hint about how to invoke 'chat' helps. If that doesn't work (and direct invocations with the redirection as shown, and 'minicom' tests) all don't work,

More on Grammar

From CodeWaRi0r on 18 Aug 1998

Thanks. I knew you could do it. I do recognize that particular style of writing as a symptom of too much time in "chat lounges" (or in IRC depending on your preferences).

However, it is still difficult to read --- and it still does say something about the relative importance you place on a given communication. (Certainly you wouldn't expect a resume' to be taken seriously if it was written in this style).

Incidentally the word is normally rendered as "erroneously."

If you are an emacs user you can "quick check" a word using the M-$ key binding. Since I use 'viper' mode, which makes it irritating to get at the [Esc] for use as [Meta] I add the following binding to my .emacs file:

(global-set-key '[f3 ?$] 'ispell-word)
(global-set-key '[f3 ?%] 'ispell-buffer)

... which means that the two key sequence: [F3], [$] will check the word at point and [F3], [%] will check the whole buffer.

(I suspect that vim also has some features for running ispell --- though I've never used any of the IMprovements of that editor).

The fact that using emacs (xemacs, actually) gives me 'ispell' in all of my editing (including in my favorite mail reader, mh-e, and my preferred newsreader, Gnus) is one of the reasons why I use it.

I personally despise the default emacs key bindings (which I think are designed to torture the pinky until you're ready to chop it off). So, I use viper-mode (a 'vi' emulation package) for the majority of my editing --- and I supplement it with a fairly long list of custom binding, most of which start with [F3] (the first available function key that had nothing assigned to it --- [F1] was used as a "Help" prefix and [F2] had some weird two column mode function bound to it).

So, I switch buffers with [F3] [b] and bring up a "buffer menu" with [F3] [B] (capitalized). I bring up the 'emacs' calendar package with [F3] [C] (capitalized) and a "shell-mode" buffer with [F3] [c] (lower case --- for "command"). I check my diary (appointment list) with [F3] [D] (capitalized), and bring up "dired" (file-manager buffers) with [F3] [d] (uncapitalized). I "unsplit" my display with [F3] [1] and split it vertically with [F3] [2] or horizontally with [F3] [4]. (The experienced 'emacs' buff may note that most of these are functions that are normally accessed via C-x keybindings; a prefix that I find truly abominable).

But ... I'm rambling. Some day maybe I'll write an article on how I use 'xemacs' --- it may be amusing to some.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 32 September 1998

	phreak	abandon	javaterm	BBS	flaws	doslinux	resume
	softwindows	convert	apache	emulate	database	distrib	proxy
	disable	DVI	superblock	serial	permission	detach	cdr
rs422	modem	notfound	tuning	libc5	startup	clock	ping
accounts	lilo	NDS	95slow	nonlinux	progenv	cluster	ftpd