From: Matthias-Christian Ott <ott@mirix.org>
To: linux-ppp@vger.kernel.org
Subject: Re: ppp_async: ioctl to set MTU needed
Date: Tue, 13 Jan 2015 23:24:11 +0000 [thread overview]
Message-ID: <54B5A91B.3050002@mirix.org> (raw)
In-Reply-To: <54B556D0.5090204@mirix.org>
On 2015-01-13 21:57, Christoph Schulz wrote:
> Matthias-Christian Ott schrieb am Tue, 13 Jan 2015 18:33:04 +0100:
>
>> The MTU of a channel of a Multilink PPP link is set from the MRU of a
>> Configure-Ack LCP packet. However, just because the is able to receive
>> packets of a certain size it doesn't mean that the link or the sender
>> are able to transmit packets of that size, so the received MTU of the
>> channel should not be set to the MRU of the peer.
>
> Well, this seems to be not so easy. I just studied the Kernel source
> code, the pppd source code and the PPP RFCs, so I feel rather
> well-informed in a way ;-)
I dont't doubt that.
> Where are we now? I think your problem lies in this comment in lcp_reqci():
>
> /*
> * He must be able to receive at least our minimum.
> * No need to check a maximum. If he sends a large number,
> ---> !! * we'll just ignore it.
> */
>
> You think each PPP implementation has to NAK when a MRU being larger
> than our MTU is REQuested by the peer. Obviously this isn't handled this
> way, at least not by pppd. However, I think your problem is twofold. You
> did not write how big your desired MTU (at the side of peer B) really
> is. I bet that it is smaller than 1500, as you write it is smaller than
> "link MTU minus maximum IP header length minus GRE/L2TP header length".
> However, RFC 1661 requires that each implementation MUST accept packets
> that are 1500 bytes long:
>
> 6.1. Maximum-Receive-Unit (MRU)
> [...]
> The default value is 1500 octets. If smaller packets are
> requested, an implementation MUST still be able to receive the
> full 1500 octet information field in case link synchronization is
> lost.
>
> So each attempt to force peer A to request a MRU < 1500 is formally
> wrong as it might be ignored -- even if the peer ACKs this MRU.
It seems that I read over this than and what I wanted to achieve is
impossible with PPP. I think setting the channel MTU to the MRU is
unaffected by this and is still wrong though. From RFC 1661:
6.1. Maximum-Receive-Unit (MRU)
[...]
This option is used to indicate an implementation capability.
The peer is not required to maximize the use of the capacity.
For example, when a MRU is indicated which is 2048 octets, the
peer is not required to send any packet with 2048 octets. The
peer need not Configure-Nak to indicate that it will only send
smaller packets, since the implementation will always require
support for at least 1500 octets.
Regards,
Matthias-Christian
next prev parent reply other threads:[~2015-01-13 23:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 17:33 ppp_async: ioctl to set MTU needed Matthias-Christian Ott
2015-01-13 20:30 ` James Carlson
2015-01-13 20:57 ` Christoph Schulz
2015-01-13 21:31 ` James Carlson
2015-01-13 21:56 ` Christoph Schulz
2015-01-13 22:22 ` James Carlson
2015-01-13 22:56 ` Christoph Schulz
2015-01-13 23:04 ` Christoph Schulz
2015-01-13 23:24 ` Matthias-Christian Ott [this message]
2015-01-13 23:39 ` Matthias-Christian Ott
2015-01-14 0:10 ` James Carlson
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=54B5A91B.3050002@mirix.org \
--to=ott@mirix.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.