All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: IPv4 multicast and mac-vlans acting weird on 3.0.4+
Date: Wed, 05 Oct 2011 15:35:07 -0700	[thread overview]
Message-ID: <4E8CDB9B.6010900@candelatech.com> (raw)
In-Reply-To: <4E8CD180.5010905@candelatech.com>

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

  reply	other threads:[~2011-10-05 22:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05 16:46 IPv4 multicast and mac-vlans acting weird on 3.0.4+ Ben Greear
2011-10-05 19:54 ` Eric Dumazet
2011-10-05 20:09   ` Ben Greear
2011-10-05 20:17     ` Eric Dumazet
2011-10-05 20:19       ` Ben Greear
2011-10-05 20:31         ` Eric Dumazet
2011-10-05 20:56           ` Ben Greear
2011-10-05 21:36             ` Eric Dumazet
2011-10-05 21:52               ` Ben Greear
2011-10-05 22:35                 ` Ben Greear [this message]
2011-10-06 20:28                   ` [PATCH net-next] macvlan: handle fragmented multicast frames Eric Dumazet
2011-10-07 16:44                     ` Ben Greear
2011-10-10 16:27                     ` Ben Greear
2011-10-10 16:41                       ` Eric Dumazet
2011-10-10 16:53                         ` Ben Greear
2011-10-19  3:22                     ` David Miller
2011-10-06 20:42               ` IPv4 multicast and mac-vlans acting weird on 3.0.4+ Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E8CDB9B.6010900@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.