Hmm,
I wonder if you can catch it again and do a ``set log local
physical'' and run ``tcpdump -i XXX -e not ip'' on the interface at
the same time ?
A ``ping -c 1'' should then show if ppp's sending the data out, and
if it is, if ng_ether is forwarding it.
I'm a little concerned about the
According to Brian Somers:
Brett Glass (cc'd) has complained about a similar problem where it
seems that the ng_pppoe node is locked up. I can't reproduce the
problem here though :(
Does the following help you :
-=-=-
tun0: Timer: Begin of Timer Service List---
tun0: Timer: physical
According to Brian Somers:
Brett Glass (cc'd) has complained about a similar problem where it
seems that the ng_pppoe node is locked up. I can't reproduce the
problem here though :(
Does the following help you :
[.]
Not really - I think we need ``physical'' logs so that we can
According to Brian Somers:
If pppctl is still working (ppp will talk to it), then it may be
worth seeing what ``show physical'' and ``show timer'' say (is the
link open, or is ppp waiting for something to happen via a timeout?).
Locked again with a pppctl attached.
show timer
-=-=-
IPCP
Hi,
I think it's important to quantify what a lockup is here.
If pppctl is still working (ppp will talk to it), then it may be
worth seeing what ``show physical'' and ``show timer'' say (is the
link open, or is ppp waiting for something to happen via a timeout?).
If pppctl isn't working it's
Brian:
If he's having the same lockup as me, PPP is blocking on
a select() while trying to re-establish a connection that
has gone down. If there's a pppctl socket open and you're
issuing commands it doesn't lock up. But when you shut
down the socket by terminating pppctl the lockup occurs.
The
According to Brett Glass:
To reproduce the problem (and it's easily reproducible
here), pull the client's Ethernet cable. The client will
retry properly once. The second time it retries, it will
lock. Since this may be adapter-dependent, try with an ed
card (I think that everyone in the
According to Brian Somers:
If pppctl is still working (ppp will talk to it), then it may be
worth seeing what ``show physical'' and ``show timer'' say (is the
link open, or is ppp waiting for something to happen via a timeout?).
ppp is still running and pppctl can talk to it. I'll try what
According to James Housley:
and I am not in Canada. I am using natd and ipfw for NAT and the
firewall. The link has a static IP if it matters. Below I am attaching
ppp.conf. I have watched some of the data with tcpdump on both tun0 and
I'm also using ppp + ng_pppoe on a 4.3-STABLE system.
James Housley wrote:
I have been having problems with the the newer Windows machines, 2000
Me, not being able to access some websites. I have had to manually edit
the registry to change the MTU. This should not be needed, because I am
running 4.3-RELEASE which has had the tcpmssfixup
Try reducing the interface MTU further. It's possible that there's a
misconfigured router between you and the sites *and* a part of the
route has an mtu of less than 1492.
``set mtu 1480'' or ``set mtu 1460'' may work.
I have been having problems with the the newer Windows machines, 2000
Brian Somers wrote:
Try reducing the interface MTU further. It's possible that there's a
misconfigured router between you and the sites *and* a part of the
route has an mtu of less than 1492.
``set mtu 1480'' or ``set mtu 1460'' may work.
That fixed it. I fat-fingered it to 1450.
12 matches
Mail list logo
