6LoWPAN kernel on a Raspberry Pi

May 26, 2014

6LoWPAN support in the Linux kernel is sufficiently new right now that you can't just use any old kernel version - you have to ensure you're using a new enough kernel if you want to do anything useful. This presents a problem since the custom kernel normally used on the Raspberry Pi is forked from an older version of the kernel. Fortunately however, support for the RPi in the vanilla kernel has reached the point where we can now run a vanilla Linux kernel on the RPi rather than the custom RPi kernel.

Actually, even the mainline kernel does not currently have sufficiently complete 6LoWPAN and 802.15.4 code to interoperate well with other platforms like Contiki OS. Our task therefore is to get the net-next kernel running on an RPi.

The net-next kernel is a branch maintained by David Miller which holds a variety of network-related changesets as they make their way into the mainline branch. As far as I know, net-next is where all 6LoWPAN and 802.15.4 Linux development is taking place and is the preferred kernel branch to work from right now if you're using either.

Previously, development had been occurring on David Miller's net-next branch. Alexander Aring now maintains linux-wpan and linux-wpan-next branches based on bluetooth and bluetooth-next, as well as a fork of the userspace tools here. Fortunately this change between branches does not seem to have caused any problems with running on the RPi.

Substituting a vanilla Linux kernel for the forked RPi Linux kernel is simple enough, but there are some noteworthy obstacles. First is that booting a vanilla kernel will require us to use U-Boot *, which the RPi does not use by default. Second is that RPi support in the vanilla kernel is not 100% done yet. The complete list of omissions is unknown to me, but I believe HDMI is the main thing that's missing. Fortunately for us though, everything that we need to turn the RPi into a 6LoWPAN border router is working.

Aside from that, this won't be too different from compiling a kernel in any other case.

* Actually, this may not be true anymore. Looking at the configuration options for the (closed source) RPi bootloader and this discussion, it seems that the necessary functionality for loading a vanilla Linux kernel may have been present for some time already. I expect I'll try this some day, but I'd still rather have a proper configurable bootloader and I imagine most would agree. Thus, U-Boot stays


Compiling the Linux kernel on an RPi is an overnight process, so we're going to want to cross-compile on something quicker instead. You can skip the cross-compiling and proceed with the remaining steps on an RPi if you need to, but you can expect it to be quite slow.

To cross-compile, we'll need to fetch an arm-linux-gnueabi build environment if we don't already have it.

On Arch, we can do something like:

pacaur -S arm-linux-gnueabi-gcc

 On a Debian-ish system, something like:

apt-get install gcc-arm-linux-gnueabi 

That will pull in what we need for cross-compiling, including the binaries like arm-linux-gnueabi-gcc and arm-linux-gnueabi-size. Of course, you might need to install some other development packages (base-devel, build-essential, ...) if you haven't previously.

Now we can prefix make commands with CROSS_COMPILE=arm-linux-gnueabi- to compile for RPi. For convenience, you might prefer to make an alias or just export the variables:

alias armmake="CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm INSTALL_MOD_PATH=.mods make"


export CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm INSTALL_MOD_PATH=.mods

ARCH=arm and INSTALL_MOD_PATH=.mods will be used for the Linux kernel and modules.

building the Linux kernel

First we'll grab the kernel source:

git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 

This can take some time even on a good connection, so you might want to start it before doing anything else.

Once git finishes cloning the kernel source, we can go ahead and configure the kernel. The default bcm2835 config will be our starting point but we'll need to add some things to it for our purposes.

CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm make bcm2835_defconfig

This will result in a kernel configuration which will run on the RPi, but it won't be very useful to us without support for 6LoWPAN, 802.15.4, or an 802.15.4 device driver - AT86RF233 in my case.

To configure the kernel the way we need it, we'll use make menuconfig...

ARCH=arm make menuconfig

...to enable the following options:


Whether we enable them as modules or as built-ins doesn't much matter, but we'll have to be sure to copy the modules over to the RPi later if we choose to build any now.

I enabled CONFIG_IEEE802154_AT86RF230 for the 802.15.4 module I'm using, but you'll need to enable a different driver if you have different hardware.

These next options aren't required but they're pretty standard and may well be desirable. You should enable them if you don't otherwise know what to do. (the first one is required if you want to build anything as a module instead of built-in)


At this point, we can proceed to build the kernel (and modules, if applicable):

CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm make
CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm make modules
CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm INSTALL_MOD_PATH=.mods make modules_install

We now have arch/arm/boot/zImage (the kernel) and arch/arm/boot/dtb/bcm2835-rpi-b.dtb (the device tree), which are the two files we need to boot our new kernel, but we still need a way to tell the kernel about the 802.15.4 device we've hooked up to our RPi.

patching the device tree

The device tree is what recent ARM systems (among others) use to describe the hardware to the kernel at boottime. x86 systems have BIOS; embedded systems have device tree. It's needed for things which are sufficiently low-level that they that aren't capable of runtime enumeration, like SPI devices, I2C devices, and many others.

The 802.15.4 device I'm using (AT86RF233) is an SPI device, so it can't be auto-enumerated and needs to go into the device tree. Therefore, I've added the following to the bottom of arch/arm/boot/dts/bcm2835-rpi-b.dts to tell the kernel how to access it. This essentially tells the kernel which driver to use and what the pinout is. This is the code you should use if you're using this module on an RPi, as I am:

&spi {
    status = "okay";
    at86rf233@0 {
        compatible = "atmel,at86rf233";
        reg = <0>;
        interrupts = <23 1>;
        interrupt-parent = <&gpio>;
        reset-gpio = <&gpio 24 1>;
        sleep-tpio = <&gpio 25 1>;
        spi-max-frequency = <500000>;

After patching a .dts file, we'll need to rebuild the .dtb files:

ARCH=arm CROSS_COMPILE=arch-arm-gnueabi- make dtbs

Now arch/arm/boot/dts/bcm2835-rpi-b.dtb contains a binary of our patched device tree which tells the kernel how to access our AT86RF233.

building U-Boot

With our kernel and device tree ready, we now need to get U-Boot compiled and set up. Stephen Warren maintains a U-Boot branch with some RPi-specific code that hasn't yet been moved into mainline U-Boot. That's the branch we're going to use.

git clone https://github.com/swarren/u-boot.git
cd u-boot
git checkout rpi_dev

 We'll need to configure for rpi_b before we can compile:

make rpi_b_config

I found it necessary to apply a small patch to U-Boot to make it work with some (all?) of my SD cards:

sed -i 's/MMC_MODE_HS_52MHz | //' drivers/mmc/sdhci.c

Presumably this patch isn't required for everyone, but as I haven't yet isolated the actual problem, it seems necessary that I include it here.

Now we can build:

CROSS_COMPILE=arm-linux-gnueabi- make

This gives us u-boot.bin, which is the bootable binary we need. The RPi (start.elf, specifically) will load this binary (rather than directly loading a Linux kernel, as it does normally) which will then load our Linux kernel in accordance with its configuration.

configuring U-Boot

U-Boot needs to be told how to boot our new Linux kernel. Its configuration resides in /boot/uEnv.txt. So we need to create this file on the RPi with the following contents:

bootargs=earlyprintk console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p5 rootwait dwc_otg.lpm_enable=0
bootcmd=load mmc 0:1 ${kernel_addr_r} zImage; load mmc 0:1 ${fdt_addr_r} zImage.dtb; bootz ${kernel_addr_r} - ${fdt_addr_r}

(As always, mind the line breaks. There are only two lines there - bootargs=... and bootcmd=...)

This configuration will cause U-Boot to automatically load /boot/zImage (the Linux kernel) and /boot/zImage.dtb (the device tree) and boot the kernel with the options given in bootargs. You might need to customize your bootargs for your Linux distribution and your own preferences, particularly the root directive in case your root partition is different. You can check your existing /boot/cmdline.txt to see what arguments your RPi is currently booting with. This file isn't used by U-Boot and we won't be touching it, so you can always refer to it later if something isn't right.

installing and rebooting

Now that we've got everything compiled, we can copy it all over to the RPi:

scp net-next/arch/arm/boot/zImage root@alarmpi:/boot/zImage
scp net-next/arch/arm/boot/dts/bcm2835-rpi-b.dtb root@alarmpi:/boot/zImage.dtb
rsync -rlhic net-next/.mods/lib/modules/ root@alarmpi:/lib/modules/
scp u-boot/u-boot.bin root@alarmpi:/boot/kernel.img

(Don't forget to first back up your existing /boot/kernel.img if you care to.)

At this point, we can reboot into the new kernel and try out the new functionality.

linux-zigbee userspace tools

Despite the historical name, the linux-zigbee project is no longer related to ZigBee at all, but rather the open replacement - 6LoWPAN over 802.15.4.

The linux-zigbee userspace tools are what we use to manage 802.15.4 devices. We'll need them in order to do anything useful with our new 6LoWPAN Linux kernel. The source code is at git://git.code.sf.net/p/linux-zigbee/linux-zigbee and it compiles uneventfully following the build instructions. Contrary to building the Linux kernel on an RPi, building the linux-zigbee tools on an RPi will take only a few minutes.

With the linux-zigbee userspace tools installed, we now have the iz binary (among a few others) which we will use to configure the 802.15.4 device. At this point we can finally verify that we do in fact have a valid 802.15.4 device recognized by the kernel:

iz listphy

That should return something like this:

wpan-phy0  IEEE 802.15.4 PHY object
    page: 0  channel: 11
    channels on page 0: 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

bringing up the 6LoWPAN network

iz is to 802.15.4 what iw is to 802.11. We can use it and ip to bring up the 6LoWPAN network like this:

iz add wpan-phy0 wpan0 00:00:00:00:00:00:00:01
iz set wpan0 0x999 0x1 11
ip link add link wpan0 name lowpan0 type lowpan
ip addr add 2001:db8:dead:beef::1/64 dev lowpan0
ip link set wpan0 up
ip link set lowpan0 up

Upon doing this, we now have a lowpan0 interface with IP address 2001:db8:dead:beef::1. To configure a second RPi on the same network, we'd want to substitute 1 for 2 in the iz addiz set, and ip addr add commands. Following that, we could ping our second RPi over the 6LoWPAN network like this:

ping6 2001:db8:dead:beef::2

And of course, with the proper network configuration, we could now just as easily ping the second RPi (or other 6LoWPAN node) from a device connected to the ethernet port of the first RPi. Thus, the RPi has become a 6LoWPAN border router for our ethernet network. This is left as an exercise for the reader until I have time for the next article.

In the mean time, I can vouch that the procedure I've described here does produce a setup which can function as a 6LoWPAN border router capable of  interoperating with devices running Contiki OS. I use it several times a day to turn my lights on and off.


Carlo Wolter

July 3, 2022, 7:55 a.m.

Hi, I bought 2 6LoWPAN modules on Jun, 1st. No info about the shipment. May I have some tracking code ? Thanks

Carlo Wolter

July 24, 2022, 10:39 a.m.

If I cannot get a satisfactory answer by the end of month I will proceed with PayPal reimbursement procedure.


July 31, 2019, 1:01 a.m.

Hi All,
I want to do security for the 6LoWPAN network, how can I do that?

Sascha Buber

July 12, 2019, 4:23 p.m.


i have now a RPi 2B and a RPi 3B running with your module. It looks like everything works properly. The devices are up in ifconfig and they have an ipv6 address. I can ping myself, but not the second RPi. When capturing with wireshark, the checksum of every packet says "Good". However, i get a "Network unreachable: Address unreachable". Sometimes it seems that i reach the other RPi's lowpan0 device. Maybe you can help me troubleshoot this, because i can't figure out the problem. Just tell me what information you need.

Thanks in Advance.


July 13, 2019, 7:53 a.m.

Ok... I figured out that it was the wrong kernel.
For everyone who ist trying this module, use kernel 4.9.y.

Maria Elena

May 1, 2019, 3:58 p.m.

buenas noches, he seguido todos los pasos que indica, ya tengo las interfaces lowpan y wpan, pero al hacer ping6 me sale destino inalcanzable, por favor ayudeme a solucionar.


Feb. 12, 2015, 5:44 a.m.


I compiled with success the "https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git" branch.
Then I decided to move to the newer brnch in order to get the promixuity mode working with wireshark as described in "sniffing 802.15.4 packets natively with Raspberry Pi and Wireshark".
But when tried to compile the "https://github.com/linux-wpan/linux-wpan-next.git" branch, I have the following error:

$ ARCH=arm CROSS_COMPILE=arch-arm-gnueabi- make dtbs
make: arch-arm-gnueabi-gcc: commande introuvable
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
CC kernel/bounds.s
/bin/sh: 1: arch-arm-gnueabi-gcc: not found
Kbuild:35: recipe for target 'kernel/bounds.s' failed
make[1]: *** [kernel/bounds.s] Error 127
Makefile:972: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2

In addition, patching the kernel as described in "sniffing 802.15.4 packets natively with Raspberry Pi and Wireshark" also fail with the following error:

Application : ieee802154: skip bad frame type warning for ack type
Application : ieee802154: at86rf230: add support for promiscuous mode
error: le patch a échoué : drivers/net/ieee802154/at86rf230.c:90
error: drivers/net/ieee802154/at86rf230.c : le patch ne s'applique pas
Le patch a échoué à 0002 ieee802154: at86rf230: add support for promiscuous mode

PLease could you help me to make it work ?
Thanks in advance.


Feb. 9, 2015, 8:21 p.m.

After all the process, finally I boot the kernel.
BUT, when I use the lowpan tools, and put "./iz listphy" into the shell, I obtain this :
"Could not get multicast group ID: No such file or directory"

Do you know what to do?

I use lib 3.2.24
and lowpan tools 0.3.1

[I don't know if GPIO detect your product, the 802.15.4 radio, or not]


Feb. 6, 2015, 10:55 p.m.

While compiling, I've got the following error :

#CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm INSTALL_MOD_PATH=.mods make modules_install

ln: la cible «.mods/lib/modules/3.19.0-rc7+/source» n'est pas un répertoire
Makefile:1121: recipe for target '_modinst_' failed
make: *** [_modinst_] Error 1

Please could you help me to fix it ?
The folder ".mods/lib/modules/3.19.0-rc7+/source" is missing, and ".mods/lib/modules/3.19.0-rc7+/" just has "kernel" in it... Maybee a mssing link ?

Thanks in advance.


Feb. 6, 2015, 5:02 p.m.

Thanks for this wonderfull and very usefull work.

Trying to compile the kernel for the Raspberry Pi, I got the following error on lib/rhashtable.c file:

lib/rhashtable.c:967:3: erreur: implicit declaration of function ‘ERR_PTR’ [-Werror=implicit-function-declaration]

I had to add
at the beginning of the file to get it compile without error.

Hope this help...

Koojana Kuladinithi

Feb. 6, 2015, 5:34 a.m.

Hello all,

I ordered one of these interfaces (i.e., Atmel AT86RF233 based OpenLabs interface) some time back and today, I was able to bring the 802.15.4 enabled kernel up and running on an RPi with this interface. Though I followed the above procedure, I was stuck with a u-boot issue for some time and could not proceed. Basically it was not using the uEnv.txt I created. So, I had to use the procedure in http://elinux.org/RPi_U-Boot to get it working. During the process, I documented what I did. Here is a link to it, in case someone else is interested.


Now, I have the following issue with the "iz set” which I am looking into.

sudo iz add wpan-phy0 wpan0 00:00:00:00:00:00:00:01
Receive failed: Unspecific failure

If anyone has any idea on this, I would be very glad to hear it.




Feb. 4, 2015, 9:36 p.m.

From my understanding, the wpan tools have changed quite a bit, so the instructions starting with "linux-zigbee userspace tools" do not work anymore.
Here is a summary of what needs to be done for ping to work correctly:
(Setup is two Raspberry Pis (A and B) with Rasbian but a self-compiled bluetooth-next kernel.)
My Pi boots with wpan0 configured, but down. This depends on the contents of /etc/ifplugd, see http://www.spinics.net/lists/linux-wpan/msg01366.html. If iwpan dev does not list anything, create wpan0 with
$ sudo iwpan phy wpan-phy0 interface add wpan0 type node)

Anyway, do the following on both sides (both RPi in my case):
Bring up wpan0:
$ sudo ip link set wpan0 up
Create lowpan Interface
$ sudo ip link add link wpan0 name lowpan0 type lowpan
Bring up lowpan0
$ sudo ip link set wpan0 up
Check all interfaces
$ ifconfig
As ifconfig only lists interfaces that are up, this should list wpan0 and lowpan0. Make a note of the "inet6 addr" of Pi A.
In Pi B, type
$ ping6 -I lowpan0
Note that specification of the interface to use is mandatory as mentioned in the man page of ping!


Dec. 4, 2014, 4:27 a.m.

For Pi, are there any assumptions about what is already running on the sdcard? For example, I started with raspbain from http://www.raspberrypi.org/downloads/.

That image doesn't have /boot/uEnv.txt (nor does the card that shipped with the Pi.)

There doesn't seem to be /dev/mmcblk0p5 either, just:

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 31275007 15576064 83 Linux

Should I start with a different distro?



Dec. 9, 2014, 1:23 a.m.

Raspbian is probably a great distro to use.

/boot/uEnv.txt doesn't exist on a system where uboot isn't being used. You have to create it when installing uboot.

/dev/mmcblk0p5 has to be customized. In your case you need /dev/mmcblk0p2 I think.


Nov. 24, 2014, 6:15 p.m.

I am a novice,
I bought two of your modules, I use a raspberry pi B+, and I am following this tutorial to get what you say. But, in the section of building U-BOOT, the oart of:
"We'll need to configure for rpi_b before we can compile:

make rpi_b_config"

I get

"HOSTCC scripts/basic/fixdep
*** Can't find the default configuration "configs/rpi_defconfig"!
make: *** [rpi_b_config] Error 1"

Thanks in advance


Nov. 25, 2014, 1:09 a.m.

It looks like uboot has changed a bit. According to the link below, you need to use `make rpi_b_defconfig` instead on recent versions of uboot.



Dec. 9, 2014, 5:52 p.m.

some news?


Nov. 26, 2014, 6:52 p.m.

The problem is, that the branch 'rpi_dev' not contains the 'rpi_b_defconfig', only contains rpi_defconfig. But I have seen it on the branch 'tegra_dev', if that file exists! so, try this branch could have a correct result?

branch rpi_dev: https://github.com/swarren/u-boot/tree/rpi_dev/configs
branch tegra_dev: https://github.com/swarren/u-boot/tree/tegra_dev/configs


Nov. 21, 2014, 5:32 a.m.

Could your 6LoWPAN adapter be made to work on Beagle Bone Black (BBB)?


Nov. 24, 2014, 12:41 a.m.

Yes I'm sure it would work. The pinout won't match of course but it's just an SPI connection so there's no limit to what you can use it with. I've got a beaglebone on my wishlist this year so maybe I'll soon be doing a blog post on it if I'm lucky.


Nov. 18, 2014, 7:01 p.m.

I'm trying only building the kernel, and the graphic part doesnt work.

i'm doing that with the rpi b+. Are the same procedures?

Thank you in advance!


Nov. 19, 2014, 1:18 a.m.

Do you mean the HDMI output? That still doesn't work on a vanilla kernel as far as I know.

The RPi B+ should hopefully use the same procedures but I don't have one to play around with yet.


Oct. 28, 2014, 9:50 p.m.


This is a very good module to deploy a 6LoWPAN solution. It is possible to attach to Contiki-based solutions? (I'm thinking in 6LBR...) I'm trying but I don't have ping connectivity.

Thanks in advance!


Oct. 29, 2014, 6:20 a.m.

Yes, Contiki is what most of my devices are running and they communicate well enough. 6lbr should work just as well, but I haven't tried it. I decided instead to replace 6lbr with a more straightforward/native approach, which is why I made this module and got it running with Linux in the first place.


Oct. 29, 2014, 6:23 a.m.

Thats nice!

Now I'm trying to get ping connectivity between them but 6lbr detects at stale neighbor... I keep trying!



Oct. 27, 2014, 5:40 p.m.

I manage to get it working but i couldn't find the instruction to compile the Zigbee user tools, i tried this http://wiki.beyondlogic.org/index.php?title=Cross_Compiling_Linux-Zigbee_for_ARM somebody found a way to compile the zigbee user tools


Oct. 29, 2014, 6:12 a.m.

The userspace tools have been updated and moved to here:


There have also been some other changes since this blog post. See the updates in this post:


Maciej Wasilak

Sept. 22, 2014, 3:55 p.m.


I'm following your tutorial, but I'm having problems with U-Boot - it hangs on error:

mbox: Response buffer mismatch
bcm2835: Could not query ARM memory size
### ERROR ### Please RESET the board ###

This seems rather rare (I haven't found any other reference on the Internet). Can you please tell me which U-Boot commit you used for your setup?

Best Regards

Maciej Wasilak

Sept. 23, 2014, 4:08 a.m.


I solved the problem - it was caused by old start.elf file. I used 2012 Raspbian image that contained old start.elf. I advise using new start.elf for testing U-Boot.

Best Regards

Inês Rodrigues

Sept. 10, 2014, 12:04 p.m.

Hello all,

I'm having some troubles when I try to reboot the raspberry pi into the new kernel. Here is what it shows up:

reading /uEnv.txt
**Unable to read file /uEven.txt **


***Warning: no boot file name: using '0A0301E0.img'
Using sms0 device
TFTP from server our IP address is; sending trough gateway
Filename '0A0301E0.img'
Load Address: 0x20000
TFTP error: 'illegal (unrecongnized) tftp operation (4)

It seems that my u-boot configurations are not able to read the uEnv.txt file.
After that, the screen shows up a TFTP error and it starts running in an infinite loop.

Can someone please help me?
Thank you in advance.

Daniel Simig

July 9, 2014, 3:26 a.m.


I am working on a demo for wireless sensor networks using 802.15.4 and ordered a few of the radio devices mentioned for my Pi, and followed this description. I got the thing working (replaced the kernel of a Raspbian image), however my eth0 and wlan0 interfaces disappeared (/etc/network/interfaces is unchanged).

Any ideas why is this happening?

I had some issues copying the kernel modules (simply cp-ing to the sd card) since it contained symlinks to the net-next library, which I resolved simply by not copying those (I had read somewhere it's OK to do), but I couldn't really find .o files anywhere else in the lib folder. Is this normal?

Let me know if you need some details like dmesg, ifconfig or whatsoever, I would appreciate any help :)



Oct. 16, 2014, 5:17 a.m.

Hi Daniel,
I'm very new to this, would you have or know where a guide to replacing the kernel of the Raspbian image would be?
Thanks in advance. Craig.


July 9, 2014, 2:50 p.m.

I was able to reproduce this just now by updating to the latest net-next commit.

These things do happen from time to time when working with a development branch. I'll spend some time with git-bisect tonight to track down which commit is responsible.

At first glance, it looks like something has broken the dwc2 (DesignWare USB Controller) driver. This has the effect of knocking out not just the USB ports but also the ethernet chip since that's connected through USB as well.

Obviously I should have specified which commit I was on as a known good reference when I wrote this. Oops.

I'll be back soon with updates.


July 11, 2014, 9:08 a.m.

The commit that did it was 47a1685f139271de401212bd69d17374ca5a5270 (usb: dwc2/s3c-hsotg: move s3c-hsotg into dwc2 directory)

Reverting this commit does fix the problem if you resolve the two conflicts, but it isn't necessary.

Enabling CONFIG_USB_DWC2_HOST and CONFIG_USB_DWC2_PLATFORM fixed this for me. It may simply be that bcm2835_defconfig needs updating although I haven't looked any deeper.

I'd be interested to know if this fixes it for you too, although I expect it will. There are probably only a tiny handful of people running a vanilla kernel on the RPi at the moment.

Daniel Simig

July 14, 2014, 6:48 p.m.


I tried the latter method and rebuilt the kernel with the new config and it indeed fixed the problem, now USB is working as it should, so I have Ethernet interface again. Thanks for the effort, it would have taken quite a lot of time to figure this out myself. By the way the radio works beautifully, though at the moment I am just sending raw 802.15.4 frames from an ATMEGA256RFR2 chip.

Leave a comment