discrepancy in ip(7) wrt. IP DF flag for UDP sockets

discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Benjamin Poirier]

Hi,

I noticed what appears to be a discrepancy between the ip(7) man page
and the kernel code with regards to the IP DF flag for UDP sockets.

The man page says that "The don't-fragment flag is set on all outgoing
datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
sockets. This is quickly disproved by doing:
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
firing up netcat and looking at a few outgoing udp packets in wireshark
(they don't have the DF flag set).

1) in the words of `man 7 ip`:
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 this socket.  The don't-fragment flag is set  on
      all  outgoing datagrams.  The system-wide default is controlled
      by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for  SOCK_STREAM
      sockets, and disabled on all others.

This is the text present in the latest version of the online manpages,
http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8

2) in net/ipv4/af_inet.c:inet_create():
	if (ipv4_config.no_pmtu_disc)
		inet->pmtudisc = IP_PMTUDISC_DONT;
	else
		inet->pmtudisc = IP_PMTUDISC_WANT;

and pmtudisc is left alone from there on for UDP sockets.

What should be adjusted, the man page or the code?

Thanks,
-Ben
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Neil Horman]

On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> Hi,
> 
> I noticed what appears to be a discrepancy between the ip(7) man page
> and the kernel code with regards to the IP DF flag for UDP sockets.
> 
> The man page says that "The don't-fragment flag is set on all outgoing
> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> sockets. This is quickly disproved by doing:
> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> firing up netcat and looking at a few outgoing udp packets in wireshark
> (they don't have the DF flag set).
> 
> 1) in the words of `man 7 ip`:
> 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 this socket.  The don't-fragment flag is set  on
>       all  outgoing datagrams.  The system-wide default is controlled
>       by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for  SOCK_STREAM
>       sockets, and disabled on all others.
> 
> This is the text present in the latest version of the online manpages,
> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
> 
> 2) in net/ipv4/af_inet.c:inet_create():
> 	if (ipv4_config.no_pmtu_disc)
> 		inet->pmtudisc = IP_PMTUDISC_DONT;
> 	else
> 		inet->pmtudisc = IP_PMTUDISC_WANT;
> 
> and pmtudisc is left alone from there on for UDP sockets.
> 
> What should be adjusted, the man page or the code?
> 
The man page is wrong I think

By my read, the code:
1) Affects UDP and TCP the same way (which makes sense to me)

2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
means the stack should be free to fragment a frame as it sees fit according to
the MTU metric of the route its traversing, hence the cleared DF bit in the
fraem.

RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
default value at creation shouldn't apply as well.
Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Michael Kerrisk]

Hello Benjamin, Neil,

On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
>> Hi,
>>
>> I noticed what appears to be a discrepancy between the ip(7) man page
>> and the kernel code with regards to the IP DF flag for UDP sockets.
>>
>> The man page says that "The don't-fragment flag is set on all outgoing
>> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
>> sockets. This is quickly disproved by doing:
>> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
>> firing up netcat and looking at a few outgoing udp packets in wireshark
>> (they don't have the DF flag set).

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?

Thanks,

Michael


>> 1) in the words of `man 7 ip`:
>> 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 this socket.  The don't-fragment flag is set  on
>>       all  outgoing datagrams.  The system-wide default is controlled
>>       by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for  SOCK_STREAM
>>       sockets, and disabled on all others.
>>
>> This is the text present in the latest version of the online manpages,
>> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
>>
>> 2) in net/ipv4/af_inet.c:inet_create():
>>       if (ipv4_config.no_pmtu_disc)
>>               inet->pmtudisc = IP_PMTUDISC_DONT;
>>       else
>>               inet->pmtudisc = IP_PMTUDISC_WANT;
>>
>> and pmtudisc is left alone from there on for UDP sockets.
>>
>> What should be adjusted, the man page or the code?
>>
> The man page is wrong I think
>
> By my read, the code:
> 1) Affects UDP and TCP the same way (which makes sense to me)
>
> 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> means the stack should be free to fragment a frame as it sees fit according to
> the MTU metric of the route its traversing, hence the cleared DF bit in the
> fraem.
>
> RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> default value at creation shouldn't apply as well.
> Neil
>
>



-- 
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 linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Benjamin Poirier]

On 11-09-20 08:14, Michael Kerrisk wrote:
> Hello Benjamin, Neil,
> 
> On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> > On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> >> Hi,
> >>
> >> I noticed what appears to be a discrepancy between the ip(7) man page
> >> and the kernel code with regards to the IP DF flag for UDP sockets.
> >>
> >> The man page says that "The don't-fragment flag is set on all outgoing
> >> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> >> sockets. This is quickly disproved by doing:
> >> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> >> firing up netcat and looking at a few outgoing udp packets in wireshark
> >> (they don't have the DF flag set).
> 
> 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

> 
> Thanks,
> 
> Michael
> 
> 
> >> 1) in the words of `man 7 ip`:
> >> 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 this socket.  The don't-fragment flag is set  on
> >>       all  outgoing datagrams.  The system-wide default is controlled
> >>       by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for  SOCK_STREAM
> >>       sockets, and disabled on all others.
> >>
> >> This is the text present in the latest version of the online manpages,
> >> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
> >>
> >> 2) in net/ipv4/af_inet.c:inet_create():
> >>       if (ipv4_config.no_pmtu_disc)
> >>               inet->pmtudisc = IP_PMTUDISC_DONT;
> >>       else
> >>               inet->pmtudisc = IP_PMTUDISC_WANT;
> >>
> >> and pmtudisc is left alone from there on for UDP sockets.
> >>
> >> What should be adjusted, the man page or the code?
> >>
> > The man page is wrong I think
> >
> > By my read, the code:
> > 1) Affects UDP and TCP the same way (which makes sense to me)
> >
> > 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> > means the stack should be free to fragment a frame as it sees fit according to
> > the MTU metric of the route its traversing, hence the cleared DF bit in the
> > fraem.
> >
> > RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> > set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> > offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> > default value at creation shouldn't apply as well.
> > Neil
> >
> >
> 
> 
> 
> -- 
> 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 linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Neil Horman]

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,
> > 
> > On Mon, Sep 19, 2011 at 3:03 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> wrote:
> > > On Mon, Sep 19, 2011 at 08:19:40AM -0400, Benjamin Poirier wrote:
> > >> Hi,
> > >>
> > >> I noticed what appears to be a discrepancy between the ip(7) man page
> > >> and the kernel code with regards to the IP DF flag for UDP sockets.
> > >>
> > >> The man page says that "The don't-fragment flag is set on all outgoing
> > >> datagrams" and that the ip_no_pmtu_disc sysctl affects only SOCK_STREAM
> > >> sockets. This is quickly disproved by doing:
> > >> echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
> > >> firing up netcat and looking at a few outgoing udp packets in wireshark
> > >> (they don't have the DF flag set).
> > 
> > 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
Neil

> > 
> > Thanks,
> > 
> > Michael
> > 
> > 
> > >> 1) in the words of `man 7 ip`:
> > >> 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 this socket.  The don't-fragment flag is set  on
> > >>       all  outgoing datagrams.  The system-wide default is controlled
> > >>       by the /proc/sys/net/ipv4/ip_no_pmtu_disc file for  SOCK_STREAM
> > >>       sockets, and disabled on all others.
> > >>
> > >> This is the text present in the latest version of the online manpages,
> > >> http://webcache.googleusercontent.com/search?q=cache:http://www.kernel.org/doc/man-pages/reporting_bugs.html&ie=UTF-8
> > >>
> > >> 2) in net/ipv4/af_inet.c:inet_create():
> > >>       if (ipv4_config.no_pmtu_disc)
> > >>               inet->pmtudisc = IP_PMTUDISC_DONT;
> > >>       else
> > >>               inet->pmtudisc = IP_PMTUDISC_WANT;
> > >>
> > >> and pmtudisc is left alone from there on for UDP sockets.
> > >>
> > >> What should be adjusted, the man page or the code?
> > >>
> > > The man page is wrong I think
> > >
> > > By my read, the code:
> > > 1) Affects UDP and TCP the same way (which makes sense to me)
> > >
> > > 2) Is doing exactly what you asked it to, since you set no_pmtu_disc, which
> > > means the stack should be free to fragment a frame as it sees fit according to
> > > the MTU metric of the route its traversing, hence the cleared DF bit in the
> > > fraem.
> > >
> > > RFC 1191 can apply equally well to udp, as tcp, and is evident in that you can
> > > set the per-socket option IP_MTU_DISCOVER to any of the 4 acceptible values
> > > offered (DONT/WANT/DO/PROBE), so theres no reason the sysctl governing the
> > > default value at creation shouldn't apply as well.
> > > Neil
> > >
> > >
> > 
> > 
> > 
> > -- 
> > 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 linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Benjamin Poirier]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Neil Horman]

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-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>

Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Michael Kerrisk]

Ben, Neil,

On Tue, Sep 20, 2011 at 4:31 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> 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-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>

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 linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Neil Horman]

On Thu, Sep 22, 2011 at 06:15:53AM +0200, Michael Kerrisk wrote:
> Ben, Neil,
> 
> On Tue, Sep 20, 2011 at 4:31 PM, Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> 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-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> 
> 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.
> 
This looks good to me.  A minor nit in the chunk you added thoguh.  Calling the
MTU discovery value 'flags' suggests they can be or-together, or somehow
otherwise combined, which is non-sensical.  It may be better to use the term
values rather than flags.

Other than that
Acked-by: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>

Thanks!
Neil

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Benjamin Poirier]

On 11-09-22 06:15, Michael Kerrisk wrote:
> Ben, Neil,
> 
[snip]
> 
> 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.

Oops, seems like there's a repetition that crept in here. I'd keep only
the first of those two sentences:

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

I think it's a welcome clarification. Is is normal that IP_PMTUDISC_WANT
gets hyphenated?

> 
>               Path MTU discovery flags   Meaning

I agree with what Neil said about "flags" here. setsockopt(2) calls
these "option values".

Other than that, LGTM
Acked-by: Benjamin Poirier <benjamin.poirier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Thanks Michael,
-Ben


>               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 linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: discrepancy in ip(7) wrt. IP DF flag for UDP sockets

[Michael Kerrisk]

HI Ben, Neil,

On Thu, Sep 22, 2011 at 2:44 PM, Benjamin Poirier
<benjamin.poirier@gmail.com> wrote:
> On 11-09-22 06:15, Michael Kerrisk wrote:
>> Ben, Neil,
>>
> [snip]
>>
>> 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.
>
> Oops, seems like there's a repetition that crept in here. I'd keep only
> the first of those two sentences:

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

Thanks for catching that! The second of the above sentences is now gone.

>>                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.
>
> I think it's a welcome clarification. Is is normal that IP_PMTUDISC_WANT
> gets hyphenated?

That's just an artifact of groff formatting. One can prevent it, but
then the text justification of some lines starts to look very weird.

>>               Path MTU discovery flags   Meaning
>
> I agree with what Neil said about "flags" here. setsockopt(2) calls
> these "option values".

Changed this to just "value".

> Other than that, LGTM
> Acked-by: Benjamin Poirier <benjamin.poirier@gmail.com>
>
> Thanks Michael,
> -Ben

You're welcome. Thanks for taking the time to write the text and check my work.

Cheers,

Michael


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



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/