From: Ray Van Dolson <rayvd@digitalpath.net>
To: linux-ppp@vger.kernel.org
Subject: Unsupported protocol errors cause some tunnels to "freeze"
Date: Fri, 01 Jul 2005 16:58:56 +0000 [thread overview]
Message-ID: <20050701165855.GA9760@digitalpath.net> (raw)
We're trying to get things stabilized for using VoIP over our tunnels (hence
the TOS stuff I was attempting before which was thwarted).
We're doing PPP within PPTP/GRE with MPPE encryption and occasionally are
running into links that "freeze" but do not disconnect.
On the client side:
pppd 2.4.2b3
MPPE Patch that comes with that version
Linux kernel 2.4.20
pppd options on client side:
defaultroute
usepeerdns
pty 'pptp 192.168.1.53 --nolaunchpppd'
user 'xxx@xxx'
nodeflate
nobsdcomp
require-mppe
require-mschap-v2
persist
mtu 1460
mru 1460
ipcp-accept-remote
ipcp-accept-local
lcp-echo-failure 5
lcp-echo-interval 20
noauth
Server side:
pppd 2.4.3
MPPE/MPPC Module from Jan Dubiec, MPPC disabled.
Kernel 2.6.11.6
We are using the following pppd options on the server:
lock
name pptpd
proxyarp
require-mschap-v2
mppe required,stateless
nomppc
ms-dns xx.xx.xx.xx
ms-dns xx.xx.xx.xx
plugin radius.so
plugin radattr.so
nodeflate
mtu 1456
mru 1456
lcp-restart 5
lcp-echo-interval 20
lcp-echo-failure 5
nobsdcomp
novj
noaccomp
nodeflate
nopcomp
The clients are running on Linksys devices and are a bit tricker to change
settings on.
What happens is occasionally, randomly, and totally unreproducibly one of our
connections freezes up. LCP and GRE (PPTP) appear to still be passing
traffic, so the connection doesn't drop, it still is passing data in both
directions, it's just that the pppd driver doesn't appear to think it's valid.
Here's what we see in the debug logs when this occurs:
Jul 1 09:16:21 chico-pptp2 pppd[6643]: Unsupported protocol 0x83 received
Jul 1 09:16:31 chico-pptp2 pppd[6643]: Unsupported protocol 0xf9 received
Jul 1 09:16:41 chico-pptp2 pppd[6643]: Unsupported protocol 0x63 received
Jul 1 09:16:51 chico-pptp2 pppd[6643]: Unsupported protocol 0x6b received
Jul 1 09:17:44 chico-pptp2 pppd[6643]: Unsupported protocol 0xc1 received
Jul 1 09:17:54 chico-pptp2 pppd[6643]: Unsupported protocol 0xd083 received
Jul 1 09:18:19 chico-pptp2 pppd[6643]: Unsupported protocol 'AppleTalk SmartBuffered' (0x3b) received
Jul 1 09:18:22 chico-pptp2 pppd[6643]: Unsupported protocol 0x11 received
Jul 1 09:18:28 chico-pptp2 pppd[6643]: Unsupported protocol 0xf7 received
Just random protocol numbers.
Our theory is that the MPPE compressesion is somehow getting screwed up and
we're getting gibberish in the protocol field. Unsure how this would happen
however. Sending a SIGUSR2 to the pppd processes does not seem to renegotiate
compression, but instead just drops the link.
I am fairly certain GRE/PPTP is not the problem as data appears to be
travelling back and forth and arriving at the destination, but pppd chokes on
it. I guess it's possible that pptpclient / ppptd are messing up the packets.
Options we are considering:
- Upgrading pppd to 2.4.3 on the client side.
- Upgrading MPPE module on client side (trickier, since we are tied to kernel
2.4.20)
- Trying noccp option (shot in the dark).
I've done tcpdumps on the raw GRE traffic, but it hasn't proven to be real
informative. Any recommendations on how I can further troubleshoot this?
Ray
reply other threads:[~2005-07-01 16:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050701165855.GA9760@digitalpath.net \
--to=rayvd@digitalpath.net \
--cc=linux-ppp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).