Re: ip_no_pmtu_disc and UDP

ok, I observed  if i increase the UDP client packet size > local
interface  MTU 1500, the client will fragment the packet first and
then send it out, if the UDP client packet size < local interface MTU
1500, the DF bit will be set when ip_no_pmtu_disc set to 0, is this
expected behavior ?



On Mon, Oct 26, 2015 at 3:35 PM, Vincent Li [off-list ref] wrote:

I test again and i did see DF bit now, it is weird. I am going to do
more test, sorry for the noise.

On Mon, Oct 26, 2015 at 3:12 PM, Hannes Frederic Sowa
[off-list ref] wrote:

quoted

Hello,

On Mon, Oct 26, 2015, at 23:00, Vincent Li wrote:

quoted

the UDP packet size is about 768, here is how packet path  like:

client
<----------------------------------------router<-------------------------------------------------->server
(eth0 mtu 1500 ip 10.3.72.69)     (eth0 mtu 1500 ip 10.3.72.1,
          (eth0 mtu 1500 ip 10.2.72.99)
                                                      eth1.1102 mtu
567 ip 10.2.72.139)


UDP client test script:

[...]

so I am hoping if I echo 0, 1, 2, 3 respectively to
/proc/sys/net/ipv4/ip_no_pmtu_disc, I am expected to see DF bit
set/unset from the client and should have shown me on the router eth0
interface tcpdump, but instead, DF bit never set on the client. am I
misunderstanding something?

This is strange...

Can you please capture traffic on eth0 on the client?

For outgoing packets only zero or non-zero matter. A '0' definitely
generates a UDP packet with a DF bit on my side, anything else a frame
with DF bit cleared. I just verified this on net-next with your script.
It also does not cause any setsockopts but uses the default.

quoted

for example:

 two concurrent tcpdump on router eth0 (mtu 1500) and eth1.1102 (mtu
576) interface:

1 #tcpdump -nn -i eth0 -v udp and host 10.3.72.69 &

14:51:11.946143 IP (tos 0x0, ttl 64, id 7193, offset 0, flags [none],
proto UDP (17), length 796)
    10.3.72.69.43748 > 10.2.72.99.9999: UDP, length 768

As I said, I cannot reproduce that. :( Please test on eth0 directly so
we can be sure the packet does not get mangled.

Can you also show me the output of
ip route get 10.2.72.139
on the client after you maybe already received a icmp pkt-too-big
packet?

Thanks,
Hannes