can not dial out when uugetty listening on cua1

can not dial out when uugetty listening on cua1

Post by Vladimir Stavitsk » Thu, 11 Jul 1996 04:00:00



Hi, everybody;
i just configured uugetty to answer on my modem line; works
fine; when i try to strt ppp, though, while uugetty is listening,
ppp fails; it tries to dial, but then i get "ttyS1: input overruns(s)"
messages in my /var/adm/messages file, and ppp fails. Sure, i can
disable uugetty by hand one way or another, but i am not thrilled
to edit inittab and kill -HUP 1 every time i want to dial out.

There must be some "right" way to do that.

Thanks for any advice

Vlad
--
---------------------------------------------------------------------
        ... occurrences like this will be few and far between ...


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

 
 
 

can not dial out when uugetty listening on cua1

Post by Vladimir Stavitsk » Thu, 11 Jul 1996 04:00:00


Hi, Rob;
thanks for your help. I set ALTLOCK & ALTLINE to cua1 - still have the
same problem, unfortunately; this is probably the third time i am setting
up dial-in on Linux over 3 years - always takes at least couple of days
on and off :-(

Thanks again

Vlad


> In comp.os.linux.setup you write:

> >Hi, everybody;
> >i just configured uugetty to answer on my modem line; works
> >fine; when i try to strt ppp, though, while uugetty is listening,
> >ppp fails; it tries to dial, but then i get "ttyS1: input overruns(s)"
> >messages in my /var/adm/messages file, and ppp fails. Sure, i can
> >disable uugetty by hand one way or another, but i am not thrilled
> >to edit inittab and kill -HUP 1 every time i want to dial out.

> >There must be some "right" way to do that.

> >Thanks for any advice

> >Vlad
> >--
> >---------------------------------------------------------------------
> >        ... occurrences like this will be few and far between ...


> >---------------------------------------------------------------------

> Hi,
> I had this problem, and it went away with some tinkering; unfortunately
> I can't exactly remember what worked to fix it.  You might try to
> replace any occurrences of 'modem' with 'cua1' in the 'uugetty.ttyS1'
> file (especially in the ALTLOCK=modem line).  The line in the inittab
> file should also look something like:

> s3:45:respawn:/sbin/uugetty ttyS1 F38400  vt100

> where, in my case, I fixed the rate at 38400 bps.

> It's not much, but I hope it's some help.

> Cheers,
> Rob Komar

---------------------------------------------------------------------
        ... occurrences like this will be few and far between ...


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

 
 
 

can not dial out when uugetty listening on cua1

Post by Bil » Sat, 13 Jul 1996 04:00:00


I got frustrated with the other gettys and finally found
mgetty+sendfax. It compiles out of the box and a 1 liner in the
inittab sets it up to answer. I think I also read something about
using ttyS1 instead of cua1 for everything somewhere...

Bill

On Wed, 10 Jul 1996 10:59:50 -0400, Vladimir Stavitsky


>Hi, everybody;
>i just configured uugetty to answer on my modem line; works
>fine; when i try to strt ppp, though, while uugetty is listening,
>ppp fails; it tries to dial, but then i get "ttyS1: input overruns(s)"
>messages in my /var/adm/messages file, and ppp fails. Sure, i can
>disable uugetty by hand one way or another, but i am not thrilled
>to edit inittab and kill -HUP 1 every time i want to dial out.

>There must be some "right" way to do that.

>Thanks for any advice

>Vlad
>--
>---------------------------------------------------------------------
>        ... occurrences like this will be few and far between ...


>---------------------------------------------------------------------

 
 
 

1. minicom, uugetty, /dev/[modem,cua1,ttyS1] Hmm...

Hmmmm ...

I had my uugetty and minicom configured (does anybody "really" know
what they are doing) somehow to work nicely.
Then I started to think about this stuff I read and heard that /dev/modem
should not be used ...
I read in the SerialHOWTO that
[ What a freaking cool MOD file [HARD.MOD]... isn't Linux great ..
source code too ... sheesh ] ... oops . digression

  On some installations, two extra devices will be created, /dev/modem
  for your modem and /dev/mouse for your mouse.  Both of these are
  symbolic links to the appropriate /dev/cuaN device which you specified
--

  There has been some discussion on the merits of /dev/mouse and
  /dev/modem.  I strongly discourage the use of these links.  In
  particular, if you are planning on using your modem for dialin you
  will run into problems because the lock files will not work correctly
  if you use /dev/modem. Use them if you like, but be sure they point to
  the right device.

***** END Serial HOWTO excerpt. *****

So .. I played around with it
till 4:00 am last night and figured this much out :

* With minicom set to use /dev/modem and ALTLOCK and INITLINE in uugetty.ttyS1
set to /dev/cua1, I am able to implement uugetty and /dev/modem smoothly,
perhaps not cleanly, (and inittab obviously set for ttyS1).

* With minicom also set to /dev/cua1 .. I can start minicom (I think)
but then it gets clobbered when the uugetty respawns ... minicom
can no longer talk to the modem ... this is the respawn of minicom since the
process ID changes.

*

2. VFS problem!

3. dialing in with uugetty not working on variable modemspeeds ??

4. reboot command

5. uugetty blocks /dev/cua1

6. Resolving IRQ conflics with PnP?

7. apache listen to port 80, another standalone apache+modssl listen port 443, not working..?!

8. options

9. It's not bad canned meat...

10. Preventing Dial outs.

11. Multiple dial OUTS & report on 3COM 3C905-TX ethernet

12. cua1=/dev/cua1?