Thread: [Madwifi-devel] IBSS mode and ar5414
Status: Beta
Brought to you by:
otaku
From: bruno r. <br...@th...> - 2007-12-28 04:04:35
|
hi! just a quick note: i noticed that ar5414 behaves differently in IBSS mode than ar5212. current trunk IBSS mode works o.k. with 5212 but does not work well with 5414 based cards. it seems like on the 5414 the ibss timers are updated automatically with the TSF so there is no need to update times so often, but it also seems like the local TSF of 5414 is a bit too much in the future, causing too many ibss merges to happen. i will look into this after next week. but it's something we have to keep in mind when discussing or testing IBSS merges. benoit may i ask which type of hardware are you working with? bruno |
From: bruno r. <br...@th...> - 2007-12-28 05:09:18
|
On Friday 28 December 2007 13:04:11 bruno randolf wrote: > hi! > > just a quick note: i noticed that ar5414 behaves differently in IBSS mode > than ar5212. current trunk IBSS mode works o.k. with 5212 but does not work > well with 5414 based cards. > > it seems like on the 5414 the ibss timers are updated automatically with > the TSF so there is no need to update times so often, but it also seems > like the local TSF of 5414 is a bit too much in the future, sorry, i mean: not in the future but in the past (behind) (stupid thinko) > causing too > many ibss merges to happen. i will look into this after next week. > > but it's something we have to keep in mind when discussing or testing IBSS > merges. benoit may i ask which type of hardware are you working with? > > bruno > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel |
From: <tk...@th...> - 2007-12-28 05:51:38
|
Bruno Thanks. I can see your desk from here, but let me post my comment this time because our office is too large to shout each other. :-) As you have made correction , "local TSF of 5414 is a bit too much in future (larger)" was just typo and "local TSF of 5414 is a bit too old (smaller)" is correct. OK . > but it's something we have to keep in mind when discussing or testing IBSS > merges. The following is out of this discussion, but let me write it down here before I forget.. This has something to do with "even break rule" in IBSS adhoc mode. . ------------------------------------------------------------------------------ Possible cause of "too many IBSS merge" : If firmware added some propagation delay to the xmitter's TSF in beacon frame and such propagation delay was too large or too small .. and so on. Of course, such delay length can not be equal to the real delay, strictly speaking, therefore we could go in the 2 cases shown below. It can be so hard (impossible?) to avoid the following cases in IBSS adhoc mode operation unless we have an additional "even break rule". 1 - Repeat joining to each other network again and again ("flip-flop behavior" ) ( Both party believe that his TSF is a bit smaller and tries to join other ) 2- Never joins to each other ( Both party invites the other, but never join) ( Both party believe that his TSF is a bit larger and expect the other to join him ) In the case of 2, SW merge does not happen while HW merge should happen as expected. Therefore don't we need to worry about case 2. for 5414 ? or do we need to go through SW merge also in this case? But more important thing is 80211 standard does not have no clean solution for a.k.a. "even break rule". Regarding infrastructure mode, we do not need to worry about this "even break rule" but need it in adhoc mode. In short, we might need to make up the weakness of 80211 standard specification in the case of IBSS adhoc . :-) -------------------------------------------------------------------------------------------- Regards Taka > hi! > > just a quick note: i noticed that ar5414 behaves differently in IBSS mode than > ar5212. current trunk IBSS mode works o.k. with 5212 but does not work well > with 5414 based cards. > > it seems like on the 5414 the ibss timers are updated automatically with the > TSF so there is no need to update times so often, but it also seems like the > local TSF of 5414 is a bit too much in the future, causing too many ibss > merges to happen. i will look into this after next week. > > but it's something we have to keep in mind when discussing or testing IBSS > merges. benoit may i ask which type of hardware are you working with? > > bruno > > > > > -- ***************************************** 株式会社 シンクチューブ 海藻 敬之 tk...@th... 〒658-0032 神戸市東灘区向洋町中6-9 KFMビル 4E-10 Phone: 078-857-8390 Fax: 078-857-8389 www.thinktube.com |
From: Benoit P. <ben...@fr...> - 2007-12-28 07:53:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 bruno randolf a écrit : > hi! > > just a quick note: i noticed that ar5414 behaves differently in IBSS mode than > ar5212. current trunk IBSS mode works o.k. with 5212 but does not work well > with 5414 based cards. > > it seems like on the 5414 the ibss timers are updated automatically with the > TSF so there is no need to update times so often, but it also seems like the > local TSF of 5414 is a bit too much in the future, causing too many ibss > merges to happen. i will look into this after next week. > > but it's something we have to keep in mind when discussing or testing IBSS > merges. benoit may i ask which type of hardware are you working with? > > bruno I'm using CM9 AR5212. There is one thing you should be aware : the bf_tsf is wrong when HW merge occurs because bf_tsf is the combination of the UPDATED TSF and the OLD RX timestamps. That's why i added the sc_nexttbtt protection in case HW TSF is updated, but no merge is detected. Regards, Benoit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHdKtqOR6EySwP7oIRAnrJAJ9CG6xjA9dRoWDFE0DOh9tnp4tuyACfUWIb 91qFEusHqXzJ8g0lewZjMHc= =tIJP -----END PGP SIGNATURE----- |