Hi!
Well, that's great! Can you post instructions on what you did to get
it up and working?
Does it come with a large set of test cases? If not, then writing a
large set of test cases would be good.
And no, you don't _have_ to fix issues that you may see creep up in
net80211 / drivers as a conse
Can somebody give me more information on this project?
I have already tested scapy on FreeBSD 9.1 and it works very well. All I'll
have to do is build some test cases and test the 802.11 code?
What will the test cases be like? I suppose that if we find any bugs in the
code, then I will be required
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
10 matches
Mail list logo
