RPi, Raspbian with openlabs transceiver - lib/tool versions and updated instructions(?)

RPi, Raspbian with openlabs transceiver - lib/tool versions and updated instructions(?)

[Christoffer Holmstedt]

I'm currently setting up my dev/test environment to get a "default"
working state to build upon but have stumbled upon some issues on the
way. I'm currently running Raspbian with latest bluetooth-next kernel.
U-Boot from last november. For libnl I use the default packages
available in Raspbian repository. wpan-tools I've checked out the 0.4
release from git repository.

U-Boot: 2014-11-10 [1]
Raspbian version: 2015-02-16 (originally built with 3.18 kernel)
Bluetooth-next kernel 4.1.0-rc1+ 2015-04-30 [2]
libnl-3-dev version: 3.2.7-4 (Raspbian repository)
libnl-genl-3-dev version: 3.2.7-4 (Raspbian repository)
wpan-tools (tag: wpan-tools-0.4) [3]

Is this set of libraries/tools ever going to work together or do I
have an obvious mismatch that will for sure fail?

### command failed: Device or resource busy (-16)
The problem I have now is that when I try to set pan_id as described
on wpan.cakelab.org I get "resource is busy" error. I also have two
wpan interfaces which I'm not sure is what I should expect, as only
one transceiver is connected to the RPi.

$ sudo iwpan --debug dev wpan0 set pan_id 0xbeef (almost identical
response for wpan1)
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 36
    .nlmsg_type = 21 <0x15>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1430895752
    .nlmsg_pid = 12459
  [PAYLOAD] 20 octets
    0a 00 00 00 08 00 03 00 02 00 00 00 06 00 09 00 ef be ..................
    00 00                                                 ..
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 56
    .nlmsg_type = 2 <ERROR>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 1430895752
    .nlmsg_pid = 12459
  [ERRORMSG] 20 octets
    .error = -16 "Device or resource busy"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .nlmsg_type = 21 <0x15>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1430895752
    .nlmsg_pid = 12459
---------------------------  END NETLINK MESSAGE   ---------------------------
command failed: Device or resource busy (-16)

### iwpan dev and ifconfig gives me the following information:
$ iwpan dev
phy#1
    Interface wpan1
        ifindex 3
        wpan_dev 0x100000001
        extended_addr 0x4507b443ff180a33
        short_addr 0xffff
        pan_id 0xffff
        type node
        max_frame_retries -1
        min_be 3
        max_be 5
        max_csma_backoffs 4
        lbt 0
phy#0
    Interface wpan0
        ifindex 2
        wpan_dev 0x1
        extended_addr 0x0000000000000000
        short_addr 0xffff
        pan_id 0xffff
        type node
        max_frame_retries -1
        min_be 3
        max_be 5
        max_csma_backoffs 4
        lbt 0

$ ifconfig
wpan0     Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:300
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wpan1     Link encap:UNSPEC  HWaddr
45-07-B4-43-FF-18-0A-33-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:300
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

### Instructions available
The most up to date instructions I have found are from august last
year and outdated (openlabs.co), has anyone else written a blog post
or similar on how to get a working setup running?

[1] https://github.com/swarren/u-boot/tree/4f70244e0a1a0d68cf3c5493998ff3565f38d825
[2] https://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=1add15646672ff4e7fe59bec2afcb5a0c80c5e49
[3] https://github.com/linux-wpan/wpan-tools/releases/tag/wpan-tools-0.4

Regards
-- 
Christoffer Holmstedt

Re: RPi, Raspbian with openlabs transceiver - lib/tool versions and updated instructions(?)

[Alexander Aring]

On Wed, May 06, 2015 at 09:27:39AM +0200, Christoffer Holmstedt wrote:
> I'm currently setting up my dev/test environment to get a "default"
> working state to build upon but have stumbled upon some issues on the
> way. I'm currently running Raspbian with latest bluetooth-next kernel.
> U-Boot from last november. For libnl I use the default packages
> available in Raspbian repository. wpan-tools I've checked out the 0.4
> release from git repository.
> 
> U-Boot: 2014-11-10 [1]
> Raspbian version: 2015-02-16 (originally built with 3.18 kernel)
> Bluetooth-next kernel 4.1.0-rc1+ 2015-04-30 [2]
> libnl-3-dev version: 3.2.7-4 (Raspbian repository)
> libnl-genl-3-dev version: 3.2.7-4 (Raspbian repository)
> wpan-tools (tag: wpan-tools-0.4) [3]
> 
> Is this set of libraries/tools ever going to work together or do I
> have an obvious mismatch that will for sure fail?
> 
> ### command failed: Device or resource busy (-16)

I think this is because raspbian has running the ifplug deamon (ifplugd)
which do an interface up if you want to do an interface down.

Guenther documented this at [0]. Try to do a:

kill $(ps awux | grep "[i]fplugd.*wpan0" | awk '{print $2}')

into your shell. Then be sure that your interface is down before setting
the pan_id.

Also I saw you have two interfaces and the wpan0 smells like the
fakelb(because zero mac address), I currently don't trust the fakelb
transceiver. It's a poor driver which should be updated. So in your case
you should use the wpan1 interface or remove the fakelb module by
putting this module in your blacklist.


more background about interface up and address settings:

The reason why we doesn't allow this is because if the interface is up
and we allow to change the address filter settings in this situation the
locking mechanism is a lot of complicated while parsing the frame. To
avoid that we simple say "it's a readonly variable when parsing the
frame can be occur". The conclusion is we don't need any locking of this
variable in a very "strong" context while parsing the frame. If the
interface is down, the rtnl mutex is enough to protect this variable.

The address filter will be filled when an interface up occurs again then.

- Alex

[0] https://honk.sigxcpu.org/piki/hw/rpi6lowpan/

Fwd: RPi, Raspbian with openlabs transceiver - lib/tool versions and updated instructions(?)

[Varka Bhadram]

Hi,

On 05/06/2015 12:57 PM, Christoffer Holmstedt wrote:

I'm currently setting up my dev/test environment to get a "default"
working state to build upon but have stumbled upon some issues on the
way. I'm currently running Raspbian with latest bluetooth-next kernel.
U-Boot from last november. For libnl I use the default packages
available in Raspbian repository. wpan-tools I've checked out the 0.4
release from git repository.

U-Boot: 2014-11-10 [1]
Raspbian version: 2015-02-16 (originally built with 3.18 kernel)
Bluetooth-next kernel 4.1.0-rc1+ 2015-04-30 [2]
libnl-3-dev version: 3.2.7-4 (Raspbian repository)
libnl-genl-3-dev version: 3.2.7-4 (Raspbian repository)
wpan-tools (tag: wpan-tools-0.4) [3]

Is this set of libraries/tools ever going to work together or do I
have an obvious mismatch that will for sure fail?

### command failed: Device or resource busy (-16)
The problem I have now is that when I try to set pan_id as described
on wpan.cakelab.org I get "resource is busy" error. I also have two
wpan interfaces which I'm not sure is what I should expect, as only
one transceiver is connected to the RPi.

$ sudo iwpan --debug dev wpan0 set pan_id 0xbeef (almost identical
response for wpan1)
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 36
    .nlmsg_type = 21 <0x15>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1430895752
    .nlmsg_pid = 12459
  [PAYLOAD] 20 octets
    0a 00 00 00 08 00 03 00 02 00 00 00 06 00 09 00 ef be ..................
    00 00                                                 ..
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 56
    .nlmsg_type = 2 <ERROR>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 1430895752
    .nlmsg_pid = 12459
  [ERRORMSG] 20 octets
    .error = -16 "Device or resource busy"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .nlmsg_type = 21 <0x15>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1430895752
    .nlmsg_pid = 12459
---------------------------  END NETLINK MESSAGE   ---------------------------
command failed: Device or resource busy (-16)

### iwpan dev and ifconfig gives me the following information:
$ iwpan dev
phy#1
    Interface wpan1
        ifindex 3
        wpan_dev 0x100000001
        extended_addr 0x4507b443ff180a33
        short_addr 0xffff
        pan_id 0xffff
        type node
        max_frame_retries -1
        min_be 3
        max_be 5
        max_csma_backoffs 4
        lbt 0
phy#0
    Interface wpan0
        ifindex 2
        wpan_dev 0x1
        extended_addr 0x0000000000000000
        short_addr 0xffff
        pan_id 0xffff
        type node
        max_frame_retries -1
        min_be 3
        max_be 5
        max_csma_backoffs 4
        lbt 0

$ ifconfig
wpan0     Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:300
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wpan1     Link encap:UNSPEC  HWaddr
45-07-B4-43-FF-18-0A-33-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:300
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

### Instructions available
The most up to date instructions I have found are from august last
year and outdated (openlabs.co), has anyone else written a blog post
or similar on how to get a working setup running?

[1] https://github.com/swarren/u-boot/tree/4f70244e0a1a0d68cf3c5493998ff3565f38d825
[2] https://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=1add15646672ff4e7fe59bec2afcb5a0c80c5e49
[3] https://github.com/linux-wpan/wpan-tools/releases/tag/wpan-tools-0.4

Regards

Similar issue faced by the community previously. see thread at [1].

The surprising thing is you got two interfaces for single h/w device.

Guido Günther wrote a blog at [2] for setup.

[1]: http://www.spinics.net/lists/linux-wpan/msg01593.html
[2]: https://honk.sigxcpu.org/piki/hw/rpi6lowpan/

-- 
Varka Bhadram

Re: RPi, Raspbian with openlabs transceiver - lib/tool versions and updated instructions(?)

[Michael C. Cambria]

On 05/06/2015 05:08 AM, Alexander Aring wrote:
> On Wed, May 06, 2015 at 09:27:39AM +0200, Christoffer Holmstedt wrote:
>> I'm currently setting up my dev/test environment to get a "default"
>> working state to build upon but have stumbled upon some issues on the
>> way. I'm currently running Raspbian with latest bluetooth-next kernel.
>> U-Boot from last november. For libnl I use the default packages
>> available in Raspbian repository. wpan-tools I've checked out the 0.4
>> release from git repository.
>>
>> U-Boot: 2014-11-10 [1]
>> Raspbian version: 2015-02-16 (originally built with 3.18 kernel)
>> Bluetooth-next kernel 4.1.0-rc1+ 2015-04-30 [2]
>> libnl-3-dev version: 3.2.7-4 (Raspbian repository)
>> libnl-genl-3-dev version: 3.2.7-4 (Raspbian repository)
>> wpan-tools (tag: wpan-tools-0.4) [3]
>>
>> Is this set of libraries/tools ever going to work together or do I
>> have an obvious mismatch that will for sure fail?
>>
>> ### command failed: Device or resource busy (-16)
> I think this is because raspbian has running the ifplug deamon (ifplugd)
> which do an interface up if you want to do an interface down.
>
> Guenther documented this at [0]. Try to do a:
>
> kill $(ps awux | grep "[i]fplugd.*wpan0" | awk '{print $2}')
>
> into your shell. Then be sure that your interface is down before setting
> the pan_id.

I have been able to fix this at boot time by changing /etc/defaults/ifplugd

From:

INTERFACES="auto"
HOTPLUG_INTERFACES="all"

to:

INTERFACES="eth0"
HOTPLUG_INTERFACES="eth0"

> Also I saw you have two interfaces and the wpan0 smells like the
> fakelb(because zero mac address), I currently don't trust the fakelb
> transceiver. It's a poor driver which should be updated. So in your case
> you should use the wpan1 interface or remove the fakelb module by
> putting this module in your blacklist.
>
>
> more background about interface up and address settings:
>
> The reason why we doesn't allow this is because if the interface is up
> and we allow to change the address filter settings in this situation the
> locking mechanism is a lot of complicated while parsing the frame. To
> avoid that we simple say "it's a readonly variable when parsing the
> frame can be occur". The conclusion is we don't need any locking of this
> variable in a very "strong" context while parsing the frame. If the
> interface is down, the rtnl mutex is enough to protect this variable.
>
> The address filter will be filled when an interface up occurs again then.
>
> - Alex
>
> [0] https://honk.sigxcpu.org/piki/hw/rpi6lowpan/
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RPi, Raspbian with openlabs transceiver - lib/tool versions and updated instructions(?)

[Christoffer Holmstedt]

2015-05-06 14:26 GMT+02:00 Michael C. Cambria <mcc@fid4.com>:
>
>
> On 05/06/2015 05:08 AM, Alexander Aring wrote:
>>
>> On Wed, May 06, 2015 at 09:27:39AM +0200, Christoffer Holmstedt wrote:
>>>
>>> I'm currently setting up my dev/test environment to get a "default"
>>> working state to build upon but have stumbled upon some issues on the
>>> way. I'm currently running Raspbian with latest bluetooth-next kernel.
>>> U-Boot from last november. For libnl I use the default packages
>>> available in Raspbian repository. wpan-tools I've checked out the 0.4
>>> release from git repository.
>>>
>>> U-Boot: 2014-11-10 [1]
>>> Raspbian version: 2015-02-16 (originally built with 3.18 kernel)
>>> Bluetooth-next kernel 4.1.0-rc1+ 2015-04-30 [2]
>>> libnl-3-dev version: 3.2.7-4 (Raspbian repository)
>>> libnl-genl-3-dev version: 3.2.7-4 (Raspbian repository)
>>> wpan-tools (tag: wpan-tools-0.4) [3]
>>>
>>> Is this set of libraries/tools ever going to work together or do I
>>> have an obvious mismatch that will for sure fail?
>>>
>>> ### command failed: Device or resource busy (-16)
>>
>> I think this is because raspbian has running the ifplug deamon (ifplugd)
>> which do an interface up if you want to do an interface down.
>>
>> Guenther documented this at [0]. Try to do a:
>>
>> kill $(ps awux | grep "[i]fplugd.*wpan0" | awk '{print $2}')
>>
>> into your shell. Then be sure that your interface is down before setting
>> the pan_id.
>
>
> I have been able to fix this at boot time by changing /etc/defaults/ifplugd
>
> From:
>
> INTERFACES="auto"
> HOTPLUG_INTERFACES="all"
>
> to:
>
> INTERFACES="eth0"
> HOTPLUG_INTERFACES="eth0"
>

Thank you all for the fast replies, I tried to bring the interface
down but didn't realize it was brought back up by ifplugd. I can
confirm that it was ifplugd problem and the solution from Michael
works perfectly, now I just need to add a bootup script to configure
the wpan0/lowpan0 interfaces after reboot.

Regards
-- 
Christoffer Holmstedt

Re: RPi, Raspbian with openlabs transceiver - lib/tool versions and updated instructions(?)

[Guido Günther]

On Wed, May 06, 2015 at 08:26:05AM -0400, Michael C. Cambria wrote:
> 
> 
> On 05/06/2015 05:08 AM, Alexander Aring wrote:
> >On Wed, May 06, 2015 at 09:27:39AM +0200, Christoffer Holmstedt wrote:
> >>I'm currently setting up my dev/test environment to get a "default"
> >>working state to build upon but have stumbled upon some issues on the
> >>way. I'm currently running Raspbian with latest bluetooth-next kernel.
> >>U-Boot from last november. For libnl I use the default packages
> >>available in Raspbian repository. wpan-tools I've checked out the 0.4
> >>release from git repository.
> >>
> >>U-Boot: 2014-11-10 [1]
> >>Raspbian version: 2015-02-16 (originally built with 3.18 kernel)
> >>Bluetooth-next kernel 4.1.0-rc1+ 2015-04-30 [2]
> >>libnl-3-dev version: 3.2.7-4 (Raspbian repository)
> >>libnl-genl-3-dev version: 3.2.7-4 (Raspbian repository)
> >>wpan-tools (tag: wpan-tools-0.4) [3]
> >>
> >>Is this set of libraries/tools ever going to work together or do I
> >>have an obvious mismatch that will for sure fail?
> >>
> >>### command failed: Device or resource busy (-16)
> >I think this is because raspbian has running the ifplug deamon (ifplugd)
> >which do an interface up if you want to do an interface down.
> >
> >Guenther documented this at [0]. Try to do a:
> >
> >kill $(ps awux | grep "[i]fplugd.*wpan0" | awk '{print $2}')
> >
> >into your shell. Then be sure that your interface is down before setting
> >the pan_id.
> 
> I have been able to fix this at boot time by changing /etc/defaults/ifplugd
> 
> From:
> 
> INTERFACES="auto"
> HOTPLUG_INTERFACES="all"
> 
> to:
> 
> INTERFACES="eth0"
> HOTPLUG_INTERFACES="eth0"

I've added a reference to that file to [0], thanks. The reason i left it
out initially is that you have to list interfaces manually then (there's
no EXCLUDE_INTERFACES="wpan*".

Cheers,
 -- Guido

> 
> >Also I saw you have two interfaces and the wpan0 smells like the
> >fakelb(because zero mac address), I currently don't trust the fakelb
> >transceiver. It's a poor driver which should be updated. So in your case
> >you should use the wpan1 interface or remove the fakelb module by
> >putting this module in your blacklist.
> >
> >
> >more background about interface up and address settings:
> >
> >The reason why we doesn't allow this is because if the interface is up
> >and we allow to change the address filter settings in this situation the
> >locking mechanism is a lot of complicated while parsing the frame. To
> >avoid that we simple say "it's a readonly variable when parsing the
> >frame can be occur". The conclusion is we don't need any locking of this
> >variable in a very "strong" context while parsing the frame. If the
> >interface is down, the rtnl mutex is enough to protect this variable.
> >
> >The address filter will be filled when an interface up occurs again then.
> >
> >- Alex
> >

[0] https://honk.sigxcpu.org/piki/hw/rpi6lowpan/