[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.11.1408271255230.2348@ja.home.ssi.bg>
Date: Wed, 27 Aug 2014 13:23:17 +0300 (EEST)
From: Julian Anastasov <ja@....bg>
To: Johannes Berg <johannes@...solutions.net>
cc: David Miller <davem@...emloft.net>, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast
Hello,
On Wed, 27 Aug 2014, Johannes Berg wrote:
> On Fri, 2014-08-22 at 10:54 -0700, David Miller wrote:
>
> > > 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.
>
> Unfortunately, I have no idea how to determine that CLUSTERIP is active
> here? Do we need to tag frames, or would a sysctl work?
>
> Or should we go back to the drawing board and not make this change in
> the IP stack at all? But parsing all the IP layer in the wireless stack
> is really quite ugly as well.
CLUSTERIP works in LOCAL_IN. My preference is to
add checks in every protocol where it is missing but if
you prefer a global check, ip_local_deliver_finish() is
a good place: CLUSTERIP already changed pkt_type to
PACKET_HOST. For example:
if (!(skb_rtable(skb)->rt_flags &
(RTCF_BROADCAST | RTCF_MULTICAST)) &&
(skb->pkt_type == PACKET_BROADCAST ||
skb->pkt_type == PACKET_MULTICAST)) {
kfree_skb(skb);
return;
}
By this way we protect the local stack globally.
BTW, what kind of packets (protocol) we want to drop? UDP?
As for ip_forward(), there is already check for
PACKET_HOST.
Not sure, may be a MIB counter for such drops
would be useful.
Regards
--
Julian Anastasov <ja@....bg>
--
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