Re: ath9k and 16 VAP interfaces?
Hi, I'm using [1]. I was seeing some trouble with powersave + broadcasts, so I added [2], so that the queue would get empty faster. Regards, M. Braun [1] http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/kernel/mac80211/patches/911-more-ap-interfaces.patch;h=873a6cb7bdb8a7462ffd07c1a50fc87c580f223d;hb=refs/heads/femwlan_stage2.kernel4.9 [2] http://git.fem.tu-ilmenau.de/?p=fem-wlan.git;a=blob;f=package/kernel/mac80211/patches/915-use-more-time-for-multicast.patch;h=05d7fb6c2567e1abdef63a4d01f02df7f8501630;hb=refs/heads/femwlan_stage2.kernel4.9 Am 30.07.2018 16:34, schrieb Ben Greear: On 07/30/2018 04:13 AM, Matthias May wrote: On 30/07/18 11:40, michael-...@fami-braun.de wrote: Do you mean AP interfaces as required for multiple BSS/SSIDs? I'm running a patched ath9k to have hostapd run >8 BSS on a single radio. It works fine since years. Yes, I'd love to see any patches you can share on this as well. Thanks, Ben Regards, M. Braun Am 27. Juli 2018 15:35:28 MESZ schrieb Ben Greear : Hello, Has anyone tried making ath9k able to support 16 vAP interfaces on a single radio? I seem to recall that there were limitations regarding beacon timers and such, and that is why the current limit is 8? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com Are these patches available somewhere? I'm interested to play with them :) BR Matthias
Re: ath9k and 16 VAP interfaces?
Do you mean AP interfaces as required for multiple BSS/SSIDs? I'm running a patched ath9k to have hostapd run >8 BSS on a single radio. It works fine since years. Regards, M. Braun Am 27. Juli 2018 15:35:28 MESZ schrieb Ben Greear : >Hello, > >Has anyone tried making ath9k able to support 16 vAP interfaces on a >single >radio? I seem to recall that there were limitations regarding beacon >timers and such, and that is why the current limit is 8? > >Thanks, >Ben > >-- >Ben Greear >Candela Technologies Inc http://www.candelatech.com
Re: [PATCH net-next] bridge: multicast to unicast
Am 09.01.2017 13:15, schrieb Johannes Berg: That is bridge fdb entries (need to) expire so the bridge might "forget" a still-connected station not sending but only consuming broadcast traffic. Ok, that I don't know. Somehow if you address a unicast packet there the bridge has to make a decision - so it really should know? If the bridge has not learned the unicast destination mac address on any port, it will flood the packet on all ports except the port it received the packet on. Regards, M. Braun
Re: [Projekt-wlan] [PATCHv5 2/2] mac80211: fix A-MSDU outer SA/DA
Am 17.10.2016 11:44, schrieb Johannes Berg: + if (bssid && ieee80211_has_fromds(hdr->frame_control)) + memcpy(h_80211_src, bssid, ETH_ALEN); + + if (bssid && ieee80211_has_tods(hdr->frame_control)) + memcpy(h_80211_dst, bssid, ETH_ALEN); but I also changed these to ether_addr_copy() ether_addr_copy requires both arguments to be __aligned(2) according to include/linux/etherdevice.h. bssid might be sdata->u.mgd.bssid, which is bssid in struct ieee80211_if_managed, but neither sdata->u, sdata->u.mgd nor sdata->u.mgd.bssid seem to be declared as __aligned(2). So ether_addr_copy should not be used. What am I missing? Regards, M. Braun
Re: [PATCH v2] mac80211: fix A-MSDU outer SA/DA
Am 12.10.2016 14:25, schrieb Johannes Berg: So, I actually think my first instinct that you were erroneously changing the inner header *was* right. You're right. Seems like this code should be inserted towards the end of ieee80211_amsdu_aggregate() instead, where it's adding the RFC 1042 header? I'm not convinced. ieee80211_amsdu_aggregate handles two skbs: the "skb" var and the "head" var. The skb is appended to the frag list of head by setting frag_tail and does not appear to have an ieee80211_hdr, as memmove is only 2 * ETH_ALEN. Additionally, the rfc1042_header is written after 2 bytes containing subframe_len, so it looks like an A-MSDU subframe with rfc1042_header is inserted at the beginning of the inner MSDU. Only the head skb is processed by ieee80211_amsdu_prepare_head and appears to have an 802.11 header. So its da/sa address should be changed. Regards, M. Braun
Re: [PATCH v2] mac80211: enable to inject a-msdu frames using monitor interface
Am 12.10.2016 09:33, schrieb Johannes Berg: However, re-reading *p looks strange to me. Why don't we just refactor this to preserve everything but the TID and ACK policy, after all, we have just previous created this all zeroed in most cases, so it won't really matter. Looks good to me. I've re-run the amsdu spoofing hwsim test as it includes an amsdu injection test and as expected it still works. Regards, M. Braun
Re: [PATCHv4] mac80211: check A-MSDU inner frame source address on AP interfaces
Am 06.10.2016 13:36, schrieb Johannes Berg: Could you test my patches in your scenario to see they do what we want? I'll resend as [PATCH] then, and think about applying them and perhaps backporting also. I've tested them by running a new hostapd hwsim test [1] and after applying [2]. I can confirm that this tests fails without your RFC series applied and passes when your RFC series is applied. So your RFC is fine. Tested-by: Michael Braun <michael-...@fami-braun.de> Regards, M. Braun [1] https://github.com/michael-dev/hostapd/commit/2caecdd9911529e39c6b8a83aac0cbe737dc8f65 [2] https://patchwork.kernel.org/patch/9367469/
Re: [PATCH 3/3] mac80211: multicast to unicast conversion
Am 05.10.2016 13:58, schrieb Johannes Berg: Anyway, perhaps this needs to change to take DMS/per-station into account? Then again, this kind of setting - global multicast-to-unicast - fundamentally *cannot* be done on a per-station basis, since if you enable it for one station and not for another, the first station that has it enabled would get the packets twice... as I see it, that is exactly how DMS is standarized. IEEE 802.11-2012 section 10.23.15 DMS procedures: "If the requested DMS is accepted by the AP, the AP shall send subsequent group addressed MSDUs that match the frame classifier specified in the DMS Descriptors to the requesting STA as A-MSDU subframes within an individually addressed A-MSDU frame (see 8.3.2.2 and 9.11)." -> so the multicast packets shall go out as unicast A-MSDU frames to stations that requested this "The AP shall continue to transmit the matching frames as group addressed frames (see 9.3.6, and 10.2.1.16) if at least one associated STA has not requested DMS for these frames." -> so it will continue to send it as multicast frames as well. As with DMS the station requested DMS for a specific multicast address, it could then drop multicast frames addressed to the multicast address it registered for DMS. Regards, M. Braun
Re: [PATCH 3/3] mac80211: multicast to unicast conversion
Am 05.10.2016 12:19, schrieb Johannes Berg:
on both ends. Furthermore, I've seen a few mobile phone stations
locally that indicate qos support but won't complete DHCP if their
broadcasts are encapsulated as A-MSDU. Though they work fine with
this series approach.
Presumably those phones also don't even try to use DMS, right?
When I traced this two years ago, almost no device indicated DMS
support, even though almost all seem to accepted multicast in unicast
a-msdu frames.
This patch therefore does not opt to implement DMS but instead just
replicates the packet and changes the destination address. As this
works fine with ARP, IPv4 and IPv6, it is limited to these protocols
and normal 802.11 multicast frames are send out for all other payload
protocols.
How did you determine that it "works fine"?
First, I tested this manually using my own devices or asked friends. I
think this covered at least a recent debian x64 with an intel wireless
card, a windows 7 x64 with an intel wireless card, an android phone, an
ios phone and some recent macbook. Manually testing included visiting an
IPv6 only website (this network uses IPv6 router advertismentens (RA)
but no DHCPv6), so RA is accepted and ND working. Additionally,
arping'ing these station using broadcast arp request worked fine, so
broadcast arp requests are working. Finally, DHCP worked fine and UPNP
multicast discovery for some closed source media streaming wireless
device was reported working.
Next, that change was rolled out. It is now in use for at least three
years with about 300 simulatenously online stations and >2000 currently
registered devices and there hasn't been a single problem report that
could be related to that change. Though, e.g. our samsung galaxy users
report consistently that their devices refuse to connect using WPA-PSK
as our network advertises FT-PSK next to WPA-PSK and I learned that
there was at least one device there that did not like the
multicast-as-unicast-amsdu packets due to a user problem report.
I see at least one undesirable impact of this, which DMS doesn't have;
it breaks a client's MUST NOT requirement from RFC 1122:
Okay, so this cannot go into linux, right?
The thing I dislike most about DMS is that it is client driven, that is
an AP will only apply unicast conversion if a station actively requests
so.
You should split the patch into cfg80211 and mac80211, IMHO it's big
enough to do that.
ok
+ * @set_ap_unicast: set the multicast to unicast flag for a AP
interface
That API name isn't very descriptive, I'm sure we can do something
better there.
proposal: "request multicast packets to be trasnmitted as unicast" ?
Also, perhaps we should structure this already like we would DMS, with
a per-station toggle or even list of multicast addresses?
should be possible, yes
+static int ieee80211_set_ap_unicast(struct wiphy *wiphy, struct
net_device *dev,
+ const bool unicast)
+{
+ struct ieee80211_sub_if_data *sdata =
IEEE80211_DEV_TO_SUB_IF(dev);
+
+ if (sdata->vif.type != NL80211_IFTYPE_AP)
+ return -1;
Was this not documented but also intended to apply to its dependent
VLANs?
it was intended as a per per-BSS toggle, so it applies to all dependent
VLANs automatically.
+/* Check if multicast to unicast conversion is needed and do it.
+ * Returns 1 if skb was freed and should not be send out. */
wrong comment style :)
you mean the */ at end of line instead of on a new line?
+ unicast = nla_data(info->attrs[NL80211_ATTR_UNICAST]);
What's this supposed to mean?
this was supposed to be nla_get_u8.
michael
Re: [PATCHv2] mac80211: check A-MSDU inner frame source address on AP interfaces
Am 27.09.2016 10:01, schrieb Johannes Berg: ... This leaves "eth_80211" uninitialized if has_80211_header is false. @@ -768,6 +768,13 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list, subframe_len = sizeof(struct ethhdr) + len; padding = (4 - subframe_len) & 0x3; + if (unlikely(has_80211_header && + (iftype == NL80211_IFTYPE_AP || + iftype == NL80211_IFTYPE_AP_VLAN) && + !ether_addr_equal(eth_80211.h_source, eth.h_source) + )) + goto purge; And this then compares against uninitialized data, so this won't work. but it only compares against eth_80211 if has_80211_header is true due to order of evaluation, which in turn implies eth_80211 is initialized, right? michael
