Modem Problems

Modem Problems

Post by Seong H. L » Fri, 09 Aug 1996 04:00:00



Hi. I am (2) TWO US Robotics Internal Sporsters (28.8k).
Linux finds the modems w/o any problems, however, after about 2 mins
after the login screen comes up, a error: INIT: 'd1' is respawning too
fast. disabled for 5 minutes.

Is there anyway to fix this bug? (I am only using one modem in the
/etc/inittab file before I attempt the other modem).


Thanks for any help.

                                  -- Michael/Virus
.

 
 
 

Modem Problems

Post by Michael Font » Tue, 13 Aug 1996 04:00:00


Like a lot of replies on these groups I am not answering
the first question, I am adding to it.  We bought 2 US Robotics
28.8 (33.3) Sportsters 3 months ago.  We bought them as replacements for
2 US Robotics 14.4 modems, but have not been able to get the new modems
to work under linux properly.  They dial out fine, we just can't
get them to answer properly.  We thought dip or ppp was to blame, but
when we went back to basics (kermit or seyon) we found that we
could only connect once (after a soft-reboot from Win95) and then
we would not be able to connect again.
        Sometimes we get the INIT respawn error, sometimes we don't.
The modems are not getting configured properly, and I don't know how
to fix it.  I am thinking it might be a problem configuring the
serial port or just finding the right init string to put in
/etc/default/uugetty.ttySx.
        Does anyone have these modems working as ppp and/or dip
servers.  Could you email or post your init strings.

        Thanks




 
 
 

Modem Problems

Post by Subhas Ro » Wed, 14 Aug 1996 04:00:00



> We bought 2 US Robotics
> 28.8 (33.3) Sportsters 3 months ago.  
...
>         Does anyone have these modems working as ppp and/or dip
> servers.  Could you email or post your init strings.
..



I use USR Sportster external 28.8/33.6 modem.
It works fine with both Win95 and Linux. I am running
Linux kernel 2.0.12. But the same setup worked in 1.2.13
as well.

Here is my modem init string in Linux:

  AT&F1&A3&B1&C1&D2&I0&H1&R2&K3&M4&S0&S1S0=0S13=1X4E1Q0V1

I also do (in the chatscript):

setserial /dev/cua1 spd_vhi

stty 115200 -tostop

This is how I invoke pppd:

 pppd asyncmap 0 -detach modem crtscts defaultroute noipdefault \
 mru 1500 /dev/$DEVICE 115200

I get 26400-31200 bps connection.

--

 
 
 

Modem Problems

Post by Unix Consulti » Thu, 15 Aug 1996 04:00:00


: > We bought 2 US Robotics
: > 28.8 (33.3) Sportsters 3 months ago.  
: ...
: >         Does anyone have these modems working as ppp and/or dip
: > servers.  Could you email or post your init strings.
: ..


:
:
: I use USR Sportster external 28.8/33.6 modem.
: It works fine with both Win95 and Linux. I am running
: Linux kernel 2.0.12. But the same setup worked in 1.2.13
: as well.
:
: Here is my modem init string in Linux:
:
:   AT&F1&A3&B1&C1&D2&I0&H1&R2&K3&M4&S0&S1S0=0S13=1X4E1Q0V1

My setup string is a bit simpler:
AT ZT4 E0 M3 S0=0 S7=180 X4 &C1 &D2

:
: ...
: I get 26400-31200 bps connection.
:
: --

--
-------- Thomas Bullinger ------- Specializing in Linux systems --------
* Installation * Setup * Maintenance * Training * Software * Information

* WWW:   http://btoy1-gw.roc.servtech.com/users/consult

 
 
 

Modem Problems

Post by Vern Hox » Fri, 16 Aug 1996 04:00:00




Quote:>Hi. I am (2) TWO US Robotics Internal Sporsters (28.8k).
>Linux finds the modems w/o any problems, however, after about 2 mins
>after the login screen comes up, a error: INIT: 'd1' is respawning too
>fast. disabled for 5 minutes.

>Is there anyway to fix this bug? (I am only using one modem in the
>/etc/inittab file before I attempt the other modem).

This is a problem about how your 'getty' was written and how your modem is
configured.

Read my 'modems.blurb'.  It is part of a collection of serial port
utilities and associated info.  The name of the collection is
'serial_suite.tgz' and is available via ftp from 'scicom.alphacdc.com'.

You should also study the docs which accompany 'mgetty'.  Some of the
requirements differ from "standard" getty's.

Don't use 'cua*' or '/dev/modem' for outgoing calls.

Try my 'getty_em' from 'serial_suite.tgz'.

------------------------

Two different methods have been developed in an attempt to avoid having
more than one process running on the same serial port at a time.  One
method was developed at AT&T by their uucico developers.  The other was
apparently developed at Berkely for the BSD system.  This method was
adopted by Sun and others including Linux.

Under the AT&T Unix, the problem was solved by using 'lockfiles'.  These
are simple files which contain the PID of the process using the port.  The
idea is that if the PID which created the lockfile is still active, other
processes should wait.  On Linux. these lockfiles are kept in the
/var/lock/uucp directory.  The names are 'LCK..ttyS0' etc.  Under this
system, only one device driver is used per port.

When a process wants to use the port, it first checks for a lockfile on the
device it wants to use.  If it find a file, it reads the PID recorded
therein and checks if the process is still active or not.  If the process
still exists, the new process quits.  If the old process has died, the
lockfile is removed and a new one created.

The technique for creating lockfiles is to first create a temporary file
complete with the PID written to it.  This file is then linked to the
desired 'LCK..ttySN' name.  If some other process also wants this port and
has created their own lockfile, our link will fail.

Under the BSD/Sun versions of Unix, two device drivers are provided for
each port.  Presumably one is for 'outgoing' calls and the other for
'incoming' calls.  Under Linux, these drivers use the same coding and are
identical except for a kernel lock.  The operation of this locking method
is very complicated and I am not sure I know all the side effects even
though I have studied the code extensively.

First, it is necessary to understand that the 'open(2)' system call has a
special flag when the file is a bolck special or character special device
driver.  This flag is 'O_NONBLOCK' or 'O_NDELAY'.  With respect to serial
devices, this means that a normal 'open' will block and not return until
the Data Carrier Detect (DCD) line is asserted.  If 'O_NONBLOCK' flag is
included in the open command, the call will return immediately regardless
of the status of the DCD line.

If the struct termios CLOCAL (see termios.blurb) option has been selected,
the O_NONBLOCK flag is ignored.

In Linux, whenever the NORMAL (ttySN) device is neither open nor blocking
on an open and an attempt is made to open the CALLOUT (cuaN) device, it
will open immediately regardless of the presence or absence of the
O_NOBLOCK flag.  However if the NORMAL device is active or blocking on a
read (see VMIN=1, VTIM=0 in 'termios.blurb'), an open on the CALLOUT device
will fail and return an EBUSY error code.

On the other hand, if the CALLOUT device is open (O_NONBLOCK doesn't
appear to be a factor), an attempt to open the NORMAL driver will fail and
return the EBUSY error code.

Thus, if you have a 'getty' listening on the 'incoming' line, it is
impossible to place a call on the 'outgoing' driver.  However, if you place
your outgoing call on the 'incoming' driver, it will open and proceed
normally.  That is 'normally', if the 'getty' is smart enough to get off
the line.  The AT&T 'uugetty' (not the Linux uugetty) expect that the first
characters received on incoming calls are either newlines or carriage
returns.  If any other characters are received, they are assumed to be
outgoing characters and the 'getty' graciously exits.

I have been carrying on a discussion for the last couple of months about the
need for 'cuaN and ttySN' drivers and so far I haven't received a
convincing reason that there is an need for the 'cuaN' series.  All the
communication software provided with Linux, recognize the /var/lock/uucp
lockfiles anyhow.

I hope that this clarifies the situation somewhat.  As far as I am
concerned, the only value the 'cuaN' and the 'Serial-HOWTO' is to confuse
immigrants from DOS.  I immigrated from AT&T SYSV and it confused me.

If you try to open a callout driver when the associated 'callin' driver is
opened, the open returns EBUSY.  If the normal driver is opened in blocking
mode, and the callout driver is busy, the attempt to open will fail with
EBUSY.  However, if it opened in standard (blocking) mode, the open will
block until the ports DCD line is asserted.  For non-blocking mode and the
cuaN port is inactive, the open will succeed immediately.  

The problem is partly cultural and partly an attempt to state a complex
situation in simply words.

The problem is "How to prevent incoming call and outgoing calls on a single
port from colliding".

-----------------------

vern

--
Vernon C. Hoxie                                           scicom!zebra!vern

Denver, Colo., 80212        uucp: 303-455-2670          voice: 303-477-1780
               Unix is what MSDOS will be when it grows up.

 
 
 

1. Odd Modem Problem (Modem not responding) (Not a WinModem!)

I've been around Linux off and on since kernel .99.15o, so believe me
when I say that this is _not_ a WinModem problem. :)

I just installed Debian "potato".  Clean install, and few problems,
but I can not make this box talk to my modems.   When I start minicom,
everything I type gets echoed back, but the modem doesn't respond
(other than to echo back what I type).  The echoing is odd-- it
only echoes the carriage return when I hit <enter>; I can manually
type a new line, but that doesn't help.   The modem doesn't act
on anything I type; e.g. typing "atdt33333" doesn't make any noise
(and should; at least the external modem I'm _sure_ is set to
make noise, since it does when hooked up to another machine, and that's
the factory default).

Just so you know I'm not crazy:
        It's not an interrupt problem.  The same thing happens with an
        external and an internal problem, and with seterial /dev/ttyS2 irq 0
        Moreover, I'm setting the interrupt by jumper.

        It's not a setserial problem.  If minicom isn't talking to the
        right port, then nothing gets echoed back.  Only when it's talking
        to the right port do I even see the echoing.

        I did get the external modem to talk back, by telling  it to ignore
        DTR.  However, that caused other problems (most notably, my ppp
        connection getting garbage that caused it to hang up; my ISP is
        a bit draconian :)

        statserial shows DTR always 1, DCD always 0.  I can give more info
        if necessary.

        The modems are a Gateway Telepath ISA (w/ jumpers :) and a USR 28.8
        Fax/Modem.  The box is a gateway P5-120 that I got for $25.  

Any ideas?  I'm open to suggestions...

Thanks in advance,

                Me
--
Disclaimer:  Anything I said, writ, or thought in my life should not
necessarily be held or thought to imply any view, opinion, or idea
of mine, any organization I have chosen to associate  with, or those
people who choose to associate with me.

2. Modem/Sound Card Success(offer of assistance)-trading for help

3. Modem problem - External US Robotics Voice modem

4. newbie requests newsreader recommendation

5. modem problem conect to provider (wisecom modem)

6. RAID on Linux

7. A modem problem about Intel 536ep Modem

8. Synch-ing directories - NT And Netscape

9. modem problem with statserial and modem tool.

10. Strange modem problem -- my modem no longer works in Linux

11. Swapping Modem in Linux : DIVA ISDN Modem problem

12. kppp/modem problem (modem busy)

13. Weird Modem problems/modem related Hangs