From: James Chapman <jchapman@katalix.com>
To: linux-ppp@vger.kernel.org
Subject: pppd mtu negotiation problems
Date: Wed, 20 Oct 2004 19:34:48 +0000 [thread overview]
Message-ID: <4176BDD8.30803@katalix.com> (raw)
I'm seeing some unexpected behavior when negotiating MTU using
ppp-2.4.2. The peer is a Cisco box, running IOS 12.1.
My PPP session is inside an L2TP tunnel. The local pppd client is
started as shown, requesting MTU of 1460 which allows space for
UDP/L2TP headers.
pppd 10.2.1.3:10.2.1.4 debug kdebug 7 mtu 1460 mru 1460 noipdefault \
user cisco password cisco local \
noaccomp nopcomp nobsdcomp nodeflate nopredictor1 novj novjccomp
When the pppN interface comes up, it has MTU of 1464. Yet on the cisco
box, its interface shows an MTU of 1460. This mismatch leads to
problems.
The local syslog contains the following.
pppd[3442]: pppd 2.4.2 started by root, uid 0
pppd[3442]: using channel 12
pppd[3442]: Using interface ppp0
pppd[3442]: Connect: ppp0 <-->
pppd[3442]: sent [LCP ConfReq id=0x1 <mru 1460> <magic 0x1175456f>]
pppd[3442]: rcvd [LCP ConfReq id=0x1 <mru 1464> <auth pap> <magic
0x7bdddc5>]
pppd[3442]: sent [LCP ConfAck id=0x1 <mru 1464> <auth pap> <magic
0x7bdddc5>]
^^^^^^^^^^
pppd[3442]: rcvd [LCP ConfReq id=0x2 <mru 1464> <auth pap> <magic
0x7bdddc5>]
pppd[3442]: sent [LCP ConfAck id=0x2 <mru 1464> <auth pap> <magic
0x7bdddc5>]
pppd[3442]: sent [LCP ConfReq id=0x1 <mru 1460> <magic 0x1175456f>]
pppd[3442]: rcvd [LCP ConfNak id=0x1 <mru 1464>]
pppd[3442]: sent [LCP ConfReq id=0x2 <mru 1464> <magic 0x1175456f>]
pppd[3442]: rcvd [LCP ConfAck id=0x2 <mru 1464> <magic 0x1175456f>]
pppd[3442]: sent [PAP AuthReq id=0x1 user="cisco" password=<hidden>]
pppd[3442]: rcvd [PAP AuthAck id=0x1 ""]
pppd[3442]: PAP authentication succeeded
pppd[3442]: sent [IPCP ConfReq id=0x1 <addr 10.2.1.3>]
pppd[3442]: rcvd [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
pppd[3442]: sent [IPCP ConfNak id=0x1 <addr 10.2.1.4>]
pppd[3442]: rcvd [IPCP ConfAck id=0x1 <addr 10.2.1.3>]
pppd[3442]: rcvd [IPCP ConfReq id=0x2 <addr 10.2.1.4>]
pppd[3442]: sent [IPCP ConfAck id=0x2 <addr 10.2.1.4>]
pppd[3442]: local IP address 10.2.1.3
pppd[3442]: remote IP address 10.2.1.4
pppd[3442]: Script /etc/ppp/ip-up started (pid 3444)
pppd[3442]: Script /etc/ppp/ip-up finished (pid 3444), status = 0x0
It looks like both pppd and cisco send ConfReq requesting different
MTU. Pppd acks the cisco 1464 MTU value but then sends another ConfReq
asking for 1460. Cisco naks the 1460 and the peers then agree to use
1464.
Questions:-
- Is cisco right to request MTU of 1464 and then set its interface to
have MTU of 1460? Perhaps the MTU value sent during LCP negotiations
is supposed to include the ethernet checksum? If so, pppd should
always reduce the negotiated value of MTU by 4 when doing
netif_set_mtu() for ethernet links.
- Is the above LCP negotiation correct? Should pppd ack the 1464 value
when an MTU of 1460 is requested? (See the '^^^^' annotation in the
log above).
Comments?
--
James Chapman
PGP key : http://www.katalix.com/~jchapman/pgpkey.txt
next reply other threads:[~2004-10-20 19:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 19:34 James Chapman [this message]
2004-10-21 8:44 ` pppd mtu negotiation problems James Chapman
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=4176BDD8.30803@katalix.com \
--to=jchapman@katalix.com \
--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).