Diald setup can be easy if you follow Jeff Balderson's proven method, attached. Here are two more tips that might be useful: 1. Enter your primary nameserver 2 or 3 times in /etc/resolv.conf. This increases the domain request timeout, letting domain requests succeed while the modem is connecting and the ppp link is being established. It's easier than recompiling the kernel with a longer timeout. 2. Insert in /etc/rc.d/init.d/network just before network interfaces are started: echo 5 > /proc/sys/net/ipv4/ip_dynaddr The need is explained in in the kernel source documentation, in /usr/src/linux/Documentation/networking/ip_dynaddr.txt. -- Jan Carlson [EMAIL PROTECTED] Scarborough, Ontario, Canada Mailed with Netscape 4.5 on Red Hat Linux 5.1
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]
