netdev - Re: [NET 00/02]: MACVLAN driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20070624142248.4ac405e2.ipng@69706e6720323030352d30312d31340a.nosense.org>
Date:	Sun, 24 Jun 2007 14:22:48 +0930
From:	Mark Smith <ipng@...06e6720323030352d30312d31340a.nosense.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [NET 00/02]: MACVLAN driver

(Applogies for not maintaining thread id, I'm not subscribed.)

>> We don't have any clean interfaces by which to do this MAC
>> programming, and we do need something for it soon.

>Yep, that's been on my long term wish list for a while, as well.

>Overall I would like to see a more flexible way of allowing the net 
>stack to learn each NIC's RX filter capabilities, and exploiting them. 
>Plenty of NICs, even 100Mbps ones, support RX filter management that 
>allows scanning for $hw_limit unicast addresses, before having to put 
>the hardware into promisc mode.
>

A thought I had when I discovered this ability in the
Natsemi/NS83815 chip was to use these RX filters for perfect multicast
DA matching until they ran out, and then reverting to the normal
Multicast DA matching mechanisms.

Another alternative use I thought of was to use these filters to filter
out different ethernet protocol types e.g. if an interface is only
going to be processing IPv4 packets, program these filters to only
accept frames with type 0800 for IP and 0806 for ARP, reverting to
non-filtering if there are too many protocol types, as per the way the
interfaces operate today.

I think it could be useful to expose the ability to have the NIC ignore
broadcast packets, or more generally, expose the three catagories of
address recognition that NICs seem to allow to be enabled / disabled -
unicast, multicast and broadcast.

If an interface then didn't need to have broadcast reception enabled
e.g. an IPv6 only interface (or Appletalk), then it wouldn't be,
preventing the host from having to process broadcasts it's going to
ignore anyway.

A future common scenario where this ability might be useful would be
LANs with a mix of IPv4 only, IPv4/IPv6 and IPv6-only nodes.

The ability to enable/disable unicast, multicast and broadcast address
recognition individually on a NIC seems to be widespread -  I've found
that the original early to mid 90s Ne2K chip, the NS8390D, the Netgear
FA311/FA312 chip, the NS83815 and the SMC Epic/100 chip all have
specific individual register values for those three types of addresses.

Regards,
Mark.
-
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