Linux PPP protocol development
 help / color / mirror / Atom feed
From: James Carlson <carlsonj@workingcode.com>
To: linux-ppp@vger.kernel.org
Subject: Re: ppp_async: ioctl to set MTU needed
Date: Tue, 13 Jan 2015 21:31:29 +0000	[thread overview]
Message-ID: <54B58EB1.7080101@workingcode.com> (raw)
In-Reply-To: <54B556D0.5090204@mirix.org>

On 01/13/15 15:57, Christoph Schulz wrote:
> (lcp.c, lines 132-133), and it is only used when setting the MTU of the
> network interface. The non-multilink case:
[...]
>     netif_set_mtu(f->unit, MIN(MIN(mtu, mru), ao->mru));
>                                ^^^                ^^^^^^^

That part looks good to me.  Capping at ao->mru means that the user can
specify the "mtu" option and force the actual link MTU to be anything he
wants (up to the peer's advertised MRU).

> (multilink.c, lines 128-133). The multilink case:
> 
>     mtu = MIN(ho->mrru, ao->mru);
>               ^^^           ^^^^^^^
>     [...]
>     netif_set_mtu(0, mtu);

That also looks good.  Again, the user can specify anything he wants
with the "mtu" option.

That's why I suggested setting "mtu" in the pppd options as a reasonable
work-around.

> 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.

Not so much "wrong" as "pointless."  Why bother to ask for less?  You
don't have to pad the packets out to the full MRU, so why do you care
what the peer has advertised as a maximum?  All that matters is that (by
acking the value) you've promised not to send anything bigger.  By
adhering to a smaller limit, you're certainly in compliance with the
peer's limitations.

Note that the "synchronization" bit there is obscure, but refers to the
possibility of LCP renegotiation.  For some (many?) implementations, LCP
renegotiation (unfortunately!) causes link failure, so everyone avoids it.

In truth, the reason you're required to support an MRU of 1500 is that
the peer can always just Configure-Reject the option.  If he does that,
then what do you do?  If the peer rejects it, that's the end; the option
ends up with the default value, which is 1500.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

  parent reply	other threads:[~2015-01-13 21:31 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 [this message]
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
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=54B58EB1.7080101@workingcode.com \
    --to=carlsonj@workingcode.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