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