From: Manikanta Pubbisetty <mpubbise@codeaurora.org> To: Johannes Berg <johannes@sipsolutions.net> Cc: Kalle Valo <kvalo@codeaurora.org>, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, Sebastian Gottschall <s.gottschall@dd-wrt.com> Subject: Re: [PATCH] ath10k: add dynamic vlan support Date: Fri, 24 Aug 2018 11:20:17 +0530 [thread overview] Message-ID: <80f8e88e5161f2731e67e1c0e1d7225c@codeaurora.org> (raw) In-Reply-To: <1534408023.3547.64.camel@sipsolutions.net> On 2018-08-16 13:57, Johannes Berg wrote: > On Tue, 2018-08-14 at 18:23 +0530, Manikanta Pubbisetty wrote: > >> > I don't think that makes sense. If we split the capability of AP_VLAN >> > and AP_VLAN_FOR_4ADDR at the "root", then we don't need to play with all >> > these things. Yes, this is slightly awkward for userspace, and perhaps >> > with the interface combination checks, but I'd like you to look at that. > >> I was working on splitting the 4-addr functionality from AP/VLAN >> iftype; >> I have introduced a new iftype NL80211_IFTYPE_AP_4ADDR and moved the >> 4-addr handling from AP/VLAN to this new iftype. But this approach >> breaks the backward compatibility with older userspace applications. > > Yeah ... > > I'm confused and no longer sure what I was thinking, nor even what > we're > trying to achieve here... > I had introduced a change db3bdcb9c3ff (" mac80211: allow AP_VLAN operation on crypto controlled devices ") for supporting VLAN functionality on ath10k devices; this commit has broken 4 addr support on ath10k devices as I was advertising the AP/VLAN support conditionally. Since 4 addr operation is tied to AP/VLAN support, with this change, only the chips which support VLAN functionality can support 4 addr operation but other ath10k chips don't. From what I can understand from our previous discussions, we had to separate the 4addr support from the AP/VLAN iftype but doing so could lead to backward compatibility issues. I have the code which separates the 4addr functionality from AP/VLAN but the bigger problem is the backward compatibility. I am hoping that now I have set the context correctly :) >> Since I am completely moving the 4-addr handling to the new type, >> older >> applications which do not understand this new type will simply fail >> and >> 4-addr mode will be completely broken. >> >> Currently, whenever a 4-addr client attempts a connection, hostapd >> just >> creates a AP/VLAN interface and moves the 4-addr client to the AP/VLAN >> iface; there are no other checks. I had no other option other than >> going >> with a new iftype for 4-addr handling. >> >> Is there a way we can maintain backward compatibility with this >> approach? Retaining the 4-addr handling in AP/VLAN and duplicating the >> same functionality to the new iftype seems will work but I am not sure >> if this is the right approach. > > I think we have to keep the 4-addr handling in AP_VLAN iftype either > way, to not break existing hostapd. We could introduce a separate > AP_VLAN_NO_4ADDR and then require updating hostapd to get non-4addr > VLAN, but that also seems awkward. > > Since hostapd doesn't currently check anything... > > Ok, no, I'm confused now. If we just clear WIPHY_FLAG_4ADDR_AP, don't > we > get what we want? 4-addr AP_VLAN interfaces would no longer be > permitted > to be created? As I explained above, the agenda is to provide the driver (in this case, ath10k) a better control for advertising the device capabilities; only few ath10k chips can support VLAN functionality but all of them can support 4 addr operation. Manikanta
WARNING: multiple messages have this Message-ID (diff)
From: Manikanta Pubbisetty <mpubbise@codeaurora.org> To: Johannes Berg <johannes@sipsolutions.net> Cc: Sebastian Gottschall <s.gottschall@dd-wrt.com>, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, Kalle Valo <kvalo@codeaurora.org> Subject: Re: [PATCH] ath10k: add dynamic vlan support Date: Fri, 24 Aug 2018 11:20:17 +0530 [thread overview] Message-ID: <80f8e88e5161f2731e67e1c0e1d7225c@codeaurora.org> (raw) In-Reply-To: <1534408023.3547.64.camel@sipsolutions.net> On 2018-08-16 13:57, Johannes Berg wrote: > On Tue, 2018-08-14 at 18:23 +0530, Manikanta Pubbisetty wrote: > >> > I don't think that makes sense. If we split the capability of AP_VLAN >> > and AP_VLAN_FOR_4ADDR at the "root", then we don't need to play with all >> > these things. Yes, this is slightly awkward for userspace, and perhaps >> > with the interface combination checks, but I'd like you to look at that. > >> I was working on splitting the 4-addr functionality from AP/VLAN >> iftype; >> I have introduced a new iftype NL80211_IFTYPE_AP_4ADDR and moved the >> 4-addr handling from AP/VLAN to this new iftype. But this approach >> breaks the backward compatibility with older userspace applications. > > Yeah ... > > I'm confused and no longer sure what I was thinking, nor even what > we're > trying to achieve here... > I had introduced a change db3bdcb9c3ff (" mac80211: allow AP_VLAN operation on crypto controlled devices ") for supporting VLAN functionality on ath10k devices; this commit has broken 4 addr support on ath10k devices as I was advertising the AP/VLAN support conditionally. Since 4 addr operation is tied to AP/VLAN support, with this change, only the chips which support VLAN functionality can support 4 addr operation but other ath10k chips don't. From what I can understand from our previous discussions, we had to separate the 4addr support from the AP/VLAN iftype but doing so could lead to backward compatibility issues. I have the code which separates the 4addr functionality from AP/VLAN but the bigger problem is the backward compatibility. I am hoping that now I have set the context correctly :) >> Since I am completely moving the 4-addr handling to the new type, >> older >> applications which do not understand this new type will simply fail >> and >> 4-addr mode will be completely broken. >> >> Currently, whenever a 4-addr client attempts a connection, hostapd >> just >> creates a AP/VLAN interface and moves the 4-addr client to the AP/VLAN >> iface; there are no other checks. I had no other option other than >> going >> with a new iftype for 4-addr handling. >> >> Is there a way we can maintain backward compatibility with this >> approach? Retaining the 4-addr handling in AP/VLAN and duplicating the >> same functionality to the new iftype seems will work but I am not sure >> if this is the right approach. > > I think we have to keep the 4-addr handling in AP_VLAN iftype either > way, to not break existing hostapd. We could introduce a separate > AP_VLAN_NO_4ADDR and then require updating hostapd to get non-4addr > VLAN, but that also seems awkward. > > Since hostapd doesn't currently check anything... > > Ok, no, I'm confused now. If we just clear WIPHY_FLAG_4ADDR_AP, don't > we > get what we want? 4-addr AP_VLAN interfaces would no longer be > permitted > to be created? As I explained above, the agenda is to provide the driver (in this case, ath10k) a better control for advertising the device capabilities; only few ath10k chips can support VLAN functionality but all of them can support 4 addr operation. Manikanta _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-08-24 9:23 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-20 13:57 [PATCH] ath10k: add dynamic vlan support Manikanta Pubbisetty 2018-04-20 13:57 ` Manikanta Pubbisetty 2018-04-23 19:18 ` Sebastian Gottschall 2018-04-23 19:18 ` Sebastian Gottschall 2018-05-18 9:53 ` Johannes Berg 2018-05-18 9:53 ` Johannes Berg 2018-05-18 10:40 ` Sebastian Gottschall 2018-05-18 10:40 ` Sebastian Gottschall 2018-04-24 8:09 ` Kalle Valo 2018-04-24 8:09 ` Kalle Valo 2018-04-24 9:09 ` Sebastian Gottschall 2018-04-24 9:09 ` Sebastian Gottschall 2018-04-24 9:18 ` Manikanta Pubbisetty 2018-04-24 9:18 ` Manikanta Pubbisetty 2018-04-24 9:52 ` Kalle Valo 2018-04-24 9:52 ` Kalle Valo 2018-04-24 9:55 ` Sebastian Gottschall 2018-04-24 9:55 ` Sebastian Gottschall 2018-05-04 6:50 ` Manikanta Pubbisetty 2018-05-04 6:50 ` Manikanta Pubbisetty 2018-05-05 9:50 ` Sebastian Gottschall 2018-05-05 9:50 ` Sebastian Gottschall 2018-05-18 9:54 ` Johannes Berg 2018-05-18 9:54 ` Johannes Berg 2018-05-18 10:52 ` Sebastian Gottschall 2018-05-18 10:52 ` Sebastian Gottschall 2018-05-21 6:42 ` Manikanta Pubbisetty 2018-05-21 6:42 ` Manikanta Pubbisetty 2018-05-23 9:50 ` Johannes Berg 2018-05-23 9:50 ` Johannes Berg 2018-05-23 10:39 ` Manikanta Pubbisetty 2018-05-23 10:39 ` Manikanta Pubbisetty 2018-05-23 10:39 ` Johannes Berg 2018-05-23 10:39 ` Johannes Berg 2018-05-23 10:50 ` Manikanta Pubbisetty 2018-05-23 10:50 ` Manikanta Pubbisetty 2018-05-24 4:41 ` Sebastian Gottschall 2018-05-24 4:41 ` Sebastian Gottschall 2018-06-18 20:49 ` Johannes Berg 2018-06-18 20:49 ` Johannes Berg 2018-08-14 12:53 ` Manikanta Pubbisetty 2018-08-14 12:53 ` Manikanta Pubbisetty 2018-08-16 8:27 ` Johannes Berg 2018-08-16 8:27 ` Johannes Berg 2018-08-24 5:50 ` Manikanta Pubbisetty [this message] 2018-08-24 5:50 ` Manikanta Pubbisetty 2018-09-03 10:39 ` Johannes Berg 2018-09-03 10:39 ` Johannes Berg 2018-09-05 6:03 ` Manikanta Pubbisetty 2018-09-05 6:03 ` Manikanta Pubbisetty [not found] ` <15ca06c2-0d43-99c1-8f31-19e73629ab70@codeaurora.org> 2018-08-24 8:14 ` Kalle Valo 2018-08-24 8:14 ` Kalle Valo
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=80f8e88e5161f2731e67e1c0e1d7225c@codeaurora.org \ --to=mpubbise@codeaurora.org \ --cc=ath10k@lists.infradead.org \ --cc=johannes@sipsolutions.net \ --cc=kvalo@codeaurora.org \ --cc=linux-wireless@vger.kernel.org \ --cc=s.gottschall@dd-wrt.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.