I might have got a bit more helpful information through tests with
Problem(2) attached below.
Now, I am wondering this problem might not be specific just for IBSS
but has something to do with SBP (Stuck Beacon Problem) which was
other thread. I do appreciate any comments and suggestions. Thank
<< Test Profile >>
Two PCs : (A) and (B) A: 10.0.1.101 B: 10.0.1.102
Both are set IBSS adhoc mode. then,
1. "ifup ath0" on (A)
2. "ifup ath0" on (B)
3. Start "ping -i x 10.0.1.101" from (B) "x" is interval
4. "ifdown ath0" on (A)
5. check out Beacon transmission status on Etherreal
<< Test Results >>
- when x = 0.5, Beacon xmit from (B) stopped at 10 secs after 4.
- when x = 1, Beacon xmit from (B) stopped at 14 secs after 4.
- when x = 2, Beacon xmit from (B) stopped at 20 secs after 4.
- when x = 5, "Unreachable to dst" shew up and Beacon xmision
was never stuck.
Once beacon ximit stopped, it did not start until the device was
On the other hand, when ping is xmitted from (A) instead of (B),
above steps did not cause Beacon stuck.
Note: default retransmission count (MAC retry) was used, which was
(Ethereal shew that each ICMP Echo request packet was
transmitted 10 times )
It appears consecutive xmission failures destined to a vanishing node
causes Beacon stuck.
From your point, can this also explain the problem, which is
"nodes stopped xmitting their beacon when one (or more) node goes
from their scope" ?.
What we are observing here is as follows:
Assuming we have 3 nodes A,B,C and they at first merge into an IBSS
then we make node A is down (or goes away), this causes Node B and C
halt xmitting beacons 7 ~ 10 seconds after A is down.
This makes B and C lose connection to each other and they are
for a while. (Even just A goes away..)