On 09.05.2013 22:11, Lev Serebryakov wrote:
And there is no power setting settings on Windows (or I
don't know how to find them, but I see big property page with
different settings, like roaming aggressiveness and preferred
frequency band).
Lev,
depends of driver versio
Ah. So these non aggregate tests are showing a problem - there shouldn't be 500
frames in the txq. Ever. That's just plain dumb.
Because of this, the logic I introduced to limit queue depth for a node isn't
working - the node software queue depth never grows past a handful. They're
immediately
Yup, looks like the TX queue is just too deep and the EAPOL messages
aren't making out.
I thought I fixed this.
I'll see if I can replicate this on holidays, but it may take a while.
But luckily this looks like I've fixed the hardware TX queue stall!
adrian
Hello, Adrian.
You wrote 9 мая 2013 г., 23:58:31:
AC> .. and basically, once you've grabbed some hostapd debugging, let me
AC> know if you see transmit queue stalls. Yes, the queue handling w/
AC> power-save handling in hostapd mode is rather suboptimal. That's high
AC> up on my 'broken stuff that
Hello, Adrian.
You wrote 9 мая 2013 г., 23:54:08:
AC> .. now, see how it's kicking you off? The transmit queue is filled
AC> _and_ the station is asleep. We're still trying to send it stupid
AC> amounts of data even though we can't get to the sleeping station.
At same moment, station prints re
.. and basically, once you've grabbed some hostapd debugging, let me
know if you see transmit queue stalls. Yes, the queue handling w/
power-save handling in hostapd mode is rather suboptimal. That's high
up on my 'broken stuff that needs fixing' list.
Let me know how the data gathering goes and w
On 9 May 2013 12:48, Lev Serebryakov wrote:
> f0:a2:25:ec:38:c6 is Kindle.
> c4:85:08:3f:9e:c2 is Windows client, UDP stream receiver.
Ok. So this is a different problem.
May 9 23:39:18 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] RSN ie: mc
3/0 uc 3/0 key 2 caps 0x0
May 9 23:39:18 gateway kern
Hello, Lev.
You wrote 9 мая 2013 г., 23:42:32:
AC>> I bet this is what is actually going on. Can you please do the
AC>> wlandebug above, so we can see if it's actually disassociating and not
AC>> transitioning back through SCAN/ASSOC states?
LS> Here it is. Faster, than usual (~150 seconds, typi
Hello, Adrian.
You wrote 9 мая 2013 г., 23:39:49:
>> May 9 23:36:43 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] pwr save q
>> overflow, drops 8895 (size 50)
>> messages are generating with these srttings.
AC> ... right; is that the MAC address of the test station?
Yep!
--
// Black Lion AKA
Hello, Adrian.
You wrote 9 мая 2013 г., 23:24:07:
AC> I bet this is what is actually going on. Can you please do the
AC> wlandebug above, so we can see if it's actually disassociating and not
AC> transitioning back through SCAN/ASSOC states?
Here it is. Faster, than usual (~150 seconds, typical
On 9 May 2013 12:37, Lev Serebryakov wrote:
> May 9 23:36:43 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] pwr save q
> overflow, drops 8895 (size 50)
>
> messages are generating with these srttings.
... right; is that the MAC address of the test station?
adrian
_
Hello, Adrian.
You wrote 9 мая 2013 г., 23:24:07:
AC> Next time you do this, can you do this:
AC> wlandebug +crypto +assoc +state
AC> I'd like to see what's actually going on behind the scenes.
AC> I bet this is what is actually going on. Can you please do the
AC> wlandebug above, so we can see i
Hi,
Next time you do this, can you do this:
wlandebug +crypto +assoc +state
I'd like to see what's actually going on behind the scenes.
so:
May 9 21:08:59 gateway sudo: lev : TTY=pts/1 ;
PWD=/usr/home/lev/bin ; USER=root ; COMMAND=/sbin/sysctl
dev.ath.0.debug=0x90020
.. then a bunc
ok, I'll go over hte logs again soon.
thanks! we're getting there!
adrian
On 9 May 2013 10:26, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 9 мая 2013 г., 21:23:20:
>
> AC> When you say "recover fast", what's that mean?
> First time I call forced bstuck several times, but it seems, t
Hello, Adrian.
You wrote 9 мая 2013 г., 21:23:20:
AC> When you say "recover fast", what's that mean?
First time I call forced bstuck several times, but it seems, that
client re-associate after first one. For second time (AP was
rebooted after first experiment) client lost association (According
When you say "recover fast", what's that mean?
adrian
On 9 May 2013 10:18, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 9 мая 2013 г., 1:24:12:
>
> AC> Ok, please update to the latest -HEAD as of right now and re-test.
> r250406: problems after long UDP stream. But it looks like it r
Hello, Adrian.
You wrote 9 мая 2013 г., 1:24:12:
AC> Ok, please update to the latest -HEAD as of right now and re-test.
r250406: problems after long UDP stream. But it looks like it recover
fast now.
BUT, BUT! After that, at second run, I got 802.11n rates with UDP at
last! They were lost lo
Ok, please update to the latest -HEAD as of right now and re-test.
Adrian
On 8 May 2013 14:03, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 9 мая 2013 г., 1:00:06:
>
> AC> Yeah, -HEAD right now is still busted.
> AC> I'm testing out some locking changes right now that fix how I was
> A
Hello, Adrian.
You wrote 9 мая 2013 г., 1:00:06:
AC> Yeah, -HEAD right now is still busted.
AC> I'm testing out some locking changes right now that fix how I was
AC> handling the holding descriptors. Once that's in -HEAD, I'll tell you
AC> to re-test.
We had long holidays (4 days!) here, so I
Yeah, -HEAD right now is still busted.
I'm testing out some locking changes right now that fix how I was
handling the holding descriptors. Once that's in -HEAD, I'll tell you
to re-test.
Thanks!
Adrian
On 8 May 2013 13:49, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 8 мая 2013 г., 6
Hi Lev (and others);
I've fixed the UDP TX + rekey session drop bug.
Please re-test your testcase on the latest -HEAD and let me know how it goes.
I'd really like to sneak in these power save and reassociate changes
of mine, but first I want to make sure that your issue is correctly
resolved.
T
Hi,
So doing this testing as a station doing the UDP transmitting (to a
FreeBSD AP) is showing some interesting behaviour. No, i don't think
it's your bug.
The key re-negotiation seems to be failing somewhere; I bet it's out
of sequence or out of order crypto frames. I've seen this happen
before
Hi!
Please update to the head -HEAD and test!
I'm still debugging all of this and trying to understand what the
other failure cases. Right now I'm seeing STA disassocications during
UDP testing but it doesn't look like a stalled queue.
Thanks,
Adrian
___
Hello, Adrian.
You wrote 3 мая 2013 г., 8:22:40:
>> I'll do some further digging. It may be that I just give in and add
>> the TXQ stall workaround. I'd however like to avoid doing that if
>> possible. :-)
AC> Hm, I'm reproducing it here and I see some odd descriptor behaviour.
AC> I'll tinker wit
On 2 May 2013 18:54, Adrian Chadd wrote:
> .. and I've now (mostly) successfully reproduced this here at home.
>
> I'll do some further digging. It may be that I just give in and add
> the TXQ stall workaround. I'd however like to avoid doing that if
> possible. :-)
Hm, I'm reproducing it here an
.. and I've now (mostly) successfully reproduced this here at home.
I'll do some further digging. It may be that I just give in and add
the TXQ stall workaround. I'd however like to avoid doing that if
possible. :-)
Adrian
___
freebsd-wireless@freebsd
I'm trying to plan out how to potentially address this.
I don't know whether it'll be enough to just set TXE to 1 for that
queue and restart TX that way. I was hoping you'd post some more
results with aggregate frames, but it doesn't seem to be happening.
I'm hoping I don't have to stop the DMA f
On 1 May 2013 02:32, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 1 мая 2013 г., 2:17:52:
>
> AC> Well, right now I'm trying to figure out whether there's a race
> AC> condition in setting up / enabling the TX queue that I haven't yet
> AC> seen before, or whether we've hit another one of t
Hello, Adrian.
You wrote 1 мая 2013 г., 2:17:52:
AC> Well, right now I'm trying to figure out whether there's a race
AC> condition in setting up / enabling the TX queue that I haven't yet
AC> seen before, or whether we've hit another one of those corner case
AC> bugs in the TX queue handling.
I
Well, right now I'm trying to figure out whether there's a race
condition in setting up / enabling the TX queue that I haven't yet
seen before, or whether we've hit another one of those corner case
bugs in the TX queue handling.
I may add in a hack to the completion code that checks if the queue
i
Hello, Adrian.
You wrote 30 апреля 2013 г., 19:41:12:
>> Warm-up: 120 seconds of TCP, throughput osculate between 50 and
>> 100Mbit/, several BAR resets, no hangs.
AC> Ok. But did it negotiate A-MPDU?
I'm not sure. Both ends showed typical N speeds (Windows in
connection properties, F
On 30 April 2013 01:24, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 30 апреля 2013 г., 8:53:00:
>
> AC> Any follow-up with the latest stuff in -HEAD? I'd like to see if the
> AC> hardware queue is behaving how I think it is.
> Sorry, was busy yesterday.
> Sources: r250041, TDMA is enab
Hello, Adrian.
You wrote 30 апреля 2013 г., 8:53:00:
AC> Any follow-up with the latest stuff in -HEAD? I'd like to see if the
AC> hardware queue is behaving how I think it is.
Sorry, was busy yesterday.
Sources: r250041, TDMA is enabled in kernel config.
Warm-up: 120 seconds of TCP, thr
Any follow-up with the latest stuff in -HEAD? I'd like to see if the
hardware queue is behaving how I think it is.
Adrian
On 29 April 2013 00:49, Adrian Chadd wrote:
> There's likely some bugs with the AMPDU aggregation negotiating
> kicking in when all the TX buffers are full. I thought that w
There's likely some bugs with the AMPDU aggregation negotiating
kicking in when all the TX buffers are full. I thought that was fixed,
alas.
I'll investigate that later. I have to acquire some programmable
attenuators to do this.
adrian
___
freebsd-wi
Hello, Adrian.
You wrote 29 апреля 2013 г., 11:29:32:
AC> Please update to -HEAD first!
Ok :) These test were on r250017.
AC> And erm, run iperf tcp first, before udp. That way aggregation is
AC> negotiated. :-)
Ok. But on previous revisions it was not needed. But previous tests
were done no
.. well, please update to -HEAD; I've just added some more debugging
to the reset path to see what the state of the hardware queue is.
Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To un
Please update to -HEAD first!
And erm, run iperf tcp first, before udp. That way aggregation is
negotiated. :-)
adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any ma
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:38:20:
AC> There's some race condition hack that Sam threw in that gets enabled
AC> only if you compile things with TDMA support enabled. Would you mind
AC> compiling in TDMA support (add options IEEE80211_SUPPORT_TDMA) to your
AC> kernel config and r
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:49:38:
AC> .. how's this never triggered a clang warning on me before?
AC> Just add casts for now or something so it compiles.
Testing... One more datapoint: with this option bsnmpd with wlan
plugin complains:
Apr 29 00:09:46 gateway snmpd[1
.. how's this never triggered a clang warning on me before?
Just add casts for now or something so it compiles.
Adrian
On 28 April 2013 12:48, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 28 апреля 2013 г., 23:38:20:
>
> AC> There's some race condition hack that Sam threw in that gets
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:38:20:
AC> There's some race condition hack that Sam threw in that gets enabled
AC> only if you compile things with TDMA support enabled. Would you mind
AC> compiling in TDMA support (add options IEEE80211_SUPPORT_TDMA) to your
AC> kernel config and r
On 28 April 2013 11:50, Lev Serebryakov wrote:
> 300M. Only 11-30M seen by client now, but no beacon stucks.
> After AP hangs several forced beacon stucks + hostaptd restart
> allow client to re-associate.
Right. That's likely because 11n aggregation wasn't enabled. I don't know why.
> Lo
Hello, Adrian.
You wrote 28 апреля 2013 г., 23:15:23:
AC> Yeah, can you see why 11n wasn't negotiated and repeat the test?
Ok, rebooted both AP and client.
Client/Windows says (via connection properties) it is "240Mbit/s",
AP/FreeBSD says (via ifconfig list sta):
ADDR AID CHAN
Hello, Adrian.
You wrote 27 апреля 2013 г., 22:56:30:
AC> Anyway, leave it how it is for now. Just update to the latest -HEAD
AC> ath code and redo the testing. It will now log the whole TX queue
AC> contents, not just the completed frames. Hopefully it'll be more
AC> obvious.
Ok, same test: UDP
Hello, Adrian.
You wrote 27 апреля 2013 г., 22:56:30:
>> AC> You're not doing something like leaving bgscan enabled, or not
>> AC> defining a channel up front?
>> Here is my config:
>
>> ifconfig_wlan0="inet 192.168.135.1 netmask 255.255.255.0 mode 11ng channel
>> 3:ht/40 -bgscan ssid home.sereb
On 27 April 2013 01:33, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 27 апреля 2013 г., 1:34:24:
>
> AC> You're not doing something like leaving bgscan enabled, or not
> AC> defining a channel up front?
> Here is my config:
>
> ifconfig_wlan0="inet 192.168.135.1 netmask 255.255.255.0 mode
Hello, Adrian.
You wrote 27 апреля 2013 г., 1:34:24:
AC> You're not doing something like leaving bgscan enabled, or not
AC> defining a channel up front?
Here is my config:
ifconfig_wlan0="inet 192.168.135.1 netmask 255.255.255.0 mode 11ng channel
3:ht/40 -bgscan ssid home.serebryakov.spb.ru cou
Hi,
I've just committed something to -HEAD that logs -all- the descriptors
in the TX queue during a reset.
This requires ATH_DEBUG_RESET to be set (0x20), so use the same debug
mask as before.
Thanks!
Adrian
___
freebsd-wireless@freebsd.org mailing
You're not doing something like leaving bgscan enabled, or not
defining a channel up front?
There's a lot of resets hre.
adrian
On 26 April 2013 14:28, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 26 апреля 2013 г., 12:51:17:
>
>>> Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
>
Hello, Adrian.
You wrote 26 апреля 2013 г., 12:51:17:
>> Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
Ok, several such commands helps without down/up of interface.
Log attached: a lot of traffic, several BAR retransmits, interface
hangs, several "forcebstuck=1", client could as
On 26 April 2013 14:14, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 26 апреля 2013 г., 18:56:57:
>
> AC> And please cc -wireless with your debugging results :)
> Ok.
>It is interesting how throughput is not connected to rate after
> these problems. Now I have client at stable 270M ra
Hello, Adrian.
You wrote 26 апреля 2013 г., 18:56:57:
AC> And please cc -wireless with your debugging results :)
Ok.
It is interesting how throughput is not connected to rate after
these problems. Now I have client at stable 270M rate with RSSI ~28,
and only 15-20Mbit/s of UDP traffic AP->Cl
On 26 April 2013 01:45, Adrian Chadd wrote:
> Hi,
>
> Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
So the descriptors are mostly completed. I really need to hack the
reset path to continue printing everything in the queue, not just the
frames that were completed.
But the TXQ[1] head point
Hi,
Wait. sysctl dev.ath.0.forcebstuck=1 didn't fix it?
adrian
On 26 April 2013 01:25, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 26 апреля 2013 г., 4:11:44:
>
> AC> Ok. Next time it happens, force a stuck beacon:
> GOT IT!
>
> You could use "sudo" messages as markers in log file.
Hello, Adrian.
You wrote 26 апреля 2013 г., 4:11:44:
AC> Ok. Next time it happens, force a stuck beacon:
AC> sysctl dev.ath.X.forcebstuck=1
AC> That will cause the right kind of reset in order to log the frames in
AC> the TX queue.
AC> Make sure you have the right debug mask though!
Without reboo
Ok. Next time it happens, force a stuck beacon:
sysctl dev.ath.X.forcebstuck=1
That will cause the right kind of reset in order to log the frames in
the TX queue.
Make sure you have the right debug mask though!
Adrian
___
freebsd-wireless@freebsd.org
Hiya,
On 25 April 2013 13:14, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 24 апреля 2013 г., 0:55:52:
>
> AC> Turn on reset debugging - sysctl dev.ath.0.debug=0x20
> Log attached. Debug was set to BAR + reset flags, UDP stream from AP
> to client, at some moment AP stops to work and I'
On 23 April 2013 12:57, Petko Bordjukov wrote:
> Falling back to a ht:20- channel did considerably lower the number of stuck
> beacon messages on my AR9220. It still periodically hangs though (is this
> why ``baseband hangs?'' is listed in the wiki?).
Well, partially.
I'm seeing stuck beacons in
Falling back to a ht:20- channel did considerably lower the number of stuck
beacon messages on my AR9220. It still periodically hangs though (is this
why ``baseband hangs?'' is listed in the wiki?).
On Tue, Apr 23, 2013 at 5:45 PM, Lev Serebryakov wrote:
> Hello, Adrian.
> You wrote 23 апреля 2
Hello, Adrian.
You wrote 23 апреля 2013 г., 18:43:45:
AC> Try dropping it down to a HT20 channel.
AP or client or both? Is it enough to disable HT40 channels on
client?
--
// Black Lion AKA Lev Serebryakov
___
freebsd-wireless@freebsd.org mailing li
Try dropping it down to a HT20 channel.
adrian
On 23 April 2013 05:41, Lev Serebryakov wrote:
> Hello, Freebsd-wireless.
>
> Now my router/AP is new hardware in new case, and it is not
> overheating for sure.
> AP's WiFi card is Ubiquity SR-71E MiniPCIe card. Client is Intel
> Advanced-N ca
Hello, Freebsd-wireless.
Now my router/AP is new hardware in new case, and it is not
overheating for sure.
AP's WiFi card is Ubiquity SR-71E MiniPCIe card. Client is Intel
Advanced-N card. When AP sends stable stream of data (like RDesktop
connection from WiFi client to computer on wired network
63 matches
Mail list logo
