Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1033 (closed defect: fixed)

Opened 13 years ago

Last modified 11 years ago

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

Reported by: Assigned to:
Priority: major Milestone: version 0.9.5
Component: madwifi: driver Version: v0.9.2
Keywords: ad-hoc beacon merge Cc:
Patch is attached: 1 Pending:


When an ad-hoc vap is just created it starts transmitting beacons with a tsf of 0. When another node is already present in the same ad-hoc network it will also transmit beacons with a higher tsf, causing the new ad-hoc vap to perform an ibss merge. After this merge the node doesn't transmit beacons anymore for quite a while (usually longer than 20 seconds).

The problem lies in the fact that the code that setups the new beacons uses the last received tsf value from the other beacon as the tsf value for the next beacon to be transmitted. The tsf value is too low (in the past) for that beacon, causing the hardware/HAL to become confused I think. The tsf value should be incremented until it has the correct value for the next beacon to be transmitted.

Unfortunately I don't know how exactly this tsf value should calculated. I've attached a patch that just adds 250ms, which seems to solve the problem but it is just a hack. I hope someone can figure out using the HAL what the real tsf value should be.

Signed-off-by: Tjalling Hattink <> Twente Institute of Wireless and Mobile Communications


adhoc_beacons_fix.diff (0.6 kB) - added by on 12/07/06 10:45:30.
Patch for fixing beacon transmissions in ad-hoc mode after ibss merge.
ibss_beacon_nexttbtt_fix.diff (1.5 kB) - added by on 01/24/07 10:32:35.
New patch that fixes adhoc beacon transmissions after ibss merge.
adhoc-beacon-3.diff (4.7 kB) - added by on 02/28/07 00:10:14.
proper ibss nexttbtt computation
adhoc-beacon-4.diff (5.6 kB) - added by on 03/17/07 22:56:34.
replace adhoc-beacon-3.diff. when nexttbtt cannot be computed, it waits for the next beacon
adhoc-beacon-5.diff (5.8 kB) - added by on 04/16/07 15:10:22.
Update of previous patch with proper tabbed indentation, removed compiler warning and checked and updated the "FIXME" entries.
madwifi-ibss-merge-clean.diff (9.6 kB) - added by on 07/16/07 01:30:25.
Updated version of adhoc-beacon-5.diff
madwifi-ibss-merge-clean.2.diff (11.3 kB) - added by mentor on 07/16/07 22:53:10.
Mangled version of above
madwifi-ibss-merge-clean.3.diff (11.0 kB) - added by mentor on 07/23/07 17:26:14.
Slightly less mangled, better comments

Change History

12/07/06 10:45:30 changed by

  • attachment adhoc_beacons_fix.diff added.

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

01/24/07 10:31:53 changed by

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 <> Twente Institute of Wireless and Mobile Communications

01/24/07 10:32:35 changed by

  • attachment ibss_beacon_nexttbtt_fix.diff added.

New patch that fixes adhoc beacon transmissions after ibss merge.

02/02/07 14:17:54 changed by

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).

02/06/07 14:46:13 changed by

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.

02/08/07 12:51:05 changed by

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?

02/14/07 16:43:41 changed by

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.

02/28/07 00:10:14 changed by

  • attachment adhoc-beacon-3.diff added.

proper ibss nexttbtt computation

03/17/07 22:56:34 changed by

  • attachment adhoc-beacon-4.diff added.

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

03/18/07 01:15:01 changed by scottr

  • milestone set to version 0.9.4.

Tagging for 0.9.4 milestone

04/16/07 15:10:22 changed by

  • attachment adhoc-beacon-5.diff added.

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

07/16/07 01:30:25 changed by

  • attachment madwifi-ibss-merge-clean.diff added.

Updated version of adhoc-beacon-5.diff

07/16/07 22:53:10 changed by mentor

  • attachment madwifi-ibss-merge-clean.2.diff added.

Mangled version of above

07/23/07 17:26:14 changed by mentor

  • attachment madwifi-ibss-merge-clean.3.diff added.

Slightly less mangled, better comments

07/24/07 03:29:57 changed by mentor

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.


10/13/07 18:10:18 changed by

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

03/01/08 01:45:58 changed by mcgrof

  • status changed from new to closed.
  • resolution set to fixed.
  • milestone changed from version 0.9.4 to version 0.9.5.

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