Re: ICMPv6 Redirects

[Alexander Aring <alex.aring@gmail.com>]

On Mon, Sep 29, 2014 at 01:23:57PM +0200, Alexander Aring wrote:
> On Mon, Sep 29, 2014 at 01:13:25PM +0200, Alexander Aring wrote:
> > Hi,
> > 
> > On Mon, Sep 29, 2014 at 11:20:41AM +0100, Simon Vincent wrote:
> > > Currently there does not seem to be any filtering in the mac layer anyway.
> > > In wpan.c mac802154_subif_frame we check the pan id and dest address but we
> > > don't discard any packets. Should we be discarding packets at this point?
> > > For example packets of type PACKET_OTHERHOST.
> > > 
> > > If I discard all PACKET_OTHERHOST in mac802154_subif_frame it solves my
> > > problem. I just don't know if this will effect anything else.
> > > 
> > 
> > Please see [0]. IPv6 will drop all PACKET_OTHERHOST. Maybe this
> > information is gone by some new skb_alloc's. Simon can you check this?
> > 
> > Simple add some printk before deliver to IPv6 layer.
> > 
> > And no, we don't make this at mac802154 layer.
> > 
> 
> Maybe we should do this in 6LoWPAN Layer. Means a:
> 
> if (skb->pkt_type == PACKET_OTHERHOST) {
> 	kfree_skb(skb);
> 	return NET_RX_DROP;
> }
> 
> in lowpan_rcv [0] function. I am not 100% sure right now, but I think it's
> better than we don't parse any OTHERHOST frames in 6LoWPAN packet layer.
> 
> But this is another issue...
> 
> - Alex
> 
> [0] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan_rtnl.c#L456

cc: jukka.rissanen@linux.intel.com 

here, this could be also useful for bluetooth 6LoWPAN.

- Alex