linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Aring <alex.aring@gmail.com>
To: linux-wpan@vger.kernel.org
Cc: linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org,
	kernel@pengutronix.de, mcr@sandelman.ca,
	lukasz.duda@nordicsemi.no, martin.gergeleit@hs-rm.de,
	Alexander Aring <alex.aring@gmail.com>
Subject: [RFCv3 bluetooth-next 0/4] 6lowpan: debugfs and stateful compression support
Date: Sun, 29 Nov 2015 12:34:38 +0100	[thread overview]
Message-ID: <1448796882-316-1-git-send-email-alex.aring@gmail.com> (raw)

Hi,

This patch based on the work of Lukasz Duda. It doesn't contain any interface
lookup methods since we have a generic private dataroom per 6lowpan interface.

Also I dropped the list implementation and do a simple array one. It also
contains support for multicast stateful compression.

To access the context we supporting a complete callback structure for
operations, the include/net/6lowpan.h header contains static inline functions
to call these operations. With such behaviour we don't get any module
dependencies if we need upcomming runtime decisions inside the IPv6 stack.
The alternative would be to do everything inside static inline functions, but
there are few different to handling unicast and multicast context id's, so
it's maybe better to do this as "ops callback structure".

Few things which I am not sure about if it's correct:
 - I implement the dci multicast context table and dci unicast as different
   table. I don't know if when I have a context id "6" which is multicast
   then, I don't can have a unicast context id which is "6". I think they are
   different and we can indicate which table we need to use by the IPHC M bit
   (receiving side)  or the multicast address scope (transmit side).
 - Unicast context prefix length can be shorter than 64 bits. Yes this can be,
   but if somebody wants to do that he usually means "expand the bits until 64
   with zeros". I forbid to add prefix below 64 bits for now.
   Each stateful compression has cases for the IID bits (last 8 byte, use it as
   inline data/do compression, etc.). When I have a prefix 2000:: with prefix
   length 16, then I we hit the case of "Any remaining bits are zero." of
   stateful compression, this means it can be converted by "2000::" prefix
   length 64, then we don't need to care about that when doing a lookup of
   context.
 - I tried to get wireshark know about the available context without success.
   What I successful get working is tell prefix length exact 64 bits long. I
   don't know if wireshark do a correct context handling here, but it's also
   possible to have a prefix length above 64 (In my opinion). E.g. unicast
   stateful compression in case of SAM/DAM 01:
   "Bits covered by context information are always used.  Any IID bits not
    covered by context information are taken directly from the corresponding
    bits carried in-line.

   This patch series do following handling for this case:
   1. generate ipv6 address with inline IID data.
   2. copy the prefix bits from context to the address, which _maybe_ overwrite
      the IID (last eight bytes) data which was carried as inline data.

   This means, if my context is a full address 2001::1/128, then it will be
   the case of SAM/DAM = 11, which means the address is fully elided. (Don't
   care about the IID bits, which will be reconstructed from encapsulating
   header.

   All others SAM/DAM cases has a similar handling.

   Nevertheless I don't know how I can tell that wireshark, I can tell prefix which
   are 64 bit's long only.

Any comments are welcome.

- Alex

changes since RFCv3:
 - add patch for introduce lowpan register/unregister functions
 - change name from ipv6_addr_prefix_cpy to ipv6_addr_prefix_copy
 - move depends on DEBUG_FS to Patch 1/4 (reported by Stefan Schmidt)
 - add "static inline" to lowpan_dev_debugfs_exit if
   CONFIG_6LOWPAN_DEBUGFS is not defined. (reported by some bot)
 - change "enum state" to simple bool and keyword "enabled"
 - change formatstring of prefix-length from "%-03d" to "%-3d", not filled
   with zeros anymore.
 - Add LOWPAN_DEBUGFS_CTX_NUM_ARGS to avoid magic numbers.
 - change name "uninit" to "exit".

changes since RFCv2:
 - fix cleanup for 6LoWPAN per interface debugfs
 - add ipv6_addr_prefix_cpy
 - replace lowpan_iphc_bitcpy with ipv6_addr_prefix_cpy (unicast)
   replace lowpan_iphc_bitcpy with ipv6_addr_prefix and memcpy (multicast)
 - add netdev mailinglist into cc

Alexander Aring (4):
  6lowpan: add lowpan dev register helpers
  6lowpan: add debugfs support
  ipv6: add ipv6_addr_prefix_copy
  6lowpan: iphc: add support for stateful compression

 include/net/6lowpan.h         |  64 +++++-
 include/net/ipv6.h            |  15 ++
 net/6lowpan/6lowpan_i.h       |  31 +++
 net/6lowpan/Kconfig           |   8 +
 net/6lowpan/Makefile          |   1 +
 net/6lowpan/core.c            |  74 ++++++-
 net/6lowpan/debugfs.c         | 166 +++++++++++++++
 net/6lowpan/iphc.c            | 479 +++++++++++++++++++++++++++++++++++++-----
 net/bluetooth/6lowpan.c       |   8 +-
 net/ieee802154/6lowpan/core.c |   6 +-
 10 files changed, 783 insertions(+), 69 deletions(-)
 create mode 100644 net/6lowpan/6lowpan_i.h
 create mode 100644 net/6lowpan/debugfs.c

-- 
2.6.1


             reply	other threads:[~2015-11-29 11:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-29 11:34 Alexander Aring [this message]
2015-11-29 11:34 ` [RFCv3 bluetooth-next 1/4] 6lowpan: add lowpan dev register helpers Alexander Aring
2015-12-01 20:38   ` Stefan Schmidt
2015-11-29 11:34 ` [RFCv3 bluetooth-next 2/4] 6lowpan: add debugfs support Alexander Aring
2015-12-01 20:50   ` Stefan Schmidt
2015-11-29 11:34 ` [RFCv3 bluetooth-next 3/4] ipv6: add ipv6_addr_prefix_copy Alexander Aring
2015-12-01 10:56   ` Hannes Frederic Sowa
2015-12-01 11:17     ` YOSHIFUJI Hideaki/吉藤英明
2015-12-01 11:38   ` Stefan Schmidt
2015-12-01 11:51   ` Duda, Lukasz
2015-11-29 11:34 ` [RFCv3 bluetooth-next 4/4] 6lowpan: iphc: add support for stateful compression Alexander Aring
2015-12-02 14:18   ` Stefan Schmidt
2015-12-03 14:22     ` Alexander Aring
2015-12-04 12:13       ` Stefan Schmidt
2015-12-11 17:05   ` Alexander Aring
2015-12-11 17:13     ` Alexander Aring
2015-12-11 19:11     ` Stefan Schmidt
2015-12-11 19:49       ` 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=1448796882-316-1-git-send-email-alex.aring@gmail.com \
    --to=alex.aring@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=lukasz.duda@nordicsemi.no \
    --cc=martin.gergeleit@hs-rm.de \
    --cc=mcr@sandelman.ca \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).