netdev - Re: [PATCH] vlan: propogate MTU changes

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]

Message-ID: <48EA369F.3090306@trash.net>
Date:	Mon, 06 Oct 2008 18:02:39 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] vlan: propogate MTU changes

Stephen Hemminger wrote:
> Propogate MTU changes of underlying device to all related VLAN
> devices.
> see: https://bugzilla.vyatta.com/show_bug.cgi?id=3742
> 
> Signed-off-by: Stephen Hemminger <shemminger@...tta.com>
> ---
> There might be some discussion about whether to preserve MTU changes
> on the vlan device if done after startup, but this seems like the best,
> most direct fix.

Agreed on both points :) But I think having that dicussion would be
useful since there are some points that make it not so clear cut
in my opinion:

- there are multiple virtual drivers depending on configuration of
   some underlying device and it would be good if this behaviour (MTU)
   was consistent since its about interaction with the remaining stack.

- the stack in fact doesn't require us to reduce the MTU of a VLAN
   device as long as its within the physically possible MTU.

- besides MTU, we have UP/DOWN state - currently VLAN devices go
   down when the lower device goes down, killing all routes, but
   don't go UP again when the lower device does. Even if they would,
   most routes can't be reconstructed. The same is true for at
   least some of the other virtual network devices.

- some more items that are often initially taken from the real
   device, but not synced later on include device and broadcast
   address and some flags (f.i. IFF_NOARP, IFF_BROADCAST).

I talked about especially the UP/DOWN point with Ben and some other
people multiple times, but failed to come up with a one-size-fits-all
behaviour. So maybe we should just add some knob (a device flag or
something similar) that "binds" things like MTU, UP/DOWN state etc.
to the lower device. That would also avoid the potential compatibility
issues.

--
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