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:	Wed, 01 Apr 2015 13:55:32 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	klamm@...dex-team.ru
Cc:	hannes@...essinduktion.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] net: sysctl for RA default route MTU

From: Roman Gushchin <klamm@...dex-team.ru>
Date: Wed, 01 Apr 2015 12:58:50 +0300

> 31.03.2015, 23:49, "David Miller" <davem@...emloft.net>:
>> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
>> Date: Tue, 31 Mar 2015 22:35:48 +0200
>>>  Could you quickly comment on what you had in mind? I guess it is about
>>>  handling RA in user space on the end hosts and overwriting MTU during
>>>  insertion of the routes?
>>
>> Even after reading your email I have no idea why you can't just have
>> RA provide a 1500 byte MTU, everything else uses the device's 9000
>> MTU, problem solved?
> 
> Because the MTU (provided by RA) is assigned to the device.

Ok, that severely limits the usefulness of this option I guess.

The next question I have is about the behavior of the new setting
in the presence of an RA MTU option.  It seems like the sysctl
doesn't override that RA MTU option, but rather just clamps it.

And then if it's in range, this controls only whether the default
route has it's MTU adjusted.

That doesn't make any sense to me if we then go and do the
rt6_mtu_change() call unconditionally.  The route metric update
and the rt6_mtu_change() go hand in hand.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ