In item 4 there is mention of the the temporary SLIP IP numbers in the /hosts file,
what are these numbers?
Cheers,
Rod
-----Original Message-----
From: Iain Hopkins [SMTP:[EMAIL PROTECTED]]
Sent: Friday, December 18, 1998 11:24 AM
To: Jan Carlson
Cc: [EMAIL PROTECTED]
Subject: Re: Diald losing packets
Jan,
Great it all works now, all I had to do was add the triple nameserver in
/etc/resolv.conf. I also moved the ip_dynaddr tweak as suggested.
Thanks for all your help !
--Iain
At 14:54 17/12/98 -0500, you wrote:
>Hi Iain,
>
>Try the ip_dynaddr tweek in a different place,
>and using your nameserver 3 times. See (revised)
>attachment, near the top. That made all
>the difference for mine.
>
>Please let me know how it goes!
>Any corrections or additions for the notes
>would be great too.
>
>I hope this helps you get it working
>perfectly.
>
>Jan
>
>--
>
>Jan Carlson
>[EMAIL PROTECTED] Scarborough, Ontario, Canada
>Mailed with Netscape 4.5 on Red Hat Linux 5.2
>
> DIALD MADE EASY FOR REDHAT 5.X
>
> 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.
>
>1. Get diald-0.16.5a-1.i386.rpm and diald-config-0.16.5a-1.i386.rpm
> from the contrib directory of a RedHat mirror
> http://www.redhat.com/mirrors.html
> I had no success with certain other diald versions.
>
>2. Enter your nameserver line 3 times in /etc/resolv.conf
> or in your local DNS server forwarders list.
> Otherwise domain requests may timeout before ppp connects.
>
>3. Insert one line after "start)" in /etc/rc.d/init.d/networking:
> case "$1" in
> start)
> echo 7 > /proc/sys/net/ipv4/ip_dynaddr #FIX FOR DIALD
>
> To learn more, install your kernel-source rpm and read
> file:/usr/src/linux/Documentation/networking/ip_dynaddr.txt
>
>4. Put all local machines into /etc/hosts unless
> you have a local DNS server with local zones.
> Add the temporary slip IP numbers to /etc/hosts,
> with names like local-slip, remote-slip.
> Make sure /etc/host.conf contains "order hosts, bind"
> This reduces unnecessary dialouts for DNS.
>
>5. Do not create a default route.
> Diald must create the default route on the fly.
>
>6. Almost all ISPs require PAP or CHAP authentication, in which
> case no scripting changes are needed. These notes do
> not cover scripting for other cases.
>
>7. Diald configuration files have moved during various releases.
> rpm -qil diald diald-conf shows where to look in this release.
> I prefer to move all into /etc/diald, with one symlink:
> /etc/diald/diald.conf --> /etc/diald.conf
>
>----------------------------------------------------------------------
>
>Date: Tue, 6 Oct 1998 23:30:03 -0400 (EDT)
>From: Jeff Balderson <[EMAIL PROTECTED]>
>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]
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
