@@ -94,6 +94,21 @@ static struct lowpan_nhc *lowpan_nhc_by_nhcid(const struct sk_buff *skb)
return NULL;
}
+/* TODO remove this and do everything in compress callback,
+ * this means, setting NHC bit in IPHC, check if compression
+ * make sense and doing compression. We will hit the issue
+ * when having two bytes long NHC ID's that the IPHC compression
+ * could be have more bytes than using raw next header, this
+ * will break btle 6lowpan.
+ *
+ * Marcel told to look into skb frag and linearlize functionality.
+ * This way is very ugly.
+ * Additonal change handling that sending compressed on transmit
+ * is default disabled. Use a compression flag e.g. RFC6775
+ *
+ * I see nhc in a bad state currently, this need to be fixed
+ * before adding new nhc's.
+ */
int lowpan_nhc_check_compression(struct sk_buff *skb,
const struct ipv6hdr *hdr, u8 **hc_ptr)
{
This patch adds a TODO for nhc to do everything what we need inside compress handling. Also we should check if the compression doesn't add more bytes than sending raw next header format. We don't hit that issue yet because NHC id is at worst case one byte long like the next header byte in IPv6 header (which will be elided when using NHC). But on NHC id's which are two bytes long it's likely that compressions adds more data than sending raw next header. The root of this issue to care about is that with running IPHC after a IPv6 packet which is 1280 bytes long, the IPHC, NHC header with payload should not exceed 1280 bytes. This will break bluetooth L2CAP mtu which is 1280 bytes as well. Signed-off-by: Alexander Aring <aar@pengutronix.de> --- net/6lowpan/nhc.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)