I've been trying to implement Mikrotik IE. It is a vendor IE that
carries stuff like radio name. Even though it is Mikrotik specific, UBNT
has a patch for madwifi:
https://github.com/jhairtt/ubnt-hal-0.7.379/blob/master/patches/madwifi-dfs-r3319-20080201/074-mtik-ie.patch
The IE is sent in beacon and assoc/reassoc frames. I think the correct
place for this is mac80211, but I'm not sure how should I expose a
switch to this functionality. Is there something like ioctl, or do I have
to implement a switch in nl80211, then in cfg80211 and then finally in
mac80211?
Any advice is greatly appreciated.
Hello
Since i already have done this for dd-wrt for mac80211 i can tell you,
its not easy but possible. the most easy way for broadcasting a custom IE
is just adding a custom IE with its properties to the hostapd
configuration. it does allow to set such properties
so you dont need to change anything in mac80211 which requires some evil
hacks
Am 15.08.2019 um 17:28 schrieb Josef Miegl:
> I've been trying to implement Mikrotik IE. It is a vendor IE that
> carries stuff like radio name. Even though it is Mikrotik specific, UBNT
> has a patch for madwifi:
> https://github.com/jhairtt/ubnt-hal-0.7.379/blob/master/patches/madwifi-dfs-r3319-20080201/074-mtik-ie.patch
>
> The IE is sent in beacon and assoc/reassoc frames. I think the correct
> place for this is mac80211, but I'm not sure how should I expose a
> switch to this functionality. Is there something like ioctl, or do I have
> to implement a switch in nl80211, then in cfg80211 and then finally in
> mac80211?
>
> Any advice is greatly appreciated.
>
Hello,
setting vendor elements in hostapd works great - but I need to add these
custom elements to assoc/reassoc management frames in station mode.
Given that the vendor elements option in hostapd works great would it be
possible to patch wpa_supplicant for it to work in station mode too?
Does nl80211 allow setting NL80211_ATTR_IE for station mode management
frames?
Also what are the 'evil hacks' you are talking about?
On Fri, Aug 16, 2019 at 06:07:02AM +0200, Sebastian Gottschall wrote:
> Hello
>
> Since i already have done this for dd-wrt for mac80211 i can tell you, its
> not easy but possible. the most easy way for broadcasting a custom IE
> is just adding a custom IE with its properties to the hostapd configuration.
> it does allow to set such properties
> so you dont need to change anything in mac80211 which requires some evil
> hacks
>
> Am 15.08.2019 um 17:28 schrieb Josef Miegl:
> > I've been trying to implement Mikrotik IE. It is a vendor IE that
> > carries stuff like radio name. Even though it is Mikrotik specific, UBNT
> > has a patch for madwifi:
> > https://github.com/jhairtt/ubnt-hal-0.7.379/blob/master/patches/madwifi-dfs-r3319-20080201/074-mtik-ie.patch
> >
> > The IE is sent in beacon and assoc/reassoc frames. I think the correct
> > place for this is mac80211, but I'm not sure how should I expose a
> > switch to this functionality. Is there something like ioctl, or do I have
> > to implement a switch in nl80211, then in cfg80211 and then finally in
> > mac80211?
> >
> > Any advice is greatly appreciated.
> >
Am 16.08.2019 um 13:10 schrieb Josef Miegl:
> Hello,
> setting vendor elements in hostapd works great - but I need to add these
> custom elements to assoc/reassoc management frames in station mode.
> Given that the vendor elements option in hostapd works great would it be
> possible to patch wpa_supplicant for it to work in station mode too?
>
> Does nl80211 allow setting NL80211_ATTR_IE for station mode management
> frames?
in station mode you are right. you need to modify mac80211. i have a mod
for mikrotik ie for ap and station implemented in mac80211.
i can send you a drop of my mac80211 tree which is not compatible with
upstream. but it will allow you to take off whatever you need to patch
it since such a
patch will never be accepted upstream. it adds a new field to the
station table which shows the radioname and broadcasts the radioname on
ap side. this has been tested
with ath9k and ath10k so far an works as expected. i modified also the
iw tool to show the informations
>
> Also what are the 'evil hacks' you are talking about?
to capture the ie from station side i have to keep the information in a
special static linked list per mac address. i cannot use the typical
mac802.11 structures for this. so its a little bit weired design to
bring it
to the station table finally. so not best design, but its working
>
> On Fri, Aug 16, 2019 at 06:07:02AM +0200, Sebastian Gottschall wrote:
>> Hello
>>
>> Since i already have done this for dd-wrt for mac80211 i can tell you, its
>> not easy but possible. the most easy way for broadcasting a custom IE
>> is just adding a custom IE with its properties to the hostapd configuration.
>> it does allow to set such properties
>> so you dont need to change anything in mac80211 which requires some evil
>> hacks
>>
>> Am 15.08.2019 um 17:28 schrieb Josef Miegl:
>>> I've been trying to implement Mikrotik IE. It is a vendor IE that
>>> carries stuff like radio name. Even though it is Mikrotik specific, UBNT
>>> has a patch for madwifi:
>>> https://github.com/jhairtt/ubnt-hal-0.7.379/blob/master/patches/madwifi-dfs-r3319-20080201/074-mtik-ie.patch
>>>
>>> The IE is sent in beacon and assoc/reassoc frames. I think the correct
>>> place for this is mac80211, but I'm not sure how should I expose a
>>> switch to this functionality. Is there something like ioctl, or do I have
>>> to implement a switch in nl80211, then in cfg80211 and then finally in
>>> mac80211?
>>>
>>> Any advice is greatly appreciated.
>>>
On Fri, Aug 16, 2019 at 01:15:30PM +0200, Sebastian Gottschall wrote:
> in station mode you are right. you need to modify mac80211.
Even if I don't need to capture the IE back? All I want is to include
extra vendor IE in client assoc/reassoc frames. If this is something the
current wireless stack cannot do, perhaps it should be implemented.
> i have a mod for mikrotik ie for ap and station implemented in mac80211.
> i can send you a drop of my mac80211 tree which is not compatible with
> upstream. but it will allow you to take off whatever you need to patch it
> since such a
>
> patch will never be accepted upstream. it adds a new field to the station
> table which shows the radioname and broadcasts the radioname on ap side.
> this has been tested
> with ath9k and ath10k so far an works as expected. i modified also the iw
> tool to show the informations
Your mac80211 tree drop would be greatly appreciated.
Thanks
On Fri, 2019-08-16 at 13:38 +0200, Josef Miegl wrote:
> On Fri, Aug 16, 2019 at 01:15:30PM +0200, Sebastian Gottschall wrote:
> > in station mode you are right. you need to modify mac80211.
> Even if I don't need to capture the IE back? All I want is to include
> extra vendor IE in client assoc/reassoc frames. If this is something the
> current wireless stack cannot do, perhaps it should be implemented.
Contrary to what Sebastian states, it certainly is possible today,
although not through wpa_supplicant's config file, only through the
wpa_cli interface, using the VENDOR_ELEM_ADD command. There are various
tests showing how to use this.
johannes
On Mon, Aug 19, 2019 at 12:12:43PM +0200, Johannes Berg wrote:
> Contrary to what Sebastian states, it certainly is possible today,
> although not through wpa_supplicant's config file, only through the
> wpa_cli interface, using the VENDOR_ELEM_ADD command. There are various
> tests showing how to use this.
Thanks Johannes. I noticed this too and tried adding a config file
option (OpenWRT doesn't compile wpa_supplicant with wpa_cli). I've added
sta_vendor_elements option (exactly like ap_vendor_elements). This is
the code setting vendor_elem:
+++ b/wpa_supplicant/wpa_supplicant.c
@@ -5833,6 +5833,16 @@
wpas_mbo_update_non_pref_chan(wpa_s, wpa_s->conf->non_pref_chan);
#endif /* CONFIG_MBO */
+ if (wpa_s->conf->sta_vendor_elements) {
+ if (wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] == NULL) {
+ wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] = wpa_s->conf->sta_vendor_elements;
+ } else {
+ wpabuf_resize(&wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ], wpabuf_len(wpa_s->conf->sta_vendor_elements));
+ wpabuf_put_buf(wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ], wpa_s->conf->sta_vendor_elements);
+ }
+ }
+
wpa_supplicant_set_default_scan_ies(wpa_s);
return 0;
But when I actually set sta_vendor_elements to something, all it does is
failing the 4-way handshake during association. The IE is perfectly
valid and it works with ap_vendor_elements, no nl80211 malformed IEs
error either. Am I missing something?
Josef
On Mon, 2019-08-19 at 13:37 +0200, Josef Miegl wrote:
> On Mon, Aug 19, 2019 at 12:12:43PM +0200, Johannes Berg wrote:
> > Contrary to what Sebastian states, it certainly is possible today,
> > although not through wpa_supplicant's config file, only through the
> > wpa_cli interface, using the VENDOR_ELEM_ADD command. There are various
> > tests showing how to use this.
>
> Thanks Johannes. I noticed this too and tried adding a config file
> option (OpenWRT doesn't compile wpa_supplicant with wpa_cli). I've added
> sta_vendor_elements option (exactly like ap_vendor_elements). This is
> the code setting vendor_elem:
>
> +++ b/wpa_supplicant/wpa_supplicant.c
> @@ -5833,6 +5833,16 @@
> wpas_mbo_update_non_pref_chan(wpa_s, wpa_s->conf->non_pref_chan);
> #endif /* CONFIG_MBO */
>
> + if (wpa_s->conf->sta_vendor_elements) {
> + if (wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] == NULL) {
> + wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ] = wpa_s->conf->sta_vendor_elements;
> + } else {
> + wpabuf_resize(&wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ], wpabuf_len(wpa_s->conf->sta_vendor_elements));
> + wpabuf_put_buf(wpa_s->vendor_elem[VENDOR_ELEM_ASSOC_REQ], wpa_s->conf->sta_vendor_elements);
> + }
> + }
> +
> wpa_supplicant_set_default_scan_ies(wpa_s);
>
> return 0;
>
>
> But when I actually set sta_vendor_elements to something, all it does is
> failing the 4-way handshake during association. The IE is perfectly
> valid and it works with ap_vendor_elements, no nl80211 malformed IEs
> error either. Am I missing something?
I don't know, try capturing over the air?
Perhaps the vendor IEs added this way are added *first* before all the
RSN IEs, and that's tripping up your AP, and you'd have to add them
*after* the normal elements? Not really sure where/how they're added?
johannes
Am 19.08.2019 um 12:12 schrieb Johannes Berg:
> On Fri, 2019-08-16 at 13:38 +0200, Josef Miegl wrote:
>> On Fri, Aug 16, 2019 at 01:15:30PM +0200, Sebastian Gottschall wrote:
>>> in station mode you are right. you need to modify mac80211.
>> Even if I don't need to capture the IE back? All I want is to include
>> extra vendor IE in client assoc/reassoc frames. If this is something the
>> current wireless stack cannot do, perhaps it should be implemented.
> Contrary to what Sebastian states, it certainly is possible today,
> although not through wpa_supplicant's config file, only through the
> wpa_cli interface, using the VENDOR_ELEM_ADD command. There are various
> tests showing how to use this.
>
> johannes
i was talking about a different scenario. its not about adding a
element, but to read it back for gui for instance. this is why i made a
patch which parses this special ie
and adds the radioname as extra element to the station table. this works
for ap as well of course. so iw ath0 station dump will print out the
radio name if available
>
>
>
On Tue, 2019-08-20 at 13:53 +0200, Sebastian Gottschall wrote:
> i was talking about a different scenario. its not about adding a
> element, but to read it back for gui for instance. this is why i made a
> patch which parses this special ie
> and adds the radioname as extra element to the station table. this works
> for ap as well of course. so iw ath0 station dump will print out the
> radio name if available
Oh. That's something I'd argue should just be implemented in hostapd
then? No need to do anything in the kernel for that.
johannes
Am 20.08.2019 um 14:22 schrieb Johannes Berg:
> On Tue, 2019-08-20 at 13:53 +0200, Sebastian Gottschall wrote:
>
>> i was talking about a different scenario. its not about adding a
>> element, but to read it back for gui for instance. this is why i made a
>> patch which parses this special ie
>> and adds the radioname as extra element to the station table. this works
>> for ap as well of course. so iw ath0 station dump will print out the
>> radio name if available
> Oh. That's something I'd argue should just be implemented in hostapd
> then? No need to do anything in the kernel for that.
i know. thats why i never even tried to contribute it upstream. but from
hostapd side it was more complicated than just hacking mac80211
and from stations a second mod for wpa_supplicant would be needed and
since the dd-wrt webgui just uses nl80211 to show the station table
its more comportable and takes less code just todo it within the driver
i there is special interest in it i could of course try to clean it up
and make a upstream patch out of it
>
> johannes
>
>
On August 19, 2019 10:21:55 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
>I don't know, try capturing over the air?
>
>Perhaps the vendor IEs added this way are added *first* before all the
>RSN IEs, and that's tripping up your AP, and you'd have to add them
>*after* the normal elements? Not really sure where/how they're added?
>
>johannes
The vendor elements are added at the very end of the frame. In fact I tried moving the RSN IE to the end of the frame so that the frame is similar to the one ubnt airos produces. No luck either. One thing I've learned is that ubnt airos assoc req frames have the WMM/WME IE placed before HT Capabilities. But I'm not sure how to move it and also not sure if it would actually work.
I am getting 4WAY_HANDSHAKE_TIMEOUT. From capturing I can see the station sends Key (msg 2 of 4) and a bunch of acknowledgements, but it never sends Key (msg 4 of 4) afterwards.
I feel like I'm stuck.. What could be the reason for this behaviour?
Josef
Am 21.08.2019 um 22:04 schrieb Josef Miegl:
> On August 19, 2019 10:21:55 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
>> I don't know, try capturing over the air?
>>
>> Perhaps the vendor IEs added this way are added *first* before all the
>> RSN IEs, and that's tripping up your AP, and you'd have to add them
>> *after* the normal elements? Not really sure where/how they're added?
>>
>> johannes
> The vendor elements are added at the very end of the frame. In fact I tried moving the RSN IE to the end of the frame so that the frame is similar to the one ubnt airos produces. No luck either. One thing I've learned is that ubnt airos assoc req frames have the WMM/WME IE placed before HT Capabilities. But I'm not sure how to move it and also not sure if it would actually work.
>
> I am getting 4WAY_HANDSHAKE_TIMEOUT. From capturing I can see the station sends Key (msg 2 of 4) and a bunch of acknowledgements, but it never sends Key (msg 4 of 4) afterwards.
>
> I feel like I'm stuck.. What could be the reason for this behaviour?
i can just tell you that i added the mikrotik ie just before the wmm ie
but after ht/vht ie
> Josef
>
On Wed, 2019-08-21 at 22:04 +0200, Josef Miegl wrote:
>
> The vendor elements are added at the very end of the frame. In fact I
> tried moving the RSN IE to the end of the frame so that the frame is
> similar to the one ubnt airos produces. No luck either. One thing I've
> learned is that ubnt airos assoc req frames have the WMM/WME IE placed
> before HT Capabilities. But I'm not sure how to move it and also not
> sure if it would actually work.
>
> I am getting 4WAY_HANDSHAKE_TIMEOUT. From capturing I can see the
> station sends Key (msg 2 of 4) and a bunch of acknowledgements, but it
> never sends Key (msg 4 of 4) afterwards.
>
> I feel like I'm stuck.. What could be the reason for this behaviour?
What AP are you trying to connect to? Have you tried adding some other
random vendor IE, with an OUI that the AP is almost certain to not know?
Maybe it's actually interpreting this somehow?
Would you be willing to show sniffer captures so we could take a look?
johannes
On August 21, 2019 10:12:26 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
>What AP are you trying to connect to? Have you tried adding some other
>random vendor IE, with an OUI that the AP is almost certain to not
>know?
>Maybe it's actually interpreting this somehow?
>
>Would you be willing to show sniffer captures so we could take a look?
>
>johannes
Of course it's interpreting the IE. Random vendor IE works fine. Let me explain why I'm even bothering with sending this mikrotik IE in association requests. The Mikrotik IE has a flag that tells the AP if the station wants WDS. Setting that flag and sending the mikrotik IE is required for transparent bridging with a mikrotik AP.
Sending the Mikrotik IE with the WDS bit set to 0 works fine. Now I'm sure this is a problem on Mikrotiks side, however in ubnts airos this works as expected, and since their airos is probably based on openwrt there has to be a way to make this work.
I will send you the captures, however there doesn't seem to be anything much interesting in them.
Josef
Forgot to add:
This is what the mikrotik AP reports:
Disconnecting, unicast key exchamge timeout
Josef
On August 20, 2019 2:36:21 PM GMT+02:00, Sebastian Gottschall <[email protected]> wrote:
>i know. thats why i never even tried to contribute it upstream. but
>from
>hostapd side it was more complicated than just hacking mac80211
>and from stations a second mod for wpa_supplicant would be needed and
>since the dd-wrt webgui just uses nl80211 to show the station table
>its more comportable and takes less code just todo it within the driver
>i there is special interest in it i could of course try to clean it up
>and make a upstream patch out of it
I don't think something like Mikrotiks IE belongs to hostapd. The cleanest solution is probably parsing the IE and generating the IE for hostapd with an external tool, that can the dd-wrt GUI then use. I've made a simple C program for this, can share if you want.
Josef
Josef
On Thu, 2019-08-22 at 01:57 +0200, Josef Miegl wrote:
> On August 20, 2019 2:36:21 PM GMT+02:00, Sebastian Gottschall <[email protected]> wrote:
> > i know. thats why i never even tried to contribute it upstream. but
> > from
> > hostapd side it was more complicated than just hacking mac80211
> > and from stations a second mod for wpa_supplicant would be needed and
> > since the dd-wrt webgui just uses nl80211 to show the station table
> > its more comportable and takes less code just todo it within the driver
> > i there is special interest in it i could of course try to clean it up
> > and make a upstream patch out of it
>
> I don't think something like Mikrotiks IE belongs to hostapd. The
> cleanest solution is probably parsing the IE and generating the IE for
> hostapd with an external tool, that can the dd-wrt GUI then use. I've
> made a simple C program for this, can share if you want.
Sebastian was talking about yet another case - namely recording it for
the stations, to be able to show it.
I guess hostapd could be made to just generally record *all* the
association request IEs that a station sent and make those available
over the control interface.
Alternatively, you could have another application just listen to nl80211
events, I guess.
Or even the kernel could capture *all*, but I don't see why we'd waste
unpageable kernel memory for it.
johannes
On Wed, 2019-08-21 at 23:17 +0200, Josef Miegl wrote:
> On August 21, 2019 10:12:26 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
> > What AP are you trying to connect to? Have you tried adding some other
> > random vendor IE, with an OUI that the AP is almost certain to not
> > know?
> > Maybe it's actually interpreting this somehow?
> >
> > Would you be willing to show sniffer captures so we could take a look?
> >
> > johannes
>
> Of course it's interpreting the IE. Random vendor IE works fine.
Ok, that wasn't really clear to me until now.
> Let me explain why I'm even bothering with sending this mikrotik IE in
> association requests. The Mikrotik IE has a flag that tells the AP if
> the station wants WDS. Setting that flag and sending the mikrotik IE
> is required for transparent bridging with a mikrotik AP.
Aha, ok.
> Sending the Mikrotik IE with the WDS bit set to 0 works fine.
Even more curious :-)
> Now I'm sure this is a problem on Mikrotiks side, however in ubnts
> airos this works as expected, and since their airos is probably based
> on openwrt there has to be a way to make this work.
>
> I will send you the captures, however there doesn't seem to be
> anything much interesting in them.
Indeed, it seems unlikely I could get anything from that.
Do you have a successful handshake done by a "real" client
implementation?
Perhaps it expects the 4-way-HS to already be in 4-addr frame format, or
something else special in the 4-way-HS if you have WDS?
johannes
On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
>
> Perhaps it expects the 4-way-HS to already be in 4-addr frame format, or
> something else special in the 4-way-HS if you have WDS?
I think this is actually the right guess.
The working capture you sent me has the EAPOL 2/4 in a 4-addr frame:
ToDS=1, FromDS=1
A1/RA = AP
A2/TA = STA
A3/DA = AP
A4/SA = STA
The non-working capture has the EAPOL 2/4 in 3-addr format, as you'd
expect in the Linux 4-addr AP/STA case:
ToDS=1, FromDS=0
A1/RA = AP
A2/TA,SA = STA
A3/DA = AP
Since it's basically ignoring the message 2 (it just says "handshake
timed out" later) it's almost certainly expecting *only* the 4-addr
format.
As a hack, you could do
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2623,8 +2623,7 @@ static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,
memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
memcpy(hdr.addr3, sdata->u.mgd.bssid, ETH_ALEN);
hdrlen = 24;
- } else if (sdata->u.mgd.use_4addr &&
- cpu_to_be16(ethertype) != sdata->control_port_protocol) {
+ } else if (sdata->u.mgd.use_4addr) {
fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS |
IEEE80211_FCTL_TODS);
/* RA TA DA SA */
in mac80211, then it should send 4-addr frames even for EAPOL.
johannes
On August 22, 2019 10:08:13 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
>On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
>>
>> Perhaps it expects the 4-way-HS to already be in 4-addr frame format,
>or
>> something else special in the 4-way-HS if you have WDS?
>
>I think this is actually the right guess.
Yes, it indeed it! Thank you so much Johannes!
>As a hack, you could do
>
>--- a/net/mac80211/tx.c
>+++ b/net/mac80211/tx.c
>@@ -2623,8 +2623,7 @@ static struct sk_buff *ieee80211_build_hdr(struct
>ieee80211_sub_if_data *sdata,
> memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
> memcpy(hdr.addr3, sdata->u.mgd.bssid, ETH_ALEN);
> hdrlen = 24;
>- } else if (sdata->u.mgd.use_4addr &&
>- cpu_to_be16(ethertype) !=
>sdata->control_port_protocol) {
>+ } else if (sdata->u.mgd.use_4addr) {
> fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS |
> IEEE80211_FCTL_TODS);
> /* RA TA DA SA */
>
>
>in mac80211, then it should send 4-addr frames even for EAPOL.
Works great. Is there a possibility that a toggle for this could be accepted upstream? After all, WDS isn't really standardized.
Thank you!
Josef
> Works great. Is there a possibility that a toggle for this could be
> accepted upstream? After all, WDS isn't really standardized.
I general, I'd say yes. However!
There's ongoing to work to make EAPOL frames go over nl80211 instead,
see e.g. ieee80211_tx_control_port() in mac80211, and this patch for
hostapd:
https://patchwork.ozlabs.org/patch/1108185/
I'd prefer to have it in this path, by having a flag like the "bool
unencrypted" passed to ieee80211_tx_control_port(), (and replace "bool
unencrypted" by "unsigned int flags"). That way, we don't have to
actually keep any state.
In mac80211, we can pass this down to __ieee80211_subif_start_xmit() and
ieee80211_build_hdr() in the ctrl_flags or something like that. It
doesn't actually need to be a control or info flag, so we could add yet
another argument to save the space, but dunno if that's worth it now.
johannes
Am 22.08.2019 um 23:06 schrieb Josef Miegl:
> On August 22, 2019 10:08:13 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
>> On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
>>> Perhaps it expects the 4-way-HS to already be in 4-addr frame format,
>> or
>>> something else special in the 4-way-HS if you have WDS?
>> I think this is actually the right guess.
> Yes, it indeed it! Thank you so much Johannes!
good finding. my idea here is if we parse the wds flags field from mtik
ie within mac80211 we could also support this special handing without
any workaround
On Tue, 2019-08-27 at 15:08 +0200, Sebastian Gottschall wrote:
> Am 22.08.2019 um 23:06 schrieb Josef Miegl:
> > On August 22, 2019 10:08:13 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
> > > On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
> > > > Perhaps it expects the 4-way-HS to already be in 4-addr frame format,
> > > or
> > > > something else special in the 4-way-HS if you have WDS?
> > > I think this is actually the right guess.
> > Yes, it indeed it! Thank you so much Johannes!
> good finding. my idea here is if we parse the wds flags field from mtik
> ie within mac80211 we could also support this special handing without
> any workaround
The same holds true if we parse it in hostapd, and add a flag to the
EAPOL to control the encapsulation, which is way more general, so much
preferable IMHO.
johannes
Am 27.08.2019 um 15:10 schrieb Johannes Berg:
> On Tue, 2019-08-27 at 15:08 +0200, Sebastian Gottschall wrote:
>> Am 22.08.2019 um 23:06 schrieb Josef Miegl:
>>> On August 22, 2019 10:08:13 PM GMT+02:00, Johannes Berg <[email protected]> wrote:
>>>> On Thu, 2019-08-22 at 09:00 +0200, Johannes Berg wrote:
>>>>> Perhaps it expects the 4-way-HS to already be in 4-addr frame format,
>>>> or
>>>>> something else special in the 4-way-HS if you have WDS?
>>>> I think this is actually the right guess.
>>> Yes, it indeed it! Thank you so much Johannes!
>> good finding. my idea here is if we parse the wds flags field from mtik
>> ie within mac80211 we could also support this special handing without
>> any workaround
> The same holds true if we parse it in hostapd, and add a flag to the
> EAPOL to control the encapsulation, which is way more general, so much
> preferable IMHO.
i know .same result and i know that the userspace solution is more prefered
Sebastian
>
> johannes
>
>