Re: [PATCHv3 bluetooth-next 3/3] 6lowpan: nhc: add other known rfc6282 compressions

[Alexander Aring <alex.aring@gmail.com>]

Hi Jukka,

On Tue, Dec 09, 2014 at 01:28:16PM +0200, Jukka Rissanen wrote:
> Hi Alex,
> 
> the module unloading caused some issues in the receiving end.
> 
> I tried this:
> * setup bluetooth 6lowpan connection
> * transfer some UDP data
> * unload the nhc_rfc6282_udp module (in one peer only, the other still
> had udp nhc module loaded)
> * try to send more data
> 
> This caused kernel crash in peer that had udp module unloaded:
> 
> 

mhh, okay. I don't know why this happens also the log gave me not much
information, but thanks anyway.

Maybe this is a global issue with bluetooth 6LoWPAN error handling.

Can you simple do something like this:

diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index 32ffec6..2228dce 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -425,6 +425,8 @@ lowpan_header_decompress(struct sk_buff *skb, struct net_device *dev,
                        return -EINVAL;
        }
 
+       return -EINVAL;
+
        /* UDP data uncompression */
        if (iphc0 & LOWPAN_IPHC_NH_C) {
                struct udphdr uh;


based on current bluetooth-next/master without the NHC framework.

This should be working, maybe you never hit any error while calling
lowpan_header_decompress function. It's simple testing the error
handling not more.

Do this please on one node, the other node should send some 6LoWPAN IPHC
packets to check if the error handling working there.





Another issue is that I see that skb->dev isn't set before calling
lowpan_header_decompress. Because inside your log is a "NULL":

(NULL net_device): received unknown nhc id which was not found.

Can you change that? That skb->dev is set to before calling
lowpan_header_decompress.


btw: 802154 has also issues with that the dev is a wpan interface but
should be a lowpan interface. It's a complicated issue because we
support more than one lowpan interface at the same time for _one_ wpan
interface. I will change that later because this has not any useful usecase
at the moment. The new behaviour is then _one_ wpan interface -> _one_ lowpan
interface.

First we need to know if global error handling is working there. Another
solution for the NULL string would be "don't using netdev_foo printouts,
but then nobody knows which interface has this issue.

- Alex