Didn't we say iw instead of iwpan? Also (but don't know if that's possible right now): I would prefer a GNRC-independent solution (so pure netdev2).

Didn't we say iw instead of iwpan?

Yes but, iw command is specifically for 802.11 MAC on linux, iwpan was introduced for 802.15.4 (http://wpan.cakelab.org/). In order to prevent possible confusions, I opted for iwpan 😄

Also (but don't know if that's possible right now): I would prefer a GNRC-independent solution (so pure netdev2).

I do not know if it makes sense, I am happy with net_gnrc_netapi for now.

💭 It is more accurate to interface with the MAC and not with netdev2. The current set of the commands would be possibly the same (common) for all the 802.15.4 MACs, plus additional MAC specific commands. Interfacing with netdev2 enables direct control over e.g. radio back-end, and I do not know for what it is needed except for testing. ❓

💭 It is more accurate to interface with the MAC and not with netdev2. The current set of the commands would be possibly the same (common) for all the 802.15.4 MACs, plus additional MAC specific commands. Interfacing with netdev2 enables direct control over e.g. radio back-end, and I do not know for what it is needed except for testing. ❓

Okay, then maybe later move it to #5511 as soon as that one is somewhat stable. My argument is more about stack-independence than about the layer.

I tested and it works (though ifconfig still shows IEEE 802.15.4 related stuff, too still). Question remains: what do we do with non-IEEE 802.15.4 radios? Do we duplicate the code that overlaps? Can we find a common module?

@jfischer-phytec-iot Ping?

Postponed due to Feature Freeze.

I will unfortunately not have time for it, sorry, it needs new caretaker.