hi ben!
i made these changes on top of your v7 patch, please tell me what you think!
and feel free to merge the changes into your patch, if you agree with them.
use staggered beacons only when multiple AP interfaces are configured.
this fixes single-interface ad-hoc mode and also reduces the impact of the vif
changes for the more common single-interface AP setups (beacon interval and
SWBA interrupts).
btw: we can always only have one ad-hoc interface. mac80211 makes sure of that,
because it's impossible to synchronize to more than one TSF. this is the most
important "feature" of ad-hoc, i think: it has to (and will) adapt the TSF of
beacons in the same IBSS. that means the local TSF can make jumps (into the
future only).
i'm not sure where that leaves us concerning one ad-hoc interface + multiple AP
interfaces. to allow the TSF updates we would have to keep the HW opmode in
ad-hoc though. would VAPs still work that way? also how about stations? aren't
they supposed to adapt the TSF of their AP? as i see the HW is in AP mode if
there is at least one AP, so that does not happen if there is an AP interface
too. how would multiple STA sync their TSF if they are connected to different
AP with different TSF? but maybe the TSF does not matter as much for STA as it
does for IBSS mode... if that is the case we could allow one adhoc + multiple
STA interfaces and drive the HW in adhoc mode.
oh, another thing: ad-hoc interfaces could potentially move to another channel
(if it is not set to a fixed channel). i quess in most cases a fixed channel
will be used, but it wouldn't be good for the other STAs if that happens. but
thinking about it - doesn't the same apply with multiple STA interfaces? how
do you avoid one STA from changing to another channel?
so... many questions about the coexistence of adhoc and other interfaces... and
honestly, i don't care much about adhoc + other vif at this time. as long as
one adhoc interface works, i'm fine.
btw: i think we should cleanup the beacon code, but i might do that after your
vif changes got merged...
bruno
---
drivers/net/wireless/ath/ath5k/base.c | 30 ++++++++++++++----------------
1 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 499a906..3ed9935 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1857,9 +1857,6 @@ ath5k_beacon_send(struct ath5k_softc *sc)
struct ath5k_vif *avf;
struct ath5k_buf *bf;
struct sk_buff *skb;
- u64 tsf;
- u32 tsftu;
- int slot;
ATH5K_DBG_UNLIMIT(sc, ATH5K_DEBUG_BEACON, "in beacon_send\n");
@@ -1891,20 +1888,21 @@ ath5k_beacon_send(struct ath5k_softc *sc)
sc->bmisscount = 0;
}
- tsf = ath5k_hw_get_tsf64(ah);
- tsftu = TSF_TO_TU(tsf);
- slot = ((tsftu % sc->bintval) * ATH_BCBUF) / sc->bintval;
- vif = sc->bslot[(slot + 1) % ATH_BCBUF];
-
- ATH5K_DBG(sc, ATH5K_DEBUG_BEACON,
- "tsf %llx tsftu %x intval %u slot %u vif %p\n",
- (unsigned long long)tsf, tsftu, sc->bintval, slot, vif);
+ if (sc->opmode == NL80211_IFTYPE_AP && sc->num_ap_vifs > 1) {
+ u64 tsf = ath5k_hw_get_tsf64(ah);
+ u32 tsftu = TSF_TO_TU(tsf);
+ int slot = ((tsftu % sc->bintval) * ATH_BCBUF) / sc->bintval;
+ vif = sc->bslot[(slot + 1) % ATH_BCBUF];
+ ATH5K_DBG(sc, ATH5K_DEBUG_BEACON,
+ "tsf %llx tsftu %x intval %u slot %u vif %p\n",
+ (unsigned long long)tsf, tsftu, sc->bintval, slot, vif);
+ } else /* only one interface */
+ vif = sc->bslot[0];
- if (vif)
- avf = (void *)vif->drv_priv;
- else
+ if (!vif)
return;
+ avf = (void *)vif->drv_priv;
bf = avf->bbuf;
if (unlikely(bf->skb == NULL || sc->opmode == NL80211_IFTYPE_STATION ||
sc->opmode == NL80211_IFTYPE_MONITOR)) {
@@ -1964,7 +1962,7 @@ ath5k_beacon_update_timers(struct ath5k_softc *sc, u64 bc_tsf)
u64 hw_tsf;
intval = sc->bintval & AR5K_BEACON_PERIOD;
- if (sc->opmode == NL80211_IFTYPE_AP) {
+ if (sc->opmode == NL80211_IFTYPE_AP && sc->num_ap_vifs > 1) {
intval /= ATH_BCBUF; /* staggered multi-bss beacons */
if (intval < 15)
ATH5K_WARN(sc, "intval %u is too low, min 15\n",
@@ -2795,7 +2793,6 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
ret = -ELNRNG;
goto end;
}
- sc->nvifs++;
switch (vif->type) {
case NL80211_IFTYPE_AP:
@@ -2809,6 +2806,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
goto end;
}
+ sc->nvifs++;
ATH5K_DBG(sc, ATH5K_DEBUG_MODE, "add interface mode %d\n", avf->opmode);
/* Assign the vap/adhoc to a beacon xmit slot. */
On Thu September 30 2010 01:45:08 Ben Greear wrote:
> > i made these changes on top of your v7 patch, please tell me what you
> > think! and feel free to merge the changes into your patch, if you agree
> > with them.
>
> I'll merge them in and do some quick testing and re-post the full
> patch.
thanks!
> For STAs, I use the can-scan-one logic so that after the first interface
> associates, future automated scans will not scan more than the single
> channel. That helps keep us on the same channel.
>
> But, if all interfaces disassociate, then full scans will happen again,
> and the first interface to associate gets to choose the channel.
>
> If the channel is changed for any reason, all of the old stations are
> un-associated and attempt full rescan to re-associate.
>
> That scan-one logic is probably not going into the upstream kernel though,
> so to keep confusion to a minimum, you would have to make sure that
> your STAs are all configured for APs on the same channel.
that makes sense.
> In general, APs and STAs have worked well together for us..but we have
> never used adhoc. It sounds to me like you know a lot more about this
> stuff than I do, so perhaps you can make more progress.
maybe, but i'm not sure if i can spend much time on this. as i said i'm fine
as long as one ad-hoc interface per device works and if we can have multiple
AP interfaces on another device.
if someone is interested in ad-hoc + STA or ad-hoc + AP interfaces, basically
we would need to test:
- can we have the HW in ad-hoc mode and still have AP interfaces?
- can we have the HW in ad-hoc mode and still have STA interfaces?
- if that's not possible, there have been patches for madwifi, which runs ad-
hoc interfaces with the hardware configured in AP mode, but this has some
disadvantages (like no TSF sync, no beacon backoff).
i'm not sure if we should disable ad-hoc + other interfaces in the mean time
or leave it open for others to test??? maybe i can give it a short try today?
> If we can get agreement on the patch as is (with your changes included),
> I'd love to get it pushed upstream. Then folks can improve it further.
sure. i tested v7 + my changes for the last 12 hours, using 2 WPA and 2 non-
encrypted AP interfaces with concurrent iperf traffic and ping without
problems. one ad-hoc interface works as well. i think the problems i saw last
time were due to dupliacte mac addresses. so i'll checkout your v8 patch and
then let's see to get it merged! :)
bruno
On 09/29/2010 02:22 AM, Bruno Randolf wrote:
> hi ben!
>
> i made these changes on top of your v7 patch, please tell me what you think!
> and feel free to merge the changes into your patch, if you agree with them.
I'll merge them in and do some quick testing and re-post the full
patch.
> use staggered beacons only when multiple AP interfaces are configured.
> this fixes single-interface ad-hoc mode and also reduces the impact of the vif
> changes for the more common single-interface AP setups (beacon interval and
> SWBA interrupts).
>
> btw: we can always only have one ad-hoc interface. mac80211 makes sure of that,
> because it's impossible to synchronize to more than one TSF. this is the most
> important "feature" of ad-hoc, i think: it has to (and will) adapt the TSF of
> beacons in the same IBSS. that means the local TSF can make jumps (into the
> future only).
>
> i'm not sure where that leaves us concerning one ad-hoc interface + multiple AP
> interfaces. to allow the TSF updates we would have to keep the HW opmode in
> ad-hoc though. would VAPs still work that way? also how about stations? aren't
> they supposed to adapt the TSF of their AP? as i see the HW is in AP mode if
> there is at least one AP, so that does not happen if there is an AP interface
> too. how would multiple STA sync their TSF if they are connected to different
> AP with different TSF? but maybe the TSF does not matter as much for STA as it
> does for IBSS mode... if that is the case we could allow one adhoc + multiple
> STA interfaces and drive the HW in adhoc mode.
>
> oh, another thing: ad-hoc interfaces could potentially move to another channel
> (if it is not set to a fixed channel). i quess in most cases a fixed channel
> will be used, but it wouldn't be good for the other STAs if that happens. but
> thinking about it - doesn't the same apply with multiple STA interfaces? how
> do you avoid one STA from changing to another channel?
For STAs, I use the can-scan-one logic so that after the first interface
associates, future automated scans will not scan more than the single channel.
That helps keep us on the same channel.
But, if all interfaces disassociate, then full scans will happen again,
and the first interface to associate gets to choose the channel.
If the channel is changed for any reason, all of the old stations are
un-associated and attempt full rescan to re-associate.
That scan-one logic is probably not going into the upstream kernel though,
so to keep confusion to a minimum, you would have to make sure that
your STAs are all configured for APs on the same channel.
In general, APs and STAs have worked well together for us..but we have
never used adhoc. It sounds to me like you know a lot more about this
stuff than I do, so perhaps you can make more progress.
>
> so... many questions about the coexistence of adhoc and other interfaces... and
> honestly, i don't care much about adhoc + other vif at this time. as long as
> one adhoc interface works, i'm fine.
>
> btw: i think we should cleanup the beacon code, but i might do that after your
> vif changes got merged...
If we can get agreement on the patch as is (with your changes included), I'd
love to get it pushed upstream. Then folks can improve it further.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com