netdev - Re: [PATCH v2 1/3] bridge: Base the BR_PROXYARP decision on the target port flag

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] [day] [month] [year] [list]

Message-ID: <20150209195401.GA18065@jouni.qca.qualcomm.com>
Date:	Mon, 9 Feb 2015 21:54:01 +0200
From:	Jouni Malinen <jouni@...eaurora.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, kyeyoonp@...eaurora.org
Subject: Re: [PATCH v2 1/3] bridge: Base the BR_PROXYARP decision on the
 target port flag

On Sat, Feb 07, 2015 at 09:59:22PM -0800, David Miller wrote:
> From: Jouni Malinen <jouni@...eaurora.org>
> > When doing proxy ARP, instead of checking the bridge port flag for
> > BR_PROXYARP on the bridge port on which the frame was received, check
> > the bridge port flag of the bridge port to which the target device
> > belongs.
> 
> This is a semantic change, what if the administrator wanted the
> current behavior?
> 
> I'm not applying this.  If you want the new behavior, it will have
> to be at a minimum turned on via a sysctl that defaults to OFF.

Agreed, this does change the semantics of the commit 958501163ddd
("bridge: Add support for IEEE 802.11 Proxy ARP"). However, I see this
as a bug fix rather than new behavior. In other words, this set of three
patches came up from extended testing coverage and issues found during
implementation of automated protocol tests. Taken into account that this
BR_PROXYARP functionality was added recently and I'm not aware of a use
case that would use the current design, I was hoping to avoid the added
complexity of configuration parameters for something that I do not
expect to be needed.

This IEEE 802.11 Proxy ARP functionality is still work in progress in
the sense that the IPv6 patch has not yet been contributed (RFC version
would be ready, but I'm waiting for the IPv4 side to get fully
completed).

If a configuration parameter is required for this, what would the
preferred way of adding it in net/bridge? It looks like only
br_netfilter.c is currently using sysctl. Would netlink with another
BRPORT_ATTR_FLAG similarly to BR_PROXYARP be a suitable alternative?

-- 
Jouni Malinen                                            PGP id EFC895FA
--
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