This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
From: fred smith <fredex@fcshome.stoneham.ma.us>
Date:
On Fri, Mar 05, 1999 at 02:47:49PM -0500, D Parsons wrote:
> Has any one got a copy for linux?
> I want to use it to program a modem in the linux environment for
> adjusting a login getty setup.
> Please mail me a copy by mime mail or by uuencode
As you may already know, 'tip' is a BSD utility. I've never
heard of it actually having been ported/rewritten for
Linux. Linux (at least all distributions I've seen) comes
with Ian Lance Taylor's uucp which includes a 'cu' clone (cu
is the AT&T "equivalent" of tip), though I must admit that
since there are much better comms programs readily available
I've never actually TRIED the Taylor 'cu' program, and it's
been years since I've used anybody's cu program.
But if I were you I'd give it a try, especially if there was
some particularly good reason why I didn't want to use
minicom or seyon. But what I'd REALLY do is go download
c-kermit from the kermit home page and use that. Easily the
best of the bunch.
===
Subject: Re: Collisions & diald
From: Jan Carlson <janc@iname.com>
Date: Wed, 26 May 1999 00:33:59 -0400
Edward Dekkers wrote:
>
> A couple of things:
[...]
> I need to
> set a 'time-out' value of about 15 mins for re-dial when the connection is
> broken (carrier dropped). Problem is, I'm using diald-config and can't find
> this value any where. It seems I can set it in the scripts, but these get
> over-written when the server re-boots (the way diald-config works it seems).
> Anyone at all have any idea on how to get around this problem?
The parameter is redial-timeout. If restarting overwrites it, the
solution can
be in the way diald is started at boot up.
One way is /etc/rc.d/init.d/diald. That way does not overwrite any
scripts. It also has the advantage that it does not involve linuxconf.
Attached are notes on setting up diald this way.
The other way is letting linuxconf start diald at boot up through its
dialout module. I tried the linuxconf method of starting diald for
awhile,
but could never make it do exactly what I want, so now I'm back to the
init.d
method.
--------------
filename="diald.txt"
DIALD MADE EASY FOR REDHAT 5.2 Revised April 15, 1999
Here are a few points I'd like to add or emphasize.
Then simply follow Jeff's instructions below.
They worked fine for me and several others.
Each step is simple. Charge ahead!
Requirements are:
A. RH5.2 updated from an update site (http://www.redhat.com/mirrors.html)
You can use RH5.1 too, if you install its more numerous updates.
B. A modem that says OK in xminicom (rpm -Uvh minicom*.rpm from RH CD).
C. An ISP that uses PAP. 99% do.
D. Send me your comments when it works!
When the next Red Hat appears I will test and update these notes
with it. That might be tomorrow!
Good luck!
Jan Carlson janc@iname.com.
Please email me your corrections, comments, complaints and questions.
1. Get diald16-0.16.5a-2.i386.rpm and diald16-config-0.16.5a-2.i386.rpm
from a RedHat CONTRIB mirror. Choose one from the CONTRIB column of
http://www.redhat.com/mirrors.html
Be sure to get this diald version only. Several other versions
are beta, broken, or both at this time.
2. Enter your nameserver line 3 times in /etc/resolv.conf. Example:
nameserver 111.222.333.444
nameserver 111.222.333.444
nameserver 111.222.333.444
If you have a local DNS server, triplicate the forwarders.
Otherwise domain requests may timeout before ppp connects.
The typical 56k modem takes 35-45 seconds to connect.
Normal DNS timeout is 30 seconds; this extends it.
3. Insert a line in /etc/rc.d/rc.local:
echo 7 > /proc/sys/net/ipv4/ip_dynaddr #FIX FOR DIALD
To learn more about this, install your kernel-source rpm and read
file:/usr/src/linux/Documentation/networking/ip_dynaddr.txt
4. Enter all local machines into /etc/hosts, or use a local
DNS server with local zones. Otherwise diald dials out
looking for local IP numbers.
5. Add 2 lines to /etc/hosts, or the "route" command will hang.
Note: "route -n" works with or without these.
These IP numbers are fine for the slip link, but make them
match what you put in diald.conf below
127.0.0.11 local-slip
127.0.0.10 remote-slip
6. Make sure /etc/host.conf contains "order hosts, bind".
This makes diald stop dialing out to resolve names in /etc/hosts.
7. Do not create a default route - let diald handle that.
Diald must create the default route on the fly.
8. Almost all ISPs require PAP or CHAP authentication, in which
case no diald scripting changes are needed. These notes do not
cover scripting for the few sites that don't use PAP or CHAP.
9. Diald configuration files have moved during various releases.
'rpm -qil diald diald-conf' shows where to look in this release.
I like having all diald's config files in /etc/diald, with one symlink:
/etc/diald/diald.conf --> /etc/diald.conf
10. Run ntsysv and make sure that inet, network, and diald are enabled.
Do all the configurations below.
Then reboot or run "telinit1;telinit 6" to make it all start.
===
Date: Tue, 6 Oct 1998 23:30:03 -0400 (EDT)
From: Jeff Balderson <jeff@netprodigy.com>
To: linux-diald@vger.rutgers.edu
Subject: RE: A strange story between RedHat 5.1 & Diald
So far, I've set up three RH 5.1 machines with diald, and found it to be
rather straightforward, and even easy. I'm not sure why everyone else is
having such a problem with diald. The procedure I used to produce all
three machines is as follows:
1) Install RedHat 5.1 (including XWindows), get it working enough that you
can run "netcfg" (the networking control panel)
2) Using only netcfg, get your connection to your ISP working.
3) get diald16-0.16.5a-2.i386.rpm and diald16-config-0.16.5a-2.i386.rpm from
a Red Hat CONTRIB site listed at http://www.redhat.com/mirrors.html.
4) Put the packages in an empty directory, cd to that directory and run
"rpm -ivh diald*"
5) run ntsysv or "chkconfig --add diald" to get diald to start on boot
6) cd /etc ; ln -s diald/diald.conf (diald looks for diald.conf in the
/etc directory, but it is installed in the /etc/diald directory. I like
leaving things where they were originally installed)
7) edit /etc/diald.conf, the lines I edit are as follows, after editing,
and in the order they are in the file:
# accept any 420 any
include /usr/lib/diald/standard.filter
device /dev/ttyS2
local 192.168.0.1
remote 192.168.0.2
pppd-options name ISP_USER_NAME :
8) edit /etc/connect, same caveat as in #7:
PHONE_NUMBER="ISP_PHONE_NUMBER"
9) edit /usr/lib/diald/standard.filter, same caveat as in #7:
#ignore udp udp.dest=udp.domain,udp.source=udp.domain
Commenting this makes outgoing DNS requests bring (and keep) the link up.
You may not desire this behavior.
10) "/etc/rc.d/init.d/diald start" or reboot
Note #1: replace ISP_USER_NAME and ISP_PHONE_NUMBER with actual values.
Note #2: Do all of the above as root.
Note #3: replace "device /dev/ttyS2" with your correct port. I don't
recommend using the /dev/cua* devices (see notes at end of message)
I've done this on two machines using accounts with a static IP address,
and one with a with a dynamic IP account. All of this was on different
hardware (Cyrix 6x86L PR166 DIY (do it yourself) machine, Compaq Deskpro
575 (P-75), 486/120 DIY machine) The only thing in common between them is
that they all used internal modems, and they all were RH 5.1. Two of them
have most of the updates applied, and one is running pretty much
out-of-the-box.
All three were this easy to set up. Now, the nice thing about the setups
I'm using is that all of them use PAP authentication. I'm not sure how
running a script might affect things. However, if you have a
brand-spanking new machine that you just set up, and you configure your
PPP connection with netcfg, I can't imagine that you'd have any problems.
Only one machine gave me problems and it was completely unrelated to
diald. That machine was set up with the IP_FIREWALL options turned on, and
due to my packet filtering rules, the packets were getting filtered out.
After a short bit of testing, I found which rule was causing the problem.
It turned out that packets weren't getting forwarded through the sl0
interface, just the ppp0 interface, so it would work fine (and keep the
link up) *IF* I manually told diald to bring the link up, or if traffic
was generated *locally* on the diald machine which would bring the link
up, since after it was up, the ppp0 interface existed and traffic went
there instead of sl0. (How's that for a run-on sentence?) I duped the
forwarding rules related to ppp0 so that sl0 mirrored ppp0 and all was
fine afterwards.
If you're not using XWindows, I suggest setting ONE machine up with
XWindows, set up and test the ifcfg-ppp0, chat-ppp0, etc and the stuff in
/etc/ppp using that machine, and then transfer those over to the
machine(s) without it. Once you have it working, it's rather easy to
change the usernames and passwords by hand editing, but setting it up by
hand can be tricky.
Doing it this way, it almost becomes as easy as setting up a Win95
machine. :) (or :( depending on your take on it)
Jeff
I hope the above helps some of you out.
========
Notes on ttyS* vs cua* (From ttyS-cua.txt in the mgetty documentation)
"Theodore Y. Ts'o" <tytso@mit.edu> wrote:
> Can someone kindly explain the difference between the /dev/cua? and
> /dev/ttyS? devices?
/dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are
only going to be using one set of tty devices, you should be using
/dev/ttySxx.
/dev/cuaXX devices are different from /dev/ttySXX in two ways --- first
of all, they will allow you to open the device even if CLOCAL is not set
and the O_NONBLOCK flag was not given to the open device. This allows
programs that don't use the POSIX-mondated interface for opening
/dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone
calls on their modem (cu stands for "callout", and is taken from SunOS).
The second way in which /dev/cuaXX differs from /dev/ttySXX is that if
they are used, they will trigger a simplistic kernel-based locking
scheme: If /dev/ttySXX is opened by one or more processes, then an
attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened
by one or more processes, then an attempt to open /dev/ttySXX will
result the open blocking until /dev/cuaXX is closed, and the carrier
detect line goes high.
While this will allow for simple lockouts between a user using a modem
for callout and a getty listening on the line for logins, it doesn't
work if you need to arbitrate between multiple programs wanting to do
dialout --- for example, users wanting to do dialout and UUCP.
I originally implemented the cuaXX/ttySXX lockout mechanism back before
FSSTND established a standard convention for the use of tty lock files.
Now that it's there, people should use the tty lock files and not try
using /dev/cuaXX. The only reason why /dev/cuaXX hasn't disappeared yet
is for backwards compatibility reasons.
===