[Madwifi-devel] Madwifi IBSS ad-hoc mode issue Vol3

[Bruno R. <bru...@4g...>]

hello taka!

sorry for the delay in answering your mails!

i just commited your suggested modification (setting try to 0 if rate is 0)=
 to=20
the BSD branch (onoe.c). i guess the other rate control modules would still=
=20
need the same change, or do they already handle this case correctly?

concerning your other modifications for IBSS beaconing, i cannot reproduce =
the=20
behaviour you described, nor that the changes fix anything, unfortunately.=
=20
could you come up with a more detailed description of your setup? which mod=
e=20
are you using, which atheros hardware? which commands do you exactly use to=
=20
setup ad-hoc mode?

one thing i noticed yesterday is that when the IBSS is merged, nexttbtt is=
=20
ususally rather large. maybe that explains why the second node sometimes do=
es=20
not send beacons for a long time. does anybody know which units this value=
=20
has? and why is it constructed like this?

nexttbtt =3D (LE_READ_4(ni->ni_tstamp.data + 4) << 22) |
	    (LE_READ_4(ni->ni_tstamp.data) >> 10);

so let me sum up again the problems we have with ad-hoc mode, as i see them=
=2E=20
please correct/add...

summary: distributed beaconing does not work reliably

1) *sometimes* both nodes send a beacon in each beacon period - the one who=
 is=20
last should refrain from sending it after is has already received a beacon=
=20
from someone else.

2) *sometimes* only one node sends beacons.

3) *sometimes* distributed beaconing works correctly, resulting in one beac=
on=20
each period, randomly distributed between the two participating nodes.

4) when one node leaves the IBSS the other does not correctly take over bea=
con=20
transmissions.

bruno





On Tuesday 05 April 2005 04:52, =E6=B5=B7=E8=97=BB=E6=95=AC=E4=B9=8B wrote:
> Hi,
>
>    Let me report the following fix with Problem(2) reported in this threa=
d.
>    (Problem(2):  BEACON  xmission  stops when neighbor node(s)
>                     goes away while packets are xmitted to the node(s)
>
>    I applied this fix to BSD branch a week before and have executed sort
> of regression test since then.
>    So far, good. we have not experienced Problem (2) again since the fix
> was applied.
>
>   <<back ground information>>
>   At first, I recognized that Problem(2) occurs when "rate" value in
> ath_rate_update()
>   goes below 3 for multi-rate retry case.
>
>   When this value is 3, ath driver gets rt->info[3], info[2], info[1],
> info[0] from rate
>   control ( onoe.c )and passes these 4 values down to HAL.
>
>   But when  the rate goes down to 2, the 4 values returned by "onoe.c"
> includes
>   rt-info[2], info[2], info[1] and 0 as for the rateCode values.
>   IT seems that HAL stops xmitting BEACON when HAL receives 0 for rateCode
>   from ath driver layer.
>   I think  that the developer of onoe.c , ( Mr. Onoe ?)  expected HAL
>   to skip the retry operation when HAL receives 0 for rateCode, but
> actually
>   HAL probably has different interpretation on it.
>   I am not sure which side is violate the specification, probably ath sid=
e,
>   but I hope that the fix below can be the appropriate action which can
> be taken
>   in ath driver layer.
>
>   Finally I hope this might help some other problems reported in other
> modes besides IBSS adhoc mode.
>
>   If I am missing something, please correct me.
>
>
> //
> //  Origonal   code in BSD branch  [ onoe.c ]
> //
> void
> ath_rate_setupxtxdesc(struct ath_softc *sc, struct ath_node *an,
>     struct ath_desc *ds, HAL_BOOL shortPreamble, u_int8_t rix)
> {
>     struct onoe_node *on =3D ATH_NODE_ONOE(an);
>
>     ath_hal_setupxtxdesc(sc->sc_ah, ds
>         , on->on_tx_rate1sp, 2    /* series 1 */
>         , on->on_tx_rate2sp, 2    /* series 2 */
>         , on->on_tx_rate3sp, 2    /* series 3 */
>     );
> }
>
> //
> //    [ onoe.c ]
> //  03/28/2005  Modified version by Takayuki Kaiso
> //
> void
> ath_rate_setupxtxdesc(struct ath_softc *sc, struct ath_node *an,
>     struct ath_desc *ds, HAL_BOOL shortPreamble, u_int8_t rix)
> {
>     struct onoe_node *on =3D ATH_NODE_ONOE(an);
>         u_int8_t        rate1, rate2, rate3 ;
>         u_int8_t        try1, try2, try3 ;
>
>         if ( shortPreamble )               /* necessary ? */
>         {
>             rate1 =3D on->on_tx_rate1sp ;
>             rate2 =3D on->on_tx_rate2sp ;
>             rate3 =3D on->on_tx_rate3sp ;
>         }
>         else
>         {
>             rate1 =3D on->on_tx_rate1 ;
>             rate2 =3D on->on_tx_rate2 ;
>             rate3 =3D on->on_tx_rate3 ;
>         }
>
>         if ( rate1 !=3D 0 )
>             try1 =3D 2 ;
>         else
>             try1 =3D 0 ;                  /* set 0 for try count to bypass
> the try if rateCode is 0 */
>
>         if ( rate2 !=3D 0 )
>             try2 =3D 2 ;
>         else
>             try2 =3D 0 ;
>
>         if ( rate3 !=3D 0 )
>             try3 =3D 2 ;
>         else
>             try3 =3D 0 ;
>
>
>     ath_hal_setupxtxdesc(sc->sc_ah, ds
>         , rate1, try1    /* series 1 */
>         , rate2, try2    /* series 2 */
>         , rate3, try3    /* series 3 */
>     );
> }
>
>
> thank you
>
> Takayuki Kaiso
> Thinktube Ltd,
> Kobe Japan
>
> > Hi, all
> >
> >    Through further investigation,  it seems that  "rate control" is
> > one of the player(s)
> >    which affects or determines when Beacon xmit from (B) stopped in my
> > last tests.
> >    ( I used  "onoe" version for rate control, but amrr probably give
> > no difference on this issue)
> >
> >    I might be able to find a certain way of "work around this problem",
> >    but this should not be the solution in real sense.
> >
> >   Any kind of comments/suggestions are so welcome.
> >
> > Thank you
> >
> > Takayuki Kaiso
> > Thinktube Ltd,
> > Kobe Japan