Conversation
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.
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.
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.
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.
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. Limitations: - no configuration of phy/mac at all, only raw frames - monitors runs in promiscuous, user space get every frame on the air, even when crc is not correct, etc - no ack handling because promiscuous This stuff makes sense to build without and with tap. With tap it could be a RIOT border router user space foo. There exists unsolved issues like acknowledge handling which isn't supported right now. Example to setup (warning you need some recent fix to not crash your kernel ;-)): 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 -w riot0 After that you are able to run ping/etc between riot and linux stack. Example run riot as user space stack (good for dev stuff, cenk is looking for that): First it's like your spidev driver but not driver level stuff... driver is by kernel. There exists a L2 raw access aka AF_PACKET. Create a monitor interface on your 802.15.4 linux phy. Run like above: gnrc_networking.elf -w riot0 Example run two virtual riot user space stacks talking to each other: modprobe fakelb numlbs=2 iwpan dev wpan0 del iwpan phy1 interface add riot1 type monitor ip link set riot1 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 -w riot0 gnrc_networking.elf -w riot1 Try to ping each other... Good news: I have the same stuff programmed also for openthread so you can do that all virtualy testing interop foo. Bad news: Only for interop test because user space filters everything - which is good for dev. No ack handling -> bad for productive use... I have ideas to improve it as well... but I don't want to support user space more than this step.
|
I guess this is an update to #5582?
Can you explain (or provide a reference) what you mean by that, please? Do you think that e.g. a Arch Linux Vagrantbox is sufficient for testing or do I have to compile my own Linux from scratch ;-)? |
miri64
left a comment
There was a problem hiding this comment.
Overall I'm happy with the code I've seen so far. I would prefer a non-randomized approach for the address initialization (like with netdev_tap).
Apart from that there are some (minor) style issues (main thing I saw were no braces around one-line blocks). While the uncrustify config isn't 100% canonical (yet) I would suggest you run it over the files you changed and see what you think makes sense under our coding conventions.
| * @file | ||
| * @brief Auto initialization for ethernet devices | ||
| * | ||
| * @author Kaspar Schleiser <kaspar@schleiser.de> |
There was a problem hiding this comment.
No, but I copied it from the great Kaspar.
There was a problem hiding this comment.
Then at least adapt the @brief above, since this is most definitely not an ethernet device ;-P
| if (len > 0) | ||
| native_async_continue_reading(dev->fd); | ||
| else | ||
| return 127; |
There was a problem hiding this comment.
Is there a way not to use a magic number here (apart from defining as macro)?
There was a problem hiding this comment.
Yea, I guess this should somewhere already defined I will look.
| int nread; | ||
|
|
||
| if (!buf) { | ||
| if (len > 0) |
There was a problem hiding this comment.
Style: Even for one-line blocks we do { } around them.
The idea is to have a virtual PHY layer in the kernel. Fakelb and mac802154_hwsim does that for you. These drivers just send/receive frames to each other phy's. Creating a interface on a phy via: iwpan phy $PHYNAME interface add... will offer you a interface which operates a MAC layer on top of a phy. Frames which are received then will be delivered to AF_PACKET RAW socket layer. This will trigger hopefully a RIOT native platform process. There are numbers of different setups what you can do with it... I also thought about to allow a real phy connected to the virtual phy's... Then you have one node in real and you will be surprised when ~1000 nodes are behind it.... I never tested ~1000 nodes. :-/ Anyway there exists a difference between fakelb and the new mac802154_hwsim (4.19+ kernel). mac802154_hwsim allows add/del virtual phys during runtime and changing the on the fly the topology underneath. Arch should be fine. I would recommend mac802154_hwsim but fakelb with 2 nodes is a good first use example. - Alex |
|
From the context I assume that fakelb and mac802154_hwsim are kernel modules then? (sorry for asking so stupidly, but the most 1337hax0r thing I did with Linux so far was installing Arch on an encrypted disk by following the instructions in the wiki ;-P) |
Yes, they are. If you have any trouble I can help... I am not so in documentation. I am sorry. modrobe fakelb, then iwpan dev -> there should be two phy's. You can't see it but internally in fakelb they are connected to each other. mac802154_hwsim allows you just to dump topology and change it during runtime. |
|
|
👍 I'll try to setup a VM tomorrow for testing |
I am sorry, I can't deal with github here. It's okay to reopen a new pull-request for your comments? |
I'm not sure what you were trying trying to do, but since you re-opened the PR its still valid (and also is if you accidentally close it and not re-open it). If you closed it intentionally, I would appreciate a reason for it. To apply changes, just use |
Yes I hit the wrong button... |
There was a problem hiding this comment.
iwpan phy $PHYNAME interface add...
I tried that now on my VM (with PHYNAME=wpan0), but only get:
command failed: No such file or directory (-2)
I used fakelb for now, because I want to test both variants. Also, I wasn't able to load mac802154_hwsim :-/
[vagrant@archlinux ~]$ sudo modprobe mac802154_hwsim
modprobe: FATAL: Module mac802154_hwsim not found in directory /lib/modules/4.18.10-arch1-1-ARCH
[vagrant@archlinux ~]$ sudo modprobe mac802154-hwsim
modprobe: FATAL: Module mac802154-hwsim not found in directory /lib/modules/4.18.10-arch1-1-ARCH
[vagrant@archlinux ~]$ uname -a
Linux archlinux 4.18.10-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 26 09:48:22 UTC 2018 x86_64 GNU/Linux
Finally (but this did not surprise me at that point): no interface except for the TAP interface showed up in the RIOT native instance). Oh, and I tested with examples/gnrc_networking.
| USEMODULE += random | ||
| endif | ||
|
|
||
| ifneq (,$(filter netdev_default gnrc_netdev_default,$(USEMODULE))) |
There was a problem hiding this comment.
This duplicates the netdev line from above, pulling in netdev_raw802154 and netdev_tap always.
There was a problem hiding this comment.
okay, no idea about the buildsystem.
|
|
||
| ifneq (,$(filter netdev_default gnrc_netdev_default,$(USEMODULE))) | ||
| USEMODULE += iolist | ||
| USEMODULE += periph_hwrng |
There was a problem hiding this comment.
These (both iolist and periph_hwrng) should rather be a dependency of netdev_raw802154. (Also, but maybe @cladmi can help you better with this: I think periph_hwrng should rather be pulled in with FEATURES_REQUIRED)
There was a problem hiding this comment.
okay, no idea about the buildsystem.
|
mac802154_hwsim is new, it's available in 4.19+ Okay here the steps which you should do: $ modprobe fakelb numlbs=3 $ iwpan dev wpan0 del $ ip link set riot0 up $ iwpan dev wpan1 del $ ip link set riot1 up $ iwpan dev wpan2 del $ ip link set monitor0 up $ gnrc_networking.elf -w riot0 I added another phy with monitor0 - that's a virtual sniffer interface, you can run wireshark on it. I didn't tested it but should work... report back. Ah, and I disabled the tap interface somehow in some Makefile... don't remember anymore. You don't need it in this case... but you could need it for border router instance. Another setup which you could try out is. Don't use fakelb use a real phy, then you have a RIOT in user space of Linux running which use a Linux 802.15.4 PHY. We name this in the Linux world as "user space stack" and it's a complete kernel bypass, you don't use the Linux kernel anymore, only the driver layer. It has limitations which can be improved... but I am not here to implement kernel bypass features :-) |
|
I guess for |
No, node interfaces having a kernel MAC layer, they do filtering... You can get ack handling with that... but it requires that the RIOT MAC layer is "in sync" with the "Linux" MAC layer which I didn't implement. In case of monitor, RIOT MAC is required to filter everything. It's is like a raw phy interface. For development only it is better to use raw phy access only. It will show up filter issues. |
|
kk |
I guess we have to wait then until Arch goes to 4.19. Shouldn't take long methinks :-) |
I wanted to have this upstream that I don't need to rebase all changes anymore, etc. Staging will care about that, so I can still build it on master? That's for me only one big point which I want to have... |
Staging is just a tree within master, so yes. You just have to |
While reviewing RIOT-OS#9942 I noticed that the documentation on the netdev driver API is unclear and in some cases outright contradicting itself: > ``` > @return number of bytes used from @p value > @return `< 0` on error, 0 on success > ``` IMHO this is unacceptable for such a central API where communication This fixes a few things and also clarifies preconditions: - Specifies negative `errno`s clearly so all drivers return the same when required - Re-iterates parameter preconditions and special cases within the parameter documentation itself (might also help towards RIOT-OS#9805?) - Fixes contradictions within return value documentation - Adds missing parameter documentation on `init()`.
While reviewing RIOT-OS#9942 I noticed that the documentation on the netdev driver API is unclear and in some cases outright contradicting itself: > ``` > @return number of bytes used from @p value > @return `< 0` on error, 0 on success > ``` IMHO this is unacceptable for such a central API where communication This fixes a few things and also clarifies preconditions: - Specifies negative `errno`s clearly so all drivers return the same when required - Re-iterates parameter preconditions and special cases within the parameter documentation itself (might also help towards RIOT-OS#9805?) - Fixes contradictions within return value documentation - Adds missing parameter documentation on `init()`.
|
Reminder to self: Arch has the 4.19 kernel now. Retest |
|
If I find the time I will try with a hand-build kernel soonish, but that might take a while. |
|
Hi,
I think they just not enabled it yet. The correct way to do that is to open a bug-report/feature-request for enable mac802154_hwsim. If you do that, please recommend to disable the fakelb driver. You are welcome to cc me somehow if possible.
ok. |
|
| #define ETH_P_IEEE802154 0x00F6 | ||
| #endif | ||
|
|
||
| #define RAW802154_DEFAULT_ADDR_PAN (0x0023) |
There was a problem hiding this comment.
With #10384 close to being merged, this is not required anymore.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
|
At least Ubuntu 19.04 has |
I hope with all the bug fixes I added afterwards... but should be came into stable if ubuntu has recent stable... but this PR is somehow frozen yet. More difficult to get something into RIOT than in Linux runaway |
Sorry for leaving this hanging... I think most of my comments on the architecture where addressed. However @alexaaring did not address any of the style requests or the request to rebase yet, so it doesn't make much sense to review this stale PR anyway yet... @benpicco if you have the time to review and test, please go ahead.
|
@alexaring, if you don't have the time to work on this one of us could also take over. |
|
Since this PR has been stale for several years, I'll convert it to a draft. Please feel free to remove the draft state if anyone wants to pick this up again. |
et voilà !
Ehm yes, I mess up the coding style... I am more into Linux, so please tell me or somebody else can fix it.
How this thing works is described in the add driver patch.
Oh I currently see that now async handling is init twice when doing tap and raw802154... I need to deal more with ifdef and two config conditions... okay I will do that.
For now people can test it. I tested it only with fakelb riot to riot as I described it in one of my examples... And I tested it only by comment some magic that I don't have tap support.
Also you should try out the hwsim driver instead of fakelb but it's not very common in distro kernel packages... it's new. There you can change PHY topology.
- Alex