Dear Jedff,
Thanks a lot for your help. I downloaded the lastest package
(diald-0.16.5a-1.i386.rpm and diald-config-0.16.5a-1.i386.rpm) and now
that's work.
Thanks again for the DNS trick in /usr/lib/diald/standard.filter.
Alexis
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Balderson
> Sent: Wednesday, October 07, 1998 5:30 AM
> To: [EMAIL PROTECTED]
> 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" <[EMAIL PROTECTED]>
>
> > 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 [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
