| Message ID | 20230106113129.694750-1-miquel.raynal@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ieee802154: Beaconing support | expand |
Hi, On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Scanning being now supported, we can eg. play with hwsim to verify > everything works as soon as this series including beaconing support gets > merged. > I am not sure if a beacon send should be handled by an mlme helper handling as this is a different use-case and the user does not trigger an mac command and is waiting for some reply and a more complex handling could be involved. There is also no need for hotpath xmit handling is disabled during this time. It is just an async messaging in some interval and just "try" to send it and don't care if it fails, or? For mac802154 therefore I think we should use the dev_queue_xmit() function to queue it up to send it through the hotpath? I can ack those patches, it will work as well. But I think we should switch at some point to dev_queue_xmit(). It should be simple to switch it. Just want to mention there is a difference which will be there in mac-cmds like association. btw: what is about security handling... however I would declare this feature as experimental anyway. - Alex
Hi Alexander, aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > Hi, > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Scanning being now supported, we can eg. play with hwsim to verify > > everything works as soon as this series including beaconing support gets > > merged. > > > > I am not sure if a beacon send should be handled by an mlme helper > handling as this is a different use-case and the user does not trigger > an mac command and is waiting for some reply and a more complex > handling could be involved. There is also no need for hotpath xmit > handling is disabled during this time. It is just an async messaging > in some interval and just "try" to send it and don't care if it fails, > or? For mac802154 therefore I think we should use the dev_queue_xmit() > function to queue it up to send it through the hotpath? > > I can ack those patches, it will work as well. But I think we should > switch at some point to dev_queue_xmit(). It should be simple to > switch it. Just want to mention there is a difference which will be > there in mac-cmds like association. I see what you mean. That's indeed true, we might just switch to a less constrained transmit path. In practice, what is deliberately "not enough" here is the precision when sending the beacons, eg. for ranging purposes (UWB) we will need to send the beacons at a strict pace. But there are two ways for doing that : - use a dedicated scheduler (not supported yet) - move this logic into a firmware, within an embedded controller on the PHY But that is something that we will have to sort out later on. For now, let's KISS. > btw: what is about security handling... however I would declare this > feature as experimental anyway. I haven't tested the security layer at all yet, would you have a few commands to start with, which I could try using eg. hwsim? Thanks, Miquèl
Hi Alexander, > > btw: what is about security handling... however I would declare this > > feature as experimental anyway. > > I haven't tested the security layer at all yet, would you have a few > commands to start with, which I could try using eg. hwsim? Using the dev_queue_xmit() doest not bypasses the whole stack anymore, the beacons got rejected by the llsec layer. I did just hack into it just to allow unsecure beacons for now: - if (hlen < 0 || hdr.fc.type != IEEE802154_FC_TYPE_DATA) + if (hlen < 0 || + (hdr.fc.type != IEEE802154_FC_TYPE_DATA && + hdr.fc.type != IEEE802154_FC_TYPE_BEACON)) return -EINVAL; I believe that would be enough as a first step, at least for merging beacons support for now. However I'll have to look at the spec about security stuff and beaconing to know how to handle this properly if security was required, but could you drive me through useful resources were I could quickly grasp how all that works? Did you make any presentation of it? Perhaps just a blog post or something alike? Or even just a script showing its use? While I was looking at linux-wpan.org, I realized we should both contribute to it with some examples about security stuff and beaconing/scanning? Thanks, Miquèl
Hi, On Mon, Jan 23, 2023 at 7:49 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > > > btw: what is about security handling... however I would declare this > > > feature as experimental anyway. > > > > I haven't tested the security layer at all yet, would you have a few > > commands to start with, which I could try using eg. hwsim? > > Using the dev_queue_xmit() doest not bypasses the whole stack anymore, > the beacons got rejected by the llsec layer. I did just hack into it > just to allow unsecure beacons for now: > Stupid questions: do the beacon frames need to be encrypted? Because we bypass llsec always with those mlme functionality. btw: there is currently an issue with the llsec hooks. You will not see the transmit side being encrypted via wireshark (so far I remember) because the capture is before encryption... > - if (hlen < 0 || hdr.fc.type != IEEE802154_FC_TYPE_DATA) > + if (hlen < 0 || > + (hdr.fc.type != IEEE802154_FC_TYPE_DATA && > + hdr.fc.type != IEEE802154_FC_TYPE_BEACON)) > return -EINVAL; > > I believe that would be enough as a first step, at least for merging > beacons support for now. > ok. > However I'll have to look at the spec about security stuff and > beaconing to know how to handle this properly if security was required, > but could you drive me through useful resources were I could quickly > grasp how all that works? Did you make any presentation of it? Perhaps > just a blog post or something alike? Or even just a script showing its > use? > I am pretty sure I have something... you need to construct an ACL there and there exist different methods to do a key lookup. Some are very easy and some are more difficult to set up. I will look later... or just do a setup again with hwsim with should work (but again don't trust wireshark/tcpdump). Also note: currently there exists practical issues on 802.15.4 stack (but star topology kind of solves it, so far I understood) to synchronize security parameters e.g. frame counter. > While I was looking at linux-wpan.org, I realized we should both > contribute to it with some examples about security stuff and > beaconing/scanning? > yes, that would be nice... I am pretty sure there are some examples on the mailinglist archive. - Alex
Hi, On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > > > Hi, > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > Scanning being now supported, we can eg. play with hwsim to verify > > > everything works as soon as this series including beaconing support gets > > > merged. > > > > > > > I am not sure if a beacon send should be handled by an mlme helper > > handling as this is a different use-case and the user does not trigger > > an mac command and is waiting for some reply and a more complex > > handling could be involved. There is also no need for hotpath xmit > > handling is disabled during this time. It is just an async messaging > > in some interval and just "try" to send it and don't care if it fails, > > or? For mac802154 therefore I think we should use the dev_queue_xmit() > > function to queue it up to send it through the hotpath? > > > > I can ack those patches, it will work as well. But I think we should > > switch at some point to dev_queue_xmit(). It should be simple to > > switch it. Just want to mention there is a difference which will be > > there in mac-cmds like association. > > I see what you mean. That's indeed true, we might just switch to > a less constrained transmit path. > I would define the difference in bypass qdisc or not. Whereas the qdisc can drop or delay transmitting... For me, the qdisc is currently in a "works for now" state. > In practice, what is deliberately "not enough" here is the precision > when sending the beacons, eg. for ranging purposes (UWB) we will need > to send the beacons at a strict pace. But there are two ways for doing > that : > - use a dedicated scheduler (not supported yet) > - move this logic into a firmware, within an embedded controller on the > PHY > then bypassing qdisc would be better. > But that is something that we will have to sort out later on. For now, > let's KISS. > > > btw: what is about security handling... however I would declare this > > feature as experimental anyway. > > I haven't tested the security layer at all yet, would you have a few > commands to start with, which I could try using eg. hwsim? hwsim should work. But again don't trust the transmit side, there are currently problems. Wireshark has also a feature to give the key and encrypt on the fly for 802.15.4. - Alex
Hi, On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote: > > Hi, > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > > > > > Hi, > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify > > > > everything works as soon as this series including beaconing support gets > > > > merged. > > > > > > > > > > I am not sure if a beacon send should be handled by an mlme helper > > > handling as this is a different use-case and the user does not trigger > > > an mac command and is waiting for some reply and a more complex > > > handling could be involved. There is also no need for hotpath xmit > > > handling is disabled during this time. It is just an async messaging > > > in some interval and just "try" to send it and don't care if it fails, > > > or? For mac802154 therefore I think we should use the dev_queue_xmit() > > > function to queue it up to send it through the hotpath? > > > > > > I can ack those patches, it will work as well. But I think we should > > > switch at some point to dev_queue_xmit(). It should be simple to > > > switch it. Just want to mention there is a difference which will be > > > there in mac-cmds like association. > > > > I see what you mean. That's indeed true, we might just switch to > > a less constrained transmit path. > > > > I would define the difference in bypass qdisc or not. Whereas the > qdisc can drop or delay transmitting... For me, the qdisc is currently > in a "works for now" state. probably also bypass other hooks like tc, etc. :-/ Not sure if we want that. - Alex
Hi, On Mon, Jan 23, 2023 at 8:50 AM Alexander Aring <aahringo@redhat.com> wrote: > > Hi, > > On Mon, Jan 23, 2023 at 7:49 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > > > btw: what is about security handling... however I would declare this > > > > feature as experimental anyway. > > > > > > I haven't tested the security layer at all yet, would you have a few > > > commands to start with, which I could try using eg. hwsim? > > > > Using the dev_queue_xmit() doest not bypasses the whole stack anymore, > > the beacons got rejected by the llsec layer. I did just hack into it > > just to allow unsecure beacons for now: > > > > Stupid questions: do the beacon frames need to be encrypted? Because > we bypass llsec always with those mlme functionality. > > btw: there is currently an issue with the llsec hooks. You will not > see the transmit side being encrypted via wireshark (so far I > remember) because the capture is before encryption... You can do with hwsim a sniffer device, just create a phy and have from every node an edge to it, then create a monitor interface on it and you will see all frames on air correctly encrypted and let wireshark decrypt it. This is a workaround I had. - Alex
Hi Alexander, aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500: > Hi, > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote: > > > > Hi, > > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > Hi Alexander, > > > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > > > > > > > Hi, > > > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify > > > > > everything works as soon as this series including beaconing support gets > > > > > merged. > > > > > > > > > > > > > I am not sure if a beacon send should be handled by an mlme helper > > > > handling as this is a different use-case and the user does not trigger > > > > an mac command and is waiting for some reply and a more complex > > > > handling could be involved. There is also no need for hotpath xmit > > > > handling is disabled during this time. It is just an async messaging > > > > in some interval and just "try" to send it and don't care if it fails, > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit() > > > > function to queue it up to send it through the hotpath? > > > > > > > > I can ack those patches, it will work as well. But I think we should > > > > switch at some point to dev_queue_xmit(). It should be simple to > > > > switch it. Just want to mention there is a difference which will be > > > > there in mac-cmds like association. > > > > > > I see what you mean. That's indeed true, we might just switch to > > > a less constrained transmit path. > > > > > > > I would define the difference in bypass qdisc or not. Whereas the > > qdisc can drop or delay transmitting... For me, the qdisc is currently > > in a "works for now" state. > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that. Actually, IIUC, we no longer want to go through the entire net stack. We still want to bypass it but without stopping/flushing the full queue like with an mlme transmission, so what about using ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it is more appropriate. Thanks, Miquèl
Hi, On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500: > > > Hi, > > > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote: > > > > > > Hi, > > > > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > Hi Alexander, > > > > > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > > > > > > > > > Hi, > > > > > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify > > > > > > everything works as soon as this series including beaconing support gets > > > > > > merged. > > > > > > > > > > > > > > > > I am not sure if a beacon send should be handled by an mlme helper > > > > > handling as this is a different use-case and the user does not trigger > > > > > an mac command and is waiting for some reply and a more complex > > > > > handling could be involved. There is also no need for hotpath xmit > > > > > handling is disabled during this time. It is just an async messaging > > > > > in some interval and just "try" to send it and don't care if it fails, > > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit() > > > > > function to queue it up to send it through the hotpath? > > > > > > > > > > I can ack those patches, it will work as well. But I think we should > > > > > switch at some point to dev_queue_xmit(). It should be simple to > > > > > switch it. Just want to mention there is a difference which will be > > > > > there in mac-cmds like association. > > > > > > > > I see what you mean. That's indeed true, we might just switch to > > > > a less constrained transmit path. > > > > > > > > > > I would define the difference in bypass qdisc or not. Whereas the > > > qdisc can drop or delay transmitting... For me, the qdisc is currently > > > in a "works for now" state. > > > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that. > > Actually, IIUC, we no longer want to go through the entire net stack. > We still want to bypass it but without stopping/flushing the full > queue like with an mlme transmission, so what about using > ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it > is more appropriate. I do not understand, what do we currently do with mlme ops via the ieee802154_subif_start_xmit() function, or? So we bypass everything from dev_queue_xmit() until do_xmit() netdev callback. I think it is fine, also I think "mostly" only dataframes should go through dev_queue_xmit(). With a HardMAC transceiver we would have control about "mostly" other frames than data either. So we should do everything with mlme-ops do what the spec says (to match up with HardMAC behaviour?) and don't allow common net hooks/etc. to change this behaviour? - Alex
Hi Alexander, alex.aring@gmail.com wrote on Tue, 24 Jan 2023 21:31:33 -0500: > Hi, > > On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500: > > > > > Hi, > > > > > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote: > > > > > > > > Hi, > > > > > > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > Hi Alexander, > > > > > > > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > > > > > > > > > > > Hi, > > > > > > > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify > > > > > > > everything works as soon as this series including beaconing support gets > > > > > > > merged. > > > > > > > > > > > > > > > > > > > I am not sure if a beacon send should be handled by an mlme helper > > > > > > handling as this is a different use-case and the user does not trigger > > > > > > an mac command and is waiting for some reply and a more complex > > > > > > handling could be involved. There is also no need for hotpath xmit > > > > > > handling is disabled during this time. It is just an async messaging > > > > > > in some interval and just "try" to send it and don't care if it fails, > > > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit() > > > > > > function to queue it up to send it through the hotpath? > > > > > > > > > > > > I can ack those patches, it will work as well. But I think we should > > > > > > switch at some point to dev_queue_xmit(). It should be simple to > > > > > > switch it. Just want to mention there is a difference which will be > > > > > > there in mac-cmds like association. > > > > > > > > > > I see what you mean. That's indeed true, we might just switch to > > > > > a less constrained transmit path. > > > > > > > > > > > > > I would define the difference in bypass qdisc or not. Whereas the > > > > qdisc can drop or delay transmitting... For me, the qdisc is currently > > > > in a "works for now" state. > > > > > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that. > > > > Actually, IIUC, we no longer want to go through the entire net stack. > > We still want to bypass it but without stopping/flushing the full > > queue like with an mlme transmission, so what about using > > ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it > > is more appropriate. > > I do not understand, what do we currently do with mlme ops via the > ieee802154_subif_start_xmit() function, or? So we bypass everything > from dev_queue_xmit() until do_xmit() netdev callback. Yes, that's the plan. We don't want any of the net stack features when sending beacons. > I think it is fine, also I think "mostly" only dataframes should go > through dev_queue_xmit(). With a HardMAC transceiver we would have > control about "mostly" other frames than data either. So we should do > everything with mlme-ops do what the spec says (to match up with > HardMAC behaviour?) and don't allow common net hooks/etc. to change > this behaviour? To summarize: - Data frames -> should go through dev_queue_xmit() - MLME ops with feedback constraints -> should go through the slow MLME path, so ieee802154_mlme_tx*() - MLME ops without feedback constraints like beacons -> should go through the hot path, but not through the whole net stack, so ieee802154_subif_start_xmit() Right now only data frames have security support, I propose we merge the initial support like that. Right now I am focused on UWB support (coming next, after the whole active scan/association additions), and in a second time we would be interested in llsec support for MLME ops. Does that sounds like a plan? If yes, I'll send a v2 with the right transmit helper used. Thanks, Miquèl NB: Perhaps a prerequisites of bringing security to the MLME ops would be to have wpan-tools updated (it looks like the support was never merged?) as well as a simple example how to use it on linux-wpan.org.
Hi, On Wed, Jan 25, 2023 at 5:00 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > Hi Alexander, > > alex.aring@gmail.com wrote on Tue, 24 Jan 2023 21:31:33 -0500: > > > Hi, > > > > On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > Hi Alexander, > > > > > > aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500: > > > > > > > Hi, > > > > > > > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > > > Hi Alexander, > > > > > > > > > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify > > > > > > > > everything works as soon as this series including beaconing support gets > > > > > > > > merged. > > > > > > > > > > > > > > > > > > > > > > I am not sure if a beacon send should be handled by an mlme helper > > > > > > > handling as this is a different use-case and the user does not trigger > > > > > > > an mac command and is waiting for some reply and a more complex > > > > > > > handling could be involved. There is also no need for hotpath xmit > > > > > > > handling is disabled during this time. It is just an async messaging > > > > > > > in some interval and just "try" to send it and don't care if it fails, > > > > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit() > > > > > > > function to queue it up to send it through the hotpath? > > > > > > > > > > > > > > I can ack those patches, it will work as well. But I think we should > > > > > > > switch at some point to dev_queue_xmit(). It should be simple to > > > > > > > switch it. Just want to mention there is a difference which will be > > > > > > > there in mac-cmds like association. > > > > > > > > > > > > I see what you mean. That's indeed true, we might just switch to > > > > > > a less constrained transmit path. > > > > > > > > > > > > > > > > I would define the difference in bypass qdisc or not. Whereas the > > > > > qdisc can drop or delay transmitting... For me, the qdisc is currently > > > > > in a "works for now" state. > > > > > > > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that. > > > > > > Actually, IIUC, we no longer want to go through the entire net stack. > > > We still want to bypass it but without stopping/flushing the full > > > queue like with an mlme transmission, so what about using > > > ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it > > > is more appropriate. > > > > I do not understand, what do we currently do with mlme ops via the > > ieee802154_subif_start_xmit() function, or? So we bypass everything > > from dev_queue_xmit() until do_xmit() netdev callback. > > Yes, that's the plan. We don't want any of the net stack features when > sending beacons. > > > I think it is fine, also I think "mostly" only dataframes should go > > through dev_queue_xmit(). With a HardMAC transceiver we would have > > control about "mostly" other frames than data either. So we should do > > everything with mlme-ops do what the spec says (to match up with > > HardMAC behaviour?) and don't allow common net hooks/etc. to change > > this behaviour? > > To summarize: > - Data frames -> should go through dev_queue_xmit() there are exceptions... e.g. AF_PACKET raw sockets can build whatever it wants (but it will probably not being supported by HardMAC transceivers) and send it out. There is no real control about it. So mostly I would agree here. > - MLME ops with feedback constraints -> should go through the slow MLME > path, so ieee802154_mlme_tx*() yea. > - MLME ops without feedback constraints like beacons -> should go > through the hot path, but not through the whole net stack, so > ieee802154_subif_start_xmit() > it will bypass the qdisc handling (+ some other things which are around there). The current difference is what I see llsec handling and other things which might be around there? It depends if other "MLME-ops" need to be e.g. encrypted or not. > Right now only data frames have security support, I propose we merge > the initial support like that. Right now I am focused on UWB support > (coming next, after the whole active scan/association additions), and > in a second time we would be interested in llsec support for MLME ops. > that's fine. > Does that sounds like a plan? If yes, I'll send a v2 with the right > transmit helper used. > yes. > Thanks, > Miquèl > > NB: Perhaps a prerequisites of bringing security to the MLME ops would > be to have wpan-tools updated (it looks like the support was never > merged?) as well as a simple example how to use it on linux-wpan.org. > this is correct. It is still in a branch, I am fine to merge it in this state although it's not really practical to use right now. - Alex
Hi, On Thu, Jan 26, 2023 at 8:29 PM Alexander Aring <aahringo@redhat.com> wrote: > > Hi, > > On Wed, Jan 25, 2023 at 5:00 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > Hi Alexander, > > > > alex.aring@gmail.com wrote on Tue, 24 Jan 2023 21:31:33 -0500: > > > > > Hi, > > > > > > On Tue, Jan 24, 2023 at 5:08 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > Hi Alexander, > > > > > > > > aahringo@redhat.com wrote on Mon, 23 Jan 2023 09:02:48 -0500: > > > > > > > > > Hi, > > > > > > > > > > On Mon, Jan 23, 2023 at 9:01 AM Alexander Aring <aahringo@redhat.com> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Wed, Jan 18, 2023 at 4:21 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > > > > > Hi Alexander, > > > > > > > > > > > > > > aahringo@redhat.com wrote on Sun, 15 Jan 2023 20:54:02 -0500: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Fri, Jan 6, 2023 at 6:33 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > > > > > > > > > > > > > > > > > Scanning being now supported, we can eg. play with hwsim to verify > > > > > > > > > everything works as soon as this series including beaconing support gets > > > > > > > > > merged. > > > > > > > > > > > > > > > > > > > > > > > > > I am not sure if a beacon send should be handled by an mlme helper > > > > > > > > handling as this is a different use-case and the user does not trigger > > > > > > > > an mac command and is waiting for some reply and a more complex > > > > > > > > handling could be involved. There is also no need for hotpath xmit > > > > > > > > handling is disabled during this time. It is just an async messaging > > > > > > > > in some interval and just "try" to send it and don't care if it fails, > > > > > > > > or? For mac802154 therefore I think we should use the dev_queue_xmit() > > > > > > > > function to queue it up to send it through the hotpath? > > > > > > > > > > > > > > > > I can ack those patches, it will work as well. But I think we should > > > > > > > > switch at some point to dev_queue_xmit(). It should be simple to > > > > > > > > switch it. Just want to mention there is a difference which will be > > > > > > > > there in mac-cmds like association. > > > > > > > > > > > > > > I see what you mean. That's indeed true, we might just switch to > > > > > > > a less constrained transmit path. > > > > > > > > > > > > > > > > > > > I would define the difference in bypass qdisc or not. Whereas the > > > > > > qdisc can drop or delay transmitting... For me, the qdisc is currently > > > > > > in a "works for now" state. > > > > > > > > > > probably also bypass other hooks like tc, etc. :-/ Not sure if we want that. > > > > > > > > Actually, IIUC, we no longer want to go through the entire net stack. > > > > We still want to bypass it but without stopping/flushing the full > > > > queue like with an mlme transmission, so what about using > > > > ieee802154_subif_start_xmit() instead of dev_queue_xmit()? I think it > > > > is more appropriate. > > > > > > I do not understand, what do we currently do with mlme ops via the > > > ieee802154_subif_start_xmit() function, or? So we bypass everything > > > from dev_queue_xmit() until do_xmit() netdev callback. > > > > Yes, that's the plan. We don't want any of the net stack features when > > sending beacons. > > > > > I think it is fine, also I think "mostly" only dataframes should go > > > through dev_queue_xmit(). With a HardMAC transceiver we would have > > > control about "mostly" other frames than data either. So we should do > > > everything with mlme-ops do what the spec says (to match up with > > > HardMAC behaviour?) and don't allow common net hooks/etc. to change > > > this behaviour? > > > > To summarize: > > - Data frames -> should go through dev_queue_xmit() > > there are exceptions... e.g. AF_PACKET raw sockets can build whatever > it wants (but it will probably not being supported by HardMAC > transceivers) and send it out. There is no real control about it. So > mostly I would agree here. > with "no real control" I mean the user needs to know what it's doing there and maybe the user just wants to play around e.g. monitor interface sending, whereas a monitor does not have an address being set up. - Alex
Alexander Aring <aahringo@redhat.com> wrote: >> - MLME ops without feedback constraints like beacons -> should go >> through the hot path, but not through the whole net stack, so >> ieee802154_subif_start_xmit() >> > it will bypass the qdisc handling (+ some other things which are around > there). The current difference is what I see llsec handling and other > things which might be around there? It depends if other "MLME-ops" need > to be e.g. encrypted or not. I haven't followed the whole thread. So I am neither agreeing nor disagreeing, just clarifying. Useful beacons are "signed" (have integrity applied), but not encrypted. It's important for userspace to be able to receive them, even if we don't have a key that can verify them. AFAIK, we have no specific interface to receive beacons. >> NB: Perhaps a prerequisites of bringing security to the MLME ops would >> be to have wpan-tools updated (it looks like the support was never >> merged?) as well as a simple example how to use it on linux-wpan.org. >> > this is correct. It is still in a branch, I am fine to merge it in this > state although it's not really practical to use right now. :-)
Hi, On Fri, Jan 27, 2023 at 2:52 PM Michael Richardson <mcr@sandelman.ca> wrote: > > > Alexander Aring <aahringo@redhat.com> wrote: > >> - MLME ops without feedback constraints like beacons -> should go > >> through the hot path, but not through the whole net stack, so > >> ieee802154_subif_start_xmit() > >> > > > it will bypass the qdisc handling (+ some other things which are around > > there). The current difference is what I see llsec handling and other > > things which might be around there? It depends if other "MLME-ops" need > > to be e.g. encrypted or not. > > I haven't followed the whole thread. > So I am neither agreeing nor disagreeing, just clarifying. > Useful beacons are "signed" (have integrity applied), but not encrypted. > I see. But that means they need to be going through llsec, just the payload isn't encrypted and the MIC is appended to provide integrity. > It's important for userspace to be able to receive them, even if we don't > have a key that can verify them. AFAIK, we have no specific interface to > receive beacons. > This can be done over multiple ways. Either over a socket communication or if they appear rarely we can put them into a netlink event. In my opinion we already put that in a higher level API in passive scan to interpret the receiving of a beacon on kernel level and trigger netlink events. I am not sure how HardMAC transceivers handle them on the transceiver side only or if they ever provide them to the next layer or not? For SoftMAC you can actually create a AF_PACKET raw socket, and you should see everything which bypass hardware address filters and kernel filters. Then an application can listen to them. - Alex
Hello, aahringo@redhat.com wrote on Fri, 27 Jan 2023 20:57:08 -0500: > Hi, > > On Fri, Jan 27, 2023 at 2:52 PM Michael Richardson <mcr@sandelman.ca> wrote: > > > > > > Alexander Aring <aahringo@redhat.com> wrote: > > >> - MLME ops without feedback constraints like beacons -> should go > > >> through the hot path, but not through the whole net stack, so > > >> ieee802154_subif_start_xmit() > > >> > > > > > it will bypass the qdisc handling (+ some other things which are around > > > there). The current difference is what I see llsec handling and other > > > things which might be around there? Not exactly, because llsec handling is not done in the net/ stack, but right inside the ieee802154 transmit callbacks, so I'd say it will be quite easy to tweak when we have a clear view of what we want in terms of encryption/integrity checking/signatures. > > > It depends if other "MLME-ops" need > > > to be e.g. encrypted or not. > > > > I haven't followed the whole thread. > > So I am neither agreeing nor disagreeing, just clarifying. > > Useful beacons are "signed" (have integrity applied), but not encrypted. > > > > I see. But that means they need to be going through llsec, just the > payload isn't encrypted and the MIC is appended to provide integrity. > > > It's important for userspace to be able to receive them, even if we don't > > have a key that can verify them. AFAIK, we have no specific interface to > > receive beacons. > > > > This can be done over multiple ways. Either over a socket > communication or if they appear rarely we can put them into a netlink > event. In my opinion we already put that in a higher level API in > passive scan to interpret the receiving of a beacon on kernel level > and trigger netlink events. Indeed. > I am not sure how HardMAC transceivers handle them on the transceiver > side only or if they ever provide them to the next layer or not? > For SoftMAC you can actually create a AF_PACKET raw socket, and you > should see everything which bypass hardware address filters and kernel > filters. Then an application can listen to them. Thanks, Miquèl