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
| ||
|
Date: Fri, 10 Oct 2008 18:28:06 +0200 From: Patrick McHardy <kaber@...sh.net> To: Jarod Neuner <j.neuner@...workharbor.com> CC: netdev@...r.kernel.org Subject: Re: IGMP sent to Foreign VLAN Jarod Neuner wrote: > On Thu, 2008-10-09 at 07:31 -0500, Patrick McHardy wrote: >> I don't think we should change the default, it would probably >> catch some people by surprise. It might not be handled properly >> by packet filtering rules etc. > > On the other hand, I was surprised that VLAN packets were being dropped > altogether. Net admins tend to assign a link to a particular VLAN with > little regard to the VLAN configuration of the hosts on that link. I'm > thinking of two general situations: > > 1) If the kernel is resident on an application device (PC, Multimedia > Device, SOHO Router, etc.), and a packet for a particular VLAN reaches > the network interface with a correct MAC and a correct IP, then they > were probably delivered correctly, whether that host is configured with > that VLAN ID or even if the VLAN module is loaded. > > 2) If the kernel is configured to route incoming VLAN packets, and a > packet arrives with an unconfigured VLAN ID, then it seems perfectly > reasonable to route it as if it had no VLAN tag. > > I'm sure someone has a setup that expects that foreign VLANs will be > dropped - but I suspect far more are generally indifferent to the > policy. There might even be a handful that will be pleasantly surprised > when IGMP snooping suddenly starts to work. Possible, but besides the fact that this has been our default since even before VLAN was merged, a reason why this absolutely has to be manually enabled is that it requires to disable hardware filters for consistent, driver-independant behaviour. >> So .. would you be interested in implementing this properly? >> I think its a good change and I could help you if needed or >> take care of some parts like the drivers myself. > > I've got quite a bit on my plate at the moment, but I will give it a > shot. I'll try to come up with some of the IFF_ALLVLAN functionality > over the next few days and get back to you. Great, thanks. -- 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