netdev - Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's 802.11f in their FullMAC fw

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]

Date:   Tue, 13 Mar 2018 07:23:31 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Linus Lüssing <linus.luessing@...3.blue>,
        Felix Fietkau <nbd@....name>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Wright Feng <wright.feng@...ress.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
        Network Development <netdev@...r.kernel.org>,
        bridge@...ts.linux-foundation.org, linux-wireless@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com, brcm80211-dev-list@...ress.com
Subject: Re: Problem with bridge (mcast-to-ucast + hairpin) and Broadcom's
 802.11f in their FullMAC fw

On 03/13/2018 12:01 AM, Stephen Hemminger wrote:
> On Mon, 12 Mar 2018 23:42:48 +0100
> Rafał Miłecki <zajec5@...il.com> wrote:
>
>> 2) Blame bridge + mcast-to-ucast + hairpin for 802.11f incompatibility
>>
>> If we agree that 802.11f support in FullMAC firmware is acceptable, then
>> we have to make sure Linux's bridge doesn't break it by passing 802.11f
>> (broadcast) frames back to the source interface. That would require a
>> check like in below diff + proper code for handling such packets. I'm
>> afraid I'm not familiar with bridge code enough to complete that.
>>
>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>> index edae702..9e5d6ea 100644
>> --- a/net/bridge/br_input.c
>> +++ b/net/bridge/br_input.c
>> @@ -126,6 +126,27 @@ static void br_do_proxy_arp(struct sk_buff *skb, struct net_bridge *br,
>>   	}
>>   }
>>
>> +static bool br_skb_is_iapp_add_packet(struct sk_buff *skb)
>> +{
>> +	const u8 iapp_add_packet[6] __aligned(2) = {
>> +		0x00, 0x01, 0xaf, 0x81, 0x01, 0x00,
>> +	};
>> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
>> +	const u16 *a = (const u16 *)skb->data;
>> +	const u16 *b = (const u16 *)iapp_add_packet;
>> +#endif
>> +
>> +	if (skb->len != 6)
>> +		return false;
>> +
>> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
>> +	return !(((*(const u32 *)skb->data) ^ (*(const u32 *)iapp_add_packet)) |
>> +	         ((*(const u16 *)(skb->data + 4)) ^ (*(const u16 *)(iapp_add_packet + 4))));
>> +#else
>> +	return !((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2]));
>> +#endif
>> +}
>> +
>>   /* note: already called with rcu_read_lock */
>>   int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb)
>>   {
>> @@ -155,6 +176,8 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
>>   	if (is_multicast_ether_addr(dest)) {
>>   		/* by definition the broadcast is also a multicast address */
>>   		if (is_broadcast_ether_addr(dest)) {
>> +			if (br_skb_is_iapp_add_packet(skb))
>> +				pr_warn("This packet should not be passed back to the source interface!\n");
>>   			pkt_type = BR_PKT_BROADCAST;
>>   			local_rcv = true;
>>   		} else {
>
>
> Don't like bridge doing special case code for magic received values directly in input path.
> Really needs to be generic which is why I suggested ebtables.

We need in-bridge solution only if we decide to support FullMAC
firmwares with 802.11f implementation.

In that case is this possible to use ebtables as a workaround at all?
Can I really use ebtables to set switch to don't pass 802.11f ADD frames
back to the original interface?