linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: David Miller <davem@davemloft.net>
Cc: ja@ssi.bg, linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast
Date: Thu, 20 Nov 2014 22:31:14 +0100	[thread overview]
Message-ID: <1416519074.8557.15.camel@sipsolutions.net> (raw)
In-Reply-To: <20140822.105405.1982870131653082781.davem@davemloft.net>

On Fri, 2014-08-22 at 10:54 -0700, David Miller wrote:

> >>  	if (res.type == RTN_BROADCAST)
> >>  		goto brd_input;
> > 
> > 	Is this place better, after checking for RTN_BROADCAST?
> > 
> > 	/* ARP link-layer broadcasts are acceptable here */
> > 	if ((skb->pkt_type == PACKET_BROADCAST ||
> > 	     skb->pkt_type == PACKET_MULTICAST) &&
> > 	    skb->protocol == htons(ETH_P_IP))
> > 		goto e_inval;
> 
> Indeed, this would make ARP happier, but that still leaves open the
> issue of CLUSTERIP.

I'm back looking at this, but must admit I'm completely confused now :-)

I could add an IPv4 sysctl to control this behaviour:
  0 - off
  1 - RFC 1122 "SHOULD"
  2 - also drop unicast-in-multicast (for wireless)

But I guess due to cluster-IP it would have to default to 0.


However, talk about ip_local_deliver_finish() in this thread has me
wondering if we could just implement it using iptables? I guess
ipt_addrtype and ip6t_addrtype would let me do that?

johannes



  parent reply	other threads:[~2014-11-20 21:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21 17:22 [RFC] net: ipv4: drop unicast encapsulated in L2 multicast Johannes Berg
2014-08-21 17:32 ` Johannes Berg
2014-08-27  7:38   ` Hannes Frederic Sowa
2014-08-27  9:05     ` Johannes Berg
2014-08-27  9:53       ` Hannes Frederic Sowa
2014-09-02  9:36         ` Johannes Berg
2014-09-03  1:59           ` YOSHIFUJI Hideaki
2014-09-02 22:03             ` David Miller
2014-09-03 12:01               ` Hannes Frederic Sowa
2014-08-21 19:51 ` Julian Anastasov
2014-08-22 17:54   ` David Miller
2014-08-27  9:13     ` Johannes Berg
2014-08-27 10:23       ` Julian Anastasov
2014-08-27 11:29         ` Johannes Berg
2014-08-27 14:31           ` Julian Anastasov
2014-09-02  9:33             ` Johannes Berg
2014-11-20 21:31     ` Johannes Berg [this message]
2014-09-02 21:16 ` Stephen Hemminger
2014-09-03  9:40   ` Johannes Berg

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=1416519074.8557.15.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=davem@davemloft.net \
    --cc=ja@ssi.bg \
    --cc=linux-wireless@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).