Hi, one hostapd process can easily cover multiple phy. Just start it with multiple config files for example. Regards, Michael Braun Am 24. März 2017 23:24:39 MEZ schrieb Matteo Croce <matteo.croce@xxxxxxxxxxxxx>: >Right, an hostapd instance can handle multiple SSIDs for the same >radio, >but with multiple radios you nees to start an instance per physical >device. > >Cheers, > >2017-03-24 23:12 GMT+01:00 Simon Wunderlich ><simon.wunderlich@xxxxxxxxxxxx>: >> On Friday, March 24, 2017 10:51:27 PM CET michael-dev wrote: >>> Hi, >>> >>> Am 24.03.2017 15:25, schrieb Simon Wunderlich: >>> > sorry for the late follow-up, I'd like to discuss and issue >regarding >>> > your FT >>> > patches sent by you. We have tested both Benjamin and your >patches, and >>> > found >>> > some performance problems. With our QCA9558/988x (using ath10k) >based >>> > Access >>> > points, enabling macvlans on top of bridges result in an >performance >>> > drop of >>> > 30-40%. >>> >>> the reasons for adding macvlan devices were: >>> >>> a) the bssid is not local to the bridge / ft_iface already >>> b) there are two hostapd instances running on the same bridge / >ft_iface >>> device >>> c) the lowerdev / ft_iface might not be a bridge >>> >>> The macvlan device is only used for low rate AP-AP-control traffic. >>> >>> Im my use case, the related lower device is only used for >AP-AP-control >>> traffic, so that performance problem did not affect me. >>> >>> Aspects to consider: >>> - having a macvlan device enables adding a local mac address also >to >>> non-bridge lower devices, e.g. ethX or vpntapX. >>> - Benjamin's patch does not address the need for marking a mac >address >>> as local to the bridge >>> - With Benjamin's patch [1], the local delivery within hostapd >might no >>> longer be required as traffic between different hapd instances might >be >>> covered as well >>> >>> I'm think about the following solutions >>> i) enhance kernel macvlan driver so that it can avoid using >promisicous >>> mode if lowerdev is a bridge by marking its mac address as local to >the >>> bridge >>> ii) tweak bridge fdb instead of using macvlan thus requiring >lowerdev >>> (ft_iface) to be a bridge >>> iii) use benjamin's patch [1] anyway and maybe avoid the need for >>> hostapd internal delivery >>> >>> Obviously, i) would benefit all other maclvan-on-top-of-bridge users >as >>> well. >>> >>> Still, I'm wondering why one would need multiple hostapd processes >>> running on an AP? >> >> Thank you for your answer! >> >> At least this last question is easy to answer on a Friday evening - >we have >> one hostapd instance per phy, so its two instances running on a dual >band >> access point (2.4 and 5 GHz). Creating two hostapd processes in this >case is >> the standard procedure in OpenWRT. >> >> Cheers, >> Simon >> _______________________________________________ >> Hostap mailing list >> Hostap@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/hostap >> _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
