All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jukka Rissanen <jukka.rissanen@linux.intel.com>
To: Alexander Aring <aar@pengutronix.de>,
	Linux Bluetooth <linux-bluetooth@vger.kernel.org>
Cc: linux-wpan@vger.kernel.org, kernel@pengutronix.de,
	patrik.flykt@linux.intel.com
Subject: Re: current btle 6lowpan issues
Date: Thu, 16 Jun 2016 13:00:58 +0300	[thread overview]
Message-ID: <1466071258.31678.12.camel@linux.intel.com> (raw)
In-Reply-To: <ccd6b822-4af0-ea89-2dba-b914e6427191@pengutronix.de>

Hi Alex,

On Wed, 2016-06-15 at 20:02 +0200, Alexander Aring wrote:
> Hi,
> 
> I like to collect some _big_ issues which I detected on current btle
> 6lowpan
> implementation, these are:
> 
>  1. The l2 daddr comes not from ndisc cache. This should come from
> ndisc
>     cache, instead the implementation construct the l2 from L3
> address
>     which only works for autoconfiguration addresses, all other
>     addresses seems not be working for btle 6lowpan.
> 
>  2. The dev->dev_addr should be the 6 byte baddr and NOT the eui64
>     generated baddr with fffe pattern and u/l bit. The eui64 should
> not
>     be part of source/target address options of ndisc messages, it
> should
>     be the baddr in big endian format. (dev->addr_len need to be 6
> then,
>     as well). baddr is the mac address of btle transceiver.
> 
> The 1. is easy to fix, but then I detected if we do that, the
> neighbour
> cache messages NS/NA/RS, etc use the eui64 fffe pattern with u/l bit
> for
> these messages, because the issue 2. So we will get the wrong address
> from ndisc. The ndisc should store the 6 bytes baddr in big endian
> format.
> So these two issues need to be fixed in some patch and changes
> everything
> in btle 6lowpan.
> 
> I started to work on this but the issue 2. is a big change in btle
> 6lowpan
> so I want to start the discussion about to fix that to doing it in
> the
> right way.
> 
> Jukka, do you agree that this behaviour is currently broken in btle
> 6lowpan?

Yes you are right that there are issues. Fortunately the bt0 is
currently a point-to-point link in which case ND is not really done and
everything kind of "works" ok.

I added Patrik to cc: as he has been working to fix the issues but the
patches are not yet ready. Perhaps we could combine the efforts here.


Cheers,
Jukka


  reply	other threads:[~2016-06-16 10:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-15 18:02 current btle 6lowpan issues Alexander Aring
2016-06-16 10:00 ` Jukka Rissanen [this message]
2016-06-16 13:41   ` Patrik Flykt
2016-06-16 21:38     ` Alexander Aring
2016-06-20  7:07       ` Jukka Rissanen
2016-07-05 13:13   ` Michael Richardson

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=1466071258.31678.12.camel@linux.intel.com \
    --to=jukka.rissanen@linux.intel.com \
    --cc=aar@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=patrik.flykt@linux.intel.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.