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
