ICMPv6 Redirects

ICMPv6 Redirects

[Simon Vincent]

I have three nodes running linux all running in promiscuous mode with 
ipv6 forwarding enabled. The kernel is built from wpan-next. The three 
nodes are all connected directly using 802.15.4.

Node A: fe80::203:9a00:0:a
Node B: fe80::203:9a00:0:b
Node C: fe80::203:9a00:0:c

If from node A I ping node B I get ICMP redirects from node C. Node C 
also forwards the packet to node B so node B receives the ping request 
twice.

If I try a similar setup using ethernet instead of 802.15.4 I do not get 
this problem.

Has anyone else seen this?

Simon

Re: ICMPv6 Redirects

[Alexander Aring]

Hi Simon,

On Fri, Sep 26, 2014 at 04:16:02PM +0100, Simon Vincent wrote:
> I have three nodes running linux all running in promiscuous mode with ipv6

Sorry I need to ask here, why it's in promiscuous mode? It's still
(mainline) a WPAN device? I don't know right now what changes you did
because at mainline state we don't have any support for running any
device into promiscuous mode.

> forwarding enabled. The kernel is built from wpan-next. The three nodes are
> all connected directly using 802.15.4.
> 
> Node A: fe80::203:9a00:0:a
> Node B: fe80::203:9a00:0:b
> Node C: fe80::203:9a00:0:c
> 
> If from node A I ping node B I get ICMP redirects from node C. Node C also
> forwards the packet to node B so node B receives the ping request twice.
> 

I have also 3 nodes here, maybe I can reproduce this scenario to help
there. Can you give me some setup steps for this?

> If I try a similar setup using ethernet instead of 802.15.4 I do not get
> this problem.
> 
> Has anyone else seen this?
> 

No, I am still try to get some basic features working which should work. :-)

- Alex

Re: ICMPv6 Redirects

[Simon Vincent]

I think we need to add some filtering so we don't process packets 
addressed to other nodes, just pass them to the promiscuous mode buffer. 
I will have a look next week at a fix.

On 26/09/14 16:35, Alexander Aring wrote:
> Hi Simon,
>
> On Fri, Sep 26, 2014 at 04:16:02PM +0100, Simon Vincent wrote:
>> I have three nodes running linux all running in promiscuous mode with ipv6
> Sorry I need to ask here, why it's in promiscuous mode? It's still
> (mainline) a WPAN device? I don't know right now what changes you did
> because at mainline state we don't have any support for running any
> device into promiscuous mode.
>
It is in promiscuous mode as the hardware does not support address 
filtering yet...
>> forwarding enabled. The kernel is built from wpan-next. The three nodes are
>> all connected directly using 802.15.4.
>>
>> Node A: fe80::203:9a00:0:a
>> Node B: fe80::203:9a00:0:b
>> Node C: fe80::203:9a00:0:c
>>
>> If from node A I ping node B I get ICMP redirects from node C. Node C also
>> forwards the packet to node B so node B receives the ping request twice.
>>
> I have also 3 nodes here, maybe I can reproduce this scenario to help
> there. Can you give me some setup steps for this?
Just setup any three nodes so they can all see each other and setup a 
wireshark sniffer.
Enable ipv6 forwarding by:
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
I guess you will also have to hack your hardware driver to put your 
hardware in promiscuous mode.

Then just do a simple ping from one node to another using link local 
addresses.
>> If I try a similar setup using ethernet instead of 802.15.4 I do not get
>> this problem.
>>
>> Has anyone else seen this?
>>
> No, I am still try to get some basic features working which should work. :-)
>
> - Alex

Re: ICMPv6 Redirects

[Alexander Aring]

Hi Simon,

On Fri, Sep 26, 2014 at 05:26:20PM +0100, Simon Vincent wrote:
> I think we need to add some filtering so we don't process packets addressed
> to other nodes, just pass them to the promiscuous mode buffer. I will have a
> look next week at a fix.
> 

yes, but by handling of mac802154 you activate a filter -> no promiscuous mode.
In 802.15.4 promiscuous mode you don't have any stack handling involved.

The requirement to offer a promiscuous mode is no doing filtering at phy
level. After this no mac802154 handling is involved, if mac802154 is
invloded means you doing filtering.

802.15.4-2011 describes to promiscuous mode:

"When in promiscuous mode, the MAC sublayer shall process received frames according to 5.1.6.2 and
pass all frames correctly received to the next higher layer using the MCPS-DATA.indication primitive. The
source and destination addressing mode parameters shall each be set to 0x00, the MSDU parameter shall
contain the MHR concatenated with the MAC payload, as illustrated in Figure 35, and the msduLength
parameter shall contain the total number of octets in the MHR concatenated with the MAC payload. The
mpduLinkQuality parameter shall be valid."

Section 5.1.6.2 describes mainly the filtering when mac pib value
macPromiscuousMode is set to FALSE. Means when TRUE -> not doing any
filtering according section 5.1.6.2

There is no much text about promiscuous mode in 802.15.4 I also see that
the at86rf231 disable ACK handling there, this means that the
promiscuous mode will never send ack's if the phy get frames which
matching on hardware address filters. Also the address filters should be
set to short_addr -> 0xffff, pan_id -> 0xffff which are the mac pib default
parameters. These are all indicators that it's only in receiving mode
the packets should not handled by mac802154 layer.

Sending frames is another question, I think you probably can do that,
but only on some 802.15.4 RAW sockets, that you can build your own mac
header in userspace. You can't interact in the network, but sending
frames to make some chaos in the network should work. Maybe for testing
use case or other crazy stuff.

What you have is only the a poor phy without filtering features. That's
the requirement for running in promiscuous, but when mac802154 is
involved it's not promiscuous mode. I have the option at at86rf231 to
set it in promiscuous mode and do other settings like "enable ack
handling and setting hw filtering (NOT for FILTERing frames, just for
AACK handling stuff) then I have that what you have but it isn't exactly
promiscuous mode according 802.15.4.

Now I confusing all people now, but currently this is my point of view. :-)

> On 26/09/14 16:35, Alexander Aring wrote:
> >Hi Simon,
> >
> >On Fri, Sep 26, 2014 at 04:16:02PM +0100, Simon Vincent wrote:
> >>I have three nodes running linux all running in promiscuous mode with ipv6
> >Sorry I need to ask here, why it's in promiscuous mode? It's still
> >(mainline) a WPAN device? I don't know right now what changes you did
> >because at mainline state we don't have any support for running any
> >device into promiscuous mode.
> >
> It is in promiscuous mode as the hardware does not support address filtering
> yet...
> >>forwarding enabled. The kernel is built from wpan-next. The three nodes are
> >>all connected directly using 802.15.4.
> >>
> >>Node A: fe80::203:9a00:0:a
> >>Node B: fe80::203:9a00:0:b
> >>Node C: fe80::203:9a00:0:c
> >>
> >>If from node A I ping node B I get ICMP redirects from node C. Node C also
> >>forwards the packet to node B so node B receives the ping request twice.
> >>
> >I have also 3 nodes here, maybe I can reproduce this scenario to help
> >there. Can you give me some setup steps for this?
> Just setup any three nodes so they can all see each other and setup a
> wireshark sniffer.
> Enable ipv6 forwarding by:
> echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
> I guess you will also have to hack your hardware driver to put your hardware
> in promiscuous mode.
> 
> Then just do a simple ping from one node to another using link local
> addresses.

ok, I will see if I can reproduce this. Thanks.

- Alex

Re: ICMPv6 Redirects

[Simon Vincent]

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.


On 27/09/14 02:42, Alexander Aring wrote:
> all p

Re: ICMPv6 Redirects

[Varka Bhadram]

Simon,

On 09/29/2014 03:50 PM, 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.
>
I think we are not supposed to discard the packets like this. This will
create the problems if routing enabled on the node.

This not problem with the IEEE-802.15.4 driver or MAC implementation.

These issues related to IPv6/ICMPv6 (ECHO request and ECHO reply). Here RFC2461/RFC4861 will
come into picture. see:http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-3/freebsd71.router/nd.p2/

Can you explain the setup..? What h/w you are using. How the network connected..?

-- 
Thanks and Regards,
Varka Bhadram.

Re: ICMPv6 Redirects

[Simon Vincent]

On 29/09/14 11:58, Varka Bhadram wrote:
> Simon,
>
> On 09/29/2014 03:50 PM, 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.
>>
> I think we are not supposed to discard the packets like this. This will
> create the problems if routing enabled on the node.
>
> This not problem with the IEEE-802.15.4 driver or MAC implementation.
>
> These issues related to IPv6/ICMPv6 (ECHO request and ECHO reply). 
> Here RFC2461/RFC4861 will
> come into picture. 
> see:http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-3/freebsd71.router/nd.p2/
>
> Can you explain the setup..? What h/w you are using. How the network 
> connected..?
>
I am running three nodes all directly connected to each other via 
powerline networking running 802.15.4.
Therefore all nodes can see all the traffic. The nodes are setup with 
ipv6 forwarding enabled.
If I ping node A from node B node C sends ICMP redirects.

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 05:15:51PM +0530, Varka Bhadram wrote:
> On 09/29/2014 05:05 PM, Varka Bhadram wrote:
> >On 09/29/2014 04:39 PM, Simon Vincent wrote:
> >>
> >>On 29/09/14 11:58, Varka Bhadram wrote:
> >>>Simon,
> >>>
> >>>On 09/29/2014 03:50 PM, 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.
> >>>>
> >>>I think we are not supposed to discard the packets like this. This will
> >>>create the problems if routing enabled on the node.
> >>>
> >>>This not problem with the IEEE-802.15.4 driver or MAC implementation.
> >>>
> >>>These issues related to IPv6/ICMPv6 (ECHO request and ECHO reply).
> >>>Here RFC2461/RFC4861 will
> >>>come into picture. see:http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-3/freebsd71.router/nd.p2/
> >>>
> >>>Can you explain the setup..? What h/w you are using. How the network
> >>>connected..?
> >>>
> >>I am running three nodes all directly connected to each other via
> >>powerline networking running 802.15.4.
> >>Therefore all nodes can see all the traffic. The nodes are setup with
> >>ipv6 forwarding enabled.
> >>If I ping node A from node B node C sends ICMP redirects.
> >Please add:
> >
> >net.ipv6.conf.all.accept_redirects = 1
> >net.ipv6.conf.all.send_redirects = 1
> >
> >to your//etc/sysctl.conf/  file.. It will disable redirect..
> >
> >Try this . I hope it will work.
> 
> Sorry for the wrong info...
> 
> Set up accept_redirects/send_redirects to boolean value '0'
> 
> echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
> 

don't know but I think this is only if we send or accept the route
ICMPv6 messages. You only configure some filtering if you get these
ICMPv6 messages or not, or if you send these ICMPv6 messages.

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 01:53:51PM +0200, Alexander Aring wrote:
> On Mon, Sep 29, 2014 at 05:15:51PM +0530, Varka Bhadram wrote:
> > On 09/29/2014 05:05 PM, Varka Bhadram wrote:
> > >On 09/29/2014 04:39 PM, Simon Vincent wrote:
> > >>
> > >>On 29/09/14 11:58, Varka Bhadram wrote:
> > >>>Simon,
> > >>>
> > >>>On 09/29/2014 03:50 PM, 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.
> > >>>>
> > >>>I think we are not supposed to discard the packets like this. This will
> > >>>create the problems if routing enabled on the node.
> > >>>
> > >>>This not problem with the IEEE-802.15.4 driver or MAC implementation.
> > >>>
> > >>>These issues related to IPv6/ICMPv6 (ECHO request and ECHO reply).
> > >>>Here RFC2461/RFC4861 will
> > >>>come into picture. see:http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-3/freebsd71.router/nd.p2/
> > >>>
> > >>>Can you explain the setup..? What h/w you are using. How the network
> > >>>connected..?
> > >>>
> > >>I am running three nodes all directly connected to each other via
> > >>powerline networking running 802.15.4.
> > >>Therefore all nodes can see all the traffic. The nodes are setup with
> > >>ipv6 forwarding enabled.
> > >>If I ping node A from node B node C sends ICMP redirects.
> > >Please add:
> > >
> > >net.ipv6.conf.all.accept_redirects = 1
> > >net.ipv6.conf.all.send_redirects = 1
> > >
> > >to your//etc/sysctl.conf/  file.. It will disable redirect..
> > >
> > >Try this . I hope it will work.
> > 
> > Sorry for the wrong info...
> > 
> > Set up accept_redirects/send_redirects to boolean value '0'
> > 
> > echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
> > 
> 
> don't know but I think this is only if we send or accept the route
> ICMPv6 messages. You only configure some filtering if you get these
> ICMPv6 messages or not, or if you send these ICMPv6 messages.
> 

ah yes and this also make handling of these ICMPv6 messages or not.

But Simon, did some dropping of skb's when these are PACKET_OTHERHOST,
and then it works for him. So this should some other issues, because
IPv6 should drop all sk_buff's which are PACKET_OTHERHOST.

Which should be the same like dropping PACKET_OTHERHOST in mac802154.

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 05:29:42PM +0530, Varka Bhadram wrote:
> On 09/29/2014 05:27 PM, Alexander Aring wrote:
> >On Mon, Sep 29, 2014 at 01:53:51PM +0200, Alexander Aring wrote:
> >>On Mon, Sep 29, 2014 at 05:15:51PM +0530, Varka Bhadram wrote:
> >>>On 09/29/2014 05:05 PM, Varka Bhadram wrote:
> >>>>On 09/29/2014 04:39 PM, Simon Vincent wrote:
> >>>>>On 29/09/14 11:58, Varka Bhadram wrote:
> >>>>>>Simon,
> >>>>>>
> >>>>>>On 09/29/2014 03:50 PM, 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.
> >>>>>>>
> >>>>>>I think we are not supposed to discard the packets like this. This will
> >>>>>>create the problems if routing enabled on the node.
> >>>>>>
> >>>>>>This not problem with the IEEE-802.15.4 driver or MAC implementation.
> >>>>>>
> >>>>>>These issues related to IPv6/ICMPv6 (ECHO request and ECHO reply).
> >>>>>>Here RFC2461/RFC4861 will
> >>>>>>come into picture. see:http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-3/freebsd71.router/nd.p2/
> >>>>>>
> >>>>>>Can you explain the setup..? What h/w you are using. How the network
> >>>>>>connected..?
> >>>>>>
> >>>>>I am running three nodes all directly connected to each other via
> >>>>>powerline networking running 802.15.4.
> >>>>>Therefore all nodes can see all the traffic. The nodes are setup with
> >>>>>ipv6 forwarding enabled.
> >>>>>If I ping node A from node B node C sends ICMP redirects.
> >>>>Please add:
> >>>>
> >>>>net.ipv6.conf.all.accept_redirects = 1
> >>>>net.ipv6.conf.all.send_redirects = 1
> >>>>
> >>>>to your//etc/sysctl.conf/  file.. It will disable redirect..
> >>>>
> >>>>Try this . I hope it will work.
> >>>Sorry for the wrong info...
> >>>
> >>>Set up accept_redirects/send_redirects to boolean value '0'
> >>>
> >>>echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
> >>>
> >>don't know but I think this is only if we send or accept the route
> >>ICMPv6 messages. You only configure some filtering if you get these
> >>ICMPv6 messages or not, or if you send these ICMPv6 messages.
> >>
> >ah yes and this also make handling of these ICMPv6 messages or not.
> >
> >But Simon, did some dropping of skb's when these are PACKET_OTHERHOST,
> >and then it works for him. So this should some other issues, because
> >IPv6 should drop all sk_buff's which are PACKET_OTHERHOST.
> >
> >Which should be the same like dropping PACKET_OTHERHOST in mac802154.
> >
> >- Alex
> 
> Please see:*http://lxr.free-electrons.com/source/net/ieee802154/af_ieee802154.c?v=2.6.34#L319*
> 
> If packet type is PACKET_OTHERHOST its dropping, isn't it..?

Yep that's why dropping PACKET_OTHERHOST is handled by next layer. Not
mac802154. We have as next layer 6LoWPAN and af_ieee802154.

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 05:39:11PM +0530, Varka Bhadram wrote:
> On 09/29/2014 05:29 PM, Varka Bhadram wrote:
> >On 09/29/2014 05:27 PM, Alexander Aring wrote:
> >>On Mon, Sep 29, 2014 at 01:53:51PM +0200, Alexander Aring wrote:
> >>>On Mon, Sep 29, 2014 at 05:15:51PM +0530, Varka Bhadram wrote:
> >>>>On 09/29/2014 05:05 PM, Varka Bhadram wrote:
> >>>>>On 09/29/2014 04:39 PM, Simon Vincent wrote:
> >>>>>>On 29/09/14 11:58, Varka Bhadram wrote:
> >>>>>>>Simon,
> >>>>>>>
> >>>>>>>On 09/29/2014 03:50 PM, 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.
> >>>>>>>>
> >>>>>>>I think we are not supposed to discard the packets like this. This will
> >>>>>>>create the problems if routing enabled on the node.
> >>>>>>>
> >>>>>>>This not problem with the IEEE-802.15.4 driver or MAC implementation.
> >>>>>>>
> >>>>>>>These issues related to IPv6/ICMPv6 (ECHO request and ECHO reply).
> >>>>>>>Here RFC2461/RFC4861 will
> >>>>>>>come into picture. see:http://www.tahi.org/logo/phase2-core/result/Self_Test_4-0-3/freebsd71.router/nd.p2/
> >>>>>>>
> >>>>>>>Can you explain the setup..? What h/w you are using. How the network
> >>>>>>>connected..?
> >>>>>>>
> >>>>>>I am running three nodes all directly connected to each other via
> >>>>>>powerline networking running 802.15.4.
> >>>>>>Therefore all nodes can see all the traffic. The nodes are setup with
> >>>>>>ipv6 forwarding enabled.
> >>>>>>If I ping node A from node B node C sends ICMP redirects.
> >>>>>Please add:
> >>>>>
> >>>>>net.ipv6.conf.all.accept_redirects = 1
> >>>>>net.ipv6.conf.all.send_redirects = 1
> >>>>>
> >>>>>to your//etc/sysctl.conf/  file.. It will disable redirect..
> >>>>>
> >>>>>Try this . I hope it will work.
> >>>>Sorry for the wrong info...
> >>>>
> >>>>Set up accept_redirects/send_redirects to boolean value '0'
> >>>>
> >>>>echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
> >>>>
> >>>don't know but I think this is only if we send or accept the route
> >>>ICMPv6 messages. You only configure some filtering if you get these
> >>>ICMPv6 messages or not, or if you send these ICMPv6 messages.
> >>>
> >>ah yes and this also make handling of these ICMPv6 messages or not.
> >>
> >>But Simon, did some dropping of skb's when these are PACKET_OTHERHOST,
> >>and then it works for him. So this should some other issues, because
> >>IPv6 should drop all sk_buff's which are PACKET_OTHERHOST.
> >>
> >>Which should be the same like dropping PACKET_OTHERHOST in mac802154.
> >>
> >>- Alex
> >Please see:*http://lxr.free-electrons.com/source/net/ieee802154/af_ieee802154.c?v=2.6.34#L319*
> >If packet type is PACKET_OTHERHOST its dropping, isn't it..?
> 
> The packet type assign value is happening here [1].
> 
> [1]:  http://lxr.free-electrons.com/source/net/mac802154/wpan.c#L420  <http://lxr.free-electrons.com/source/net/mac802154/wpan.c#L420>

yep, that's what Simon mentioned the function "mac802154_subif_frame".

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 01:49:26PM +0100, Simon Vincent wrote:
...
> >>
> >>Try this . I hope it will work.
> >Sorry for the wrong info...
> >
> >Set up accept_redirects/send_redirects to boolean value '0'
> >
> >echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
> >-- 
> I don't have a
> 
> /proc/sys/net/ipv6/conf/all/send_redirects
> 
> It looks like it is not possible to disable redirects on ipv6.

Do you have SYSFS enabled?

btw. Why we talking now about this... I think the issue is fixed by
dropping HOST_OTHERHOST in mac802154, but this handling is part of next
layer like 6LoWPAN(IPv6) or af802154.

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 03:12:00PM +0200, Alexander Aring wrote:
> On Mon, Sep 29, 2014 at 01:49:26PM +0100, Simon Vincent wrote:
> ...
> > >>
> > >>Try this . I hope it will work.
> > >Sorry for the wrong info...
> > >
> > >Set up accept_redirects/send_redirects to boolean value '0'
> > >
> > >echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
> > >-- 
> > I don't have a
> > 
> > /proc/sys/net/ipv6/conf/all/send_redirects
> > 
> > It looks like it is not possible to disable redirects on ipv6.
> 
> Do you have SYSFS enabled?
> 

Sorry I don't mean SYSFS here, something with SYS.... I mean this [0].

The CONFIG_SYSCTL.

- Alex

[0] http://lxr.free-electrons.com/source/net/ipv6/route.c#L2880

Re: ICMPv6 Redirects

[Simon Vincent]

Yes. It seems to be part of the ipv6 std that you can't disable redirects.
http://www.gossamer-threads.com/lists/nsp/ipv6/20760

On 29/09/14 14:30, Alexander Aring wrote:
> On Mon, Sep 29, 2014 at 03:12:00PM +0200, Alexander Aring wrote:
>> On Mon, Sep 29, 2014 at 01:49:26PM +0100, Simon Vincent wrote:
>> ...
>>>>> Try this . I hope it will work.
>>>> Sorry for the wrong info...
>>>>
>>>> Set up accept_redirects/send_redirects to boolean value '0'
>>>>
>>>> echo 0 > /proc/sys/net/ipv6/conf/all/accept_redirects
>>>> -- 
>>> I don't have a
>>>
>>> /proc/sys/net/ipv6/conf/all/send_redirects
>>>
>>> It looks like it is not possible to disable redirects on ipv6.
>> Do you have SYSFS enabled?
>>
> Sorry I don't mean SYSFS here, something with SYS.... I mean this [0].
>
> The CONFIG_SYSCTL.
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/ipv6/route.c#L2880

Re: ICMPv6 Redirects

[Alexander Aring]

Simon,

On Mon, Sep 29, 2014 at 02:33:29PM +0100, Simon Vincent wrote:
> Yes. It seems to be part of the ipv6 std that you can't disable redirects.
> http://www.gossamer-threads.com/lists/nsp/ipv6/20760

I don't understand now. Is your issue that you want to disable redirects
but you can't. Or something is not working because PACKET_OTHERHOST has
a wrong handling.

Your first mail shows that you have issues with PACKET_OTHERHOST and
these packets are not dropped.

Now we talk about disabling ICMPv6 redirects. All PACKET_OTHERHOST
sk_buff's should be dropped by IPv6 layer.

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 03:38:41PM +0200, Alexander Aring wrote:
> Simon,
> 
> On Mon, Sep 29, 2014 at 02:33:29PM +0100, Simon Vincent wrote:
> > Yes. It seems to be part of the ipv6 std that you can't disable redirects.
> > http://www.gossamer-threads.com/lists/nsp/ipv6/20760
> 
> I don't understand now. Is your issue that you want to disable redirects
> but you can't. Or something is not working because PACKET_OTHERHOST has
> a wrong handling.
> 
> Your first mail shows that you have issues with PACKET_OTHERHOST and
> these packets are not dropped.
> 
Sorry I didn't mean Your first mail, I mean the mail when you fixed the
issue by dropping PACKET_OTHERHOST sk_buff's at mac802154 layer.

- Alex

Re: ICMPv6 Redirects

[Simon Vincent]

Sorry for the confusion. My problem is I am receiving all packets. 
PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka 
was to disable redirects however it now seems that this is not possible 
on a ipv6 interface.

I can fix the problem by dropping PACKET_OTHERHOST in 
mac802154_subif_frame.

On 29/09/14 14:38, Alexander Aring wrote:
> Simon,
>
> On Mon, Sep 29, 2014 at 02:33:29PM +0100, Simon Vincent wrote:
>> Yes. It seems to be part of the ipv6 std that you can't disable redirects.
>> http://www.gossamer-threads.com/lists/nsp/ipv6/20760
> I don't understand now. Is your issue that you want to disable redirects
> but you can't. Or something is not working because PACKET_OTHERHOST has
> a wrong handling.
>
> Your first mail shows that you have issues with PACKET_OTHERHOST and
> these packets are not dropped.
>
> Now we talk about disabling ICMPv6 redirects. All PACKET_OTHERHOST
> sk_buff's should be dropped by IPv6 layer.
>
> - Alex

Re: ICMPv6 Redirects

[Varka Bhadram]

On Monday 29 September 2014 07:21 PM, Simon Vincent wrote:
> Sorry for the confusion. My problem is I am receiving all packets. 
> PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka 
> was to disable redirects however it now seems that this is not 
> possible on a ipv6 interface.
>
Have you seen this [1].

[1] :http://linuxpoison.blogspot.in/2010/01/how-to-disable-icmp-redirects-in-linux.html

> I can fix the problem by dropping PACKET_OTHERHOST in 
> mac802154_subif_frame.

-- 
-Varka Bhadram

Re: ICMPv6 Redirects

[Simon Vincent]

On 29/09/14 14:54, Varka Bhadram wrote:
>
> On Monday 29 September 2014 07:21 PM, Simon Vincent wrote:
>> Sorry for the confusion. My problem is I am receiving all packets. 
>> PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka 
>> was to disable redirects however it now seems that this is not 
>> possible on a ipv6 interface.
>>
> Have you seen this [1].
>
> [1] 
> :http://linuxpoison.blogspot.in/2010/01/how-to-disable-icmp-redirects-in-linux.html
>
This does not seem to work. I get an error message on boot. error: 
"net.ipv6.conf.all.send_redirects" is an unknown key

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
> Sorry for the confusion. My problem is I am receiving all packets.
> PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
> disable redirects however it now seems that this is not possible on a ipv6
> interface.
> 
> I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.

The first what IPv6 does is [0].

See my previous mail. Also that we should handle on 6LoWPAN packet
handler function for receiving "lowpan_rcv" we should do the same,
otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
in IPv6 layer, which makes no sense.

But what I see is that the current behaviour should also work.
Instrument the IPv6 delivery function and be sure that the information
about PACKET_OTHERHOST was not dropped.

- Alex

[0] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72

Re: ICMPv6 Redirects

[Varka Bhadram]

On Monday 29 September 2014 07:28 PM, Alexander Aring wrote:
> On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
>> Sorry for the confusion. My problem is I am receiving all packets.
>> PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
>> disable redirects however it now seems that this is not possible on a ipv6
>> interface.
>>
>> I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> The first what IPv6 does is [0].
>
> See my previous mail. Also that we should handle on 6LoWPAN packet
> handler function for receiving "lowpan_rcv" we should do the same,
> otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> in IPv6 layer, which makes no sense.
>
> But what I see is that the current behaviour should also work.
> Instrument the IPv6 delivery function and be sure that the information
> about PACKET_OTHERHOST was not dropped.
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72

Generally Echo reply will happen at the IP Layer. But the dropping of packet is
happening at IPv6 layer by as you mentioned above.

 From where the packet redirected we need to debug the  exact reason...?

-- 
-Varka Bhadram

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 07:35:05PM +0530, Varka Bhadram wrote:
> On Monday 29 September 2014 07:28 PM, Alexander Aring wrote:
> >On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
> >>Sorry for the confusion. My problem is I am receiving all packets.
> >>PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
> >>disable redirects however it now seems that this is not possible on a ipv6
> >>interface.
> >>
> >>I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> >The first what IPv6 does is [0].
> >
> >See my previous mail. Also that we should handle on 6LoWPAN packet
> >handler function for receiving "lowpan_rcv" we should do the same,
> >otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> >in IPv6 layer, which makes no sense.
> >
> >But what I see is that the current behaviour should also work.
> >Instrument the IPv6 delivery function and be sure that the information
> >about PACKET_OTHERHOST was not dropped.
> >
> >- Alex
> >
> >[0] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72
> 
> Generally Echo reply will happen at the IP Layer. But the dropping of packet is
> happening at IPv6 layer by as you mentioned above.
> 

IP Layer == (IPv6 || IPv4)

I don't understand what you mean. There is some code sharing between
IPv4 and IPv6 like neighbor discovery and ARP handling. Also for route
things...

- Alex

Re: ICMPv6 Redirects

[Varka Bhadram]

On Monday 29 September 2014 07:42 PM, Alexander Aring wrote:
> On Mon, Sep 29, 2014 at 07:35:05PM +0530, Varka Bhadram wrote:
>> On Monday 29 September 2014 07:28 PM, Alexander Aring wrote:
>>> On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
>>>> Sorry for the confusion. My problem is I am receiving all packets.
>>>> PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
>>>> disable redirects however it now seems that this is not possible on a ipv6
>>>> interface.
>>>>
>>>> I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
>>> The first what IPv6 does is [0].
>>>
>>> See my previous mail. Also that we should handle on 6LoWPAN packet
>>> handler function for receiving "lowpan_rcv" we should do the same,
>>> otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
>>> in IPv6 layer, which makes no sense.
>>>
>>> But what I see is that the current behaviour should also work.
>>> Instrument the IPv6 delivery function and be sure that the information
>>> about PACKET_OTHERHOST was not dropped.
>>>
>>> - Alex
>>>
>>> [0] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72
>> Generally Echo reply will happen at the IP Layer. But the dropping of packet is
>> happening at IPv6 layer by as you mentioned above.
>>
> IP Layer == (IPv6 || IPv4)
>
> I don't understand what you mean. There is some code sharing between
> IPv4 and IPv6 like neighbor discovery and ARP handling. Also for route
> things...
>
I am taking about IPv6 stuff.. We need to debug from where the redirect is happening..?

-- 
-Varka Bhadram

Re: ICMPv6 Redirects

[Alexander Aring]

Hi Varka,

On Mon, Sep 29, 2014 at 07:45:50PM +0530, Varka Bhadram wrote:
> 
> On Monday 29 September 2014 07:42 PM, Alexander Aring wrote:
> >On Mon, Sep 29, 2014 at 07:35:05PM +0530, Varka Bhadram wrote:
> >>On Monday 29 September 2014 07:28 PM, Alexander Aring wrote:
> >>>On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
> >>>>Sorry for the confusion. My problem is I am receiving all packets.
> >>>>PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
> >>>>disable redirects however it now seems that this is not possible on a ipv6
> >>>>interface.
> >>>>
> >>>>I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> >>>The first what IPv6 does is [0].
> >>>
> >>>See my previous mail. Also that we should handle on 6LoWPAN packet
> >>>handler function for receiving "lowpan_rcv" we should do the same,
> >>>otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> >>>in IPv6 layer, which makes no sense.
> >>>
> >>>But what I see is that the current behaviour should also work.
> >>>Instrument the IPv6 delivery function and be sure that the information
> >>>about PACKET_OTHERHOST was not dropped.
> >>>
> >>>- Alex
> >>>
> >>>[0] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72
> >>Generally Echo reply will happen at the IP Layer. But the dropping of packet is
> >>happening at IPv6 layer by as you mentioned above.
> >>
> >IP Layer == (IPv6 || IPv4)
> >
> >I don't understand what you mean. There is some code sharing between
> >IPv4 and IPv6 like neighbor discovery and ARP handling. Also for route
> >things...
> >
> I am taking about IPv6 stuff.. We need to debug from where the redirect is happening..?
> 

sorry, but the issue is that PACKET_OTHERHOST is not dropped by IPv6/6LoWPAN Layer.
We don't talking about ICMPv6 redirect messages now.

- Alex

Re: ICMPv6 Redirects

[Simon Vincent]

On 29/09/14 14:58, Alexander Aring wrote:
> On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
>> Sorry for the confusion. My problem is I am receiving all packets.
>> PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
>> disable redirects however it now seems that this is not possible on a ipv6
>> interface.
>>
>> I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> The first what IPv6 does is [0].
>
> See my previous mail. Also that we should handle on 6LoWPAN packet
> handler function for receiving "lowpan_rcv" we should do the same,
> otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> in IPv6 layer, which makes no sense.
>
> But what I see is that the current behaviour should also work.
> Instrument the IPv6 delivery function and be sure that the information
> about PACKET_OTHERHOST was not dropped.
I do not catch any PACKET_OTHERHOST packets in the ip6_input.c ipv6_rcv 
function.
I don't think the packets get this far. Also in the ieee802154_rcv 
function they are dropped. I will add some more debug to find where the 
redirects come from.

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 03:12:21PM +0100, Simon Vincent wrote:
> 
> On 29/09/14 14:58, Alexander Aring wrote:
> >On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
> >>Sorry for the confusion. My problem is I am receiving all packets.
> >>PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
> >>disable redirects however it now seems that this is not possible on a ipv6
> >>interface.
> >>
> >>I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> >The first what IPv6 does is [0].
> >
> >See my previous mail. Also that we should handle on 6LoWPAN packet
> >handler function for receiving "lowpan_rcv" we should do the same,
> >otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> >in IPv6 layer, which makes no sense.
> >
> >But what I see is that the current behaviour should also work.
> >Instrument the IPv6 delivery function and be sure that the information
> >about PACKET_OTHERHOST was not dropped.
> I do not catch any PACKET_OTHERHOST packets in the ip6_input.c ipv6_rcv
> function.

Can you please check these two functions:

lowpan_give_skb_to_devices -> send to IPv6 layer

and

lowpan_rcv -> getting sk_buff from mac802154

and with check I mean PACKET_OTHERHOST value. I suppose we drop the
information somewhere in the middle.

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

Simon,

On Mon, Sep 29, 2014 at 03:12:21PM +0100, Simon Vincent wrote:
> 
> On 29/09/14 14:58, Alexander Aring wrote:
> >On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
> >>Sorry for the confusion. My problem is I am receiving all packets.
> >>PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
> >>disable redirects however it now seems that this is not possible on a ipv6
> >>interface.
> >>
> >>I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> >The first what IPv6 does is [0].
> >
> >See my previous mail. Also that we should handle on 6LoWPAN packet
> >handler function for receiving "lowpan_rcv" we should do the same,
> >otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> >in IPv6 layer, which makes no sense.
> >
> >But what I see is that the current behaviour should also work.
> >Instrument the IPv6 delivery function and be sure that the information
> >about PACKET_OTHERHOST was not dropped.
> I do not catch any PACKET_OTHERHOST packets in the ip6_input.c ipv6_rcv
> function.
> I don't think the packets get this far. Also in the ieee802154_rcv function
> they are dropped. I will add some more debug to find where the redirects
> come from.

I think I have it.

Remove this line [0].

This is wrong, all packets will be PACKET_HOST then.

Try and test it again, please.

- Alex

http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/ieee802154/6lowpan_rtnl.c?id=f19f4f9525cf32f97341fac20ce66392e86a1b67#n527

Re: ICMPv6 Redirects

[Alexander Aring]

On Mon, Sep 29, 2014 at 04:39:41PM +0200, Alexander Aring wrote:
> Simon,
> 
> On Mon, Sep 29, 2014 at 03:12:21PM +0100, Simon Vincent wrote:
> > 
> > On 29/09/14 14:58, Alexander Aring wrote:
> > >On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
> > >>Sorry for the confusion. My problem is I am receiving all packets.
> > >>PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
> > >>disable redirects however it now seems that this is not possible on a ipv6
> > >>interface.
> > >>
> > >>I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> > >The first what IPv6 does is [0].
> > >
> > >See my previous mail. Also that we should handle on 6LoWPAN packet
> > >handler function for receiving "lowpan_rcv" we should do the same,
> > >otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> > >in IPv6 layer, which makes no sense.
> > >
> > >But what I see is that the current behaviour should also work.
> > >Instrument the IPv6 delivery function and be sure that the information
> > >about PACKET_OTHERHOST was not dropped.
> > I do not catch any PACKET_OTHERHOST packets in the ip6_input.c ipv6_rcv
> > function.
> > I don't think the packets get this far. Also in the ieee802154_rcv function
> > they are dropped. I will add some more debug to find where the redirects
> > come from.
> 
> I think I have it.
> 
> Remove this line [0].
> 
> This is wrong, all packets will be PACKET_HOST then.
> 
> Try and test it again, please.
> 
> - Alex
> 
> [0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/ieee802154/6lowpan_rtnl.c?id=f19f4f9525cf32f97341fac20ce66392e86a1b67#n527

Additional also remove the line [1]. :-) Ugly bug.

- Alex

[1] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/6lowpan/iphc.c?id=f19f4f9525cf32f97341fac20ce66392e86a1b67#n192

Re: ICMPv6 Redirects

[Alexander Aring]

Hi Simon,

On Mon, Sep 29, 2014 at 03:12:21PM +0100, Simon Vincent wrote:
> 
> On 29/09/14 14:58, Alexander Aring wrote:
> >On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
> >>Sorry for the confusion. My problem is I am receiving all packets.
> >>PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
> >>disable redirects however it now seems that this is not possible on a ipv6
> >>interface.
> >>
> >>I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
> >The first what IPv6 does is [0].
> >
> >See my previous mail. Also that we should handle on 6LoWPAN packet
> >handler function for receiving "lowpan_rcv" we should do the same,
> >otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
> >in IPv6 layer, which makes no sense.
> >
> >But what I see is that the current behaviour should also work.
> >Instrument the IPv6 delivery function and be sure that the information
> >about PACKET_OTHERHOST was not dropped.
> I do not catch any PACKET_OTHERHOST packets in the ip6_input.c ipv6_rcv
> function.
> I don't think the packets get this far. Also in the ieee802154_rcv function
> they are dropped. I will add some more debug to find where the redirects
> come from.

please try this:


diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index 142eef5..002cd7c 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -189,7 +189,6 @@ static int skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr,
        skb_copy_to_linear_data(new, hdr, sizeof(struct ipv6hdr));
 
        new->protocol = htons(ETH_P_IPV6);
-       new->pkt_type = PACKET_HOST;
        new->dev = dev;
 
        raw_dump_table(__func__, "raw skb data dump before receiving",
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index 4413629..820922a 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -515,6 +515,9 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
        if (!netif_running(dev))
                goto drop_skb;
 
+       if (skb->pkt_type == PACKET_OTHERHOST)
+               goto drop_skb;
+
        if (dev->type != ARPHRD_IEEE802154)
                goto drop_skb;
 
@@ -524,7 +527,6 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
        /* check that it's our buffer */
        if (skb->data[0] == LOWPAN_DISPATCH_IPV6) {
                skb->protocol = htons(ETH_P_IPV6);
-               skb->pkt_type = PACKET_HOST;
 
                /* Pull off the 1-byte of 6lowpan header. */
                skb_pull(skb, 1);



should fix the issue, somebody overwrite the pkt_type skb attribute always
with PACKET_HOST, which is wrong.

Also we can first check this in lowpan_rcv and drop the skb when it's
not belong to us.

If you want to fix this mainline please seperate it in 3 patches, one
for generic 6lowpan, other ieee802154 6lowpan and one for the check on
PACKET_OTHERHOST in lowpan_rcv.

- Alex

Re: ICMPv6 Redirects

[Simon Vincent]

I can confirm that this fixes the problem. I will create some patches 
when I get a chance.
Thanks

Simon

On 29/09/14 17:41, Alexander Aring wrote:
> Hi Simon,
>
> On Mon, Sep 29, 2014 at 03:12:21PM +0100, Simon Vincent wrote:
>> On 29/09/14 14:58, Alexander Aring wrote:
>>> On Mon, Sep 29, 2014 at 02:51:51PM +0100, Simon Vincent wrote:
>>>> Sorry for the confusion. My problem is I am receiving all packets.
>>>> PACKET_OTHERHOST does not seem to be dropped. A suggestion from Varka was to
>>>> disable redirects however it now seems that this is not possible on a ipv6
>>>> interface.
>>>>
>>>> I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.
>>> The first what IPv6 does is [0].
>>>
>>> See my previous mail. Also that we should handle on 6LoWPAN packet
>>> handler function for receiving "lowpan_rcv" we should do the same,
>>> otherwise we parsing PACKET_OTHERHOST sk_buff's and drop these directly
>>> in IPv6 layer, which makes no sense.
>>>
>>> But what I see is that the current behaviour should also work.
>>> Instrument the IPv6 delivery function and be sure that the information
>>> about PACKET_OTHERHOST was not dropped.
>> I do not catch any PACKET_OTHERHOST packets in the ip6_input.c ipv6_rcv
>> function.
>> I don't think the packets get this far. Also in the ieee802154_rcv function
>> they are dropped. I will add some more debug to find where the redirects
>> come from.
> please try this:
>
>
> diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
> index 142eef5..002cd7c 100644
> --- a/net/6lowpan/iphc.c
> +++ b/net/6lowpan/iphc.c
> @@ -189,7 +189,6 @@ static int skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr,
>          skb_copy_to_linear_data(new, hdr, sizeof(struct ipv6hdr));
>   
>          new->protocol = htons(ETH_P_IPV6);
> -       new->pkt_type = PACKET_HOST;
>          new->dev = dev;
>   
>          raw_dump_table(__func__, "raw skb data dump before receiving",
> diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
> index 4413629..820922a 100644
> --- a/net/ieee802154/6lowpan_rtnl.c
> +++ b/net/ieee802154/6lowpan_rtnl.c
> @@ -515,6 +515,9 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
>          if (!netif_running(dev))
>                  goto drop_skb;
>   
> +       if (skb->pkt_type == PACKET_OTHERHOST)
> +               goto drop_skb;
> +
>          if (dev->type != ARPHRD_IEEE802154)
>                  goto drop_skb;
>   
> @@ -524,7 +527,6 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *dev,
>          /* check that it's our buffer */
>          if (skb->data[0] == LOWPAN_DISPATCH_IPV6) {
>                  skb->protocol = htons(ETH_P_IPV6);
> -               skb->pkt_type = PACKET_HOST;
>   
>                  /* Pull off the 1-byte of 6lowpan header. */
>                  skb_pull(skb, 1);
>
>
>
> should fix the issue, somebody overwrite the pkt_type skb attribute always
> with PACKET_HOST, which is wrong.
>
> Also we can first check this in lowpan_rcv and drop the skb when it's
> not belong to us.
>
> If you want to fix this mainline please seperate it in 3 patches, one
> for generic 6lowpan, other ieee802154 6lowpan and one for the check on
> PACKET_OTHERHOST in lowpan_rcv.
>
> - Alex

Re: ICMPv6 Redirects

[Varka Bhadram]

On 09/30/2014 02:04 PM, Simon Vincent wrote:
> I can confirm that this fixes the problem. I will create some patches 
> when I get a chance.
> Thanks
>
Good to listen.. Thanks...

> Simon

-- 
Regards,
Varka Bhadram.

Re: ICMPv6 Redirects

[Alexander Aring]

On Tue, Sep 30, 2014 at 09:34:29AM +0100, Simon Vincent wrote:
> I can confirm that this fixes the problem. I will create some patches when I
> get a chance.
> Thanks
> 

This should make trouble on phy's which have no address filter...

But when IPv6 Layer look on PACKET_BROADCAST then this is also another
bug...

I did a grep:

grep -r "PACKET_BROADCAST" net/IPv6

matches on:

net/ipv6/mcast.c:	    skb->pkt_type != PACKET_BROADCAST)

whatever this is, it's also fixed by this. Because we override always
this value with PACKET_HOST.

Don't look at me, it wasn't me which introduce the setting of
PACKET_HOST. :-)

I cc Jukka here, this is also setted in 6LoWPAN GENERIC, so bluetooth is
also affected into this.

- Alex

Re: ICMPv6 Redirects

[Varka Bhadram]

Alex,

On 09/30/2014 02:09 PM, Alexander Aring wrote:
> On Tue, Sep 30, 2014 at 09:34:29AM +0100, Simon Vincent wrote:
>> I can confirm that this fixes the problem. I will create some patches when I
>> get a chance.
>> Thanks
>>
> This should make trouble on phy's which have no address filter...

I didnt get what do you mean by this..?

> But when IPv6 Layer look on PACKET_BROADCAST then this is also another
> bug...
>
> I did a grep:
>
> grep -r "PACKET_BROADCAST" net/IPv6
>
> matches on:
>
> net/ipv6/mcast.c:	    skb->pkt_type != PACKET_BROADCAST)

This match for IGMPv6...

> whatever this is, it's also fixed by this. Because we override always
> this value with PACKET_HOST.

-- 
Regards,
Varka Bhadram.

Re: ICMPv6 Redirects

[Alexander Aring]

Hi Varka,

On Tue, Sep 30, 2014 at 02:16:46PM +0530, Varka Bhadram wrote:
> Alex,
> 
> On 09/30/2014 02:09 PM, Alexander Aring wrote:
> >On Tue, Sep 30, 2014 at 09:34:29AM +0100, Simon Vincent wrote:
> >>I can confirm that this fixes the problem. I will create some patches when I
> >>get a chance.
> >>Thanks
> >>
> >This should make trouble on phy's which have no address filter...
> 
> I didnt get what do you mean by this..?
> 

The mac802154 address filter sets PACKET_BROADCAST, PACKET_HOST and
PACKET_OTHERHOST. When you have an address filter on PHY, then
PACKET_OTHERHOST should never happen (on good phy's).

So you always set PACKET_HOST xor PACKET_BROADCAST.

> >But when IPv6 Layer look on PACKET_BROADCAST then this is also another
> >bug...
> >
> >I did a grep:
> >
> >grep -r "PACKET_BROADCAST" net/IPv6
> >
> >matches on:
> >
> >net/ipv6/mcast.c:	    skb->pkt_type != PACKET_BROADCAST)
> 

6LoWPAN layer always override the mac802154 parse value to PACKET_HOST.
Now I want to check if IPv6 Layer ever evaluate this value to
PACKET_BROADCAST and yes it seems so. So there is some other bug which
nobody detected.

Ok?

- Alex

Re: ICMPv6 Redirects

[Varka Bhadram]

Hi Alex,


On 09/30/2014 02:23 PM, Alexander Aring wrote:
> Hi Varka,
>
> On Tue, Sep 30, 2014 at 02:16:46PM +0530, Varka Bhadram wrote:
>> Alex,
>>
>> On 09/30/2014 02:09 PM, Alexander Aring wrote:
>>> On Tue, Sep 30, 2014 at 09:34:29AM +0100, Simon Vincent wrote:
>>>> I can confirm that this fixes the problem. I will create some patches when I
>>>> get a chance.
>>>> Thanks
>>>>
>>> This should make trouble on phy's which have no address filter...
>> I didnt get what do you mean by this..?
>>
> The mac802154 address filter sets PACKET_BROADCAST, PACKET_HOST and
> PACKET_OTHERHOST. When you have an address filter on PHY, then
> PACKET_OTHERHOST should never happen (on good phy's).
>
> So you always set PACKET_HOST xor PACKET_BROADCAST.

Enabling address filtering is in drivers hand..

Few hardware devices may not be handling the address filtering (SOftMAC devices).
So we need take care of this at Software layers.
  

>>> But when IPv6 Layer look on PACKET_BROADCAST then this is also another
>>> bug...
>>>
>>> I did a grep:
>>>
>>> grep -r "PACKET_BROADCAST" net/IPv6
>>>
>>> matches on:
>>>
>>> net/ipv6/mcast.c:	    skb->pkt_type != PACKET_BROADCAST)
> 6LoWPAN layer always override the mac802154 parse value to PACKET_HOST.
> Now I want to check if IPv6 Layer ever evaluate this value to
> PACKET_BROADCAST and yes it seems so. So there is some other bug which
> nobody detected.
>
> Ok?

6LoWPAN layer override the mac802154 parse value to PACKET_HOST, but that you only
fixed yesterday. Now we need not to worry about override.

Here we need to consider one point. IPv6 layer deals with MUTICAST addresses, there is no
broadcast address at this pint.

MAC802154 deals with BROADCAST addresses...?

What is the bug that you are talking about..?

> - Alex


-- 
Regards,
Varka Bhadram.

Re: ICMPv6 Redirects

[Alexander Aring]

On Tue, Sep 30, 2014 at 02:40:59PM +0530, Varka Bhadram wrote:
> Hi Alex,
> 
> 
> On 09/30/2014 02:23 PM, Alexander Aring wrote:
> >Hi Varka,
> >
> >On Tue, Sep 30, 2014 at 02:16:46PM +0530, Varka Bhadram wrote:
> >>Alex,
> >>
> >>On 09/30/2014 02:09 PM, Alexander Aring wrote:
> >>>On Tue, Sep 30, 2014 at 09:34:29AM +0100, Simon Vincent wrote:
> >>>>I can confirm that this fixes the problem. I will create some patches when I
> >>>>get a chance.
> >>>>Thanks
> >>>>
> >>>This should make trouble on phy's which have no address filter...
> >>I didnt get what do you mean by this..?
> >>
> >The mac802154 address filter sets PACKET_BROADCAST, PACKET_HOST and
> >PACKET_OTHERHOST. When you have an address filter on PHY, then
> >PACKET_OTHERHOST should never happen (on good phy's).
> >
> >So you always set PACKET_HOST xor PACKET_BROADCAST.
> 
> Enabling address filtering is in drivers hand..

no, drivers doesn't parse anything. Address filtering "CAN" done on phy.
But afterwards we set PACKET_FOO in mac802154 this is another address filtering.

Dropping frames when PACKET_OTHERHOST is part of next layer like (IPv6/6LoWPAN).
> 
> Few hardware devices may not be handling the address filtering (SOftMAC devices).
> So we need take care of this at Software layers.
> 
Yes that's what we do mac802154 set PACKET_FOO and next layer will drop
if it's OTHERHOST.

> >>>But when IPv6 Layer look on PACKET_BROADCAST then this is also another
> >>>bug...
> >>>
> >>>I did a grep:
> >>>
> >>>grep -r "PACKET_BROADCAST" net/IPv6
> >>>
> >>>matches on:
> >>>
> >>>net/ipv6/mcast.c:	    skb->pkt_type != PACKET_BROADCAST)
> >6LoWPAN layer always override the mac802154 parse value to PACKET_HOST.
> >Now I want to check if IPv6 Layer ever evaluate this value to
> >PACKET_BROADCAST and yes it seems so. So there is some other bug which
> >nobody detected.
> >
> >Ok?
> 
> 6LoWPAN layer override the mac802154 parse value to PACKET_HOST, but that you only
> fixed yesterday. Now we need not to worry about override.
> 

Of course we need to worry about that, it's not fixed mainline. :-)

> Here we need to consider one point. IPv6 layer deals with MUTICAST addresses, there is no
> broadcast address at this pint.
> 

In 802.15.4 the MULTICAST in our case is BROADCAST. We don't have any MULTICAST
feature. Only logical MULTICAST over BROADCAST. If you want to see a L2 Layer with
multicast support and address filtering on L2 see [0] as ethernet example.

> MAC802154 deals with BROADCAST addresses...?
> 

yes.

> What is the bug that you are talking about..?
> 

Don't know I didn't hit the bug and doesn't care about that. Point is
"that skb->pkt_type != PACKET_BROADCAST" is dead code in IPv6 and 6LoWPAN
because we always setting it to PACKET_HOST.

The code shows:
        
	if (skb->pkt_type != PACKET_MULTICAST &&
            skb->pkt_type != PACKET_BROADCAST)
                return 0;

We need to set PACKET_BROADCAST here otherwise some weird things happen. But
we don't need to set PACKET_MULTICAST, this code accept MULTICAST and BROADCAST.

When 6LoWPAN Layer always sets PACKET_HOST, this code is dead.

- Alex

[0] http://lxr.free-electrons.com/source/net/ethernet/eth.c#L168

Re: ICMPv6 Redirects

[Varka Bhadram]

On 09/30/2014 02:55 PM, Alexander Aring wrote:
> On Tue, Sep 30, 2014 at 02:40:59PM +0530, Varka Bhadram wrote:
>> Hi Alex,
>>
>>
>> On 09/30/2014 02:23 PM, Alexander Aring wrote:
>>> Hi Varka,
>>>
>>> On Tue, Sep 30, 2014 at 02:16:46PM +0530, Varka Bhadram wrote:
>>>> Alex,
>>>>
>>>> On 09/30/2014 02:09 PM, Alexander Aring wrote:
>>>>> On Tue, Sep 30, 2014 at 09:34:29AM +0100, Simon Vincent wrote:
>>>>>> I can confirm that this fixes the problem. I will create some patches when I
>>>>>> get a chance.
>>>>>> Thanks
>>>>>>
>>>>> This should make trouble on phy's which have no address filter...
>>>> I didnt get what do you mean by this..?
>>>>
>>> The mac802154 address filter sets PACKET_BROADCAST, PACKET_HOST and
>>> PACKET_OTHERHOST. When you have an address filter on PHY, then
>>> PACKET_OTHERHOST should never happen (on good phy's).
>>>
>>> So you always set PACKET_HOST xor PACKET_BROADCAST.
>> Enabling address filtering is in drivers hand..
> no, drivers doesn't parse anything. Address filtering "CAN" done on phy.
> But afterwards we set PACKET_FOO in mac802154 this is another address filtering.
>
> Dropping frames when PACKET_OTHERHOST is part of next layer like (IPv6/6LoWPAN).

For enabling filtering, driver has to update one of the radio chip register.

>> Few hardware devices may not be handling the address filtering (SOftMAC devices).
>> So we need take care of this at Software layers.
>>
> Yes that's what we do mac802154 set PACKET_FOO and next layer will drop
> if it's OTHERHOST.

ok

>>>>> But when IPv6 Layer look on PACKET_BROADCAST then this is also another
>>>>> bug...
>>>>>
>>>>> I did a grep:
>>>>>
>>>>> grep -r "PACKET_BROADCAST" net/IPv6
>>>>>
>>>>> matches on:
>>>>>
>>>>> net/ipv6/mcast.c:	    skb->pkt_type != PACKET_BROADCAST)
>>> 6LoWPAN layer always override the mac802154 parse value to PACKET_HOST.
>>> Now I want to check if IPv6 Layer ever evaluate this value to
>>> PACKET_BROADCAST and yes it seems so. So there is some other bug which
>>> nobody detected.
>>>
>>> Ok?
>> 6LoWPAN layer override the mac802154 parse value to PACKET_HOST, but that you only
>> fixed yesterday. Now we need not to worry about override.
>>
> Of course we need to worry about that, it's not fixed mainline. :-)

Yes.. Simon told that he will generate the patches..

>> Here we need to consider one point. IPv6 layer deals with MUTICAST addresses, there is no
>> broadcast address at this pint.
>>
> In 802.15.4 the MULTICAST in our case is BROADCAST. We don't have any MULTICAST
> feature. Only logical MULTICAST over BROADCAST. If you want to see a L2 Layer with
> multicast support and address filtering on L2 see [0] as ethernet example.

OK..

>> MAC802154 deals with BROADCAST addresses...?
>>
> yes.
>
>> What is the bug that you are talking about..?
>>
> Don't know I didn't hit the bug and doesn't care about that. Point is
> "that skb->pkt_type != PACKET_BROADCAST" is dead code in IPv6 and 6LoWPAN
> because we always setting it to PACKET_HOST.

May be IEEE-802.11 packets send to IPv6 Layer. In that case Its not dead code.

-- 
Regards,
Varka Bhadram.

Re: ICMPv6 Redirects

[Alexander Aring]

On Tue, Sep 30, 2014 at 03:05:15PM +0530, Varka Bhadram wrote:
....
> >>Enabling address filtering is in drivers hand..
> >no, drivers doesn't parse anything. Address filtering "CAN" done on phy.
> >But afterwards we set PACKET_FOO in mac802154 this is another address filtering.
> >
> >Dropping frames when PACKET_OTHERHOST is part of next layer like (IPv6/6LoWPAN).
> 
> For enabling filtering, driver has to update one of the radio chip register.
> 
yep, for enable the filter on phy level it's driver handling.

> >>Few hardware devices may not be handling the address filtering (SOftMAC devices).
> >>So we need take care of this at Software layers.
> >>
> >Yes that's what we do mac802154 set PACKET_FOO and next layer will drop
...
> 
> May be IEEE-802.11 packets send to IPv6 Layer. In that case Its not dead code.
> 


802.11 data frames will be converted to ethernet frames.

Why we now talking about 802.11? 6LoWPAN set always PACKET_HOST and then
we never have PACKET_BROADCAST set in IPv6 Layer. Then matching pkt_type
with PACKET_BROADCAST is dead code.

- Alex

Re: ICMPv6 Redirects

[Alexander Aring]

On Tue, Sep 30, 2014 at 03:23:09PM +0530, Varka Bhadram wrote:
> On 09/30/2014 03:13 PM, Alexander Aring wrote:
> >
> >>May be IEEE-802.11 packets send to IPv6 Layer. In that case Its not dead code.
> >>
> >
> >802.11 data frames will be converted to ethernet frames.
> >
> >Why we now talking about 802.11? 6LoWPAN set always PACKET_HOST and then
> >we never have PACKET_BROADCAST set in IPv6 Layer. Then matching pkt_type
> >with PACKET_BROADCAST is dead code.
> 
> We don't know in which scenario the IPv6 Layer checking that statement.
> 
> The control is reaching there when they got ICMPv6 message of typeICMPV6_MGM_REPORT  <http://lxr.free-electrons.com/ident?i=ICMPV6_MGM_REPORT>  [1] .
> 
> We don't know the significance of it..??
> 

Yep, we don't know it and it doesn't matter, but override the pkt_type
to PACKET_HOST when we have a broadcast frame is wrong.

Broadcast means it's IPv6 BROADCAST or MULTICAST, the detection if
LOGICAL MULTICAST over BROADCAST xor BROADCAST over BROADCAST is IPv6 Layer.

These ICMPv6 messages check on this and it's currently broken.

- Alex

Re: ICMPv6 Redirects

[Jukka Rissanen]

Hi Alex,

On ti, 2014-09-30 at 12:03 +0200, Alexander Aring wrote:
> On Tue, Sep 30, 2014 at 03:23:09PM +0530, Varka Bhadram wrote:
> > On 09/30/2014 03:13 PM, Alexander Aring wrote:
> > >
> > >>May be IEEE-802.11 packets send to IPv6 Layer. In that case Its not dead code.
> > >>
> > >
> > >802.11 data frames will be converted to ethernet frames.
> > >
> > >Why we now talking about 802.11? 6LoWPAN set always PACKET_HOST and then
> > >we never have PACKET_BROADCAST set in IPv6 Layer. Then matching pkt_type
> > >with PACKET_BROADCAST is dead code.
> > 
> > We don't know in which scenario the IPv6 Layer checking that statement.
> > 
> > The control is reaching there when they got ICMPv6 message of typeICMPV6_MGM_REPORT  <http://lxr.free-electrons.com/ident?i=ICMPV6_MGM_REPORT>  [1] .
> > 
> > We don't know the significance of it..??
> > 
> 
> Yep, we don't know it and it doesn't matter, but override the pkt_type
> to PACKET_HOST when we have a broadcast frame is wrong.
> 
> Broadcast means it's IPv6 BROADCAST or MULTICAST, the detection if
> LOGICAL MULTICAST over BROADCAST xor BROADCAST over BROADCAST is IPv6 Layer.

I probably missed something from earlier mails but why are we talking
about broadcast with IPv6? After all IPv6 supports only multicast and
broadcasting is not supported.

Also what is this "logical multicast over broadcast"?

> 
> These ICMPv6 messages check on this and it's currently broken.
> 
> - Alex


Cheers,
Jukka

Re: ICMPv6 Redirects

[Alexander Aring]

Hi Jukka,

On Tue, Sep 30, 2014 at 01:55:14PM +0300, Jukka Rissanen wrote:
> Hi Alex,
> 
> On ti, 2014-09-30 at 12:03 +0200, Alexander Aring wrote:
> > On Tue, Sep 30, 2014 at 03:23:09PM +0530, Varka Bhadram wrote:
> > > On 09/30/2014 03:13 PM, Alexander Aring wrote:
> > > >
> > > >>May be IEEE-802.11 packets send to IPv6 Layer. In that case Its not dead code.
> > > >>
> > > >
> > > >802.11 data frames will be converted to ethernet frames.
> > > >
> > > >Why we now talking about 802.11? 6LoWPAN set always PACKET_HOST and then
> > > >we never have PACKET_BROADCAST set in IPv6 Layer. Then matching pkt_type
> > > >with PACKET_BROADCAST is dead code.
> > > 
> > > We don't know in which scenario the IPv6 Layer checking that statement.
> > > 
> > > The control is reaching there when they got ICMPv6 message of typeICMPV6_MGM_REPORT  <http://lxr.free-electrons.com/ident?i=ICMPV6_MGM_REPORT>  [1] .
> > > 
> > > We don't know the significance of it..??
> > > 
> > 
> > Yep, we don't know it and it doesn't matter, but override the pkt_type
> > to PACKET_HOST when we have a broadcast frame is wrong.
> > 
> > Broadcast means it's IPv6 BROADCAST or MULTICAST, the detection if
> > LOGICAL MULTICAST over BROADCAST xor BROADCAST over BROADCAST is IPv6 Layer.
> 
> I probably missed something from earlier mails but why are we talking
> about broadcast with IPv6? After all IPv6 supports only multicast and
> broadcasting is not supported.

The issue what we talking about is:

6LoWPAN the header creating part is setting PACKET_HOST always to
skb->pkt_type, see [0].

These PACKET_FOO types is set by mac layer, means 802.15.1 (bluetooth <-
okay bluetooth low energy) or 802.15.4 (wpan <- we don't have a fancy name,
so we call it wpan).

After that 6LoWPAN replace the this value PACKET_HOST (don't know why,
but it's wrong. Somebody doesn't really realized what this do).

After 6LoWPAN handling we have IPv6 handling, what IPv6 do at first is
[1]. On handling without address filtering this doesn't work because we
always set (I don't know why we set it, but it's wrong. You know the
state before I worked with 6LoWPAN was also a awful state) PACKET_HOST.

The check on [1] is only that we don't want to parse frames that does
not belong to us. We need the same mechanism earlier in 6LoWPAN handling.
I already fixed it in the rework branch of 802.15.4, see [2]. But this
is only a performance hint! This performance hint you should also
implement in bluetooth 6lowpan.

Just for fun I did a 'grep -r "PACKET_BROADCAST" net/ipv6'. I only want
to know if there are also some other issues, because we always set to
PACKET_HOST which is wrong. And it's true, it matches on:

net/ipv6/mcast.c:	    skb->pkt_type != PACKET_BROADCAST)

which seems to be dead code [3]. In bluetooth and wpan(802.15.4).

> 
> Also what is this "logical multicast over broadcast"?
> 

I mean with logical multicast a multicast when the mac layer only
support broadcasts. Then IPv6 filtering the multicast packets when it's
broadcast. It's easy, you have broadcast frames only on MAC Layer (L2), then
you have MULTICAST over BROADCAST, some software filtering in IPv6 Layer
make some filtering so you have MULTICAST over BROADCAST.

I mean MULTICAST is a group of nodes of a BROADCAST. The filtering of
these groups is done by IPv6.



Sorry I know my english is hard to understand. Do you understand what I
mean now?

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/6lowpan/iphc.c?id=f19f4f9525cf32f97341fac20ce66392e86a1b67#n192
[1] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72
[2] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan_rtnl.c#L465
[3] http://lxr.free-electrons.com/source/net/ipv6/mcast.c#L1413

Re: ICMPv6 Redirects

[Alexander Aring]

On Tue, Sep 30, 2014 at 01:13:24PM +0200, Alexander Aring wrote:
> Hi Jukka,
> 
> On Tue, Sep 30, 2014 at 01:55:14PM +0300, Jukka Rissanen wrote:
> > Hi Alex,
> > 
> > On ti, 2014-09-30 at 12:03 +0200, Alexander Aring wrote:
> > > On Tue, Sep 30, 2014 at 03:23:09PM +0530, Varka Bhadram wrote:
> > > > On 09/30/2014 03:13 PM, Alexander Aring wrote:
> > > > >
> > > > >>May be IEEE-802.11 packets send to IPv6 Layer. In that case Its not dead code.
> > > > >>
> > > > >
> > > > >802.11 data frames will be converted to ethernet frames.
> > > > >
> > > > >Why we now talking about 802.11? 6LoWPAN set always PACKET_HOST and then
> > > > >we never have PACKET_BROADCAST set in IPv6 Layer. Then matching pkt_type
> > > > >with PACKET_BROADCAST is dead code.
> > > > 
> > > > We don't know in which scenario the IPv6 Layer checking that statement.
> > > > 
> > > > The control is reaching there when they got ICMPv6 message of typeICMPV6_MGM_REPORT  <http://lxr.free-electrons.com/ident?i=ICMPV6_MGM_REPORT>  [1] .
> > > > 
> > > > We don't know the significance of it..??
> > > > 
> > > 
> > > Yep, we don't know it and it doesn't matter, but override the pkt_type
> > > to PACKET_HOST when we have a broadcast frame is wrong.
> > > 
> > > Broadcast means it's IPv6 BROADCAST or MULTICAST, the detection if
> > > LOGICAL MULTICAST over BROADCAST xor BROADCAST over BROADCAST is IPv6 Layer.
> > 
> > I probably missed something from earlier mails but why are we talking
> > about broadcast with IPv6? After all IPv6 supports only multicast and
> > broadcasting is not supported.
> 
> The issue what we talking about is:
> 

In a nutshell:

We have issues at [1] and [3] because [0]. For better performance we
should something do like [1] at 6LoWPAN packet receive function for
example [2].

:-)

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/6lowpan/iphc.c?id=f19f4f9525cf32f97341fac20ce66392e86a1b67#n192
[1] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72
[2] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan_rtnl.c#L465
[3] http://lxr.free-electrons.com/source/net/ipv6/mcast.c#L1413

Re: ICMPv6 Redirects

[Alexander Aring]

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.

- Alex

[0] http://lxr.free-electrons.com/source/net/ipv6/ip6_input.c#L72

Re: ICMPv6 Redirects

[Alexander Aring]

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

Re: ICMPv6 Redirects

[Alexander Aring]

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