current btle 6lowpan issues

current btle 6lowpan issues

[Alexander Aring]

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?

- Alex

Re: current btle 6lowpan issues

[Jukka Rissanen]

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

Re: current btle 6lowpan issues

[Patrik Flykt]

On Thu, 2016-06-16 at 13:00 +0300, Jukka Rissanen wrote:
> 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.

I had some patches that make BTLE interfaces non-point-to-point. Let me
check that they can be applied on the latest bluetooth-next and that
they still compile after a few months of sitting on an old version.
Then let's hope they also work as expected...

Cheers,

	Patrik

Re: current btle 6lowpan issues

[Alexander Aring]

Hi,

On 06/16/2016 03:41 PM, Patrik Flykt wrote:
> On Thu, 2016-06-16 at 13:00 +0300, Jukka Rissanen wrote:
>> 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.
> 
> I had some patches that make BTLE interfaces non-point-to-point. Let me
> check that they can be applied on the latest bluetooth-next and that
> they still compile after a few months of sitting on an old version.
> Then let's hope they also work as expected...
> 

With non-point-to-point you mean to remove the IFF_POINTOPOINT flag in
net_device? Yes this should be removed.

But I think this is one of the smallest issue in btle 6lowpan.

What means "ND is not really done", does that means you will not see
btle neighbours by doing "ip -6 neigh" for your bt interface?

I don't believe that and I think no matter if you set IFF_POINTOPOINT or
not, the IPv6 stack will mostly ignore such flag. I did a grep and it
seems the SIT stuff sets this flag and IPv6 stack does something with
that, but not in case of ARPHRD_6LOWPAN, it's for ARPHRD_SIT only. So I
think this flag makes some "peer" address in "ip a" handling instead of
showing broadcast address. But nobody will make special handling in IPv6
or btle 6lowpan if this flag is set.

What I mean is, you can set this flag on or off but it will don't change
any behaviour.

---

Back to the two issues which I mentioned. I suppose "ip -6 neigh" shows
currently some neighbours or not? I don't believe, that IPv6 can
working without any neighbours in "ip -6 neigh", otherwise the IPv6
stack would send NS messages again and again. (Because 2. issue the
addresses in ndisc is not be the 6-byte address of bluetooth device, it's
the fffe with u/l bit flip stuff, which is the /64 prefix of
autoconfiguration L3 address which is wrong.)

These NS messages have some multicast address as L3 daddr and so far I
know, it should be working like the following example: 
(correct me if I am wrong)

         _____ Slave #1 (6LN)
        /
Master #0 (6LBR)
        \----- Slave #2 (6LN)
	 \
	  \--- Slave #n (6LN)
	   \
	    \- ... (6LN)
	     .
	      .
	       .

So if one Slave multicast address as destination, the master need to
send to all Slaves the same 6lowpan packet to handle somehow the
multicast stuff for L2 point-to-point connection.

I think it's described at [0], also there is somewhere some nicer
graphic.

So far I see it in the code, there is no such implementation to realize
multicasting on btle 6lowpan, or?

---

My questions are:

The neighbour cache stores the wrong addresses because the dev->addr isn't
the real bluetooth device addr and we need to use the l2 addr getting from
ndisc cache. Will this be fixed in the pending patch series?

As an example I can show you [1], which should be something like:

(I changed some variable names, just a byteswap)

dev->dev_addr[0] = bdaddr->b[5];
dev->dev_addr[1] = bdaddr->b[4];
dev->dev_addr[2] = bdaddr->b[3];
dev->dev_addr[3] = bdaddr->b[2];
dev->dev_addr[4] = bdaddr->b[1];
dev->dev_addr[5] = bdaddr->b[0];

The fffe, and bitflip for has nothing to do with that, this is necessary
for the /64 prefix in case of autoconfiguration [2], which should look
something like:

static int addrconf_ifid_eui64(u8 *eui, struct net_device *dev)
{
       switch (lowpan_dev(dev)->lltype) {
       case LOWPAN_LLTYPE_BTLE:
               if (dev->addr_len != 6)
                       return -1;

               memcpy(eui, dev->dev_addr, 3);
               memcpy(eui + 5, dev->dev_addr + 3, 3);
               eui[3] = 0xFF;
               eui[4] = 0xFE;

               /* Universal/local bit set, BT 6lowpan draft ch. 3.2.1 */
               if (*(dev->dev_addr + 5) & 0x02)
                       eui[0] |= 0x02;
               else
                       eui[0] &= ~0x02;
               break;
       default:
               if (dev->addr_len != EUI64_ADDR_LEN)
                       return -1;

               memcpy(eui, dev->dev_addr, EUI64_ADDR_LEN);
               eui[0] ^= 2;
               break;
       }

       return 0;
}

Second question:

Still I don't know what exactly "some patches that make BTLE interfaces
non-point-to-point" really means here. Dropping the above mentioned flag
will not fix this behaviour. What does this really mean?

- Alex

[0] https://tools.ietf.org/html/rfc7668#section-3.2.5
[1] http://lxr.free-electrons.com/source/net/bluetooth/6lowpan.c#L674
[2] http://lxr.free-electrons.com/source/net/ipv6/addrconf.c#L1963

Re: current btle 6lowpan issues

[Jukka Rissanen]

Hi Alex,

On Thu, 2016-06-16 at 23:38 +0200, Alexander Aring wrote:
> Hi,
> 
> On 06/16/2016 03:41 PM, Patrik Flykt wrote:
> > 
> > On Thu, 2016-06-16 at 13:00 +0300, Jukka Rissanen wrote:
> > > 
> > > 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.
> > I had some patches that make BTLE interfaces non-point-to-point.
> > Let me
> > check that they can be applied on the latest bluetooth-next and
> > that
> > they still compile after a few months of sitting on an old version.
> > Then let's hope they also work as expected...
> > 
> With non-point-to-point you mean to remove the IFF_POINTOPOINT flag
> in
> net_device? Yes this should be removed.

Yes, agreed.

> 
> But I think this is one of the smallest issue in btle 6lowpan.
> 
> What means "ND is not really done", does that means you will not see
> btle neighbours by doing "ip -6 neigh" for your bt interface?

Yes.

> 
> I don't believe that and I think no matter if you set IFF_POINTOPOINT
> or
> not, the IPv6 stack will mostly ignore such flag. I did a grep and it
> seems the SIT stuff sets this flag and IPv6 stack does something with
> that, but not in case of ARPHRD_6LOWPAN, it's for ARPHRD_SIT only. So
> I
> think this flag makes some "peer" address in "ip a" handling instead
> of
> showing broadcast address. But nobody will make special handling in
> IPv6
> or btle 6lowpan if this flag is set.
> 
> What I mean is, you can set this flag on or off but it will don't
> change
> any behaviour.

Unfortunately there is a different behaviour. If the interface has
IFF_POINTTOPOINT, then kernel will not send neighbor discovery messages
to that link. I have not checked the kernel code where exactly that is
enforced but I have looked the wireshark output and there are no ND's
sent if bt0 is p-to-p link. If the flag is removed, the device starts
to send ND's to that interface.

Removing the IFF_POINTTOPPOINT is not enough as the MAC address will be
wrongly set in that case as you have noticed.


Cheers,
Jukka

Re: current btle 6lowpan issues

[Michael Richardson]

Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote:
    >> 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've read that btle 4.2, while it won't permit one to maintain multiple
links at the same time, will permit a device to quickly cycle between
multiple attachments.  A device could therefore move from one btle star to
another one several times per second, and route packets that way.
This puts btle in the same space as time slotted -- 6tisch (802.15.4e).

My gut is that btle will be *the* low-power mesh tech in ten years.
(Unless it's DECT...)

The other situation in which we might need more than ptp is when we have
multiple btle radios, or when we are doing any kind of layer-3 mesh with
multiple technologies...