Conversation
The tap interface is compile time optional currenlty. This patch makes the tap interface runtime optional and handle it as usually argument. Note: Documentation need to be updated for new command argument. Signed-off-by: Alexander Aring <[email protected]>
The raw802154 driver needs to generate random data for a possible random extended address generation. This patch allows to init hwrng twice in case of using hwrng unit-tests and raw802154 driver. Signed-off-by: Alexander Aring <[email protected]>
This patch moves the continue_reading to the async file api. The raw802154 driver needs such function as well, so we move it to a shared place. Signed-off-by: Alexander Aring <[email protected]>
The raw802154 driver use also the async file api. This patch moves the async file api init to startup to init the file api once. Signed-off-by: Alexander Aring <[email protected]>
The raw802154 uses AF_PACKET SOCK_RAW api. To have some cleaner cleanup routine which shutdown the socket before close, this patch adds such wrapper to handle it. Signed-off-by: Alexander Aring <[email protected]>
This patch adds the raw802154 driver to RIOT. The idea is to run of top of an 802.15.4 monitor interface. This interface can be run on any driver, for virtual testing the linux-wpan "fakelb" driver can be used. There exists unsolved issues like acknowledge handling which isn't supported right now. Example to setup: modprobe fakelb numlbs=2 ip link add link wpan0 name lowpan0 type lowpan iwpan dev wpan0 set pan_id 0x23 ip link set wpan0 up ip link set lowpan0 up iwpan dev wpan1 del iwpan phy1 interface add riot0 type monitor ip link set riot0 up Starting native gnrc_networking example: gnrc_networking.elf -r riot0 -ra After that you are able to run ping/etc between riot and linux stack. Signed-off-by: Alexander Aring <[email protected]>
Kijewski
changed the title
miri64
added
Platform: native
|
Awesome! |
|
I would love to test and review this but I am not certain I can manage to find enough time. |
| netdev2_tap_params_t p; | ||
| p.tap_name = &(argv[1]); | ||
| netdev2_tap_setup(&netdev2_tap, &p); | ||
| } |
There was a problem hiding this comment.
There is a semantic change here in that the interface is optional now. It was a positional parameter before because a network application can't run without it.
If there is good reason (other than personal preference) to discard the positional parameter please explain.
|
I have quickly looked at all but the @miri64 reassigning to you for netdev related review. I'll keep reading here, though. |
|
Needs rebase (and probably some syncing with #5614). Also addressing of @LudwigKnuepfer's comments would be appreciated :-) |
|
It's fine for me to apply #5614 at first, then I will try to adapt these changes to raw802154 driver so we could also add multiple raw802154 instances. |
|
kk, so you will rebase this PR to #5614? |
|
Yes, I think this makes sense. I grab many code from tap stuff. So I would wait for great new features for the tap interfaces (have multiple of them) and make the same for raw802154 driver. |
miri64
added
the
State: waiting for other PR
|
Okay, then I label this PR as such ;-) |
miri64
added
the
State: WIP
|
Needs rebase. |
|
@alexaring ping? |
1 similar comment
|
@alexaring ping? |
|
Sorry, currently write my thesis and have no time to working on it. While my thesis I improved the fakelb phy stuff so you can generate easily mesh networks. I have a talk about that at netdev and will report also about stupid MLE stituation which we currently have. After that I will look how I bring these things all upstream and I have time maybe mid of April. :-/ |
|
@alexaring please inform me when this PR is finished. It will be very useful for #5552 . |
|
well, if you run it on a virtual machine then you don't need root rights on a host pc. I cannot send pull-request to openthread code because google CLA, sorry. about the adaption layer protocol, what does that mean? Putting 802.15.4 frames in UDP Payload? That was one thing which I want to avoid and offering one kernel UAPI for doing a PHY layer where you have control about how the connections are in a mesh setup. |
|
I'd like to bring to your attention our latest project, borderrouter, which targets Linux-based hosts with OpenThread NCPs to allow them to be Thread border routers. @alexaring I'm curious as to why you cannot submit a PR because of the Google CLA. Any details you can share? |
That might help you if we are talking about real deployment, but |
|
I met some "India kid" \o/ - I have the task to test him that he is able to send patches to linux kernel etc. I will give him these tasks - as well for RIOT native and this driver. Is that okay for you? :-) @beriberikix what you doing in wpantund scares me and it looks like bluetooth people want to do the same... I guess to avoid GPL license. |
|
Ping @alexaring @beriberikix? I'd really like to test this, but this requires a rebase on your part. |
Of course it is. As long as the work is done, I don't care who done it ;-) |
|
Now that there is #9942, can this be closed then? |
|
Updated in #9942. |
7 participants
This pull-request adds a raw802154 driver to native board functionality.
With this driver you can run the RIOT stack on 802.15.4 Linux interfaces.
In general the basic idea is to run on monitor interfaces to test Linux 802.15.4 stack with RIOT and have some way to easily reproduce issues by running RIOT in userspace. For this use-case the Linux kernel has a virtual phy driver named "fakelb".
Furthermore it could be possible to run on normal wpan "node" interfaces as well. It should be possible if mac address settings are equal with the RIOT mac address settings. Nevertheless this needs more logic with netlink nl802154 interface and it will not work right now, because receiving expects FCS which is not available on node interfaces (again needs additional nl802154 handling).
Note: because other issues wireshark expects a FCS while sending on monitor interfaces, but there is none. Frames will be marked as corrupted but they are still correct.
To sniff the traffic, create one "wpan phy" interface more and run them as monitor (without running RIOT-OS stack on it.)
Please note also, that you can't run multiple RIOT-OS instances on one interface, it need always a separate phy. This is because we don't send frames back on a phy which actually transmit them.
At least, you need 1-2 patches which are currently on linux-wpan mailinglist http://www.spinics.net/lists/linux-wpan to make the full stuff working with fakelb driver, on other driver with monitor interface (e.g. at86rf230) it should be possible. I didn't test it with real hardware because I saw other issues to cross compile native board and when I had a cross compiled version for my arm device it didn't work because some not working assembler code. :-)
Here are the steps how to use it (with monitor interface for sniffing):
modprobe fakelb numlbs=3
ip link add link wpan0 name lowpan0 type lowpan
iwpan dev wpan0 set pan_id 0x23
ip link set wpan0 up
ip link set lowpan0 up
iwpan dev wpan1 del
iwpan phy1 interface add riot0 type monitor
ip link set riot0 up
iwpan dev wpan2 del
iwpan phy2 interface add monitor0 type monitor
ip link set monitor0 up
Starting native gnrc_networking example:
gnrc_networking.elf -r riot0 -ra
Sniffing example:
run wireshark on monitor0 interface.