[PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Simon Vincent]

This series of patches fix the cases where the pkt_type is overriden 
resulting in skbs of type PACKET_OTHERHOST getting set to PACKET_HOST.
Also it drops packets of PACKET_OTHERHOST type in the 6lowpan layer
as there is not point processing them as they are dropped at the next
layer.

Simon Vincent (3):
  6lowpan: Ensure pkt_type is not lost
  ieee802154: 6lowpan: Ensure pkt_type is not lost
  ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan

 net/6lowpan/iphc.c            | 1 -
 net/ieee802154/6lowpan_rtnl.c | 4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH linux-wpan 1/3] 6lowpan: Ensure pkt_type is not lost

[Simon Vincent]

Remove line which overrrides pkt_type to PACKET_HOST

Signed-off-by: Simon Vincent <simon.vincent@xsilon.com>
---
 net/6lowpan/iphc.c | 1 -
 1 file changed, 1 deletion(-)

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",
-- 
1.9.1

[PATCH linux-wpan 2/3] ieee802154: 6lowpan: Ensure pkt_type is not lost

[Simon Vincent]

Remove line which overrides pkt_type to PACKET_HOST

Signed-off-by: Simon Vincent <simon.vincent@xsilon.com>
---
 net/ieee802154/6lowpan_rtnl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index 4413629..e246edc 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -524,7 +524,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);
-- 
1.9.1

[PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan

[Simon Vincent]

There is no point processing pkts which are PACKET_OTHERHOST
in 6lowpan as they are discarded as soon as they reach the
ipv6 layer. Therefore we should drop them in the 6lowpan layer.

Signed-off-by: Simon Vincent <simon.vincent@xsilon.com>
---
 net/ieee802154/6lowpan_rtnl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index e246edc..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;
 
-- 
1.9.1

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

Hi Simon,

On Thu, Oct 02, 2014 at 09:56:43AM +0100, Simon Vincent wrote:
> This series of patches fix the cases where the pkt_type is overriden 
> resulting in skbs of type PACKET_OTHERHOST getting set to PACKET_HOST.
> Also it drops packets of PACKET_OTHERHOST type in the 6lowpan layer
> as there is not point processing them as they are dropped at the next
> layer.
> 

serie looks good, I took a fast look into this.

You hit the GENERIC 6LOWPAN branch and all patches have a dependency to
each other. Means all patches should go into bluetooth repo.

Marcel's bluetooth repository isn't based on current net, this is done
after the merge window. I think we should base it on bluetooth-next, but
it's a big issue... forget users for the current kernel, will be fixed
in the next version. I discuss this with Marcel at [0]. So we doesn't
matter to fix it in current/-stable versions. If somebody like to fix it,
he can do the effort and send it to -stable mailinglist.

Please rebase it on bluetooth-next and send it again to the bluetooth 
mailinglist in cc (also linux-wpan and Jukka, me, etc..).


- Alex

[0] (was somewhere on linux-wpan with Marcel, we don't have a mail archive for this)

Re: [PATCH linux-wpan 1/3] 6lowpan: Ensure pkt_type is not lost

[Alexander Aring]

On Thu, Oct 02, 2014 at 09:56:44AM +0100, Simon Vincent wrote:
> Remove line which overrrides pkt_type to PACKET_HOST
> 

s/overrrides/overrides

> Signed-off-by: Simon Vincent <simon.vincent@xsilon.com>
> ---
>  net/6lowpan/iphc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> 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",
> -- 
> 1.9.1
> 

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

On Thu, Oct 02, 2014 at 09:56:43AM +0100, Simon Vincent wrote:
> This series of patches fix the cases where the pkt_type is overriden 
> resulting in skbs of type PACKET_OTHERHOST getting set to PACKET_HOST.
> Also it drops packets of PACKET_OTHERHOST type in the 6lowpan layer
> as there is not point processing them as they are dropped at the next
> layer.

Please don't forget:

$ grep -r -n "PACKET_HOST" net/bluetooth/6lowpan.c

276:		local_skb->pkt_type = PACKET_HOST;

- Alex

Re: [PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan

[Alexander Aring]

On Thu, Oct 02, 2014 at 09:56:46AM +0100, Simon Vincent wrote:
> There is no point processing pkts which are PACKET_OTHERHOST
> in 6lowpan as they are discarded as soon as they reach the
> ipv6 layer. Therefore we should drop them in the 6lowpan layer.
> 
> Signed-off-by: Simon Vincent <simon.vincent@xsilon.com>
> ---
>  net/ieee802154/6lowpan_rtnl.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
> index e246edc..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;
>  

This one should also added in bluetooth, but I don't know where. Maybe
Jukka will take care of this.

- Alex

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Simon Vincent]

I will add this patch when I rebase on bluetooth-next.

On 02/10/14 10:28, Alexander Aring wrote:
> On Thu, Oct 02, 2014 at 09:56:43AM +0100, Simon Vincent wrote:
>> This series of patches fix the cases where the pkt_type is overriden
>> resulting in skbs of type PACKET_OTHERHOST getting set to PACKET_HOST.
>> Also it drops packets of PACKET_OTHERHOST type in the 6lowpan layer
>> as there is not point processing them as they are dropped at the next
>> layer.
> Please don't forget:
>
> $ grep -r -n "PACKET_HOST" net/bluetooth/6lowpan.c
>
> 276:		local_skb->pkt_type = PACKET_HOST;
>
> - Alex

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Jukka Rissanen]

Hi Simon,

On to, 2014-10-02 at 10:36 +0100, Simon Vincent wrote:
> I will add this patch when I rebase on bluetooth-next.

and thanks for doing that.

> 
> On 02/10/14 10:28, Alexander Aring wrote:
> > On Thu, Oct 02, 2014 at 09:56:43AM +0100, Simon Vincent wrote:
> >> This series of patches fix the cases where the pkt_type is overriden
> >> resulting in skbs of type PACKET_OTHERHOST getting set to PACKET_HOST.
> >> Also it drops packets of PACKET_OTHERHOST type in the 6lowpan layer
> >> as there is not point processing them as they are dropped at the next
> >> layer.
> > Please don't forget:
> >
> > $ grep -r -n "PACKET_HOST" net/bluetooth/6lowpan.c
> >
> > 276:		local_skb->pkt_type = PACKET_HOST;
> >
> > - Alex
> 


Cheers,
Jukka

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

Jukka,

On Thu, Oct 02, 2014 at 12:43:05PM +0300, Jukka Rissanen wrote:
> Hi Simon,
> 
> On to, 2014-10-02 at 10:36 +0100, Simon Vincent wrote:
> > I will add this patch when I rebase on bluetooth-next.
> 
> and thanks for doing that.
> 

I see now, that the bluetooth layer never sets this value. I don't know
how bluetooth deal with that. But you need to set PACKET_HOST if packet
belongs to you, OTHERHOST if packets belongs not to you, or
PACKET_BROADCAST if packet belongs to you, but is a broadcast.

Also for PACKET_MULTICAST, if bluetooth support MULTICAST frames.


I think you need handling for this in bluetooth 6lowpan layer.

- Alex

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

On Thu, Oct 02, 2014 at 11:54:30AM +0200, Alexander Aring wrote:
> Jukka,
> 
> On Thu, Oct 02, 2014 at 12:43:05PM +0300, Jukka Rissanen wrote:
> > Hi Simon,
> > 
> > On to, 2014-10-02 at 10:36 +0100, Simon Vincent wrote:
> > > I will add this patch when I rebase on bluetooth-next.
> > 
> > and thanks for doing that.
> > 
> 
> I see now, that the bluetooth layer never sets this value. I don't know
> how bluetooth deal with that. But you need to set PACKET_HOST if packet
> belongs to you, OTHERHOST if packets belongs not to you, or
> PACKET_BROADCAST if packet belongs to you, but is a broadcast.
> 
> Also for PACKET_MULTICAST, if bluetooth support MULTICAST frames.
> 
> 
> I think you need handling for this in bluetooth 6lowpan layer.
> 

and this should be fixed before Simon's patches. I add Marcel here in
cc, maybe he can bring some new information if bluetooth ever set's the
pkt_type in sk_buff.

Point is IPv6 needs this information and we should set it to a valid value.
... and this is not always set PACKET_HOST, IPv6 also check on PACKET_BROADCAST.

- Alex

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Jukka Rissanen]

Hi Alex,

On to, 2014-10-02 at 11:58 +0200, Alexander Aring wrote:
> On Thu, Oct 02, 2014 at 11:54:30AM +0200, Alexander Aring wrote:
> > Jukka,
> > 
> > On Thu, Oct 02, 2014 at 12:43:05PM +0300, Jukka Rissanen wrote:
> > > Hi Simon,
> > > 
> > > On to, 2014-10-02 at 10:36 +0100, Simon Vincent wrote:
> > > > I will add this patch when I rebase on bluetooth-next.
> > > 
> > > and thanks for doing that.
> > > 
> > 
> > I see now, that the bluetooth layer never sets this value. I don't know
> > how bluetooth deal with that. But you need to set PACKET_HOST if packet
> > belongs to you, OTHERHOST if packets belongs not to you, or
> > PACKET_BROADCAST if packet belongs to you, but is a broadcast.
> > 
> > Also for PACKET_MULTICAST, if bluetooth support MULTICAST frames.
> > 
> > 
> > I think you need handling for this in bluetooth 6lowpan layer.
> > 
> 
> and this should be fixed before Simon's patches. I add Marcel here in
> cc, maybe he can bring some new information if bluetooth ever set's the
> pkt_type in sk_buff.
> 
> Point is IPv6 needs this information and we should set it to a valid value.
> ... and this is not always set PACKET_HOST, IPv6 also check on PACKET_BROADCAST.

Hmm, bluetooth 6lowpan is a bit different from ieee802154 as the
bluetooth link is a point-to-point one and typically only uses link
local addresses so normally every packet is really meant for that host.

I will investigate this a bit more, so perhaps it is best if Simon does
not change the pkt_type field after all. Everything seems to work just
fine with unicast and multicast packets at the moment (when pkt_type ==
PACKET_HOST).


Cheers,
Jukka

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

Hi Jukka,

On Thu, Oct 02, 2014 at 01:12:44PM +0300, Jukka Rissanen wrote:
> Hi Alex,
> 
> On to, 2014-10-02 at 11:58 +0200, Alexander Aring wrote:
> > On Thu, Oct 02, 2014 at 11:54:30AM +0200, Alexander Aring wrote:
> > > Jukka,
> > > 
> > > On Thu, Oct 02, 2014 at 12:43:05PM +0300, Jukka Rissanen wrote:
> > > > Hi Simon,
> > > > 
> > > > On to, 2014-10-02 at 10:36 +0100, Simon Vincent wrote:
> > > > > I will add this patch when I rebase on bluetooth-next.
> > > > 
> > > > and thanks for doing that.
> > > > 
> > > 
> > > I see now, that the bluetooth layer never sets this value. I don't know
> > > how bluetooth deal with that. But you need to set PACKET_HOST if packet
> > > belongs to you, OTHERHOST if packets belongs not to you, or
> > > PACKET_BROADCAST if packet belongs to you, but is a broadcast.
> > > 
> > > Also for PACKET_MULTICAST, if bluetooth support MULTICAST frames.
> > > 
> > > 
> > > I think you need handling for this in bluetooth 6lowpan layer.
> > > 
> > 
> > and this should be fixed before Simon's patches. I add Marcel here in
> > cc, maybe he can bring some new information if bluetooth ever set's the
> > pkt_type in sk_buff.
> > 
> > Point is IPv6 needs this information and we should set it to a valid value.
> > ... and this is not always set PACKET_HOST, IPv6 also check on PACKET_BROADCAST.
> 
> Hmm, bluetooth 6lowpan is a bit different from ieee802154 as the
> bluetooth link is a point-to-point one and typically only uses link
> local addresses so normally every packet is really meant for that host.
> 
> I will investigate this a bit more, so perhaps it is best if Simon does
> not change the pkt_type field after all. Everything seems to work just
> fine with unicast and multicast packets at the moment (when pkt_type ==
> PACKET_HOST).
> 

Okay, then maybe bluetooth 6lowpan need to set it to PACKET_HOST always.

Another idea would be:
We could also set PACKET_BROADCAST if the IPv6 address is a
multicast/broadcast addresss.

But it looks wrong, the PACKET_FOO values should be set by mac layer only.


What I deteced is at [0]. There it checks if the "mac frame" was
broadcast or multicast. I don't know when this occurs, I need to check
this but it seems to be broken, when we always set the PACKET_HOST.



Simon had issues with routing when IPv6 Layer gets a skb with PACKET_HOST and
it was PACKET_OTHERHOSTS before.


Simon:

Maybe only send patch:

[PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan

this should fix your routing problems, but issue with [0] still exists.

- Alex

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

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

On Thu, Oct 02, 2014 at 12:22:01PM +0200, Alexander Aring wrote:
...
> 
> Okay, then maybe bluetooth 6lowpan need to set it to PACKET_HOST always.
> 
> Another idea would be:
> We could also set PACKET_BROADCAST if the IPv6 address is a
> multicast/broadcast addresss.
> 
> But it looks wrong, the PACKET_FOO values should be set by mac layer only.
> 
> 
> What I deteced is at [0]. There it checks if the "mac frame" was
> broadcast or multicast. I don't know when this occurs, I need to check
> this but it seems to be broken, when we always set the PACKET_HOST.
> 
> 
> 
> Simon had issues with routing when IPv6 Layer gets a skb with PACKET_HOST and
> it was PACKET_OTHERHOSTS before.
> 
> 
> Simon:
> 
> Maybe only send patch:
> 
> [PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan
> 
> this should fix your routing problems, but issue with [0] still exists.
> 

Another idea would be to put out the handling of setting pkt_type inside
the 6LOWPAN GENERIC branch. This is what Martin does in the lowpan_rcv
fixes... I still need some time to review his patch.

Maybe Simon add patch "[PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop
PACKET_OTHERHOST skbs in 6lowpan" this only affects the 802.15.4 branch.

Then Martin solve the lowpan_rcv issue which put out the handling of
pkt_type in lowpan_header_create function. Then you can do whatever
bluetooth need to do there and we can drop the override of set this
value to PACKET_HOST.

- Alex

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Simon Vincent]

On 02/10/14 11:22, Alexander Aring wrote:
> Hi Jukka,
>
> On Thu, Oct 02, 2014 at 01:12:44PM +0300, Jukka Rissanen wrote:
>> Hi Alex,
>>
>> On to, 2014-10-02 at 11:58 +0200, Alexander Aring wrote:
>>> On Thu, Oct 02, 2014 at 11:54:30AM +0200, Alexander Aring wrote:
>>>> Jukka,
>>>>
>>>> On Thu, Oct 02, 2014 at 12:43:05PM +0300, Jukka Rissanen wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On to, 2014-10-02 at 10:36 +0100, Simon Vincent wrote:
>>>>>> I will add this patch when I rebase on bluetooth-next.
>>>>> and thanks for doing that.
>>>>>
>>>> I see now, that the bluetooth layer never sets this value. I don't know
>>>> how bluetooth deal with that. But you need to set PACKET_HOST if packet
>>>> belongs to you, OTHERHOST if packets belongs not to you, or
>>>> PACKET_BROADCAST if packet belongs to you, but is a broadcast.
>>>>
>>>> Also for PACKET_MULTICAST, if bluetooth support MULTICAST frames.
>>>>
>>>>
>>>> I think you need handling for this in bluetooth 6lowpan layer.
>>>>
>>> and this should be fixed before Simon's patches. I add Marcel here in
>>> cc, maybe he can bring some new information if bluetooth ever set's the
>>> pkt_type in sk_buff.
>>>
>>> Point is IPv6 needs this information and we should set it to a valid value.
>>> ... and this is not always set PACKET_HOST, IPv6 also check on PACKET_BROADCAST.
>> Hmm, bluetooth 6lowpan is a bit different from ieee802154 as the
>> bluetooth link is a point-to-point one and typically only uses link
>> local addresses so normally every packet is really meant for that host.
>>
>> I will investigate this a bit more, so perhaps it is best if Simon does
>> not change the pkt_type field after all. Everything seems to work just
>> fine with unicast and multicast packets at the moment (when pkt_type ==
>> PACKET_HOST).
>>
> Okay, then maybe bluetooth 6lowpan need to set it to PACKET_HOST always.
>
> Another idea would be:
> We could also set PACKET_BROADCAST if the IPv6 address is a
> multicast/broadcast addresss.
>
> But it looks wrong, the PACKET_FOO values should be set by mac layer only.
>
>
> What I deteced is at [0]. There it checks if the "mac frame" was
> broadcast or multicast. I don't know when this occurs, I need to check
> this but it seems to be broken, when we always set the PACKET_HOST.
>
>
>
> Simon had issues with routing when IPv6 Layer gets a skb with PACKET_HOST and
> it was PACKET_OTHERHOSTS before.
>
>
> Simon:
>
> Maybe only send patch:
>
> [PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan
>
> this should fix your routing problems, but issue with [0] still exists.
So I should rebase and submit the whole patch series on bluetooth-next 
but not add a new patch to change net/bluetooth/6lowpan.c ?

Simon

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

Hi Simon,

....
> >
> >[PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan
> >
> >this should fix your routing problems, but issue with [0] still exists.
> So I should rebase and submit the whole patch series on bluetooth-next but
> not add a new patch to change net/bluetooth/6lowpan.c ?
> 

until we don't clarify how bluetooth need to handle the pkt_type value
in skb. You should only send one patch [PATCH linux-wpan 3/3] based on
wpan-next then. 

This should fix your routing issue but for me there exist still an issue
at [0] which nobody hit yet.

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

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

Hi,

On Thu, Oct 02, 2014 at 01:12:44PM +0300, Jukka Rissanen wrote:
> 
> Hmm, bluetooth 6lowpan is a bit different from ieee802154 as the
> bluetooth link is a point-to-point one and typically only uses link
> local addresses so normally every packet is really meant for that host.
> 

mhh, when it's point-to-point, how can multicast work? Okay, maybe it's
some broadcast/multicast over point-to-point communication.

I don't understand maybe I should download some 802.15.1 material and read a
little bit more, but for now I have enough to care about the 802.15.4 layer.

- Alex

Re: [PATCH linux-wpan 0/3] Fix handling of skbs of type PACKET_OTHERHOST

[Alexander Aring]

On Thu, Oct 02, 2014 at 12:51:18PM +0200, Alexander Aring wrote:
> Hi,
> 
> On Thu, Oct 02, 2014 at 01:12:44PM +0300, Jukka Rissanen wrote:
> > 
> > Hmm, bluetooth 6lowpan is a bit different from ieee802154 as the
> > bluetooth link is a point-to-point one and typically only uses link
> > local addresses so normally every packet is really meant for that host.
> > 
> 
> mhh, when it's point-to-point, how can multicast work? Okay, maybe it's
> some broadcast/multicast over point-to-point communication.
> 

mhh, seems to be something like that. I mean [0] should describe it how
it works. Maybe detect this mechanism then you know "it's multicast"
and set the pkt_type. I am not an expert for this stuff right now.

Salves and masters, you yes it's very different than 802.15.4, we have
broadcast frames.

- Alex

[0] http://tools.ietf.org/html/draft-ietf-6lowpan-btle-12#section-3.2.4

Re: [PATCH linux-wpan 3/3] ieee802154: 6lowpan: Drop PACKET_OTHERHOST skbs in 6lowpan

[Alexander Aring]

Simon,

I applied now this patch to linux-wpan-next/testing, this should fix
routing problems. For the upcomming issue "always set PACKET_HOST"... I
put it on the TODO list. ;-)

Thanks.

I will send it to bluetooth-next now, then Martin can base his patches
on it.

On Thu, Oct 02, 2014 at 09:56:46AM +0100, Simon Vincent wrote:
> There is no point processing pkts which are PACKET_OTHERHOST
> in 6lowpan as they are discarded as soon as they reach the
> ipv6 layer. Therefore we should drop them in the 6lowpan layer.
> 
> Signed-off-by: Simon Vincent <simon.vincent@xsilon.com>
> ---
>  net/ieee802154/6lowpan_rtnl.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
> index e246edc..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;
>  
> -- 
> 1.9.1
>