All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Aring <aar@pengutronix.de>
To: Michael Richardson <mcr@sandelman.ca>
Cc: linux-wpan@vger.kernel.org
Subject: Re: [RFC bluetooth-next 01/20] 6lowpan: ndisc: don't remove short address
Date: Thu, 21 Jul 2016 09:10:15 +0200	[thread overview]
Message-ID: <88ca76b5-2fb4-6201-1bb9-2a6ec2a46fc9@pengutronix.de> (raw)
In-Reply-To: <6d9dc3cd-c272-6f77-a81e-cc6556097c4f@pengutronix.de>

Hi,

On 07/21/2016 08:37 AM, Alexander Aring wrote:
> 
...
> ---
> 
> For the transmit side, I think receive side would be _per_ _socket_
> then, if we using in6_pktinfo. For the transmit side we should have it
> also per socket then.
> 
> My idea with "using neighbour discovery with flags" will not work!
> Because if we doing our own neighbour over IPv6 RAW sockets then we
> don't have a neighbour discovery yet.
> 
> The other solution might work with the "own" hash table and daddr as key
> to map which l2 address will be used, but I think we should be able to
> do this somehow like "IPV6_RECVPKTINFO" just for the tx side.
> 

The b) case and I think this is to control source address as "interface"
attribute to prefer short or extended will be complicated. I currently
think about if you doing that fast while a current socket connection.

You can't control it because sockets have queues (so far I know).
Maybe I am wrong and synced send handling will wait until "xmit
callback" of the interface will be called (It's a zero queue interface).
Zero queue means that there is no qdisc but socket queues exists, so far
I know.

It should be possible to tell somehow over IPv6 raw sockets which
destination address for the l2 address should be used, or? I think the
solution is maybe somewhere in libndp.c I didn't found it yet. We just
need to add support for the 802.15.4 short or extended addr.

Our current implementation will not work with disabled kernelspace
neighbour discovery yet and currently I don't know how it can work when
holding the complete cache inside the userspace. :-/

Disable ndisc handling in kernelspace and do handling in userspace
(RS/RA/NS/NA) but using the neighbour cache in kernel. Means: fill the
neighbour entries in the cache with netlink might work. Don't know which
way we should going here. I need to look into libndp, I think we should
extend it that we can handle short+extended handling from userspace side.

- Alex

  reply	other threads:[~2016-07-21  7:10 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-11 19:50 [RFC bluetooth-next 00/20] bluetooth: rework 6lowpan implementation Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 01/20] 6lowpan: ndisc: don't remove short address Alexander Aring
2016-07-19 13:19   ` Michael Richardson
2016-07-19 18:03     ` Alexander Aring
2016-07-21  6:37       ` Alexander Aring
2016-07-21  7:10         ` Alexander Aring [this message]
2016-07-21  8:44       ` Michael Richardson
2016-07-11 19:50 ` [RFC bluetooth-next 02/20] nhc: add TODO for nhc work Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 03/20] ieee802154: 6lowpan: remove headroom check Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 04/20] ieee802154: 6lowpan: move skb cb BUILD_BUG_ON check Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 05/20] 6lowpan: remove LOWPAN_IPHC_MAX_HEADER_LEN Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 06/20] 6lowpan: hold netdev while unregister Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 07/20] 6lowpan: introduce generic default naming Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 08/20] 6lowpan: move rx defines to generic Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 09/20] bluetooth: introduce l2cap_hdev_chan_connect Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 10/20] bluetooth: add hci dev notifier Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 11/20] bluetooth: export functions and variables Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 12/20] 6lowpan: bluetooth: remove implementation Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 13/20] ieee802154: 6lowpan: move header create to 6lowpan Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 14/20] 6lowpan: move dev_init to generic Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 15/20] 6lowpan: iphc: override l2 packet information Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 16/20] ipv6: addrconf: fix 48 bit 6lowpan autoconfiguration Alexander Aring
2016-07-12 20:16   ` Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 17/20] 6lowpan: iphc: add handling for btle Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 18/20] 6lowpan: move multicast flags to generic Alexander Aring
2016-07-12 20:34   ` Alexander Aring
2016-07-13 11:15     ` Jukka Rissanen
2016-07-14  8:21       ` Alexander Aring
2016-07-14  8:36         ` Alexander Aring
2016-07-19 14:51       ` Michael Richardson
2016-07-19 18:20         ` Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 19/20] 6lowpan: delete addr_len handling " Alexander Aring
2016-07-11 19:50 ` [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation Alexander Aring
2016-07-12 21:19   ` Alexander Aring
2016-07-14 11:40     ` Luiz Augusto von Dentz
2016-07-17 15:52       ` Alexander Aring
2016-07-18  8:59         ` Luiz Augusto von Dentz
2016-07-18 21:52           ` Alexander Aring
2016-07-19  5:45             ` Johan Hedberg
2016-07-19  8:23               ` Luiz Augusto von Dentz
2016-07-19 21:05                 ` Alexander Aring
2016-07-20  7:39                   ` Johan Hedberg
2016-07-20  8:14                     ` Luiz Augusto von Dentz
2016-07-20 10:22                     ` Marcel Holtmann
2016-07-19  8:49             ` Luiz Augusto von Dentz
2016-07-19 14:48               ` Michael Richardson
2016-07-19 21:24               ` Alexander Aring
2016-07-12 14:51 ` [RFC bluetooth-next 00/20] bluetooth: rework 6lowpan implementation Luiz Augusto von Dentz
2016-07-12 18:35   ` Alexander Aring
2016-07-13  9:12     ` Alexander Aring
2016-07-13 10:13       ` Luiz Augusto von Dentz
2016-07-13 10:56         ` Alexander Aring
2016-07-14 12:02           ` Luiz Augusto von Dentz
2016-07-19 12:58 ` Michael Richardson
2016-08-05  7:15 ` Bakke, Glenn Ruben
2016-08-05  9:18   ` 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=88ca76b5-2fb4-6201-1bb9-2a6ec2a46fc9@pengutronix.de \
    --to=aar@pengutronix.de \
    --cc=linux-wpan@vger.kernel.org \
    --cc=mcr@sandelman.ca \
    /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.