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]

Date:	Mon, 6 Oct 2008 19:54:46 +0200
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] vlan: propogate MTU changes

On Mon, 06 Oct 2008 18:02:39 +0200
Patrick McHardy <kaber@...sh.net> wrote:

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

Increase is also important, there are two common cases. Reducing MTU
because of PPPoe crap, and increasing it because of Jumbo frames.

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

I think it should call change_mtu so userspace gets notified about both
changes.

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