[EMAIL PROTECTED] wrote:
> Barrett Morris, Jr. wrote:
> > 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.'
This just means the ppp.o module has been unloaded from the kernel.
If you are able to start ppp by hand, then you must have kerneld(1) set
up properly to reload ppp.o when it is needed again. If you want to
eliminate this as a possible source of your problems, just use modprobe
or insmod to load ppp.o forever (or until your next reboot or you manually
unload the module).
After you have done your one diald connection, does ppp still manually come up?
>
> >
> > 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.
> ....
My masquerading (and firewall) is set up when I boot and never changed.
Just a wild idea, how do you bring down the diald connection when you don't
want it any more? Do you let it timeout and disconnect on its own or do you
maybe kill the diald process? You want the first and not the second.
>
>
> > 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 do not need (or want) a default route when you are not connected to the
Internet. The output from 'netstat -nr' on my machine (with diald and ppp connected)
looks like this:
$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.250 0.0.0.0 255.255.255.255 UH 1500 0 0 sl0
168.121.1.1 0.0.0.0 255.255.255.255 UH 1500 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 1500 0 0 ppp0
0.0.0.0 0.0.0.0 0.0.0.0 U 1500 0 0 sl0
$
There is no default route to the eth0 interface. The line
192.168.1.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0
Is all you need to allow your local net to work just fine.
THIS COULD BE YOUR PROBLEM. If your default route to eth0 is
masking the default route to sl0, then diald would not be triggered to dial out.
> >
> > - 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.
>
This is supposed to allow your connection to go more smoothly. When I am using
netscape on a Win/NT machine on my in-home network without the ip_dynaddr
set as above, netscape will timeout trying to reach the site if diald needed to make
a connection. With ip_dynaddr set to 1, when the kernel retries to connect to a
site it will rewrite the IP packet headers taking into account any new connection
that diald might have been able to estanblish and allow netscape to not timeout.
So setting ip_dynaddr makes using diald a little more seamless.
> > - 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.
>
We use this resolv.conf
$ cat /etc/resolv.conf
search domain.com
nameserver 127.0.0.1
$
And leave the nameserver up all the time. That way the named process can accumulate
a larger cache of DNS entries so there is less DNS traffic over the dialup line. At
least
that is how the theory goes, I haven't been any to find any stats that tell me this
is actually
happening. If you are curious, our named.boot is setup like this:
$ more named.boot
;
; a caching only nameserver config
;
directory /var/named
cache . named.ca
primary 0.0.127.in-addr.arpa pz/127.0.0
primary 1.168.192.in-addr.arpa pz/192.168.1
forwarders 207.69.188.185 207.69.188.186 207.69.188.187
options forward-only
$
Using the forward-only to the DNS servers at our ISP allowed the firewall rules
to be more secure because the firewall only needs to pass DNS traffic from
the ISP instead of allowing DNS packets from the entire internet. DNS attacks
have been used in the past.
>
> > 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.)
I have been looking for the second modem support myself. I have been told
the net/sched subsystem in the 2.1 kernel will have some (all?) support for this.
Unfortunately at this point, there is no documentation on this new feature.
Try the ip_dynaddr option to get the queued up packets to go through and
those optimistic programs might start working.
If you get too frustrated, you might try the dial on demand feature in the latest
ppp releases. Personally I am sticking with diald since I have it working and
I am not sure the new ppp supports different timeouts for different protocols.
Brian Beuning
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
