Hi,  all

  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 mode,
  but has something to do with SBP (Stuck Beacon Problem) which was reported in
  other thread.   I do appreciate any comments and suggestions.  Thank you.

<<  Test Profile >>
    Two PCs  :  (A) and (B)   A:  B:
     Both  are set IBSS adhoc mode.  then,

     1. "ifup ath0" on (A)
     2. "ifup ath0" on (B)
     3.  Start  "ping -i x" from (B)     "x" is interval (sec)
     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. above
  - when x = 1,    Beacon xmit from (B) stopped at 14 secs after 4. above
  - when x = 2,    Beacon xmit from (B) stopped at 20 secs after 4. above
  - 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 reset.

  On the other hand, when ping is xmitted from (A) instead of (B), executing the
  above steps did not cause Beacon stuck. 

  Note:  default retransmission count (MAC retry) was used, which was 10.
       (Ethereal shew that each ICMP Echo request packet was transmitted 10 times )

  For me,
  It appears consecutive xmission failures destined to a vanishing node
  causes Beacon stuck.  

thank you.

  From your point, can this also explain the problem, which is
  "nodes stopped xmitting their beacon when one (or more) node goes away
  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 succsessfully,
  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 stranded
    for a while. (Even just A goes away..)