From: gleasokr@rintintin.Colorado.EDU (Kris Gleason) Subject: Re: dial-in over a serial line, some answers//dial-in dial-out Date: Fri, 14 May 1993 16:38:42 GMT
larry@palan.uucp (Larry Strickland) writes:
>In article <1sugbqINN55l@crcnis1.unl.edu> jbettis@cse.unl.edu (Jeremy Bettis) writes:
>>hucke@ux1.cso.uiuc.edu (Matt Hucke) writes:
>>
>>>In article <C6prEo.5x5@palan.uucp> larry@palan.uucp (Larry Strickland) writes:
>>>)
>>>)CAN LINUX do dial-in/dial-out at present on the same line? If the answer is
>>>)NO, I can live with that, but not the idea of everyone else being able to do
>>>)this while I beat my head against the wall
>>
>>>I've found a way to do it... have getty respawn on /dev/ttyS? for runlevels 5
>>>and 6 only (see /etc/inittab). When I want to use kermit, I first
>>>'echo 4 >/etc/initrunlvl ; kill -1 1' which will cause init to restart
>>>without trying to run getty on the modem line. When I'm finished with kermit
>>>and want to allow modem logins again, just do the same thing but with a 6 in
>>>/etc/initrunlvl.
>>
>>
>>There is an easier way. FTP getty_ps 1.0.7 or whatever the latest version,
>>not the version which comes with SLS that is an older version. Compile it
>>and run it. It works fine. I use the same modem for dialin and dialout with
>>no problems with kermit, minicom, or uucp.
>Since I started this, I thought I'd jump back in with an update. When I posted
>originally, there was only _one_ response and that was by email. That person
>suggested that I get getty_ps 1.0.7 (_not_ 1.0.6) and there would be no problem.
>I have done that and am now HALF way there. After modifying my /etc/inittab
>file to say (paraphrased):
>c8:56:/usr/src/getty_ps/uugetty ttyS1 2400 vt100
>and making sure my 2400 baud modem was working, I got dial in/out to work
>properly after a reboot (I'm still not sure why the reboot was necessary,
>but it was the only thing that worked...) Using this setup, I can reliably
>dial in/out of the same port now at 2400.
>Then I decided to use a TrailBlazer Plus modem to implement a higher speed,
>9600 locked and PEP, and I'm back to square one again. When I modify the above
>to 9600tb (the gettydefs is a standard 9600 that loops back on itself since
>the modem is locked in speed), a getty war starts that ends with the port
>thinking it is logging in. Unfortunately, the modem is a loaner that I don't
>have the manual for, so I'm not exactly sure what settings are different.
Getty_ps usually waits for carrier detect before opening the line, not
a character. If you want it to wait for a character, you need to
specify this. The problem with the modem is most likely that the carrier
detect is left on all of the time. The terminal may also assert the carrier
detect line (depending on your null-modem cable), but probably leaves it
floating. This will cause the carrier to be high at random times
(a bad thing).
So... to fix all of these problems: Configure your modems to not leave
the carrier detect on all of the time (yes... I know it't tough without
a manual). If you're using dumb terminals, add clocal to the gettydefs
line for the terminal if your null modem has no support for a carrier
detect line. If all of this fails, try using the software connect
(WAITFOR, INITLINE) method instead of the hardware (autoanswer) method.
There are so many ways to configure getty_ps, that I can't think of a
possible setup that is not possible, even with really braindead terminals
or modems. In fact, the only thing I can think of that will not work
is trying to get dialins over a modem that cannot detect incoming calls
(unless you want to sit around and do it manually). With all of this
functionality comes a complex configuration file... not complex looking,
but not too easy to set up. I have tried to provide several examples
of `suggested' configurations in the Examples directory of the package,
but I can't read everyone's mind.
I said it in the docs, and I'll say it here... if you are having trouble
like this, don't hesitate to mail me about it. I am pretty friendly to
newbies that can read [i.e. before mailing me take time to sort through
the README's, and the man pages], since I know that this is complex.
>I connected the port to another computer and set up a null modem line to try
>it out. The port issues the INIT string and then outputs /etc/issue. I'm not
>sure why, since I thought it was supposed to wait for a char, but...
>I updated the /etc/inittab line to include -r0 so it would wait, but then it
>waits on the /dev/ttyS1 line and won't release it.
If you're doing this, you need to add INITLINE=cua1 to the defaults file,
or you will find your serial line very useless by the rest of the world.
>Obviously, there is some middle ground here and I just haven't found it yet.
>Any ideas, comments, etc. are encouraged.
Please mail me with your questions, comments, etc...
Kris
-- gleasokr@rintintin.colorado.edu HARDWARE (noun): The equipment that makes up a computer system, not to be confused with software