|
|
The Answer Guy 32:
Fwd: ANOTHER MODEM PROB
"Linux Gazette...making Linux just a little more fun!"
[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
> It sounds like a "winmodem." (These are devices which don't
> support the standard AT command set and which require proprietary
> drivers in order to function. Currently those drivers are only
> available for Windows --- I gather that some of them don't even
> work under Windows NT).
> The acid test for this is to try to use the modem under DOS (boot
> from DOS and try run a program like Telix). If that also can't
> "see" the modem --- then it's not a real modem; it's a "winmodem."
> Although I've read rumors about an effort to reverse engineer the
> "Rockwell chipset" (RPI) --- which is the one commonly used in
> these "winmodems" --- I believe that you're only reliable recourse
> for now is to exchange this piece of junk with a real modem.
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.
so i do that, and quit X. I run chat with the following script
TIMEOUT 5
"" ATZ
OK ATDT6161038
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT WAITING
TIMEOUT 45
CONNECT ""
TIMEOUT 5
"ogin:" blah
"assword:" blah
i run chat
$chat -f /etc/ppp/chatscript (where i store the above script)
i see linux go:
AT
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.
again sorry to bother u.
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
BTW: I apologize for my sloppy spelling and grammer... it's just the
internet talk that does that to you Despite my erronious writing
(I'm sure I spelled that wrong.. LoL), I'm an accompilshed
programmer in C\C++ (including Window's MFC and UNIX), Visual Basic,
Perl, and Assembly languages
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
![[ Table Of Contents ]](../gx/indexnew.gif)
![[ Front Page ]](../gx/homenew.gif)
![[ Previous Section ]](../gx/back2.gif)
![[ Next Section ]](../gx/fwd.gif)
|
![[ Answer Guy Index ]](../gx/dennis/answernew.gif)