Barrett Morris, Jr. wrote:
>
> I've had the opportunity to look through the archive to try to find
> something similar to my problem. Mostly I see problems relating to diald
> bringing the connection up too frequenlty. I've got the opposite problem.
>
> I've managed to get all set up with a stable ppp and masquerading setup
> which I'm able to share with a win95 and mac client.
AHA! (I'll wait for the problem statement to explain.)
> I can manually bring ppp up and down at will. I've installed what I
> understand to be the current diald-version. Got it in rpm form from red-had
> contrib area (diald-0.16.5a-1.i386.rpm)--also diald-config of the same version.
>
> Running Redhad 5.0 setup with a recently upgraded kernel (2.0.35). I've had
> ip networking up for about 3 months without problem. I am also running
> Samba, but my problems don't seem affected by running without samba.
>
> Problem: I can fire up diald after a fresh reboot, and it works like a
> champ...connects and disconnects as it should. However, I have yet to get
> it to connect twice. Frequently I'm getting a message approximately 2 mins
> (1:57 to be exact) after diald brings down the ppp connection that the 'ppp
> line dicipline successfully unregistered.'
>
> The only way that I can get diald to initiate a connection again is to
> reboot my Linux system, and then restart diald.
I think masquerading is your key - I had this same problem when I set up
masquerading at first. Does your ppp-up script configure your
masquerading? I put mine here because it was the logical place.
However, I put nothing in ppp-down, because I figured that, with no
ppp0, the masquerading would go away. It doesn't.
You need to clear your forwarding rules, and set outbound traffic to be
accepted. If you specify that outbound be masqueraded, it'll bypass the
diald fake interface, and diald will not know to start the connection.
In short, /etc/ppp/ip-down gets the lines
ipfwadm -F -f
ipfwadm -F -p accept
You could do it other ways as well. (I actually reset my firewall to a
limited version, for the sheer masochism of it all.)
If you just want the solution to your problem, stop here and ignore
everything else. If you want assurances I read everything, you may
continue further.
> A couple of things I've noticed:
>
> - My net configuration right now sets up a default route to my ethernet card
> on my host. Before I run diald or manually run ppp, I drop this route by
> entering 'route del default'.
You'll probably want to change this in your setup files. I cannot
remember offhand where the "proper" redhat location is to do it, but you
can probably find out by looking in /etc/rc2.d/S20network (I think); if
I have the right file, and you don't care about the "proper" way to do
it, you can change it there. The only problem you'd have doing that is
that if you upgraded your system (say, to 5.2, which is imminent), it
could revert to the old behavior.
> - When diald brings down the ppp connection, ppp reports in
> /var/log/messages that it has been killed with a signal 2. When I bring
> down a manual ppp connection, ppp reports dying with a signal 15.
Just a difference in how diald works. You're lazy, you send a default
kill signal. Diald sends a 'more correct' signal. Not that it makes
any real difference, other than it saved a diald programmer a keystroke.
> - I've noted in the archive that using /dev/modem can cause some permission
> problems, so I'm now using /dev/ttyS1.
>
> - I understand that one must echo the value 1 to ip_dynaddr in the proc
> tree. I've seen it referred to as 'echo 1 > /proc/...' and 'echo '1' >
> /proc/...'. I've tried both ways.
Yeah, but I've never needed it. *shrug*. There's a lot of stuff you
need to do if you nit-pick. (Anyone want to tell me what I'm hosing by
not doing this?)
> - Also note that I am using a stripped down ppp options file with diald: it
> includes only a 'name' line and a 'debug' line.
Diald.conf handles a lot. Mine fits entirely on the next line.
> - The way my pppd set-up is configured, when a ppp connection is initiated,
> my resolv.conf file is replaced with one which references my ISP's
> nameservers, and an instance of named is started as a cacheing name server.
> When the ppp connection comes down, named is shut down and resolv.conf is
> replaced with a local version referencing only my local host.
Cool. I've been too lazy to set this up.
> -I'm using an out of the box 'standard.filter' file, although I've also
> tried a 'phone.filter' that came with the config files. Again-- didn't help
> my problem.
>
> - Finally, because the rather late notice of unregistration of ppp line
> mentioned above, I've gotten the feeling that there's something not getting
> released or unlocked, so for kicks I remove the 'lock' line from my
> diald.conf file...unfortunately to no avail.
If it takes under five minutes, it could be on-time. autoclean happens
periodically, it checks every five minutes for 0 reference modules. (As
I recall). Admittedly, there is something still looking at your ppp
module, but not in the standard way...
> Again, I'm able to bring up and take down ppp manually as many times as I
> like. But after one diald-sponsored ppp connection, I cannot connect again
> though diald. Even if I restart diald, no joy. I have to reboot, restart
> diald, and then I got one shot again. I'm gaining great knowledge about the
> whole boot process--I've watched it happen over and over and over....
But, have you tried sending either an 'up' or 'force' command through
the diald control line? (for example, using diald-top) That should
still work, though it counts as manual in my book.
> Thanks for help in advance. For anyone considering diald, I can say this
> much... when inet, routed, named, masquerading, ppp, chat and diald are all
> working properly, and diald brings up a connection, it is truly a beautiful
> thing to behold...in my case rare, but still quite beautiful.
Now, if only I could get it to handle the second modem, from 12pm-8am,
but only if there is enough traffic to warrent it. (Basically, I need a
conditional based on number of open connects...) It'd also be nice if
it could do NAT, sort of like masquerading, for the few packets which
queue up before a connection starts. I have several programs I can't
use to bring up diald because of that. (Optimistic buggers, they send
one message out, and wait for five fricking minutes.)
> Sorry to be so longwinded. As I'm not a big-time Linux guru (a monkey could
> load the RedHat package), there could well be some minor system
> configuration trick that I've missed that's resulting in this problem.
I do tech support. Trust me, I *LIKE* longwinded, especially in email
messages. Basically, if you're asking me for help, you want me to be
happy, and you don't know what details are important, spew. It makes it
*so* much easier when the information I need is there, and *so* much
more likely that it will be when you tell all the information you have.
> Since you've gotten this far in my message, please indulge me for one more
> moment: Linux rocks!!!!! Thanks to all who make it possible!
Agreed. Beautiful thing, huh? So many more components to it, so much
easier to support than the frass at work.
Ed
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
