netdev - Re: ip_no_pmtu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Oct 2015 23:12:26 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Vincent Li <vincent.mc.li@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: ip_no_pmtu_disc and UDP

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html