[ath9k-devel] ATH9K does not transmit beacons in AD-HOC mode

[ath9k-devel] ATH9K does not transmit beacons in AD-HOC mode

[Alphan Ulusoy]

Hi,

I have noticed that ATH9K does not transmit beacons in IBSS. I can only see probe request/response frames but no periodic beacons. I have even applied the patch proposed by Felix (https://patchwork.kernel.org/patch/99373/) that disables VEOL and uses SWBA interrupts instead. It looks like beacon tasklet is never called. I don't think this is normal. Is there a missing line that must kick-off beacon transmission (e.g. ath9k_hw_puttxbuf, ath9k_hw_txstart) ?


-- alphan

[ath9k-devel] ATH9K does not transmit beacons in AD-HOC mode

[Felix Fietkau]

On 2010-06-25 11:07 AM, Alphan Ulusoy wrote:
> Hi,
> 
> I have noticed that ATH9K does not transmit beacons in IBSS. I can
> only see probe request/response frames but no periodic beacons. I
> have even applied the patch proposed by Felix
> (https://patchwork.kernel.org/patch/99373/) that disables VEOL and
> uses SWBA interrupts instead. It looks like beacon tasklet is never
> called. I don't think this is normal. Is there a missing line that
> must kick-off beacon transmission (e.g. ath9k_hw_puttxbuf,
> ath9k_hw_txstart) ?
The second patch (the one you applied) doesn't work without the first
patch (https://patchwork.kernel.org/patch/99372/)

- Felix

[ath9k-devel] ATH9K does not transmit beacons in AD-HOC mode

[Alphan Ulusoy]

Dear Felix,

Thank you for your reply, as I was going over the code yesterday I've changed several parts and also the part your first patch covers. However I have also felt that beacon staggering is somewhat problematic. I've made a total of 4 changes and ad-hoc beacons work now:

1) Applied your second patch.

2) Disabled beacon staggering by setting ATH_BCBUF (ath9k.h) to 1. I believe, this covers your second patch.

3) main.c:ath9k_bss_info_changed() calls ath_beacon_alloc() when called by mac80211. However, ath_beacon_alloc() honors the sc->sc_ah->opmode field for deciding which beacon config function to run while ath9k_bss_info_changed() does not update this field from vif->type. Thus, I've added the following at line 2051 of main.c:ath9k_bss_info_changed().
	"ah->opmode = vif->type;"

4) beacon.c:ath_beacon_config_adhoc() relies on sc->beacon.bc_tstamp field to determine the next beacon time. However, during initialization I've found this field to be very large in number causing the first beacon to suffer a long delay causing problems in association. Maybe this field is missing the required initialization somewhere? Instead, I've added the following at line 752 of beacon.c so that first beacon is sent sooner.
	"nexttbtt = tsftu + 5*intval;"

After these modifications ad-hoc beacons work just fine, beacon tasklet is called appropriately and I did not observe any missed beacons. I would like to hear your comments especially regarding points 3, 4.

regards,

-- alphan



On 25 Jun, 2010, at 3:43 PM, Felix Fietkau wrote:

> On 2010-06-25 11:07 AM, Alphan Ulusoy wrote:
>> Hi,
>> 
>> I have noticed that ATH9K does not transmit beacons in IBSS. I can
>> only see probe request/response frames but no periodic beacons. I
>> have even applied the patch proposed by Felix
>> (https://patchwork.kernel.org/patch/99373/) that disables VEOL and
>> uses SWBA interrupts instead. It looks like beacon tasklet is never
>> called. I don't think this is normal. Is there a missing line that
>> must kick-off beacon transmission (e.g. ath9k_hw_puttxbuf,
>> ath9k_hw_txstart) ?
> The second patch (the one you applied) doesn't work without the first
> patch (https://patchwork.kernel.org/patch/99372/)
> 
> - Felix

[ath9k-devel] ATH9K does not transmit beacons in AD-HOC mode

[Felix Fietkau]

On 2010-06-26 8:47 AM, Alphan Ulusoy wrote:
> Dear Felix,
> 
> Thank you for your reply, as I was going over the code yesterday I've
> changed several parts and also the part your first patch covers.
> However I have also felt that beacon staggering is somewhat
> problematic. I've made a total of 4 changes and ad-hoc beacons work
> now:
> 
> 1) Applied your second patch.
> 
> 2) Disabled beacon staggering by setting ATH_BCBUF (ath9k.h) to 1. I
> believe, this covers your second patch.
Unnecessary, with my patch, as long as the opmode is set to ad-hoc, it
will use a beacon interval that will only leave one beacon slot active
anyway.

> 3) main.c:ath9k_bss_info_changed() calls ath_beacon_alloc() when
> called by mac80211. However, ath_beacon_alloc() honors the
> sc->sc_ah->opmode field for deciding which beacon config function to
> run while ath9k_bss_info_changed() does not update this field from
> vif->type. Thus, I've added the following at line 2051 of
> main.c:ath9k_bss_info_changed(). "ah->opmode = vif->type;"
sc->ah->opmode should have been set by the code that is called when the
interface is brought up, setting it from ath9k_bss_info_changed() is
definitely wrong.

> 4) beacon.c:ath_beacon_config_adhoc() relies on sc->beacon.bc_tstamp
> field to determine the next beacon time. However, during
> initialization I've found this field to be very large in number
> causing the first beacon to suffer a long delay causing problems in
> association. Maybe this field is missing the required initialization
> somewhere? Instead, I've added the following at line 752 of beacon.c
> so that first beacon is sent sooner. "nexttbtt = tsftu + 5*intval;"
It's normal for this to be large, however maybe this needs some range
checking against the local tsf. The intention behind using bc_tstamp is
that the hardware syncs its own TSF against the one from the beacon
automatically.

> After these modifications ad-hoc beacons work just fine, beacon
> tasklet is called appropriately and I did not observe any missed
> beacons. I would like to hear your comments especially regarding
> points 3, 4.
I'd suggest testing a recent version of mac80211/ath9k before taking
another look at any of the changes that you made.

- Felix

[ath9k-devel] ATH9K does not transmit beacons in AD-HOC mode

[Alphan Ulusoy]

On 26 Jun, 2010, at 1:51 PM, Felix Fietkau wrote:

> On 2010-06-26 8:47 AM, Alphan Ulusoy wrote:
>> Dear Felix,
>> 
>> Thank you for your reply, as I was going over the code yesterday I've
>> changed several parts and also the part your first patch covers.
>> However I have also felt that beacon staggering is somewhat
>> problematic. I've made a total of 4 changes and ad-hoc beacons work
>> now:
>> 
>> 1) Applied your second patch.
>> 
>> 2) Disabled beacon staggering by setting ATH_BCBUF (ath9k.h) to 1. I
>> believe, this covers your second patch.
> Unnecessary, with my patch, as long as the opmode is set to ad-hoc, it
> will use a beacon interval that will only leave one beacon slot active
> anyway.
> 
>> 3) main.c:ath9k_bss_info_changed() calls ath_beacon_alloc() when
>> called by mac80211. However, ath_beacon_alloc() honors the
>> sc->sc_ah->opmode field for deciding which beacon config function to
>> run while ath9k_bss_info_changed() does not update this field from
>> vif->type. Thus, I've added the following at line 2051 of
>> main.c:ath9k_bss_info_changed(). "ah->opmode = vif->type;"
> sc->ah->opmode should have been set by the code that is called when the
> interface is brought up, setting it from ath9k_bss_info_changed() is
> definitely wrong.

I've placed several printk's and observed that opmode was STA although 
vif sent to bss_info_changed() was reporting AD-HOC. Maybe it's set 
sometime later, I have no idea but as I am only interested in the ad-hoc
mode, this is good enough for me.

> 
>> 4) beacon.c:ath_beacon_config_adhoc() relies on sc->beacon.bc_tstamp
>> field to determine the next beacon time. However, during
>> initialization I've found this field to be very large in number
>> causing the first beacon to suffer a long delay causing problems in
>> association. Maybe this field is missing the required initialization
>> somewhere? Instead, I've added the following at line 752 of beacon.c
>> so that first beacon is sent sooner. "nexttbtt = tsftu + 5*intval;"
> It's normal for this to be large, however maybe this needs some range
> checking against the local tsf. The intention behind using bc_tstamp is
> that the hardware syncs its own TSF against the one from the beacon
> automatically.
> 
>> After these modifications ad-hoc beacons work just fine, beacon
>> tasklet is called appropriately and I did not observe any missed
>> beacons. I would like to hear your comments especially regarding
>> points 3, 4.
> I'd suggest testing a recent version of mac80211/ath9k before taking
> another look at any of the changes that you made.
> 
> - Felix