ICMPv6 Redirects

DISCUSSION Simon Vincent 4 participants 45 messages Sep 26, 2014 – Sep 30, 2014 6 messages not in the archive

Subsystems (3)

Networking IEEE 802.15.4 6LOWPAN generic (btle/IEEE 802.15.4)

lore

Share & tools

lore

Simon Vincent

author

2014-09-26 15:16 UTC #0 lore raw

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

Alexander Aring

maintainer

2014-09-26 15:35 UTC #1 lore raw

Hi Simon,

Quoted 1 line · Simon Vincent

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.

Quoted 10 lines

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?

Quoted 5 lines

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

Simon Vincent

author

2014-09-26 16:26 UTC #2 lore raw

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.

Quoted 9 lines · Alexander Aring

Hi Simon,
Quoted 1 line · Simon Vincent
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...

Quoted 7 lines

Quoted 7 lines
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

Quoted 5 lines

Quoted 3 lines
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.

Quoted 8 lines

Quoted 5 lines
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

Alexander Aring

maintainer

2014-09-27 01:42 UTC #3 lore raw

Hi Simon,

Quoted 4 lines · 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.

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. :-)

Quoted 31 lines · Alexander Aring

Quoted 9 lines
Hi Simon,
Quoted 1 line · Simon Vincent
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...
Quoted 7 lines
Quoted 7 lines
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
Quoted 5 lines
Quoted 3 lines
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.

Quoted 2 lines

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

Simon Vincent

author

2014-09-29 10:20 UTC #4 lore raw

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.

Quoted 1 line · Alexander Aring

all p

Varka Bhadram

2014-09-29 11:01 UTC #5 lore raw

Simon,

Quoted 4 lines · 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.

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..?

Signature · 2 lines

Thanks and Regards,
Varka Bhadram.

Simon Vincent

author

2014-09-29 11:09 UTC #6 lore raw

Quoted 10 lines · Varka Bhadram

Simon,
Quoted 4 lines · 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.
I think we are not supposed to discard the packets like this. This will create the problems if routing enabled on the node.

Quoted 7 lines

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.

Alexander Aring

maintainer

2014-09-29 11:13 UTC #48 lore raw

In reply to Simon Vincent

Hi,

Quoted 8 lines · 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.

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

Alexander Aring

maintainer

2014-09-29 11:24 UTC #49 lore raw

Quoted 12 lines · Alexander Aring

Hi,
Quoted 8 lines · 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.

Quoted 7 lines

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

Alexander Aring

maintainer

2014-09-29 11:37 UTC #50 lore raw

Quoted 28 lines · Alexander Aring

Quoted 12 lines · Alexander Aring
Hi,
Quoted 8 lines · 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.
Quoted 7 lines
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;
}

Quoted 8 lines

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 [email protected]

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

- Alex

Alexander Aring

maintainer

2014-09-29 11:54 UTC #9 lore raw

In reply to a message not in the archive

Quoted 39 lines · Varka Bhadram

Quoted 38 lines · Varka Bhadram
Quoted 22 lines · Simon Vincent
Quoted 20 lines · Varka Bhadram
Simon,
Quoted 8 lines · 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.
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/
Quoted 8 lines
Quoted 3 lines
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..

Quoted 8 lines

Quoted 1 line
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

Alexander Aring

maintainer

2014-09-29 11:57 UTC #10 lore raw

Quoted 44 lines · Alexander Aring

Quoted 43 lines · Varka Bhadram
Quoted 31 lines · Varka Bhadram
Quoted 22 lines · Simon Vincent
Quoted 20 lines · Varka Bhadram
Simon,
Quoted 8 lines · 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.
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/
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
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...

Quoted 9 lines

Quoted 4 lines
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

Alexander Aring

maintainer

2014-09-29 12:14 UTC #12 lore raw

In reply to a message not in the archive

Quoted 58 lines · Varka Bhadram

Quoted 57 lines · Alexander Aring
Quoted 42 lines · Alexander Aring
Quoted 41 lines · Varka Bhadram
Quoted 30 lines · Varka Bhadram
Quoted 21 lines · Simon Vincent
Quoted 20 lines · Varka Bhadram
Simon,
Quoted 8 lines · 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.
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/
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
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...
Quoted 8 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 3 lines
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

Alexander Aring

maintainer

2014-09-29 12:14 UTC #14 lore raw

In reply to a message not in the archive

Quoted 61 lines · Varka Bhadram

Quoted 60 lines · Varka Bhadram
Quoted 59 lines · Alexander Aring
Quoted 42 lines · Alexander Aring
Quoted 41 lines · Varka Bhadram
Quoted 30 lines · Varka Bhadram
Quoted 21 lines · Simon Vincent
Quoted 20 lines · Varka Bhadram
Simon,
Quoted 8 lines · 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.
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/
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
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...
Quoted 8 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
- 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

Alexander Aring

maintainer

2014-09-29 13:12 UTC #16 lore raw

In reply to a message not in the archive

On Mon, Sep 29, 2014 at 01:49:26PM +0100, Simon Vincent wrote:
...

Quoted 6 lines

Quoted 6 lines
Quoted 2 lines
Try this . I hope it will work.
Sorry for the wrong info...
Set up accept_redirects/send_redirects to boolean value '0'

Quoted 7 lines

Quoted 2 lines
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

Alexander Aring

maintainer

2014-09-29 13:30 UTC #17 lore raw

Quoted 10 lines · Alexander Aring

On Mon, Sep 29, 2014 at 01:49:26PM +0100, Simon Vincent wrote:
...
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
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

Quoted 8 lines

Quoted 5 lines
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

Simon Vincent

author

2014-09-29 13:33 UTC #18 lore raw

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

Quoted 24 lines · Alexander Aring

Quoted 7 lines · Alexander Aring
On Mon, Sep 29, 2014 at 01:49:26PM +0100, Simon Vincent wrote:
...
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Try this . I hope it will work.
Sorry for the wrong info...
Set up accept_redirects/send_redirects to boolean value '0'
Quoted 9 lines
Quoted 7 lines
Quoted 2 lines
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

Alexander Aring

maintainer

2014-09-29 13:38 UTC #19 lore raw

Simon,

Quoted 2 lines · 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

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

Alexander Aring

maintainer

2014-09-29 13:42 UTC #20 lore raw

Quoted 6 lines · Alexander Aring

Simon,
Quoted 2 lines · 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

Quoted 7 lines

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

Simon Vincent

author

2014-09-29 13:51 UTC #21 lore raw

In reply to Alexander Aring

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.

Quoted 16 lines · Alexander Aring

Simon,
Quoted 2 lines · 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
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

Varka Bhadram

2014-09-29 13:54 UTC #22 lore raw

Quoted 2 lines · 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.

Have you seen this [1].

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

Quoted 1 line

I can fix the problem by dropping PACKET_OTHERHOST in mac802154_subif_frame.

Signature · 1 line

-Varka Bhadram

Alexander Aring

maintainer

2014-09-29 13:58 UTC #24 lore raw

In reply to Simon Vincent

Quoted 6 lines · 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.

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

Varka Bhadram

2014-09-29 14:08 UTC #25 lore raw

Quoted 14 lines · Alexander Aring

Quoted 6 lines · 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.
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.

Quoted 7 lines

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...?

Signature · 1 line

-Varka Bhadram

Simon Vincent

author

2014-09-29 14:12 UTC #29 lore raw

In reply to Alexander Aring

Quoted 9 lines · Alexander Aring

Quoted 6 lines · 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.
The first what IPv6 does is [0].

Quoted 8 lines

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.

Simon Vincent

author

2014-09-29 14:12 UTC #23 lore raw

In reply to Varka Bhadram

Quoted 8 lines · Varka Bhadram

Quoted 2 lines · 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.
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

Alexander Aring

maintainer

2014-09-29 14:12 UTC #26 lore raw

In reply to Varka Bhadram

Quoted 19 lines · Varka Bhadram

Quoted 18 lines · Alexander Aring
Quoted 6 lines · 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.
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.

Quoted 7 lines

Quoted 3 lines
- 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

Varka Bhadram

2014-09-29 14:15 UTC #27 lore raw

Quoted 23 lines · Alexander Aring

Quoted 22 lines · Varka Bhadram
Quoted 21 lines · Alexander Aring
Quoted 6 lines · 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.
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

Quoted 9 lines

Quoted 3 lines
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..?

Signature · 1 line

-Varka Bhadram

Alexander Aring

maintainer

2014-09-29 14:17 UTC #30 lore raw

In reply to Simon Vincent

Quoted 16 lines · Simon Vincent

Quoted 14 lines · Alexander Aring
Quoted 6 lines · 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.
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.

Quoted 5 lines

Quoted 3 lines
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

Alexander Aring

maintainer

2014-09-29 14:19 UTC #28 lore raw

In reply to Varka Bhadram

Hi Varka,

Quoted 28 lines · Varka Bhadram

Quoted 26 lines · Alexander Aring
Quoted 25 lines · Varka Bhadram
Quoted 14 lines · Alexander Aring
Quoted 6 lines · 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.
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.
Quoted 7 lines
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.

Quoted 8 lines

Quoted 6 lines
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

Alexander Aring

maintainer

2014-09-29 14:39 UTC #31 lore raw

In reply to Simon Vincent

Simon,

Quoted 16 lines · Simon Vincent

Quoted 14 lines · Alexander Aring
Quoted 6 lines · 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.
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.

Quoted 8 lines

Quoted 3 lines
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

Alexander Aring

maintainer

2014-09-29 14:51 UTC #32 lore raw

Quoted 32 lines · Alexander Aring

Simon,
Quoted 16 lines · Simon Vincent
Quoted 14 lines · Alexander Aring
Quoted 6 lines · 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.
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.
Quoted 8 lines
Quoted 3 lines
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].

Quoted 7 lines

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

Alexander Aring

maintainer

2014-09-29 16:42 UTC #33 lore raw

In reply to Simon Vincent

Hi Simon,

Quoted 16 lines · Simon Vincent

Quoted 14 lines · Alexander Aring
Quoted 6 lines · 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.
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.

Quoted 8 lines

Quoted 3 lines
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:

net/6lowpan/iphc.c +0 -1

index 142eef5..002cd7c 100644
@@ -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",

net/ieee802154/6lowpan_rtnl.c +3 -1

index 4413629..820922a 100644
@@ -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

Simon Vincent

author

2014-09-30 08:34 UTC #34 lore raw

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

Simon

Quoted 77 lines · Alexander Aring

Hi Simon,
Quoted 15 lines · Simon Vincent
Quoted 14 lines · Alexander Aring
Quoted 6 lines · 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.
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.
Quoted 8 lines
Quoted 3 lines
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:
net/6lowpan/iphc.c +0 -1
index 142eef5..002cd7c 100644
@@ -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",
net/ieee802154/6lowpan_rtnl.c +3 -1
index 4413629..820922a 100644
@@ -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

Varka Bhadram

2014-09-30 08:36 UTC #35 lore raw

Quoted 3 lines · Simon Vincent

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

Good to listen.. Thanks...

Quoted 1 line

Simon

Signature · 2 lines

Regards,
Varka Bhadram.

Alexander Aring

maintainer

2014-09-30 08:39 UTC #36 lore raw

In reply to Simon Vincent

Quoted 4 lines · Simon Vincent

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

Varka Bhadram

2014-09-30 08:49 UTC #37 lore raw

Alex,

Quoted 6 lines · Alexander Aring

Quoted 4 lines · Simon Vincent
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..?

Quoted 10 lines

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...

Quoted 2 lines

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

Signature · 2 lines

Regards,
Varka Bhadram.

Alexander Aring

maintainer

2014-09-30 08:53 UTC #38 lore raw

Hi Varka,

Quoted 12 lines · Varka Bhadram

Alex,
Quoted 6 lines · Alexander Aring
Quoted 4 lines · Simon Vincent
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.

Quoted 11 lines

Quoted 10 lines
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

Varka Bhadram

2014-09-30 09:13 UTC #39 lore raw

Hi Alex,

Quoted 11 lines · Alexander Aring

Hi Varka,
Quoted 8 lines · Varka Bhadram
Alex,
Quoted 5 lines · Alexander Aring
Quoted 4 lines · Simon Vincent
I can confirm that this fixes the problem. I will create some patches when I get a chance.
Thanks

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
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.

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
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:

Quoted 7 lines

Quoted 1 line
Quoted 1 line
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..?

Quoted 1 line

- Alex

Signature · 2 lines

Regards,
Varka Bhadram.

Alexander Aring

maintainer

2014-09-30 09:25 UTC #40 lore raw

Quoted 18 lines · Varka Bhadram

Hi Alex,
Quoted 14 lines · Alexander Aring
Hi Varka,
Quoted 11 lines · Varka Bhadram
Alex,
Quoted 6 lines · Alexander Aring
Quoted 4 lines · Simon Vincent
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..?

Quoted 7 lines

Quoted 5 lines
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).

Quoted 4 lines

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.

Quoted 15 lines

Quoted 15 lines
Quoted 10 lines
Quoted 10 lines
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.

Quoted 5 lines

Quoted 1 line
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. :-)

Quoted 3 lines

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.

Quoted 2 lines

MAC802154 deals with BROADCAST addresses...?

yes.

Quoted 2 lines

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

Varka Bhadram

2014-09-30 09:37 UTC #41 lore raw

Quoted 23 lines · Alexander Aring

Quoted 22 lines · Varka Bhadram
Hi Alex,
Quoted 18 lines · Alexander Aring
Hi Varka,
Quoted 11 lines · Varka Bhadram
Alex,
Quoted 6 lines · Alexander Aring
Quoted 4 lines · Simon Vincent
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).

Quoted 6 lines

Quoted 2 lines
Quoted 1 line
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.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 15 lines

Quoted 15 lines
Quoted 15 lines
Quoted 10 lines
Quoted 10 lines
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.

Quoted 5 lines

Quoted 4 lines
Quoted 1 line
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..

Quoted 6 lines

Quoted 3 lines
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..

Quoted 9 lines

Quoted 2 lines
MAC802154 deals with BROADCAST addresses...?
yes.
Quoted 2 lines
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.

Signature · 2 lines

Regards,
Varka Bhadram.

Alexander Aring

maintainer

2014-09-30 09:43 UTC #42 lore raw

On Tue, Sep 30, 2014 at 03:05:15PM +0530, Varka Bhadram wrote:
....

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
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.

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
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

...

Quoted 3 lines

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

Alexander Aring

maintainer

2014-09-30 10:04 UTC #44 lore raw

In reply to a message not in the archive

Quoted 11 lines · Varka Bhadram

Quoted 9 lines · Alexander Aring
Quoted 3 lines
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.

Quoted 6 lines

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

Jukka Rissanen

2014-09-30 10:55 UTC #45 lore raw

Hi Alex,

Quoted 16 lines · Alexander Aring

Quoted 15 lines · Varka Bhadram
Quoted 9 lines · Alexander Aring
Quoted 3 lines
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] .

Quoted 8 lines

Quoted 2 lines
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"?

Quoted 4 lines

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

Cheers,
Jukka

Alexander Aring

maintainer

2014-09-30 11:13 UTC #46 lore raw

Hi Jukka,

Quoted 25 lines · Jukka Rissanen

Hi Alex,
Quoted 22 lines · Alexander Aring
Quoted 11 lines · Varka Bhadram
Quoted 9 lines · Alexander Aring
Quoted 3 lines
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.
Quoted 6 lines
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.

Quoted 6 lines

Quoted 2 lines
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).

Quoted 3 lines

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

Alexander Aring

maintainer

2014-09-30 11:35 UTC #47 lore raw

Quoted 28 lines · Alexander Aring

Hi Jukka,
Quoted 25 lines · Jukka Rissanen
Hi Alex,
Quoted 22 lines · Alexander Aring
Quoted 11 lines · Varka Bhadram
Quoted 9 lines · Alexander Aring
Quoted 3 lines
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.
Quoted 6 lines
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.

Quoted 9 lines

Quoted 6 lines
Quoted 2 lines
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