[Madwifi-devel] rx_bytes, tx_bytes - only for transfer between sta and ap

[kachim kachim <k4chim@gm...>]

hi;

How can I learn about amount of tx_bytes and rx_bytes on device in
station mode? I'm interested only in tx_bytes and tx_bytes for
transfer between station and ap(not whole traffic for interface).

Regards,

krzychu

Re: [Madwifi-devel] Question about tasklet and processq

[Maali Al Hachami <alhachami@gm...>]

Yeah, I figured that out earlier today through debugging :(

I need a way to call a function for each retry. Basically, what I'm trying
to do is implementing a new backoff scheme, and obviously this needs
processing for each transmission trial.

Thank you for the reply,
Maali

On Wed, May 14, 2008 at 10:30 AM, Benoit PAPILLAULT <
benoit.papillault@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Maali Al Hachami a écrit :
> | Thank you very much for the guidance. I compared what I understood from
> | the book with the madwifi code and some insights from ath5k openHAL.
> | ath_tasklet is a deferred bottom-half interrupt processing that is
> | scheduled for processing when the processor best can. the interrupts
> | that provoke this tasklet are related to transmission, including TXOK
> | and TXERR. Still, I couldn't  figure out whether this TXERR is per
> | transmission trial or per packet (after all retries are exausted).
> |
> | On Tue, May 13, 2008 at 5:32 PM, Matthew mentor Bell <mentor@...
> | <mailto:mentor@...>> wrote:
> |
> |     On Tue, 2008-05-13 at 17:01 +0400, Maali Al Hachami wrote:
> |      > - is the tasklet (and therefore processq) function called upon
> each
> |      > transmission trial (including retransmissions)? or just called
> once
> |      > per packet (to assess the overall packet transmission outcome)?
> |
> |     http://www.xml.com/ldd/chapter/book/ch09.html#t5
> |     http://www.xml.com/ldd/chapter/book/ch06.html#t4
> |
> |     Matthew
>
> AFAIK, the interrupt is triggered after all retries are exhausted. Of
> course, if the packet is transmitted after 1 retry, the interrupt should
> come up at this point.
>
> I'm not aware of a way to do processing between retries...
>
> Regards,
> Benoit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIKocJOR6EySwP7oIRAjs8AJ9i9f0BbLrEv/BRpU/aXcH+/EDZOwCdGiuo
> 1BxJ3jeqHf6ioxFJfqCjY3k=
> =C/j5
> -----END PGP SIGNATURE-----
>

Re: [Madwifi-devel] Question about tasklet and processq

[Benoit PAPILLAULT <benoit.papillault@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maali Al Hachami a écrit :
| Thank you very much for the guidance. I compared what I understood from
| the book with the madwifi code and some insights from ath5k openHAL.
| ath_tasklet is a deferred bottom-half interrupt processing that is
| scheduled for processing when the processor best can. the interrupts
| that provoke this tasklet are related to transmission, including TXOK
| and TXERR. Still, I couldn't  figure out whether this TXERR is per
| transmission trial or per packet (after all retries are exausted).
|
| On Tue, May 13, 2008 at 5:32 PM, Matthew mentor Bell <mentor@...
| <mailto:mentor@...>> wrote:
|
|     On Tue, 2008-05-13 at 17:01 +0400, Maali Al Hachami wrote:
|      > - is the tasklet (and therefore processq) function called upon each
|      > transmission trial (including retransmissions)? or just called once
|      > per packet (to assess the overall packet transmission outcome)?
|
|     http://www.xml.com/ldd/chapter/book/ch09.html#t5
|     http://www.xml.com/ldd/chapter/book/ch06.html#t4
|
|     Matthew

AFAIK, the interrupt is triggered after all retries are exhausted. Of
course, if the packet is transmitted after 1 retry, the interrupt should
come up at this point.

I'm not aware of a way to do processing between retries...

Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKocJOR6EySwP7oIRAjs8AJ9i9f0BbLrEv/BRpU/aXcH+/EDZOwCdGiuo
1BxJ3jeqHf6ioxFJfqCjY3k=
=C/j5
-----END PGP SIGNATURE-----

Re: [Madwifi-devel] Madwifi Driver 0.9.4 freezes a Linux

[Thomas Fiksel <Thomas.Fiksel@je...>]

Hi,

a workaround for this problem is the using of the select function. Before the write function is called (on board A) it should be checked with the select function that a write is possible. Doing this no freeze of Linux is observed in case that the receiver is down.

Thomas