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 <vincent.mc...@gmail.com> 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 > <han...@stressinduktion.org> wrote: >> Hello, >> >> On Mon, Oct 26, 2015, at 23:00, Vincent Li wrote: >>> 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. >> >>> 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 >> >> >> >> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html