netdev - Re: IPv4 multicast and mac-vlans acting weird on 3.0.4+

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: <4E8CDB9B.6010900@candelatech.com>
Date:	Wed, 05 Oct 2011 15:35:07 -0700
From:	Ben Greear <greearb@...delatech.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: IPv4 multicast and mac-vlans acting weird on 3.0.4+

On 10/05/2011 02:52 PM, Ben Greear wrote:
> On 10/05/2011 02:36 PM, Eric Dumazet wrote:
>> Le mercredi 05 octobre 2011 à 13:56 -0700, Ben Greear a écrit :
>>
>>> Wouldn't you have the same problem with two real Ethernet interfaces on
>>> the same LAN, or two 802.1Q devices for that matter? The addrs will all
>>> be the same in that case too?
>>>
>>
>> Usually multicast is coupled with routing.
>>
>> A JOIN message from your app wont be sent on all interfaces...
>
> It will be if you open two sockets and bind each one of them
> to a network device, at least as far as I can tell.
>
>>
>> But yes, we might have a similar issue with regular vlans.
>>
>> Probably nobody noticed yet. Just say no to fragments :)
>
> Heh, it's regression testing time..we're trying all the weird
> stuff this week :)
>
>>> Also, if I have just a single mac-vlan active (the other 3 are 'ifconfig foo down'),
>>> I still see the problem with mcast.
>>>
>>
>> Thats another bug : macvlan doesnt test IFF_UP on broadcasts, only for
>> unicast messages. Please test following patch.
>>
>>> From what you describe, I am thinking I may be hitting a different
>>> issue. Any ideas on how to figure out why exactly the NF_HOOK isn't
>>> calling the ip_rcv_finish method?
>>>
>>
>> Really I believe I tried to explain the thing already...
>>
>> ip_local_deliver() -> ip_defrag() :
>
> It seems that netfilter is reporting the pkt as NF_STOLEN, probably
> because of the nf_ct_ipv4_gather_frags (which ends up calling ip_defrag)
> logic in nf_defrag_ipv4.c, line 86 or so. I'm adding more debugging
> to verify this.

Ok, this is definitely the problem.  Also, even if you have a single
mac-vlan, you will still have this problem because the underlying device
will get a copy first.  So, your patch doesn't solve my particular problem,
but it does appear to be correct.

If someone wants to cook up macvlan-ip-defrag patch I'll be happy
to test it.  But, as far as I can tell, this problem can happen on
any two interfaces.  The reason that some of mine work (.1q vlans)
and macvlan didn't is probably because those were separated by
some virtual network links that imparted extra delay...so the
vlan consumed all its fragments and passed the complete pkt up
the stack before the mac-vlan ever saw the initial frame.

With this in mind, it seems that using multiple udp multicast
sockets bound to specific devices is fundamentally broken for
fragmented packets.

I have no pressing need for this feature, so now that I better understand
the problem I can just document it and move on to other things.

Thanks for all the help.

Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

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