Re: FreeBSD current RT3071 can't connect to 5G network
On Wed, Aug 20, 2014 at 5:55 PM, Adrian Chadd wrote: > On 20 August 2014 16:33, PseudoCylon wrote: >> On Wed, Aug 20, 2014 at 1:29 PM, Adrian Chadd wrote: >>> Are you seeing RX CRC errors for all rates? CCK? OFDM? HT? At all distances? >> >> CCK not sure, OFDM and HT yes. And at wide range of distances. (Tx >> rates usually hit mcs 12 to 14 with 2s ht20 ap) >> >>> >>> There's a handful of things we can look at to see what's causing it >>> once some more digging is done. >>> >>> (Eg, HT? could be guard interval. OFDM has similar issues, there's >>> typically ways to configure how much time between each symbol is left >>> before transmitting the next one. It may not be doing CTS-to-self, or >>> it may not be advertising the right thing via NAV, or it may be >>> ignoring CCK, or the receive gain tables are all messed up, etc.) >> >> I have looked into stuff I was able to dig out from other src codes, >> ie protection, ifs, nav, bk slot. (Because I do not have datasheet, >> every thing is based on my guesses.) One thing I could not figure out >> is if on-chip memory is properly allocated for rx pkt. (It seems >> memory can be allocated for different things, ie beacon, enc keys). >> > > So CRC errors are pretty normal with wifi. Even a tiny bit of > interference generates CRC errors. That's why there's an ACK and retry > mechanism. :P > > If you're hitting MCS 12 then you're doing pretty well. A-MPDU will > see lots of CRC errors just because of how long the transmissions are > and how easily corrupted things can get. That's again why there's a > quick retry mechanism for things. To clarify, tx on run hits mcs 12 to 14. I assume tx on run is working. But, tx on ap can hit 39mbps at the best, most likely due to high rx crc error rates on run. > > What %age errors are you seeing? Constantly 70 to 80 rx crc errors/sec during active downloads. (h/w does not count total rx, so cannot tell the %.) > > > > > -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: FreeBSD current RT3071 can't connect to 5G network
On Wed, Aug 20, 2014 at 1:29 PM, Adrian Chadd wrote: > Are you seeing RX CRC errors for all rates? CCK? OFDM? HT? At all distances? CCK not sure, OFDM and HT yes. And at wide range of distances. (Tx rates usually hit mcs 12 to 14 with 2s ht20 ap) > > There's a handful of things we can look at to see what's causing it > once some more digging is done. > > (Eg, HT? could be guard interval. OFDM has similar issues, there's > typically ways to configure how much time between each symbol is left > before transmitting the next one. It may not be doing CTS-to-self, or > it may not be advertising the right thing via NAV, or it may be > ignoring CCK, or the receive gain tables are all messed up, etc.) I have looked into stuff I was able to dig out from other src codes, ie protection, ifs, nav, bk slot. (Because I do not have datasheet, every thing is based on my guesses.) One thing I could not figure out is if on-chip memory is properly allocated for rx pkt. (It seems memory can be allocated for different things, ie beacon, enc keys). > > > -a ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: FreeBSD current RT3071 can't connect to 5G network
> Message: 4 > Date: Mon, 18 Aug 2014 16:49:32 +0800 > From: Kevin Lo > To: Miguel Clara > Cc: freebsd-wireless@freebsd.org > Subject: Re: FreeBSD current RT3071 can't connect to 5G network > Message-ID: <20140818084932.ga31...@ns.kevlo.org> > Content-Type: text/plain; charset=us-ascii Adding 11n support to run is pretty much done. But, run (either stock or with 11n) generates lots of rx crc errors. I do not have datasheets neither, so I kinda gave up. If some one fix it, the driver is ready to go. Otherwise, the performance sucks. > > Since there is no data sheets available, looking throught the source code > from the vendor makes slower development and is very time-consuming, > at least in my case. > > Kevin > > On Sun, Aug 17, 2014 at 05:03:50PM +0100, Miguel Clara wrote: >> >> Thanks for clarifying Kevin. >> >> I wonder whats the reason for this? Since its in all I guess something in >> the kernel makes this harder? or is it just lack of time/resources? >> >> thanks >> >> >> >> >> Melhores Cumprimentos // Best Regards >> --- >> *Miguel Clara* >> *IT - Sys Admin & Developer* >> *E-mail:*miguelmcl...@gmail.com >> www.linkedin.com/in/miguelmclara/ >> >> >> On Sun, Aug 17, 2014 at 3:43 PM, Kevin Lo wrote: >> >> > On Sat, Aug 16, 2014 at 09:07:29PM +0100, Miguel Clara wrote: >> > > >> > > On Fri, Aug 15, 2014 at 4:06 AM, Kevin Lo wrote: >> > > >> > > > All USB wifi dongles in FreeBSD don't support 11n yet. >> > > > >> > > > Kevin >> > > > >> > > > >> > > I was not aware of that, is this really true for all USB wifi dongles or >> > > do you mean ralink only? >> > >> > It's true for all USB wifi dongles in *BSD... >> > >> > Kevin >> > >> ___ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" >> > > ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout
The following reply was made to PR kern/177451; it has been noted by GNATS. From: PseudoCylon To: bug-follo...@freebsd.org, dav...@freebsd.org Cc: Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout Date: Fri, 29 Mar 2013 16:37:20 -0600 Oops. The code casts the enum to the pointer to begin, so it works. Sorry, for the noise. On Fri, Mar 29, 2013 at 3:21 PM, PseudoCylon wrote: > http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2506 > enum ieee80211_state ostate = (enum ieee80211_state) arg; > casting a pointer to an enum > > http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2519 > if (vap->iv_state == ostate) > So that, this test is always false -> callout_reset() will never be > called -> by the time the callout timer runs out, ni could be freed. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout
The following reply was made to PR kern/177451; it has been noted by GNATS. From: PseudoCylon To: bug-follo...@freebsd.org, dav...@freebsd.org Cc: Subject: Re: kern/177451: [ieee80211] page fault in ieee80211_tx_mgt_timeout Date: Fri, 29 Mar 2013 15:21:58 -0600 http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2506 enum ieee80211_state ostate = (enum ieee80211_state) arg; casting a pointer to an enum http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c?v=FREEBSD91#L2519 if (vap->iv_state == ostate) So that, this test is always false -> callout_reset() will never be called -> by the time the callout timer runs out, ni could be freed. ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: [RFT] net80211 TX serialisation, take #4
On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd wrote:
> The trouble with using a queue is that things will dequeue frames out
> of order, bceause multiple dequeue contexts (ie, each call to
> driver_start / driver_transmit) will execute in-parallel.
Actually, to prevent that, there is an extra queue.
To begin
driver_queue:packet1--packet2--3--4--...
working_queue:empty
hadware_queue:empty
After multiple thread dequeue
lock dequeue enqueue unlock
lock dequeue enqueue unlock
They look like,
driver_queue:2--3--4--...
working_queue:1--2 (the lock preserves the order)
hardware_queue: empty
If a thread has packet #1 finished first, there is no problem.
If a thread has packet #2 finished first, it will try to dequeue the
packet #1 (head of the queue) from the working_queue. But the packet
isn't marked as "completed", so it will just return.
Queue still look like
driver_queue:2--3--4--...
(of course, other threads are processing remaining packets,
but to simplify, no change in driver_queue.)
working_queue: 1--2
hardware: empty
Later, once the thread with #1 finished processing, it will
lock while (completed) {dequeue enqueue} unlock
At the end, queue look like,
driver_queue:2--3--4--...
working_queue: empty
hardware_queue: 1--2 (the lock preserves the order)
Just wanted to clarify. I will soon test the latest txlock patch.
AK
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: [RFT] net80211 TX serialisation, take #4
On Sun, Feb 24, 2013 at 12:45 AM, Adrian Chadd wrote:
> On 23 February 2013 22:30, PseudoCylon wrote:
>>> So, this is all pretty terrible. The only sane solution for now is to
>>> make my VAP TX lock an IC TX lock,and grab said IC TX lock for all
>>> VAPs. That way the driver can grab the IC TX lock when it's doing
>>> deferred sends and it'll be sure the lock is held when it decides to
>>> grab/increment sequence numbers from ni->ni_txseqs[].
>>
>> I don't think
>> lock();
>> ni->ni_txseqs[]++;
>> unlock();
>> can fix the problem because no one can guarantee which process/thread
>> grabs the lock next.
>
> Yup, that's definitely a problem.
>
> The problem here is that packets coming into net80211 - either via
> vap->input() (bpf injection) or vap->transmit() (802.3) , have to do
> this:
There isn't any sequence relations between bpf injection and packets
from vap->transmit(). First come first enqueue should work.
80211 stack generated packets --\
bpf_injection -> ieee80211_output()--\
vap_transmit() -> vap_queue -> 80211stack --> driver_queue
>
> * processed in order;
> * the same order as they're then pushed into the power save / age queue;
> * the same order that these frames get assigned sequence numbers and
> enforce state (eg considering things for ampdu, power save, etc);
> * the same order that they're queued to the driver;
> * the same order that they're dequeued from the driver;
> * the same order that they're processed (eg crypto encaps);
> * the same order that it's then passed down into the driver - either
> via direct dispatch or deferred queue.
>
>
>>> * .. and do this without tearing my hair out.
>>
>> The sequence will be messed up during moving packets from one queue to
>> another, i.e from driver queue to hardware queue. As long as packets
>> are in a queue (in a linked list) sequence won't change unless we
>> explicitly write such code. So...
>>
>> Saving your hair option 1
>> tx()
>> {
>> for() {
>> lock();
>> dequeue(m);/* assuming queue is in order */
>> ni_txseqs[]++
>> enqueue_working_queue(m);
>> unlock();
>> ...
>> process m
>> ...
>> lock();
>> /*
>> * m may change here.
>> * Whichever the thread does dequeues, m0 will be
>> * the head of the queue, so sequence will be kept intact.
>> * But, need to test if processing of m0 has been completed.
>> */
>> dequeue_working_queue(m0);
>> enqueue_driver_queue(m0); /* or hardware_queue() */
>> unlock();
>> }
>> }
>> This will keep sequence intact.
>
> Right. This is similar to my idea (or two.)
>
> There's a few other issues though!
>
> ic_raw_xmit() is called by a bunch of places to generate both raw
> frames and management frames. This bypasses the vap queue and calls
> the driver direct. As an example, injected EAPOL frames have CCMP IV
> numbers (as they're encrypted!) but not necessarily sequence numbers.
> Because the CCMP IV gets calculated int he driver at some point after
> it's been queued, ANY slight race here causes some other frame to get
> queued with a CCMP IV -after- the EAPOL frame, and it will get
> dropped. Then you get your session dropped. :-)
That's a tricky one. (I didn't think about encryption.) Queue only
maintains the order of packets. It doesn't mean packets are processed
in order. If packets need to be processed in order, should be done
while the lock is held. I think this should do the trick.
lock();
dequeue_working_queue();/* or driver_queue */
if (IEEE80211_FC1_WEP)
ieee80211_crypto_encap();
pass_to_hardware();
unlock();
>
> ic_raw_xmit() is also an ic method, not a vap method. Yes, it bypasses
> the vap queue.
the same as bpf injection part
>
> There's deferred transmission going on (eg ath_start() getting called
> from TX completion, as an example.) Should that be called under the
> above lock() in your example?
Yes. With encryption stuff, if_start or if_transmission will look like this.
if_start/_transmit()
{
for () {
lock();
dequeue_driver_queue();
enqueue_working_queue();
unlock();
...
process
...
Re: [RFT] net80211 TX serialisation, take #4
> --
>
> Message: 12
> Date: Fri, 22 Feb 2013 17:18:44 -0800
> From: Adrian Chadd
> To: freebsd-wireless@freebsd.org
> Subject: Re: [RFT] net80211 TX serialisation, take #4
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 22 February 2013 15:25, Adrian Chadd wrote:
>
> So, this is all pretty terrible. The only sane solution for now is to
> make my VAP TX lock an IC TX lock,and grab said IC TX lock for all
> VAPs. That way the driver can grab the IC TX lock when it's doing
> deferred sends and it'll be sure the lock is held when it decides to
> grab/increment sequence numbers from ni->ni_txseqs[].
I don't think
lock();
ni->ni_txseqs[]++;
unlock();
can fix the problem because no one can guarantee which process/thread
grabs the lock next.
i.e. concurrently, without lock,
- Thread A is processing packet seq#1
- Thread B is processing packet seq#2
When the time to do ni_txseqs[]++, how can we guarantee thread A grabs
the lock before thread B? In other word, if thread A always grabs the
lock first, we don't need to serialize the Tx, do we?
> * .. and do this without tearing my hair out.
The sequence will be messed up during moving packets from one queue to
another, i.e from driver queue to hardware queue. As long as packets
are in a queue (in a linked list) sequence won't change unless we
explicitly write such code. So...
Saving your hair option 1
tx()
{
for() {
lock();
dequeue(m);/* assuming queue is in order */
ni_txseqs[]++
enqueue_working_queue(m);
unlock();
...
process m
...
lock();
/*
* m may change here.
* Whichever the thread does dequeues, m0 will be
* the head of the queue, so sequence will be kept intact.
* But, need to test if processing of m0 has been completed.
*/
dequeue_working_queue(m0);
enqueue_driver_queue(m0); /* or hardware_queue() */
unlock();
}
}
This will keep sequence intact.
Saving your hair option 2
Shave your head until you fix the problem. Hair will grow again, you
know. No bad hair day is a bonus.
AK
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: kern/176201: [net80211] [patch] 11n station includes unrelated ht params into ASSOC_REQ packet
On Fri, Feb 22, 2013 at 12:05 PM, Bernhard Schmidt wrote: > On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote: >> Hm, it's possible in my sleep deprived state that I'm on the right but >> wrong track here. >> >> The OP problem is that we're not advertising the right capabilities >> when we associate, right? > > Correct. I didn't patch it right, but all of us agree on sta isn't sending correct param at association. With current code, sta sends back whatever it has received in probe resp packet. > >> Why aren't we just advertising the VAP ampdumax and ampdudensity no >> matter what the operating mode? Why are we capping those parameters to >> the learnt-from-AP parameters? > > Because the AP would otherwise deny the association request. Should ap only allow node which caps match ap's to associate? (By the way, can anyone point me to the code does denial? I couldn't find it.) AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: negotiating HT params at assoc in sta mode
On Wed, Feb 20, 2013 at 9:40 PM, Adrian Chadd wrote: > On 20 February 2013 20:38, PseudoCylon wrote: > >>> Who can we rope in to review whether this is being done "right" ? >> >> Since it is ht param issue, anyone with 11n capable hardware with >> working driver, or anyone with an AP which can tell Tx'd ampdu packets >> are smaller than what the station has asked for. >> >> run(4) still generates lots of Rx errors. I cannot tell if the patch >> does any good. I can only tell the AP does receive the driver defined >> ht param, now. > > When doing aggregation? Try upping the ampdu density to something like > 8 or 16 microseconds, maybe it needs more spacing between frames. > > What are you using as a transmitter in your run(4) tests? Currently, using my ISP supplied modem/router. I cannot set those param by hand on the ap. At least, the sta requests 16ms spacing, but no improvements. I'll be comparing with linux driver, and see what the differences are. I've got a good idea on registers and descriptors. But, most of bbps are still mystery. Maybe, blindly copy & past their value. (Hope I have a datasheet.) AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: negotiating HT params at assoc in sta mode
On Wed, Feb 20, 2013 at 4:52 PM, Adrian Chadd wrote: > On 15 February 2013 21:18, Adrian Chadd wrote: >> Oh lordie. :-) >> >> Please file a PR so we don't forget to fix this? :) > > Ok, you filed a PR with a patch. > > Who can we rope in to review whether this is being done "right" ? Since it is ht param issue, anyone with 11n capable hardware with working driver, or anyone with an AP which can tell Tx'd ampdu packets are smaller than what the station has asked for. run(4) still generates lots of Rx errors. I cannot tell if the patch does any good. I can only tell the AP does receive the driver defined ht param, now. AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: negotiating HT params at assoc in sta mode
On Fri, Feb 15, 2013 at 8:54 PM, Adrian Chadd wrote: > On 15 February 2013 18:21, PseudoCylon wrote: >> On Fri, Feb 15, 2013 at 6:20 PM, Adrian Chadd wrote: >>> Hm, that sounds right, what's the code doing wrong? >> >> Currently, it seems the sta sends back ht params the ap included in a >> PROBE_RESP packet. So, the ap could send ampdu packets bigger (in >> byte) than the sta can handle or packet gaps are different from the >> sta wants after ba session is created. (During ba session negotiation, >> these params are not exchanged, only window sizes (frame count), seq >> #, and token.) > > Right. yes, we should be negotiating the ampdu density to be the > maximum of what the AP and STA can associate. > > Same deal with IBSS peers (and mesh peers too, eventually.) Yes. But because of this test http://fxr.watson.org/fxr/source/net80211/ieee80211_ht.c#L2649 only nodes in sta mode are affected. AK > > > > Adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: negotiating HT params at assoc in sta mode
On Fri, Feb 15, 2013 at 6:20 PM, Adrian Chadd wrote:
> Hm, that sounds right, what's the code doing wrong?
Currently, it seems the sta sends back ht params the ap included in a
PROBE_RESP packet. So, the ap could send ampdu packets bigger (in
byte) than the sta can handle or packet gaps are different from the
sta wants after ba session is created. (During ba session negotiation,
these params are not exchanged, only window sizes (frame count), seq
#, and token.)
AK
>
>
>
> Adrian
>
>
> On 15 February 2013 17:09, PseudoCylon wrote:
>> http://fxr.watson.org/fxr/source/net80211/ieee80211_ht.c?#L2656
>> Shouldn't a sta include iv_ampdu_rxmax and iv_ampdu_density instead
>> when associating?
>>
>> 1) A driver initiates iv_ampdu_rxmax and iv_ampdu_density based on h/w
>> capabilities.
>>
>> 2) When a sta trying to associate,
>> ieee80211_send_mgmt()
>> {
>> case IEEE80211_FC0_SUBTYPE_ASSOC_REQ:
>> ieee80211_add_htcap();/* the function in question */
>> }
>>
>> 3) When an ap receives the assoc_req packet, the ap will save ht
>> params to ni_htparam. Then the ap will use those values for Tx
>> packets.
>>
>> 4) The sta will receive packets which size is within the limits if the
>> sta included iv_ampdu_rxmax and iv_ampdu_density.
>>
>>
>> AK
>> ___
>> freebsd-wireless@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: [RFC] serialising net80211 TX
On Fri, Feb 15, 2013 at 4:03 PM, Adrian Chadd wrote: > The (many) problems include the two TX paths - one is via _start / > _transmit, and one is the raw xmit path. > > So in the short term it'll be easier (!) to just wrap all TX entry > points with a VAP TX lock. > Once that's done and we've debugged it, we can look at breaking it > into a queue with a taskqueue thread for deferred transmit. > > How's that sound? I think that's good because if_start/transmit == data packet && if_raw_xmit == mgmt packet is no longer true. http://svnweb.freebsd.org/base?view=revision&revision=222682 And, all-in-one Tx path works with run(4) at least. AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
negotiating HT params at assoc in sta mode
http://fxr.watson.org/fxr/source/net80211/ieee80211_ht.c?#L2656
Shouldn't a sta include iv_ampdu_rxmax and iv_ampdu_density instead
when associating?
1) A driver initiates iv_ampdu_rxmax and iv_ampdu_density based on h/w
capabilities.
2) When a sta trying to associate,
ieee80211_send_mgmt()
{
case IEEE80211_FC0_SUBTYPE_ASSOC_REQ:
ieee80211_add_htcap();/* the function in question */
}
3) When an ap receives the assoc_req packet, the ap will save ht
params to ni_htparam. Then the ap will use those values for Tx
packets.
4) The sta will receive packets which size is within the limits if the
sta included iv_ampdu_rxmax and iv_ampdu_density.
AK
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: [RFC] serialising net80211 TX
> -- > > Message: 2 > Date: Wed, 13 Feb 2013 21:14:53 -0800 > From: Adrian Chadd > To: freebsd-wireless@freebsd.org > Subject: [RFC] serialising net80211 TX > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I'd like to work on the net80211 TX serialisation now. I'll worry > about driver serialisation and if_transmit methods later. > > The 30 second version - it happens in parallel, which means preemption > and multi-core devices can and will hit lots of subtle and > hard-to-debug races in the TX path. > > We actually need an end-to-end serialisation method - not only for the > 802.11 state (sequence number, correct aggregation handling, etc) but > to line up 802.11 sequence number allocation with the encryption IV/PN > values. Otherwise you end up with lots of crazy subtle out of order > packets occuring. The other is the seqno/CCMP IV race between the raw > transmit path and the normal transmit path. There are other nagging > issues that I'm trying to resolve - but, one thing at a time. > > So there are three current contenders: > > * wrap everything in net80211 TX in a per-vap TX lock; grab it at the > beginning of ieee80211_output() and ieee80211_start(), and don't > release it until the frame is queued to something (a power save queue, > an age queue, the driver.) That guarantees that the driver is called > in lock-step with each frame being processed. Long held locks could be worse. While another thread holding a lock, when one thread try to grab a lock, it will spin a bit then be suspended. This could be more expensive than context switching by the scheduler. If a thread hold a lock longer, there will be more chance this to happen. > * do deferred transmit- ie, the net80211 entry points simply queue > mbufs to a queue, and a taskqueue runs over the ifnet queue and runs > those frames in-order. There's no need for a lock here as there's only > one sending context (either per-VAP or per-IC). I tried taskqueue on run(4), changed it from 1) to 2). Queue with shared thaskqueue, i.e taskqueue_thread, didn't work good, but with own taskqueue works good (60mbp->70+mbp). The catch is I only tested on core2 duo and dual core + ht atom. I saw you patched ath(4) to use taskqueue. How is it working? There are threads other than Tx thread are running on a system, so context switching will happen one way or other. We want to do it smart way, i.e. rather than changing thread on every tx, switch on multiple tx. Currently, tx threads are kept alive until packets are passed to h/w. Instead, if we kill them right after queuing a frame to if_snd and let one thread (would be new ieee80211_tx thread) handle all the packets, there will be fewer threads, so should be less context switching. Anyhow, I don't think we need to queue/dequeue twice, one on vap->iv_ifp->if_snd and one on ic->ic_ifp->if_snd. AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: freebsd-wireless Digest, Vol 87, Issue 2
> Message: 5 > Date: Tue, 12 Feb 2013 14:57:17 +0400 > From: N V > To: "freebsd-wireless@freebsd.org" > Subject: D-Link DWA-140 Rev. B3 > Message-ID: <180661360666...@web7f.yandex.ru> > Content-Type: text/plain > > Hi. > > I have got D-Link DWA-140 Rev. B3. > The problem: it's not even recognised by the system. > > Diag info: > > # uname -a > FreeBSD sf1.local 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 > 09:23:10 UTC 2012 > r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > # dmesg > ... > ugen2.2: at usbus2 > ... > > nothing else in dmesg. > > # usbconfig -d 2.2 dump_device_desc > ugen2.2: <11n Adapter D-Link> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=ON > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x > bDeviceSubClass = 0x > bDeviceProtocol = 0x > bMaxPacketSize0 = 0x0040 > idVendor = 0x2001 > idProduct = 0x3c15 That is a RT5372 chipset, and it is currently not supported by any of FreeBSD drivers. AK > bcdDevice = 0x0101 > iManufacturer = 0x0001 > iProduct = 0x0002 <11n Adapter> > iSerialNumber = 0x0003 <1.0> > bNumConfigurations = 0x0001 > > I've tried preloading runfw vie loader.conf - no result. > I've tried 9.1-RELEASE i386 also - no result. > > Googling on the internet gave me the idea this device is based on RT2870. > > Regards, > Vans. > > > -- > ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Ralink RT2860 Driver - Block ACK's
> Message: 1 > Date: Thu, 24 Jan 2013 13:31:40 -0500 > From: Ramanujan Seshadri > To: freebsd-wireless@freebsd.org > Subject: Ralink RT2860 Driver - Block ACK's > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > I am trying to read the contents of block ack's in a Ralink RT2860 driver. > Can you please help me to know which function i should be looking into ? http://lists.freebsd.org/pipermail/freebsd-net/2013-January/034432.html Doesn't work? AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: if_transmit() and the quirky issues with node referencing
> -- > > Message: 3 > Date: Thu, 27 Dec 2012 22:24:33 -0800 > From: Adrian Chadd > To: Monthadar Al Jaberi , Bernhard Schmidt > , freebsd-wireless@freebsd.org > Subject: .. if_transmit() and the quirky issues with node referencing > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > So I finally figured out my problem with if_transmit()'ifying the > ath(4) code. (Yes, this means I have TX fragmentation working with > ath(4), as well as some non-trivial performance improvements in TX TCP > tests.) > > In quick summary: net80211's call to the driver will decrement the > node ref if the driver if_transmit() call fails. > > So I went looking for instances of where if_transmit() is called > without correct error checking. > > One is in ieee80211_hwmp.c . It pops frames off of the ageq and calls > if_transmit(). It should deref the node ref the same way that the ageq > code does. > > The other is in ieee80211_hostap.c - my fault. It uses the psq; I > should deref the node ref the same way that the psq code does. > > This just highlights some of the rather quirky corners of net80211: > > * if_transmit() can be called on the driver facing interface (ie, the > driver ifp) or the vap ifp. > * for driver ifp, the frame should be encapsulated and there must be a > node reference held/given when it's called. If if_transmit() fails > here, it must deref the node. > * for non-encapsulated frames (eg perhaps some stuff in the ageq or > one of the psqs), if_transmit() will be called on the VAP interface. > * .. now, when if_transmit() is called on the vap interface, the mbuf > m_pkthdr.recvif will point to the vap ifp; > * .. when if_transmit() is called on the physical interface, the mbuf > m_pkthdr.recvif will point to the node reference. > > This is all a bit kooky and very prone to people making mistakes, > especially when mbufs may be pushed up, down and throughout all kinds > of weird places. I also bet the re-entrant parts of the codebase (ie > stuff that uses the ageq, psq, wds .. maybe the mesh stuff) could do > with a bit of a re-review. > > In any case, what this means is: > > * we need to be really, really careful with how we route mbufs through > net80211 here, aiee! > * if a frame has M_ENCAP tagged and it's pushed into an ageq or psq, > it _must_ have the TX node ref held; > .. thus, if we raw construct an encapsulated frame (locally in > net80211, or in a driver, or via ieee80211_output, etc) then when we > set M_ENCAP, we must hold the TX node reference and we must set recvif > correctly! > > What I'd really like to do here: > > * re-review all the if_transmit() error handling - make sure that if > it fails, we correctly handle dereferencing the node or things will > leak; > * make "get/set recvif from ifp" and "get/set recvif from node" as methods; > * have those methods check whether M_ENCAP is correctly set/cleared, > and complain loudly if we ever try to get the wrong reference for the > given situation (eg, if we try to read the node reference from an > mbuf, but M_ENCAP isn't set, then complain); > * .. figure out some alternate way to store the node reference (mbuf > tags?) and start migrating the code that way. > Just to add another thing before I forget. When tearing a ba session is somehow failed, a node could still receive ampdu packets from another node which ni has already freed. I don't know exactly how that happens, yet. I will let you know when I figured it out. AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: 11n in adhoc mode
> -- > > Message: 1 > Date: Tue, 11 Dec 2012 01:19:51 -0800 > From: Adrian Chadd > To: Johann Hugo > Cc: freebsd-wireless@freebsd.org > Subject: Re: 11n in adhoc mode > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > .. so now I have 11n IBSS working, but the performance is pretty > shocking. I bet there's some timers that are just not programmed > correctly. > I see massive numbers of long retries and CRC errors. Are protection modes set correctly on both ends? This happens when each end uses different prot mode. > * Then some ancillary stuff - mostly processing beacon frames from > peers and handling HT IE changes correctly. Because this is an adhoc mode issue, this may not apply. But, this is what I have been seeing. Yet another ancillary stuff. Currently, protection mode is updated though ieee80211_htprot_update() (finally iv_update_beacon() is called), and it is called only in hostap mode. When occupancy changes, an ap updates beacon and tells driver to updated the prot mode. Even though, other ends receives updated beacon, ieee80211 stack doesn't tell driver to update the mode (other than in ap mode). As the result, those nics run on different prot modes. When operating with mismatched mode, retry and crc error counts skyrocket. I think we need to add ic_update_prot(). AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: Wireless Ralink Adapter is detected but doesn't work
> -- > > Message: 5 > Date: Fri, 23 Nov 2012 17:21:30 +0300 > From: Nikolay Tychina > To: freebsd-wireless@freebsd.org > Subject: Wireless Ralink Adapter is detected but doesn't work > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi! > > I got TP-LINK TL-W727N adapter with a Ralink chipset, added > > product RALINK RT5370 0x5370 RT5370 // to usbdevs > RUN_DEV(RALINK, RT5370), // to if_run.c RT5370 has not been supported, yet. AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: request for help: 'fixing' the 802.11 TX path
On Mon, Oct 29, 2012 at 3:47 AM, Andre Oppermann wrote:
> On 29.10.2012 04:53, Adrian Chadd wrote:
>>
>> On 28 October 2012 20:43, PseudoCylon wrote:
>>
>>> Cannot we just add custom hand off function to ieee80211_start()?
>>
>>
>> Yes. That's the general idea. But what I don't want to do is have it
>> just wake up the driver TX taskqueue - well, unless we have to.
>>
>> That means we'll have two context switches for each frame being
>> transmitted and that as a concept just sucks.
Plan B
vap->iv_ifp->if_transmit = ieee80211_transmit;
ieee80211_transmit() /* new */
{
/* Alternatively, we can make a list of param and attach mbuf to it. */
HANDOFF(parent->if_snd, m);
ieee80211_new_tx(vap, m);
}
/* enque packet, but keep working on the same mbuf */
ieee80211_new_tx(vap, m)
{
encap;
if (fragment)
insert_fragmented_packet_to_queue;
/* don't forget about a fragmented packet */
for (; m->m_nextpkt != NULL; m = m->m_nextpkt)
parent->if_new_tx(vap, m);
}
/* keep working on the same mbuf */
driver_new_tx(vap, m)
{
do_descriptor_stuff;
m->m_flags |= ALL_SET;
/*
* If, for instance, processing of queue #5 packet finished
before queue #1,
* #5 packet will stay in queue until all of preceding packets
get processed.
*/
if (parent->if_sc->sc_tx == NOT_RUNNING &&
ifq_head->m_flags & ALL_SET)
driver_pass2hw(parent);
}
/* finally, process mbuf from the head of queue */
driver_pass2hw()
{
/* only one thread to dequeue */
if (atomic_compset(&sc->sc_tx, NOT_RUNNING, RUNNING) == 0)
return;
for (;;) {
DEQUEUE(ifq, m);
if (!(m->m_flags & ALL_SET)) {
PREPEND();
break;
}
/*
* want to do seq stuff somewhere in ieee80211_*(),
* but I guess this is the only place could do.
*/
do_seqnum_stuff;
/* simply put a packet onto dma-able memory area */
pass2hw;
}
sc->sc_tx = NOT_RUNNING;
}
No additional context switching, no long-held lock, but first queue first tx.
AK
>>
>> See my (very recent) email to -wireless - I broke TCP throughput quite
>> substantially by moving ath(4) TX into the taskqueue. I thought the
>> problem was _just_ going to be how overlapping, direct dispatch TX
>> could be preempted by the RX tasklet and TX completion, but there's
>> obviously more going on.
>
>
> I can't believe that TCP is getting broken by just introducing some
> additional delay in the TX path. That can't add more than 300ms,
> can it? There must be something else going on. Most likely either
> severe packet loss (the m_nextpkt leak you mentioned earlier) or
> severe packet re-ordering.
>
> So don't rule out the TX taskqueue concept quite yet.
>
> --
> Andre
>
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: request for help: 'fixing' the 802.11 TX path
> --
>
> Message: 1
> Date: Sat, 27 Oct 2012 16:18:11 -0700
> From: Adrian Chadd
> To: freebsd-wireless@freebsd.org
> Cc: FreeBSD Net , freebsd-a...@freebsd.org
> Subject: request for help: 'fixing' the 802.11 TX path
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi all,
>
> I'd like to try and sort out the last remaining niggles in the 802.11
> code - this email is focusing on the TX path.
>
> The TX path has a few problems:
>
> * there's a normal versus raw TX path (for raw frames, management
> frames, etc) - the raw path doesn't necessarily queue frames into the
> raw TX queue, so it's a kind of "side path" to the driver. This causes
> frame ordering problems with things like sequence number allocation.
> * there's limited locking in the TX path, primarily because you can't
> _really_ fine grain lock the TX path. Since you have multiple TX
> thread contexts all sending into the same driver queue and that queue
> has to share incrementing sequence number, aggregate status and CCMP
> encryption replay counters, you _have_ to either use some long-held
> mutexes to enforce this _or_ throw all sending into a TX thread and
> run that.
> * raw TX requires some extra state to be glued (the bpf_params info);
> I'd like to glue that into mbufs as an option, so the driver can use
> those instead of interpreting their own 802.11 header contents.
>
> And the one I'd like to discuss here:
>
> * Fragment transmission is totally broken and causes mbufs to be just
> leaked. The problem with sending fragments (at least for the ath
> drivr) is the packet duration calcluation requires the _next_ fragment
> to be available.
>
> Now, this is a design hold-over from the previous, pre-vap scheme. The
> driver netif would be handed a raw mbuf frame, which it would then
> pass through the net80211 encapsulation code and that would
> potentially generate 802.11 fragments. The rest of the driver TX path
> would then see that it was handed a fragment list and TX those.
> Fragments were chained together using m_nextpkt, like a normal mbuf
> list.
>
> This doesn't happen any longer. The net80211 vap gets the raw frame,
> which then sends that to the driver netif after doing the vap and
> 802.11 state / encapsulation work. But since all the wifi drivers use
> if_start() right now, m_nextpkt gets blanked on both encap and decap..
> and thus things leak.
>
> Now I can't really see a way around this, without doing dirty hacks
> with mbuf attributes to link the fragments together. The only clean
> way I can see is to force all wifi drivers to use if_transmit(), and
> then have if_transmit() interpret a chain of frames as "the fragment
> list."
Cannot we just add custom hand off function to ieee80211_start()?
ieee80211_start()
{
encap;
IF_LOCK(parent->if_snd);
do_seqnum_stuff;
/* We can also queue mgt packets to the same queue */
for (m0 = m; m0->m_nextpkt != NULL; m0 = m0->m_nextpkt);
ifq_tail = m0;
IF_UNLOCK();
taskqueue_enqueue(taskqueue, parent->if_new_tx_function); /*
or wake(); */
}
Because of IF_LOCK, queued packets and seq num should be in order.
Then, the driver only need to dequeue and Tx. The drivers can tell if
the packet is a fragmented packet or a standalone packet from
ieee80211 header or we can add a new member to bpf_params.
AK
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: [RFC] How the TX path works; I'd like to fix this before 10.x
On Sat, Oct 6, 2012 at 3:00 PM, Adrian Chadd wrote:
> Well, i would like to implement if_transmit for net80211 tx, then have the
> tx routine queue the frame and wakeup the tx taskqueue or tasklet. Im not
> sure yet whether to put the tx processing in the existing ic taskqueue or
> not, but since the current tx path runs separate to the ic taskqueue, the
> hard work is already done for us.
If we forget about hooking ieee80211_output() and leave
ether_ifattach() default hooks
http://fxr.watson.org/fxr/source/net80211/ieee80211.c#L548
if_transmit will be called with packets encaped in ethernet header.
Then, in a will-be-added ieee80211_transmit(), call ieee80211_encap(),
IFQ_HANDOFF(), and call (or enqueue) driver's new tx task. This can be
done by just teaching new tx path aware drivers correct functions to
hook. (So, we don't have to change all wifi drivers.)
>
> In parallel I would like to kill the ieee80211_output and raw xmit code,
> instead doing the encap and such in the tx tasklet.
If all packets, whether data or mgmt, are queued to the same buff
(i.e. if_snd), probably raw_xmit won't be needed. And, somehow attach
txparam to all packets. Then, driver can handle the packets in the
same tx function by using info in txparam. (I think the driver code
will be simpler.)
But, I wonder if waiting for all previously queued packets being
processed causes any trouble for shorter buffer-life packets, i.e.
addba/probe response packets.
AK
>
> We could later allow encap before serialisation but delay seqno and
> encryption. Thats a later thing.
>
> In parallel we do need to fix driver tx. It all has to stay in order... Ie
> the order that the tx tasklet does encap must reflect the driver setup. Or,
> we push seqno allocation to each driver. Ew.
>
> Adrian
>
> On Oct 6, 2012 3:01 PM, "PseudoCylon" wrote:
>>
>> > --
>> >
>> > Message: 4
>> > Date: Fri, 5 Oct 2012 23:44:10 -0700
>> > From: Adrian Chadd
>> > Subject: [RFC] How the TX path works; I'd like to fix this before 10.x
>> > To: freebsd-wireless@freebsd.org
>> > Message-ID:
>> >
>> >
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Before I continue - if_transmit() is not the answer. if_transmit()
>> > guarantess _no_ serialisation at all. So we'd stlil have to stuff
>> > things into queues. And ensure only one thing is running at once.
>>
>> As far as I know, if_transmit/if_start are options for drivers, not
>> for the serialisation.
>> if_transmit to use device specific queue
>> if_start to use if_snd queue
>> i.e.
>> http://fxr.watson.org/fxr/source/dev/e1000/if_em.c#L2941
>>
>> >
>> > I could wrap a big VAP TX lock around ieee80211_output() and
>> > ieee80211_start(), ensuring they don't run over each other. But
>> > long-held locks need to go away and die. yes, even the ones in the
>> > ath(4) driver that I've introduced. They're there because of a lack of
>> > synchronisation and queue design. A lot of the gige/10ge drivers use
>> > long-held locks.. sigh.
>> >
>> > I could create a net80211 TX tasklet for each vap (or ic, _maybe_)
>> > which serialises the TX path. ieee80211_start() would just schedule
>> > the tasklet to run. That would serialise all of the parallel TX entry
>> > points and solve a bunch of the subtle sequence number and other TX
>> > state races that are occuring. That doesn't solve the ic_raw_xmit() or
>> > ieee80211_output() problem, as both of those can also do TX 802.11
>> > encapsulation and kick off parts of the state machine.
>>
>> I prefer taskqueue over new lock. I have had enough of LORs already.
>>
>> We just need to decide where/how to funnel all tx entries.
>> Currently,
>> pseudo devices (i.e. if_bridge) \
>> IP stack --> ieee80211 stack -->
>> driver
>>ic_raw_xmit
>> /
>> so we need to ensure serialization (by lock or taskqueue) at 2 points,
>> 1) between upper layer and ieee80211,
>> 2) driver and ieee80211.
>> If we solve the raw_xmit problem, there will be only 1 point to take care.
>>
>>
>> An idea
>> Guarantee only one thread is running at any moment. So, first queued
>> first dequeued and tx'd without a lock.
>>
>> if_start() {
>> if (sc_task == NOT_RUNNING)
>> wakeup(sc_txtask);
>> }
>>
>> if_txtask() {
>> for (;sc_txtask_exit != DONE;
Re: [RFC] How the TX path works; I'd like to fix this before 10.x
> --
>
> Message: 4
> Date: Fri, 5 Oct 2012 23:44:10 -0700
> From: Adrian Chadd
> Subject: [RFC] How the TX path works; I'd like to fix this before 10.x
> To: freebsd-wireless@freebsd.org
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Before I continue - if_transmit() is not the answer. if_transmit()
> guarantess _no_ serialisation at all. So we'd stlil have to stuff
> things into queues. And ensure only one thing is running at once.
As far as I know, if_transmit/if_start are options for drivers, not
for the serialisation.
if_transmit to use device specific queue
if_start to use if_snd queue
i.e.
http://fxr.watson.org/fxr/source/dev/e1000/if_em.c#L2941
>
> I could wrap a big VAP TX lock around ieee80211_output() and
> ieee80211_start(), ensuring they don't run over each other. But
> long-held locks need to go away and die. yes, even the ones in the
> ath(4) driver that I've introduced. They're there because of a lack of
> synchronisation and queue design. A lot of the gige/10ge drivers use
> long-held locks.. sigh.
>
> I could create a net80211 TX tasklet for each vap (or ic, _maybe_)
> which serialises the TX path. ieee80211_start() would just schedule
> the tasklet to run. That would serialise all of the parallel TX entry
> points and solve a bunch of the subtle sequence number and other TX
> state races that are occuring. That doesn't solve the ic_raw_xmit() or
> ieee80211_output() problem, as both of those can also do TX 802.11
> encapsulation and kick off parts of the state machine.
I prefer taskqueue over new lock. I have had enough of LORs already.
We just need to decide where/how to funnel all tx entries.
Currently,
pseudo devices (i.e. if_bridge) \
IP stack --> ieee80211 stack --> driver
ic_raw_xmit /
so we need to ensure serialization (by lock or taskqueue) at 2 points,
1) between upper layer and ieee80211,
2) driver and ieee80211.
If we solve the raw_xmit problem, there will be only 1 point to take care.
An idea
Guarantee only one thread is running at any moment. So, first queued
first dequeued and tx'd without a lock.
if_start() {
if (sc_task == NOT_RUNNING)
wakeup(sc_txtask);
}
if_txtask() {
for (;sc_txtask_exit != DONE;) {
IFQ_DRV_DEQUEUE();
if (m == NULL) {
sc_txtask = NOT_RUNNING;
tsleep();
sc_txtask = RUNNING;
} else
tx();
}
}
tx_callback() {
...
if (sc_task == NOT_RUNNING)
wakeup(sc_txtask);
}
iv_vap_create() {
...
taskqueue_enqueue(sc_taskqueue);
}
iv_vap_delete() {
...
sc_txtask_exit = DONE;
if (sc_task == NOT_RUNNING)
wakeup(sc_txtask);
}
>
> It doesn't solve the same issues with the drivers .Yes, even if we
> converted them to use if_transmit(). iwn(4) solves this by just having
> a big IWN_LOCK() but it releases it when doing anything stack related.
> I'm not sure if it holds it across the whole TX path through
> iwn_start(). In any case, it's a big lock. ath(4) can and does have
> multiple ath_start() instances running in multiple kernel threads,
> fighting to dequeue frames from the ifnet. This still can cause issues
> with non-aggregate sequence number and CCMP IV counter allocation.
> Sigh.
>
> God even knows what to do about USB devices in all of this.
>
Similar to other drivers, i.e. iwn(4). The difference is USB drivers
create per-USB-pipe queue in addition to if_snd queue. So that, tx
path look like
if_transmit -> queue -> if_start -> dequeue -> driver_tx -> usb_queue
-> usb_stack
It seems redundant. I'd like to change that to (for run(4))
if_transmit -> driver_tx -> usb_queue -> usb_stack
AK
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: ath0_node_lock ath0_com_lock lor
> -- > > Message: 1 > Date: Thu, 27 Sep 2012 12:44:04 -0700 > From: Adrian Chadd > Subject: Re: ath0_node_lock ath0_com_lock lor > To: Kim Culhan > Cc: freebsd-wireless@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hm, that's odd. Who wants to go digging to figure out which code paths > are causing this? :) > A suggestion in setmlme_dropsta() http://fxr.watson.org/fxr/source/net80211/ieee80211_ioctl.c#L1331 Just forget about node lock and call ieee80211_find_node() instead of ieee80211_find_node_locked(). (I believe this lor occurs only in AP mode.) AK PS This lor is already documented in wifi debug wiki. > > > On 26 September 2012 12:49, Kim Culhan wrote: >> Have not seen an lor in some time, this noted today fyi >> >> lock order reversal: >> 1st 0xff80009267f0 ath0_node_lock (ath0_node_lock) @ >> /usr/src/sys/net80211/ieee80211_ioctl.c:1341 >> 2nd 0xff8000925018 ath0_com_lock (ath0_com_lock) @ >> /usr/src/sys/net80211/ieee80211_node.c:2619 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b >> kdb_backtrace() at kdb_backtrace+0x39 >> witness_checkorder() at witness_checkorder+0xc37 >> _mtx_lock_flags() at _mtx_lock_flags+0x83 >> ieee80211_node_leave() at ieee80211_node_leave+0x97 >> setmlme_common() at setmlme_common+0x3f7 >> ieee80211_ioctl_setmlme() at ieee80211_ioctl_setmlme+0x87 >> ieee80211_ioctl_set80211() at ieee80211_ioctl_set80211+0x5a5 >> in_control() at in_control+0x216 >> ifioctl() at ifioctl+0x1020 >> kern_ioctl() at kern_ioctl+0x1b0 >> sys_ioctl() at sys_ioctl+0x11f >> amd64_syscall() at amd64_syscall+0x25a >> Xfast_syscall() at Xfast_syscall+0xfb >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x801203b8a, rsp = >> 0x7fffd9b8, rbp = 0x7fffda20 --- >> >> >> -- >> thanks >> -kim ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: native USB 802.11n adapter w/ external SMA jacks?
> -- > > Message: 3 > Date: Sun, 2 Sep 2012 20:39:46 +0200 > From: Juergen Lock > Subject: Re: native USB 802.11n adapter w/ external SMA jacks? > To: Adrian Chadd > Cc: John-Mark Gurney , freebsd-wireless@freebsd.org > Message-ID: <20120902183946.ga88...@triton8.kn-bremen.de> > Content-Type: text/plain; charset=us-ascii > > On Sun, Sep 02, 2012 at 11:15:09AM -0700, Adrian Chadd wrote: >> Hi, >> >> On 2 September 2012 11:12, John-Mark Gurney wrote: >> > Hello, >> > >> > Please cc me as I'm not subscribed to -wireless. >> > >> > I'm looking for a 802.11n USB adapter that is supported on ARM w/ external >> > SMA jacks. I plan to use this w/ a BeagleBone so clearly ndis drivers >> > will not work. >> > >> > I see plenty of adapters are available, but as usual, they don't list >> > which chipset they are based upon, making the decission hard. >> > >> > I'm looking at 802.11n more for future support, so even just a 802.11bg >> > device would be fine. >> >> I'm not currently aware of any USB wifi devices that are like that. >> >> I'd suggest first canvassing ebay/google/amazon for some candidates? > > I don't know about arm but I have here "LogiLink WL0054" which is > driven by if_run(4) and comes with an external antenna that's screwed > on, the connector looks smaller than what I see on > > https://en.wikipedia.org/wiki/SMA_connector > > but maybe there are adapters? Even with just that screwed-on antenna > the range is definitely better than with other usb wifi dongles that > have their antenna built in... And it works in hostap mode too, > tho I haven't tried 11n myself yet, only g. If you are brave, you can try https://gitorious.org/run/run/trees/11n_rc3 Because of dead locks, it blindly unlocks some locks. I don't know what kind of trouble it may cause. AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: native USB 802.11n adapter w/ external SMA jacks?
> -- > > Message: 5 > Date: Mon, 3 Sep 2012 00:14:25 -0700 > From: John-Mark Gurney > Subject: Re: native USB 802.11n adapter w/ external SMA jacks? > To: Adrian Chadd > Cc: freebsd-wireless@freebsd.org > Message-ID: <20120903071425.gj58...@funkthat.com> > Content-Type: text/plain; charset=us-ascii > > Adrian Chadd wrote this message on Sun, Sep 02, 2012 at 11:15 -0700: >> On 2 September 2012 11:12, John-Mark Gurney wrote: >> > Hello, >> > >> > Please cc me as I'm not subscribed to -wireless. >> > >> > I'm looking for a 802.11n USB adapter that is supported on ARM w/ external >> > SMA jacks. I plan to use this w/ a BeagleBone so clearly ndis drivers >> > will not work. >> > >> > I see plenty of adapters are available, but as usual, they don't list >> > which chipset they are based upon, making the decission hard. >> > >> > I'm looking at 802.11n more for future support, so even just a 802.11bg >> > device would be fine. >> >> I'm not currently aware of any USB wifi devices that are like that. >> >> I'd suggest first canvassing ebay/google/amazon for some candidates? > > As I said earlier, I've found a number of devices that do have the > connector, but the problem is that trying to figure out which driver > they use is a bit difficult... It looks like the Hawking HWUN1 (run) > would work, but it's no longer sold.. > > I also noticed that many of the USB drivers are listed as supporting > only one virtual interface at a time, though run doesn't list that > limitation... Does run support multiple wlan networks at once? Not really/yet. The device could support up to 8 vaps. (I have found there is memory for 8 beacons and 8 shared keys, but I haven't found out how to make h/w use it.) AK ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
