On Wed 31.10.07 21:49, Nick Kossifidis wrote:
> 2007/10/31, Ulrich Meis <[EMAIL PROTECTED]>:
> > On Mon 29.10.07 17:12, Ulrich Meis wrote:
> > [snip]
> > > There's just one problem...I can't send more than 2312 bytes, which also
> > > happens to be the limit defined in the 802.11 spec. Or maybe I c
2007/10/31, Ulrich Meis <[EMAIL PROTECTED]>:
> On Mon 29.10.07 17:12, Ulrich Meis wrote:
> [snip]
> > There's just one problem...I can't send more than 2312 bytes, which also
> > happens to be the limit defined in the 802.11 spec. Or maybe I can, but
> > the receiver(also running ath5k) doesn't acc
On Mon 29.10.07 17:12, Ulrich Meis wrote:
[snip]
> There's just one problem...I can't send more than 2312 bytes, which also
> happens to be the limit defined in the 802.11 spec. Or maybe I can, but
> the receiver(also running ath5k) doesn't accept it...on that side I
> hacked into the rx tasklet an
On Mon 29.10.07 19:00, Nick Kossifidis wrote:
> > I hacked into the tx function and managed to let the card send out the
> > contents of two descriptors in one frame. I didn't do any encapsulation,
> > I just copied the first packet(an ICMP echo request), fetched a second
> > buffer, called the fil
> I hacked into the tx function and managed to let the card send out the
> contents of two descriptors in one frame. I didn't do any encapsulation,
> I just copied the first packet(an ICMP echo request), fetched a second
> buffer, called the fill functions appropriately and finally it worked. I
> c
On Sat 27.10.07 03:12, Nick Kossifidis wrote:
[snip]
> About fast frames: actually it's more complicated, we have more
> descriptors for each buffer, we have to do encapsulation and
> decapsulation (check out madwifi code) by also tweaking the stack etc.
> Currently noone is working on fast frames
2007/10/26, Ulrich Meis <[EMAIL PROTECTED]>:
> This patch fixes the setup of transmit descriptors. tx_control_1 is set
> in ath5k_hw_setup_{2,4}word_tx_desc but was subsequently overriden by
> ath5k_hw_fill_{2,4}word_tx_desc. The victims were FRAME_TYPE and NO_ACK.
> The missing no_ack in broadcast
On Fri 26.10.07 10:37, Luis R. Rodriguez wrote:
> On 10/26/07, Ulrich Meis <[EMAIL PROTECTED]> wrote:
> > This patch fixes the setup of transmit descriptors. tx_control_1 is set
> > in ath5k_hw_setup_{2,4}word_tx_desc but was subsequently overriden by
> > ath5k_hw_fill_{2,4}word_tx_desc. The victim
On 10/26/07, Ulrich Meis <[EMAIL PROTECTED]> wrote:
> This patch fixes the setup of transmit descriptors. tx_control_1 is set
> in ath5k_hw_setup_{2,4}word_tx_desc but was subsequently overriden by
> ath5k_hw_fill_{2,4}word_tx_desc. The victims were FRAME_TYPE and NO_ACK.
> The missing no_ack in br
This patch fixes the setup of transmit descriptors. tx_control_1 is set
in ath5k_hw_setup_{2,4}word_tx_desc but was subsequently overriden by
ath5k_hw_fill_{2,4}word_tx_desc. The victims were FRAME_TYPE and NO_ACK.
The missing no_ack in broadcast frames caused them to be retried up to
the retry_lim
10 matches
Mail list logo
