All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Vincent <simon.vincent@xsilon.com>
To: Alexander Aring <alex.aring@gmail.com>
Cc: Varka Bhadram <varkabhadram@gmail.com>, linux-wpan@vger.kernel.org
Subject: Re: ICMPv6 Redirects
Date: Tue, 30 Sep 2014 09:34:29 +0100	[thread overview]
Message-ID: <542A6B15.7060203@xsilon.com> (raw)
In-Reply-To: <20140929164157.GA17633@omega>

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


  reply	other threads:[~2014-09-30  8:34 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26 15:16 ICMPv6 Redirects Simon Vincent
2014-09-26 15:35 ` Alexander Aring
2014-09-26 16:26   ` Simon Vincent
2014-09-27  1:42     ` Alexander Aring
2014-09-29 10:20       ` Simon Vincent
2014-09-29 10:58         ` Varka Bhadram
2014-09-29 11:09           ` Simon Vincent
     [not found]             ` <5429441C.5000302@gmail.com>
     [not found]               ` <5429466F.4080506@gmail.com>
2014-09-29 11:53                 ` Alexander Aring
2014-09-29 11:57                   ` Alexander Aring
     [not found]                     ` <542949AE.30701@gmail.com>
2014-09-29 12:14                       ` Alexander Aring
     [not found]                       ` <54294BE7.7040501@gmail.com>
2014-09-29 12:14                         ` Alexander Aring
     [not found]                 ` <54295556.3030800@xsilon.com>
2014-09-29 13:12                   ` Alexander Aring
2014-09-29 13:30                     ` Alexander Aring
2014-09-29 13:33                       ` Simon Vincent
2014-09-29 13:38                         ` Alexander Aring
2014-09-29 13:41                           ` Alexander Aring
2014-09-29 13:51                           ` Simon Vincent
2014-09-29 13:54                             ` Varka Bhadram
2014-09-29 14:12                               ` Simon Vincent
2014-09-29 13:58                             ` Alexander Aring
2014-09-29 14:05                               ` Varka Bhadram
2014-09-29 14:12                                 ` Alexander Aring
2014-09-29 14:15                                   ` Varka Bhadram
2014-09-29 14:19                                     ` Alexander Aring
2014-09-29 14:12                               ` Simon Vincent
2014-09-29 14:17                                 ` Alexander Aring
2014-09-29 14:39                                 ` Alexander Aring
2014-09-29 14:51                                   ` Alexander Aring
2014-09-29 16:41                                 ` Alexander Aring
2014-09-30  8:34                                   ` Simon Vincent [this message]
2014-09-30  8:34                                     ` Varka Bhadram
2014-09-30  8:39                                     ` Alexander Aring
2014-09-30  8:46                                       ` Varka Bhadram
2014-09-30  8:53                                         ` Alexander Aring
2014-09-30  9:10                                           ` Varka Bhadram
2014-09-30  9:25                                             ` Alexander Aring
2014-09-30  9:35                                               ` Varka Bhadram
2014-09-30  9:43                                                 ` Alexander Aring
     [not found]                                                   ` <542A7D85.8050608@gmail.com>
2014-09-30 10:03                                                     ` Alexander Aring
2014-09-30 10:55                                                       ` Jukka Rissanen
2014-09-30 11:13                                                         ` Alexander Aring
2014-09-30 11:35                                                           ` Alexander Aring
2014-09-29 11:13         ` Alexander Aring
2014-09-29 11:23           ` Alexander Aring
2014-09-29 11:37             ` Alexander Aring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542A6B15.7060203@xsilon.com \
    --to=simon.vincent@xsilon.com \
    --cc=alex.aring@gmail.com \
    --cc=linux-wpan@vger.kernel.org \
    --cc=varkabhadram@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.