[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1428922636.2355.7.camel@sipsolutions.net>
Date: Mon, 13 Apr 2015 12:57:16 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Julian Anastasov <ja@....bg>
Cc: netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
matti.gottlieb@...el.com
Subject: Re: [PATCH 1/4] ipv4: add option to drop unicast encapsulated in L2
multicast
Hi Julian,
> > Hm. I didn't see this in my testing so far, but I only enable this
> > temporarily, so perhaps by that time it was already done.
>
> I didn't tested it myself, may be you can try:
>
> other_host_on_LAN# arp -d patched_box
> other_host_on_LAN# arping -c 1 -I eth0 patched_box
>
> There must be reply for broadcast requests.
Sure; I would have expected this to have broken my network but as I
said, it was only enabled temporarily.
> > On the other hand, there's not all that much reason not to put this into
> > ip_rcv_finish(), we already touch the rt->rt_type there for MIB
> > counters. I'll look into that.
>
> May be in ip_local_deliver_finish because:
>
> - ip_forward() already has PACKET_HOST check.
>
> - for broadcast/multicast dests we do not care
>
> - CLUSTERIP works in LOCAL_IN (after ip_rcv_finish), LOCAL_IN
> is here: ip_rcv_finish->dst_input->ip_local_deliver->
> ip_local_deliver_finish
It's just that the later this is, the more nervous I get about it being
really effective. :)
I'm willing to discount the CLUSTERIP case, it seems insane to want to
run CLUSTERIP over wifi on a network that explicitly limits multicast.
Other than that, do you see any reason for not putting it in
ip_rcv_finish()?
johannes
--
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
Powered by blists - more mailing lists