Thanks, will do.
Michael Remski
Software Engineer
[EMAIL PROTECTED]
7 Henry Clay Drive
Merrimack, NH 03054
+1 603.879.7241 direct
+1 603.577.5533 fax
www.ellacoya.com
On Mon, 4 Dec 2000, Brian Somers wrote:
> Sorry for the delay - I've had no connectivity over the weekend...
>
> I think you need to add some bits to your ppp config to find out
> what's going on. I'd suggest:
>
> ppp.linkup:
>
> MYADDR:
> set log -dns -tcp/ip
>
> ppp.linkdown:
>
> MYADDR:
> set log +dns +tcp/ip
>
> The idea is to enable tcp/ip and DNS logging while the link is down
> and disable it when the link comes up (it's mostly useless then).
>
> When ppp gets into the state where it's not bringing the link up, you
> should be able to look in ppp.linkup and either see that packets are
> being blocked or that packets are not being seen.
>
> Alternatively, you could be seeing ppp failing to connect to your
> ISP, blocking up with packets and waiting for the choked timer to
> kick in (default of 2 minutes) and drop the queue in the bit-bucket.
> If this is the case, you can do something like ``set choked 20'' to
> bring that timeout down to a value that'll make ppp more persistent
> in trying to connect.
>
> > Thanks Brian. I took a look at the faq, and had everything set up the
> > way it suggested. netstat -rn showed a default route and a route
> > between the two 10. addresses for tun0. My /etc/resolv.conf was
> > pointing to the nameserver on the local machine: nameserver 0.0.0.0
> > directive.
> > I wasn't clear that the fetchmail is running on the same box that is
> > running ppp -auto. I think this indicates outgoing traffic is not
> > causing ppp to dial. When it gets into this state it seems like named
> > had reaped some stuff out of its cache (time to live stuff). Could
> > this (named clearing cache) or an iface clear in ppp.linkdown be causing
> > an adverse reaction with the routing table?
> >
> > It will typically work for 3 or 4 days befre getting into this state.
> >
> > Again, thanks for the suggestions.
> >
> > Michael Remski
> > Software Engineer
> > [EMAIL PROTECTED]
> > 7 Henry Clay Drive
> > Merrimack, NH 03054
> > +1 603.879.7241 direct
> > +1 603.577.5533 fax
> > www.ellacoya.com
> >
> > On Fri, 1 Dec 2000, Brian Somers wrote:
> >
> > > Check out http://www.FreeBSD.org/FAQ/ppp.html. Your best bet is to
> > > set up a diagnostic socket and attach to it when ppp appears hung.
> > > You should be able to ``set log local physical'' and see any incoming
> > > and outgoing traffic. If there's no incoming traffic, I'd tend to
> > > blame the peer.
> > >
> > > > Hi all.
> > > > I have a small network (3 machines) running on 192.168. addresses,
> > > > outside connection is 56K modem. I'm starting both named and userland
> > > > ppp at boottime. ppp.conf is basically the one that gets installed,
> > > > with the enable dns line commented out and the username, phonenumber and
> > > > password set. I then have a cron job that runs fetchmail every 4 hours
> > > > or so to pull down mail. After a time (maybe a day or so), ppp never
> > > > dials out. If I kill -9 and restart it stays ok for awhile again.
> > > > ppp is started with -nat -auto -quiet papchap
> > > > named just resolves my three machines.
> > > > netstat -rn shows the default route pointing out thru tun0.
> > > > ppp.linkdown has an iface clear in it.
> > > >
> > > > ps ax when this is happening does not show anything unusual about ppp.
> > > > kernel has the IPDIVERT/IPFIREWALL and NETGRAPH options in it (I am not
> > > > running natd, I'm letting ppp handle that)
> > > >
> > > > Any suggestions of what to look at greatly appreciated.
> > > >
> > > > Michael Remski
> > > > Software Engineer
> > > > [EMAIL PROTECTED]
> > > > 7 Henry Clay Drive
> > > > Merrimack, NH 03054
> > > > +1 603.879.7241 direct
> > > > +1 603.577.5533 fax
> > > > www.ellacoya.com
>
> --
> Brian <[EMAIL PROTECTED]> <brian@[uk.]FreeBSD.org>
> <http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org>
> Don't _EVER_ lose your sense of humour !
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
