lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 22 Sep 2011 06:15:53 +0200
From:	Michael Kerrisk <mtk.manpages@...il.com>
To:	Benjamin Poirier <benjamin.poirier@...il.com>
Cc:	Neil Horman <nhorman@...driver.com>, linux-man@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

Ben, Neil,

On Tue, Sep 20, 2011 at 4:31 PM, Neil Horman <nhorman@...driver.com> wrote:
> On Tue, Sep 20, 2011 at 10:12:34AM -0400, Benjamin Poirier wrote:
>> On 11-09-20 09:38, Neil Horman wrote:
>> > On Tue, Sep 20, 2011 at 09:29:54AM -0400, Benjamin Poirier wrote:
>> > > On 11-09-20 08:14, Michael Kerrisk wrote:
>> > > > Hello Benjamin, Neil,
>> > > >
>> [snip]
>> > > >
>> > > > Could you describe the required change in terms of how the man page
>> > > > text should look--i.e., rewrite the passage as you think it should
>> > > > look?
>> > >
>> > > How about changing it to:
>> > >   IP_MTU_DISCOVER (since Linux 2.2)
>> > >   Set or receive the Path MTU Discovery setting for a socket. When
>> > >   enabled, the don't-fragment flag is set on all outgoing packets.
>> > >   Linux will perform Path MTU Discovery as defined in RFC 1191 on
>> > >   SOCK_STREAM sockets. For non-SOCK_STREAM sockets, it is the
>> > >   user's responsibility to packetize the data in MTU sized chunks
>> > >   and to do the retransmits if necessary. The kernel will reject
>> > >   (with EMSGSIZE) datagrams that are bigger than the known path
>> > >   MTU. The system-wide default is controlled by the
>> > >   /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>> > >
>> > >   Path MTU discovery flags   Meaning
>> > >   [...]
>> > >
>> > > There are some differences between _DO and _WANT that are glossed over
>> > > in this description, but I suppose there's only so much detail you can
>> > > put in...
>> > >
>> > > Thanks,
>> > > -Ben
>> > >
>> > Yeah, I think thats close, but its only the users responsibility to package
>> > datagrams in mtu sized chunks if they force the dont fragment bit on.  If they
>> > go wtih the default, the stack will fragment a datagram is it sees fit according
>> > to the mtu of the path it traverses
>>
>> Exactly. To get into this level of detail, I think we have to mention
>> the option value, not just enabled/disabled. Let's try like this:
>>
>>       IP_MTU_DISCOVER (since Linux 2.2)
>>       Set or receive the Path MTU Discovery setting for a socket. When
>>       enabled, Linux will perform Path MTU Discovery as defined in RFC
>>       1191 on SOCK_STREAM sockets.  For non-SOCK_STREAM sockets,
>>       IP_PMTUDISC_DO forces the don't-fragment flag to be set on all
>>       outgoing packets.  It is the user's responsibility to packetize
>>       the data in MTU sized chunks and to do the retransmits if
>>       necessary.  The kernel will reject (with EMSGSIZE) datagrams
>>       that are bigger than the known path MTU.  IP_PMTUDISC_WANT will
>>       fragment a datagram if needed according to the path MTU or will
>>       set the don't-fragment flag otherwise.
>>
>>       The system-wide default can be toggled between IP_PMTUDISC_WANT
>>       and IP_PMTUDISC_DONT by writting to the
>>       /proc/sys/net/ipv4/ip_no_pmtu_disc file.
>>
> Yes, that sounds good to me.  Thanks for doing this!
> Acked-by: Neil Horman <nhorman@...driver.com>

Ben, thanks for writing this, and Neil, thanks for reviewing it. I've
applied that change for man-pages-3.34.

Ben, I added one small piece ti the description of
/proc/sys/net/ipv4/ip_no_pmtu_disc. For completeness, I've reproduced
the entire text below. Perhaps you could take a quick scan, to make
sure that the changed text is consistent with the whole piece.

Thanks,

Michael

       IP_MTU_DISCOVER (since Linux 2.2)
              Set or receive the Path  MTU  Discovery  setting  for  a
              socket.   When enabled, Linux will perform Path MTU Dis-
              covery as defined in RFC 1191  on  SOCK_STREAM  sockets.
              For  non-SOCK_STREAM  sockets, IP_PMTUDISC_DO forces the
              don't-fragment flag to be set on all  outgoing  packets.
              The  don't-fragment  flag  is  set on all outgoing data-
              grams.  It is the user's responsibility to packetize the
              data  in  MTU-sized  chunks and to do the retransmits if
              necessary.  The kernel will reject (with EMSGSIZE) data-
              grams   that   are  bigger  than  the  known  path  MTU.
              IP_PMTUDISC_WANT will  fragment  a  datagram  if  needed
              according  to  the path MTU, or will set the don't-frag-
              ment flag otherwise.

              The system-wide default can be toggled between IP_PMTUD-
              ISC_WANT  and IP_PMTUDISC_DONT by writing (respectively,
              zero      and      nonzero      values)      to      the
              /proc/sys/net/ipv4/ip_no_pmtu_disc file.

              Path MTU discovery flags   Meaning
              IP_PMTUDISC_WANT           Use per-route settings.
              IP_PMTUDISC_DONT           Never do Path MTU Discovery.
              IP_PMTUDISC_DO             Always do Path MTU Discovery.
              IP_PMTUDISC_PROBE          Set DF but ignore Path MTU.

              When PMTU discovery is enabled, the kernel automatically
              keeps track of the path MTU per destination host.   When
              it  is connected to a specific peer with connect(2), the
              currently known path MTU can be  retrieved  conveniently
              using  the IP_MTU socket option (e.g., after an EMSGSIZE
              error occurred).  The path MTU  may  change  over  time.
              For  connectionless  sockets with many destinations, the
              new MTU for a given destination  can  also  be  accessed
              using  the  error  queue  (see IP_RECVERR).  A new error
              will be queued for every incoming MTU update.

              While MTU discovery is in progress, initial packets from
              datagram sockets may be dropped.  Applications using UDP
              should be aware of this and not take it into account for
              their packet retransmit strategy.

              To  bootstrap  the  path MTU discovery process on uncon-
              nected sockets, it is possible to start with a big data-
              gram  size  (up  to  64K-headers  bytes long) and let it
              shrink by updates of the path MTU.

              To get an initial estimate of the path  MTU,  connect  a
              datagram  socket  to  the destination address using con-
              nect(2) and retrieve the MTU  by  calling  getsockopt(2)
              with the IP_MTU option.

              It  is  possible  to implement RFC 4821 MTU probing with
              SOCK_DGRAM or SOCK_RAW sockets by  setting  a  value  of
              IP_PMTUDISC_PROBE  (available since Linux 2.6.22).  This
              is also particularly useful for diagnostic tools such as
              tracepath(8)  that wish to deliberately send probe pack-
              ets larger than the observed Path MTU.


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ