Well, that's true, seems to work. I don't know why all the firmwares I know start an instance per phy, is it a new feature or just undocumented? Cheers, 2017-03-25 11:06 GMT+01:00 <michael-dev@xxxxxxxxxxxxx>: > 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 >>> -- Matteo Croce Ubuntu - Linux For Human Beings perl -e 'for($t=0;;$t++){print chr($t*($t>>8|$t>>13)&255)}' |aplay _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
