From patchwork Tue Dec 15 11:08:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 556923 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 459C71402D9 for ; Tue, 15 Dec 2015 22:08:54 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=QFzvgtxr; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964963AbbLOLIu (ORCPT ); Tue, 15 Dec 2015 06:08:50 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:37338 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964803AbbLOLIt (ORCPT ); Tue, 15 Dec 2015 06:08:49 -0500 Received: by mail-wm0-f51.google.com with SMTP id n186so20111361wmn.0; Tue, 15 Dec 2015 03:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WdKaQ/IEaQoCXX/p8Th0wuHH7MovfIzwA+f1ZU0NrRA=; b=QFzvgtxr/jEUfCvJPfGyGrv0jB47v1HMaUUHKafgFDPyhwxF7VgWaHfGp5k04mqACr NpsGf/eMJNbUMn6gsmNACIVVf0lwfRu5YNSSJCebBgHFKl47xwh+VTckl6h8KNtT3lR/ 7fg/UlA6kB05eCXN+eixeOI/CTdTHET3XT3vEx9YglFbl56ny3UwooHka7PuoD7evVFa eFTdrvCL+BvCih+17v2z3d5fKShCWbAN0Ll39o6qS08aVX2wK6RLS74fTgb/aj0XNbNJ tSS2t9/dPkIR7db+ikWINLRXsznwonsDuVZiDOqkKHbUTUq0qOPn/U6pfCUcgrhHv6wU IB7w== X-Received: by 10.28.229.65 with SMTP id c62mr3695069wmh.25.1450177727801; Tue, 15 Dec 2015 03:08:47 -0800 (PST) Received: from omega (p20030064A90B1446E2CB4EFFFE1BB546.dip0.t-ipconnect.de. [2003:64:a90b:1446:e2cb:4eff:fe1b:b546]) by smtp.gmail.com with ESMTPSA id id1sm326117wjb.19.2015.12.15.03.08.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Dec 2015 03:08:47 -0800 (PST) Date: Tue, 15 Dec 2015 12:08:41 +0100 From: Alexander Aring To: "Duda, Lukasz" Cc: "linux-wpan@vger.kernel.org" , "linux-bluetooth@vger.kernel.org" , "netdev@vger.kernel.org" , "kernel@pengutronix.de" , "mcr@sandelman.ca" , "martin.gergeleit@hs-rm.de" Subject: Re: [RFCv4 bluetooth-next 1/2] 6lowpan: iphc: add support for stateful compression Message-ID: <20151215110835.GA3774@omega> References: <1450101654-22633-1-git-send-email-alex.aring@gmail.com> <1450101654-22633-2-git-send-email-alex.aring@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Dec 15, 2015 at 10:29:51AM +0000, Duda, Lukasz wrote: > First of all great work for your series of patches on 6lowpan improvements and > stateful compression! > > I have just done some testing of this patch (without RADVD modifications), and > I can share my experiments using 6LoWPAN over BT-LE by sending simple ICMPv6 > messages. Contexts for BTLE device has been added manually. > did you test that with linux <-> linux? Or linux <-> $SOME_OTHER_6LOWPAN_BTLE_STACK. I tested it on my side with RIOT, it has 802.15.4 6LoWPAN support and also manipulate manually the context table. > Experiment 1: > > Router: 2001:db8::1/64 BTLE: 2001:db8::211:22FF:FE33:4455/64 > CID 1: 2001:db8::/64 > > Works fine, I see that CID 1 is used for both addresses. Router has 64 bits of > IID inline and BTLE node has 0. > > Experiment 2: > > Router: 2001:db8::1/64 BTLE: 2001:db8::211:22FF:FE33:4455/64 > CID 3: 2001:db8::/64 CID 5: 2001:db8::1/128 > > Works also fine, I see that both CID 3 and 5 are used, as well as both sides > compress its IID in the best possible way. So the patch appears to work fine on > 6LoWPAN over BT-LE. > ok. > > However, I notice that the folder created in the sys/kernel/debug/6lowpan/ for > my bluetooth network interface is called "bt%d". And I would imagine this > should be "bt0", "bt1", ... and not the template? > urgh, this should not happen. I use "dev->name" for that and dev is the netdevice structure. This should be an _unique_ interface name, otherwise you will getting trouble if you have two btle 6lowpan interfaces. I didn't realized it because I create my interface with: ip link add link wpan0 name lowpan0 type lowpan but should change it into: ip link add link wpan0 name lowpan%d type lowpan I realized that the dev->name will be changed from template into "real" name after registering. This should do the job: I think it should be safe to do that after registering because we held the RTNL lock. And the interface isn't up after registering. > Also, I notice that the compression for Flow Control and Traffic Label in IPv6 > header has been modified, these fields are no longer compressed in any packets > (0b11 value) that comes from Linux Kernel (e.g. ICMP Echo Request, > Router Advertisement), instead I get three extra bytes (0b01 value). > I would like to understand reason for this modification a little better. 0b11 means that traffic class and flow label are zero. Are you sure that these fields are zero inside the IPv6 header when you transmit "e.g. ICMP Echo Request, RA"? Can you verify this by running tcpdump/wireshark? Or instruments some printk's at [0] for hdr->flow_lbl array and hdr->priority? - Alex [0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L428 --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/6lowpan/core.c b/net/6lowpan/core.c index c7f06f5..faf65ba 100644 --- a/net/6lowpan/core.c +++ b/net/6lowpan/core.c @@ -29,13 +29,13 @@ int lowpan_register_netdevice(struct net_device *dev, lowpan_priv(dev)->lltype = lltype; - ret = lowpan_dev_debugfs_init(dev); + ret = register_netdevice(dev); if (ret < 0) return ret; - ret = register_netdevice(dev); + ret = lowpan_dev_debugfs_init(dev); if (ret < 0) - lowpan_dev_debugfs_exit(dev); + unregister_netdevice(dev); return ret; }