On Thursday 20 July 2006 12:42, Sam Leffler wrote:
The original posting didn't provide any basic info so there's little
anyone can provide except wild guesses. There are debugging mechanisms
for tracing what's going on at the net80211 layer and in the driver that
have been referenced
How is data transmission related to power management?
They are pretty intimately related over a wireless link. If
the power management at one end decided it can use less transmit
power and gets it wrong then your data stops getting through.
___
Pete French wrote:
How is data transmission related to power management?
They are pretty intimately related over a wireless link. If
the power management at one end decided it can use less transmit
power and gets it wrong then your data stops getting through.
Your posting truncated the note
The original posting didn't provide any basic info so there's little
anyone can provide except wild guesses. There are debugging mechanisms
for tracing what's going on at the net80211 layer and in the driver that
have been referenced countless times in this forum.
Sorry, didn't know it could
Sounds like what always happens when crappy power management stuff is
enabled either on the station or the ap.
I would investigate that first.
Victor Semionov wrote:
Hello list,
I have a wireless card with an Atheros 5212 chipset and I'm experiencing the
following behavior under FreeBSD 6.1:
How is data transmission related to power management?
On Wednesday 19 July 2006 19:01, you wrote:
Sounds like what always happens when crappy power management stuff is
enabled either on the station or the ap.
I would investigate that first.
Victor Semionov wrote:
Hello list,
I have a
Hello list,
I have a wireless card with an Atheros 5212 chipset and I'm experiencing the
following behavior under FreeBSD 6.1:
TCP connections that consist of small short bursts of one-way (transmission)
traffic often stall until traffic is received over another TCP connection.
For example,
