Hi Martin,
On Wed, Dec 04, 2013 at 02:39:02PM +, Martin Townsend wrote:
> Hi,
>
> I have a 3.10 Kernel from a Xilinx repository that I'm using. I would
> like to build with your latest IEEE802154 and 6lowpan code including
> Alexander's recent patches. What would be the best way for me to
Hi,
I have a 3.10 Kernel from a Xilinx repository that I'm using. I would
like to build with your latest IEEE802154 and 6lowpan code including
Alexander's recent patches. What would be the best way for me to do this?
Best Regards,
Martin.
-
This patch adds necessary ieee802154 6lowpan namespace to provide the
inet_frag information. This is a initial support for handling 6lowpan
fragmentation with the inet_frag api.
Signed-off-by: Alexander Aring
---
include/net/net_namespace.h| 4
include/net/netns/ieee802154_6low
The current fragmentation handling isn't rfc compatible and have several
issues.
On receiving side the fragmentation use a own implemented api which have
issues like:
- Race conditions in fragmentation list handling
- Match on fragmentation tag id only
This patch series add support for fragment
This patch fix the fragmentation on sending side according to rfc4944.
Also add improvement to use the full payload of a PDU which calculate the
nearest divided to 8 payload length for the fragmentation datagram
offset attribute.
The main issue is that the datagram_size of fragmentation header us
This patch adds a 6lowpan fragmentation struct into cb of skb which
is necessary to hold fragmentation information.
Signed-off-by: Alexander Aring
---
include/net/ieee802154_netdev.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee8021
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index d64cdd1..abb362e 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1176,7 +1176,7 @@
This patch drops the current way of 6lowpan fragmentation on receiving
side and replace it with a implementation which use the inet_frag api.
The old fragmentation handling has some race conditions and isn't
rfc4944 compatible. Also adding support to match fragments on
destination and source addres