netdev - Re: [RFC patch net-next-2.6] net: allow multiple rx

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: <4E0DF9C6.703@gmail.com>
Date:	Fri, 01 Jul 2011 18:45:58 +0200
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Michał Mirosław <mirqus@...il.com>,
	Jiri Pirko <jpirko@...hat.com>
CC:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org,
	davem@...emloft.net, kaber@...sh.net, fubar@...ibm.com,
	eric.dumazet@...il.com, andy@...yhouse.net
Subject: Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration

Le 01/07/2011 17:01, Michał Mirosław a écrit :

>>> We could introduce a catch-all macvlan/vlan device that would take
>>> addresses/VLANs which are not covered by other configured
>>> macvlans/vlans. This would allow clearer configuration and would make
>>> the evaluation order explicit. As a bonus, this will give another
>>> device to put tcpdump on. ;-)
>>
>> 'Sounds like what I had in mind in
>> http://marc.info/?l=linux-netdev&m=130622112921245&w=2 .
>
> Almost. My idea assumes that eth0.any won't strip VLAN headers (so its
> just looks like a filtered eth0).

I originally thought unstripped packets should go to eth0.

But, if eth0.any get untagged packets, we face two problems:

1/ We need a way to retrieve the original tag.
2/ We need a way to force the tag on output (or we consider eth0.any a pure tcpdump device, which is 
less useful).

But if eth0.any get the exact same packets as those delivered to eth0, this seems useless.

Or maybe, eth0.any should get only packets that weren't delivered to any eth0.XXXX devices... and 
should be named eth0.unmatched instead of eth0.any :-)

Do we need eth0.untagged too (which would only get packets that were originally *not* tagged)?

eth0 - Get everything, untouched. (I know several people except tagged packets to be untagged here, 
but I disagree with this part. eth0 is the raw device and should deliver raw packets, possibly 
retagging packets that were untagged by hw-accel).
eth0.100 - Get VLAN 100 packet, untagged.
eth0.untagged - Get only non-tagged packets, untouched.
eth0.unmatched - Get only tagged packets, untouched.

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