From: Johannes Berg <johannes@sipsolutions.net>
To: Denis Kenzior <denkenz@gmail.com>, linux-wireless@vger.kernel.org
Subject: Re: [RFC v5 0/9] EAPoL over NL80211
Date: Thu, 22 Mar 2018 11:28:13 +0100 [thread overview]
Message-ID: <1521714493.19621.5.camel@sipsolutions.net> (raw)
In-Reply-To: <6c4a389a-55e1-5af2-cac2-1754fce7fabf@gmail.com> (sfid-20180321_161830_319006_32337E45)
On Wed, 2018-03-21 at 10:18 -0500, Denis Kenzior wrote:
>
> Sorry. I assumed people read the change log :)
And I should :-)
> > > - It is unclear to me how AP_VLAN and AP interfaces should synchronize on
> > > conn_owner_nlportid. This is required for tx_control_port to work.
> >
> > I'm not really sure what you mean? Technically I guess an AP_VLAN could
> > have a different owner from an AP, but if the AP goes down all the
> > AP_VLANs go down with it already anyway.
>
> So the issue is that when mac80211 calls cfg80211_rx_control_port and
> subsequently __nl80211_rx_control_port, we grab the nlportid from the
> wdev. So if that isn't synchronized, then AP_VLAN devices won't be
> sending the EAPoL frames to the right place.
Oh, ok, gotcha. I guess mac80211 would have to sync over the data, just
like it does for other things? You also copied over the
control_port_over_nl80211 setting, so could do the same here?
But no, maybe that doesn't make sense, since ...
Hmm. Ok, I think I see what you're getting at.
The key point seems to be that we don't have any sort of "add VLAN to
AP operation" - it's auto-detected based on the MAC address.
However, it doesn't actually matter at all - we shouldn't get there
with VLAN interface. EAPOL frames are always sent out to the
corresponding AP interface, see ieee80211_rx_h_data:
if (rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
unlikely(port_control) && sdata->bss) {
sdata = container_of(sdata->bss, struct ieee80211_sub_if_data,
u.ap);
dev = sdata->dev;
rx->sdata = sdata;
}
> > > - JOIN_IBSS & JOIN_MESH don't seem to support control_port_ethertype or
> > > control_port_no_encrypt. Should struct cfg80211_crypto_settings parsed inside
> > > nl80211_crypto_settings be added to ibss_params or mesh_config/mesh_setup?
> >
> > I don't think it matters - they just don't support this now and don't
> > really need to.
> >
>
> Except that the eapol over nl80211 flag is being sent in security
> settings. This covers STA/AP/P2P_GO/P2P_CLIENT. We need some way of
> passing this information for mesh & ibss.
Not sure I understand what you're saying. Can't we just say the flag
isn't permitted in those modes?
johannes
next prev parent reply other threads:[~2018-03-22 10:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 21:59 [RFC v5 0/9] EAPoL over NL80211 Denis Kenzior
2018-03-13 21:59 ` [RFC v5 1/9] nl80211: Add CMD_CONTROL_PORT_FRAME API Denis Kenzior
2018-03-13 21:59 ` [RFC v5 2/9] nl80211: Implement TX of control port frames Denis Kenzior
2018-03-13 21:59 ` [RFC v5 3/9] nl80211: Add CONTROL_PORT_OVER_NL80211 attribute Denis Kenzior
2018-03-21 7:47 ` Johannes Berg
2018-03-21 15:01 ` Denis Kenzior
2018-03-21 15:09 ` Johannes Berg
2018-03-13 21:59 ` [RFC v5 4/9] cfg80211: Support all iftypes in autodisconnect_wk Denis Kenzior
2018-03-21 7:46 ` Johannes Berg
2018-03-21 15:27 ` Denis Kenzior
2018-03-21 15:40 ` Johannes Berg
2018-03-13 21:59 ` [RFC v5 5/9] nl80211: Add SOCKET_OWNER support to JOIN_IBSS Denis Kenzior
2018-03-13 21:59 ` [RFC v5 6/9] nl80211: Add SOCKET_OWNER support to JOIN_MESH Denis Kenzior
2018-03-13 21:59 ` [RFC v5 7/9] nl80211: Add SOCKET_OWNER support to START_AP Denis Kenzior
2018-03-13 21:59 ` [RFC v5 8/9] mac80211: Add support for tx_control_port Denis Kenzior
2018-03-13 21:59 ` [RFC v5 9/9] mac80211: Send control port frames over nl80211 Denis Kenzior
2018-03-21 15:13 ` [RFC v5 0/9] EAPoL over NL80211 Johannes Berg
2018-03-21 15:18 ` Denis Kenzior
2018-03-22 10:28 ` Johannes Berg [this message]
2018-03-22 13:54 ` Denis Kenzior
2018-03-23 8:04 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1521714493.19621.5.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=denkenz@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).