Ad-hoc mode beacons are not transmitted for a while after a merge with another network.

Patch for fixing beacon transmissions in ad-hoc mode after ibss merge.

After extensive experimenting I came up with a patch for this problem that at least seems to work better. Especially when host generated adhoc beacons are used (VEOL trick disabled) the previous patch didn't work.

The patch as built against r1980.

Signed-off-by: Tjalling Hattink <tjalling.hattink@ti-wmc.nl> Twente Institute of Wireless and Mobile Communications

New patch that fixes adhoc beacon transmissions after ibss merge.

I've observed this problem too, so I tried your second patch. I'm working with hardware generated beacons, and the card still takes around 30s before sending its first beacon.

It seems that in the beginning, (nexttbtt == intval) is true and your code is not called due to HAL_BEACON_RESET_TSF being set in intval. When I remove this precondition, the card starts sending beacons much sooner. I am not quite sure what the if clause is meant for.

I think, the do/while loop can be replaced too by some code using modulo-calculation with a runtime of O(1), otherwise the code might take very long when entering an old ad hoc network with a high TSF (mine is 961701683936 right now, making the loop run almost 10 million times).

The goal of the if statement is to split beacon setup request between setups for a new ad-hoc network and setups caused after a merge with an existing ad-hoc network. When the radio is turned on it always assumes that nobody else is present in the ad-hoc network it is configured on, so it just starts transmitting beacons with tsf 100. The flag HAL_BEACON_RESET_TSF is also set in this case to tell the hardware to drop its current tsf value and always use the new one. I thought there would be no need to push the tsf forward in the while loop according to the current tsf value (the one retrieved with ath_hal_gettsf64) because it is probably invalid anyway.

When this flag is not set I assume that the beacon setup is called because of a merge and the while loop should be used to push forward the new tsf value so that it always lies ahead of the current tsf value of the radio. The current tsf value of the radio should already been updated by the hardware (is this actually true?) because of the previously received management frame that caused the merge.

The while loop should only take 1 or 2 iterations because the nexttbtt value should be very close to the current tsf value of the radio. I think your millions of iterations is caused by the fact that you removed the if statement, which will use a nexttbtt value of 100 (the intval).

The reason why you have to remove the if statement to get it work is a mystery for me as well. Because removing the if statement contradicts the ideas behind this patch it basically makes this patch invalid.

Maybe you can check why the beacon setup function is called in such a way after an ibss merge that the HAL_BEACON_RESET_TSF flag is set earlier on, because that shouldn't happen I think. This flag should only be set once after a radio reset.

It seems, there is some kind of a race condition between the hardware TSF and the ni->ni_tstamp value from the last received beacon. Sometimes, the function is called with the TSF being very low (<2000) and the ni_tstamp being already updated from the older network, so that nexttbtt is set according to the old network, while the hardware has not adapted yet.

Sometimes it happens the other way around, with the TSF being very big (already merged from the old network), but ni_tstamp being zero. In this case, HAL_BEACON_RESET_TSF is set, but has no visible effect, while nexttbtt stays at 100 and the beacon is never(*) sent, thus your patch not having any effect.

(*) BTW never: nexttbtt is a uint32, holding a value in TUs (approx. 1ms), which is not enough to fit the complete TSF (64-10=54 bits). Maybe only the lower 16 bits of nexttbtt are used, so an overflow is happening every 65s, thus making the next beacon appearing after not much more than a minute.

By removing the if statement, I solved the latter problem (ni_tstamp == 0 when merging into another cell), but with the overhead of so many iterations. My current code is:

tsftu = TSF_TO_TU(tsf>>32, tsf) + FUDGE;
if (nexttbtt <= tsftu)
         nexttbtt = roundup(tsftu, clintval);

This works around both race condition problems in my case, but probably conflicts with HAL_BEACON_RESET_TSF. I'm not sure what I could do to really solve this race condition. Maybe ni->ni_tstamp is not the right place to look for the TSF of the cell to be merged into?

The race condition with the large tsf value and a ni_stamp being zero is not a situation caused by a merge. This situation arises when the hardware or 802.11 stack is reset. That's why the HAL_BEACON_RESET_TSF bit is set because the tsf should start counting from zero.

The difference in my situation is that HAL_BEACON_RESET_TSF does have effect. When set the tsf value is always set to 0 on the hardware. If this doesn't happen then I understand your problem. The reason why it doesn't happen is a mystery though and makes it impossible to fix this right with the current information we get from the hardware (tsf) and last received beacon (nexttbtt).

I checked the value of ni->ni_tstamp while merging with multiple networks and in different setup scenarios and it always contained the tstamp of the beacon it needs to merge to, so I think this value is correct.

You would expect the hardware (HAL) to update (merge) to the new tsf value as soon as it processed the beacon but this doesn't always happen. I don't know exactly if we should expect the hardware to do this or that the driver should change the tsf value (because that is what the patch tries to do).

Your replacement code for the for loop looks much better to me as well.

proper ibss nexttbtt computation

replace adhoc-beacon-3.diff. when nexttbtt cannot be computed, it waits for the next beacon

Tagging for 0.9.4 milestone

Update of previous patch with proper tabbed indentation, removed compiler warning and checked and updated the "FIXME" entries.

Updated version of adhoc-beacon-5.diff

Mangled version of above

Slightly less mangled, better comments

Er, so I checked the add_neighbour functipn reference counting was merged, and it was using permanent nodes; so, I'm happy for this patch to be merged now.

:)

This is fixed in branches/madwifi-dfs. Maybe it should be merged back to trunk? Testing has been done using DevDocs/AdhocTestScenario

This is in trunk, it didn't make it into 0.9.4 though.