[101501] in RedHat Linux List
Re: diald
daemon@ATHENA.MIT.EDU (Jan Carlson)
Thu Nov 26 22:09:56 1998
Date: Thu, 26 Nov 1998 22:08:41 -0500
From: Jan Carlson <janc@iname.com>
To: "Bob C. Ruddy" <ruddy@udlug.org>,
RedHat Mailing List <redhat-list@redhat.com>
Resent-From: redhat-list@redhat.com
Reply-To: redhat-list@redhat.com
This is a multi-part message in MIME format.
--------------B3DDC5B71D6CDB8EF36322DF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
No need to compile it. There are rpm's that work fine,
and some that don't. Here are the versions that worked fine
for me and several others:
diald-0.16.5a-1.i386.rpm
diald-config-0.16.5a-1.i386.rpm
You can get these from ftp://contrib.redhat.com.
Before you install them, get a ppp working using
netcfg and nothing else. Most people must use
PAP. The PAP secret is just the password
for your ISP account, and PAP name is the
username for the ISP.
Then rpm -Uvh the two diald rpms,
and follow Jeff Balderson's instructions, attached.
"Bob C. Ruddy" wrote:
> Hello,
> I was wondering if anyone has gotten diald compiled, or if anyone knows
> were there is an rpm for the newest version when I try to 'make depend' in
> the diald source I get a ton of errors similar to this.
>
> /usr/include/linux/in.h:95: warning: `IN_BADCLASS' redefined
> /usr/include/netinet/in.h:123: warning: this is the location of the
> previous definition
>
> I get the same type of errors when I type make. Does anyone have any
> ideas, or know where I can get an rpm? Thanks for your help.
>
> Bob
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> the body of a message to majordomo@vger.rutgers.edu
--
Jan Carlson
janc@iname.com Scarborough, Ontario, Canada
Mailed with Netscape 4.5 on Red Hat Linux 5.2
--------------B3DDC5B71D6CDB8EF36322DF
Content-Type: text/plain; charset=us-ascii;
name="balderson.notes"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="balderson.notes"
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 diald-0.16.5a-1.i386.rpm and diald-config-0.16.5a-1.i386.rpm from
ftp.redhat.com in the /pub/contrib/hurricane/i386 directory (or from a
mirror that mirrors the contrib directory, like linux.eecs.umich.edu).
Note that the one in the /pub/contrib/i386 directory is an old one (16.4,
I think, although I've successfully used 16.4 with roughly the same
procedure, since some of the files were different and in different places)
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)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to majordomo@vger.rutgers.edu
--------------B3DDC5B71D6CDB8EF36322DF--
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.
