Hi Alexander, On Sat, Jul 23, 2016 at 03:43:05PM +0200, Alexander Aring wrote: > Please don't use af_802154 raw sockets which are a long time broken, use > AF_PACKET raw. See as example [0] which allows to run RIOT-OS native as > elf binary in userspace and talk with the 802.15.4 6LoWPAN kernel stuff. > Also the AF_PACKET RAW will directly called xmit callback and not > dev_queue_xmit -> no qdisc is involved and mostly you like to have that > for such kind of sockets. > > The socket "af_802154" should be used to doing MAC frames by kernel, > AF_PACKET DGRAM sockets has a very limited UAPI for that. my idea using it was to have the MAC implemented in userspace and use raw sockets to interface with existing drivers. > Unfortunately this will not fix your issues if you sending out raw > frames with security bits enabled. > > You found the right issue because the "xmit callback" should not touch > the header again. I also had issues by using wireshark, because it > doesn't show the encrypted frame. > > It's the same for rx handling where decryrption should be "somehow" done > after the packet-layer. I haven't notice that yet, still trying to work out sending and receiving frames without encryption. > The issue getting even bigger (and the reason why I didn't solved it) > when you think about HardMAC transceivers. > > HardMAC transceivers do encryption end decryption on transceivers side, > so on linux side we have always not encrypted frames. This issue is a > whole unsolved issue in out architecture. Maybe we should simple handle > then as "not encrypted" but then the MAC headers frame control bits need > to show that. Or we tell the userspace, "You have here a HardMAC > transceiver and please note there is no control for showing encrypted > payload while dumping e.g. in libpcap". I think it's okay to have the > frame control secbits sets there, but we need some way to tell the > userspace "there is no support for showing encrypted payload" for > HardMAC transceivers and security enabled in frames. > > I had no idea for that currently, HardMAC transceivers will also > introduce some other stuff we need to do. At the moment we ignore > "HardMAC" transceivers at some points right now. > > I am fine if we fix this behaviour for SoftMAC transceivers side (later > we can introduce such flag for UAPI that "encrypted payload not > supported"). > > This will not work if we later add support for running HardMAC and > SoftMAC. I tried to fix it on my own (can't find the branch anymore and > patches never get into mainline). If I remember correctly, I used a callback > but I saw then the better idea would it to move encryption to > wpan_dev_hard_header, callback. > > Some parameters what for a frame we need and SoftMAC/HardMAC can be > doing (something) for that. For HardMAC I need to figure out how this > can be working then. At least wireshark/tcpdump will see the mac header > so everybody should do the same stuff there. > > If both do the same stuff, it's indicate that this is for > "net/ieee802154" branch. > > Another issue is that wpan_dev_hard_header callback was simpled > copy&pasted right now from the global generic "dev_hard_header" callback > which had several issues, because it was called by AF_PACKET DGRAM > sockets and this had 8 bytes limited parameters for e.g. addresses and > the callback had some out-of-bound array access there. > > Nevertheless the wpan_dev_hard_header fixed it because it will called by > 802.15.4 upper layers only. The bad thing is that skb->cb is still used > there, which was a workaround for "dev_hard_header" callback to extend > the callback with additional information. This should be removed, since > we have our own callback for that where we have control over it and can > add more parameters. > > Everything is ugly solved and fixing this requires to fix header > creation currently. :-) I also don't know if we really needs this > callback or simple have creation functions in "net/ieee802154" which > will be called by upper layers. HardMAC drivers need to parse the frame > then and doing something that these settings for this frame will be done > on transceivers side. > > It's a big TODO there. Thanks for the explanation, as someone starting working with this it saves me a ton of time! Much appreciated! > Nevertheless it's okay for me to fix that on rx/tx side so the RAW > socket are really RAW sockets which sends user generated frames out > (also with secbit enabled). > > But please fix this for rx/tx side and not in a way which makes the > behaviour with future HardMAC transceivers more possible. > > For tx side it should be okay to move it to the end of > "wpan_dev_hard_header" callback which should be not called by AF_PACKET > raw sockets. This should be a simple fix... > > For rx side it would be harder. I thought maybe there exists some > packet_layer "hook" before starting packet_type->func e.g. [1] > > Do encrypt payload, so we don't need to duplicate code much... if such > hook doesn't exist then we need out own hook mechanism for > packet_type->func callback. I'll take a look on it and see if I can come with an acceptable solution. Thanks! -- Aristeu -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
