Re: [ath5k-devel] Rookie needs helps with ath5k basics
Hi, right. The default NIC EEPROM setup doesn't include those channels because they haven't tested them out. If you have an 802.11p regulatory compliant NIC then it should have the 11p frequencies show up in the EEPROM channel range. So you should definitely first check that the NIC EEPROM has those as available channels. :) -adrian On 7 November 2014 07:04, Bruno Randolf b...@einfach.org wrote: Hi, I don't remember all the details but there are various places which can limit the available channels in ath5k. Check ath5k_is_standard_channel() ath5k_setup_channels() ath5k_setup_bands() in drivers/net/wireless/ath/ath5k/base.c Good luck! bruno On 11/07/2014 02:27 PM, Sergey Ryazanov wrote: Cc linux-wireless since Rostislav Lisovy just working on adding 802.11p to the stack. 2014-11-07 16:49 GMT+03:00 Hernán Maximiliano González Calderón hernan.gonzalez.calde...@gmail.com: Hello everyone, I am still working to adapt the ath5k module to transmit in the 5850..5925GHz range, in order to comply with IEEE 802.11p requirements. Our plan is to liberate the code to the community as soon as we develop it. I have already compiled a new regdomains database with wireless-regdb and crda, and we are using the module in ATH5K_TEST_CHANNELS mode. The database is now defined as follows: (2402 - 2472 @ 40), (3, 27) (5170 - 5250 @ 40), (3, 17) (5250 - 5330 @ 40), (3, 20) (5490 - 5600 @ 40), (3, 20) (5650 - 5710 @ 40), (3, 20) (5735 - 5835 @ 40), (3, 30) (5835 - 5925 @ 10), (3, 30) However, when I execute iw wlan1 ibss join TFG 5850 it returns the -22 error number, indicating that we are using a frequency not defined. 2014-02-19 17:22 GMT+01:00 Hernán Maximiliano González Calderón hernan.gonzalez.calde...@gmail.com: Thanks for the quick reply and sorry for not giving an answer until now, but first I had to talk with my project advisor. The reason we chose ath5k was that the cards we bought used it and all information we gather about this kind of projects were related to that driver. I also have talked with my advisor and whatever we accomplish will come back to the community. I am just starting with the project and I am needing some guides, the tips and info you all gave me will be very helpful. I will keep on working and will tell you if I get something done. Thanks a lot, Hernán M. G. C. 2014-02-18 2:03 GMT+01:00 Adrian Chadd adr...@freebsd.org: ... because some of the 802.11p NICs are actually ath5k NICs that have the relevant bandpass filters for 5.9GHz and high output amplifiers. -a On 17 February 2014 01:27, Holger Schurig holgerschu...@gmail.com wrote: Okay, I admit that I cannot help you, I have no clue on the driver level. But maybe I can help with the methodology. :-) You mention 802.11p (car-to-car-communication). Is there any specific reason you base it on ath5k and not on ath9k? If you look at the number of commits, then you should see that ath9k is much more lively. People are actively working with that code and might be able to be answer more specific questions. Another thing that I noted: I have seen over the years many requests of information from uni projects in this mailing list. But I'm quite unsure if ever something came back into the Linux kernel. How do you plan to tackle that? I have the feeling that people are more likely to cooperate if the work doesn't end up in yet another black hole ... And one tip: ask specific questions, not broad ones. For example, look at what features you need to implement 802.11p. Now look at what OSI level this has to be done, e.g. at hardware level (frequency, bandwidth), driver level, or protocoll layer (mac80211, user-space layer (e.g. wpa_supplicant). That would allow you to ask questions not like Tell me everything, but Oh, I need to do XYZ, where can I do it?. It might even help you in finding your way, e.g. by looking into git commits inside the ath/ath9k subdirectories that might have something to do with what you need. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k 5GHz Receive Diversity problem
Hi, Does the reported RSSI on both antennas actually match? Or is the non-main antenna RSSI crappy? If you flip the default antenna over (btu not disable diversity) does it still behave this way? -a On 17 July 2014 23:53, brettwri...@eaton.com wrote: Thanks Adrian and Wojtek, There is a bit called AR5K_PHY_AGCCTL_OFDM_DIV_DIS which led me to thinking it should be possible. At least now I can give up and work around it. I still don't fully understand why fast diversity works for CCK (11b) rates with the same length preamble as the OFDM rates. i.e. The radio definitely must be looking at the non-default antenna for those modulations, because it receives them fine - just not OFDM. However, there is a lot I don't understand about this radio ;o) Thanks Brett -Original Message- From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf Of Adrian Chadd Sent: 17 July, 2014 6:13 PM To: Wojciech Dubowik Cc: ath5k-devel@lists.ath5k.org; Wright, Brett Subject: Re: [ath5k-devel] ath5k 5GHz Receive Diversity problem Hi, Right. It takes time for the hardware to figure out the signal level on each antenna - there's a coarse gain change and then a couple of fine gain changes so it can calculate RSSI. If the packet has a short preamble or it picks it up a little too late then yeah, you won't get any fast diversity. -a On 17 July 2014 01:01, Wojciech Dubowik wojciech.dubo...@neratec.com wrote: On 07/17/2014 03:24 AM, brettwri...@eaton.com wrote: Hello List, I am having a problem getting Rx diversity to work with both ar5213 and ar5413. What I have found is that the fast diversity works great for receiving 802.11b (i.e. CCK) modulations. But fast diversity for OFDM just does not seem to work (and yes diversity is turned ON). I am using controlled conditions, i.e. cable and attenuators, and find that basically on the non-default antenna there is effectively 30dB attenuation. This means that to successfully receive an OFDM frame on the non-default antenna the signal has to be 30dBm above the noise floor! Not very useful… Basically Rx diversity for 802.11a 5GHz and pure 802.11g is a no-go. Does anyone know if this should work – or perhaps Rx diversity for OFDM is just a no-go? BTW – I’ve tried this with ath5k/mac80211 as well as madwifi and openhal, as well as the old closed source madwifi hal. They all behave the same way. Adrian – I see you have made some changes to FreeBSD related to this – do you have any idea if this **should** work? Anyone else? AFAIK at least for OFDM the packet has to be seen first on default antenna. Then rx diversity is switching to the other antenna during preamble to check for a better signal. It means that first you have to be on a proper antenna and be able to decode a packet (or at least preamble). You can receive on the other one when you pump the signal 30dB because it's a typical isolation for antenna RF switch on reference designs. In our design it's typically 50dB and then for sure you won't get rx diversity to work if you are on the wrong antenna. That's why I know ;o) Rest is handled in SW i.e. if chipset has chosen alternate antenna three times in a row then switch default to the other one. Could be also based on tx failures. Br, Wojtek Thanks Brett ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k: phy0: failed to wakeup the MAC Chip
I have that model chip somewhere. Resuming works fine in freebsd. Is the MAC/PHY and PCI reset stuff correctly being (re) initialised after resume? What's in AR_SCR, AR_PCICFG, AR_RC ? AR_SCR = 0x4004 AR_PCICFG = 0x4010 AR_RC = 0x4000 -a On 25 March 2014 01:07, Eugene Shatokhin eugene.shatok...@rosalab.ru wrote: Hi, On 01/21/2014 05:48 PM, Nick Kossifidis wrote: Since you have a version that works you could use git bisect to find out the patch that introduced the bug, try to revert it and see what happens. Well, our user that reported the problem first has not responded since I sent him the first kernels needed to bisect the problem. Another our user, however, seems to have a very similar problem: the system cannot wake up the WiFi adapter (Atheros AR2425) after suspend. This time, we could not find a kernel version where it works after resume. The problem shows up with kernels 3.0.x, 3.2.x, 3.10.x, 3.13.x at least. From the system log: - kernel: ath5k :03:00.0: Refused to change power state, currently in D3 ... kernel: ath5k: phy0: failed to wakeup the MAC Chip kernel: ath5k: phy0: can't reset hardware (-5) - lcpci: - 03:00.0 Ethernet controller [0200]: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) [168c:001c] (rev ff) (prog-if ff) - The adapter works fine in MS Windows installed on the same laptop, so, I guess, it is unlikely to be a hardware issue. Any more ideas how could one debug this? The system log also shows more suspicious messages related to that device: kernel: pci :03:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' ... ath5k :03:00.0: can't disable ASPM; OS doesn't have ASPM control Could they be related? Any help is appreciated. Regards, Eugene -- Eugene Shatokhin, ROSA www.rosalab.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Is Message in Message mode supported?
Yes its called ofdm restart. Its enabled on some and disabled on others, depending upon the chipset bugs. Adrian On Feb 8, 2014 11:52 AM, Mathy vanho...@gmail.com wrote: Hi, I encountered two papers [1, 2] which claim that the AR5112 and 5213 support message in message mode. This would allow a receiver to disengage from an ongoing reception, and engage onto a stronger incoming signal. Does anyone know if these chipsets indeed support this? I'm not fully convinced of the experiments/arguments these papers give, and unfortunately I don't have these chipsets to experiment myself. However, when experimenting with an AR7010 and AR9271, I did not observe the message in message mode support. Cheers, Mathy [1] Order Matters: Transmission Reordering in Wireless Networks Justin. http://www.cs.duke.edu/~jgm/files/manweiler09order.pdf [2] An Experimental Study on the Capture Effect in 802.11a Networks. http://mmlab.snu.ac.kr/~jklee/papers/wintech2007.pdf ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Power save support checklist?
Hi, I recall someone (Bob?) had patches for power saving. Where are they? Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
Hi, I've just created AdrianChadd. Please go forth and add me to the relevant bits. :P -a On 26 February 2014 01:50, Nick Kossifidis mickfl...@gmail.com wrote: So will you edit the OPW wiki (http://kernelnewbies.org/OPWIntro) or should I do it ? I've already added a project description for AR5513 support and added me and Adrian as mentors. You can create an account on http://kernelnewbies.org and talk with Sarah to get edit access and invitations to the relevant mailing lists ;-) 2014-02-25 12:24 GMT+00:00 Bob Copeland m...@bobcopeland.com: On Tue, Feb 25, 2014 at 09:23:38AM +, Nick Kossifidis wrote: That should be fun ! Have in mind there is already a driver (STA only) included since 3.8 - http://wireless.kernel.org/en/users/Drivers/ar5523 so probe/attach should be fine. Bob are you still interested in power saving stuff ? Yes, I'm happy to mentor for power saving. -- Bob Copeland %% www.bobcopeland.com -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
sorry, I meant AR5513. :-P And I can help with DFS, but since the spec changed after the 11n chips came out, it's going to be hard to make a spec-compliant DFS implementation for the pre-11n chips. The short pulses and the chirps are the two things these chips have no real chance of handling well.. -a On 25 February 2014 01:23, Nick Kossifidis mickfl...@gmail.com wrote: That should be fun ! Have in mind there is already a driver (STA only) included since 3.8 - http://wireless.kernel.org/en/users/Drivers/ar5523 so probe/attach should be fine. Bob are you still interested in power saving stuff ? Is anyone interested in working on DFS ? 2014-02-25 5:30 GMT+00:00 Adrian Chadd adr...@freebsd.org: I'm happy to be a mentor for the AR5523 support. Who knows, I may end up learning how the hardware works! I'll see if I can dig up my AR5523 and get the basic probe/attach working. -a On 24 February 2014 10:39, Sarah Sharp sarah.a.sh...@intel.com wrote: On Mon, Feb 24, 2014 at 10:19:20AM +, Nick Kossifidis wrote: On 09/11/13 19:14, Bob Copeland wrote: On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. Hello all, So the application period for the next OPW round starts tomorrow, I'm CCing Sarah Sharp who is coordinating things to let you know about the details in case anyone else is interested. I'm already in on AR5513 support and we can also go for power saving, tx completion etc stuff (Bob ?) and more. It sounds like Luis might be interested in volunteering to be a mentor too. Looks like there are plenty of ath5k/ath9k project ideas, so it would be fine to have multiple mentors (or have two people co-mentor an intern). Bob and Adrian, if you're interested in being an OPW mentor, please take a look at this page: http://kernelnewbies.org/OPWMentor As Nick mentioned, the application period opens tomorrow (Feb 25th), and continues until March 19th. After that interns will be selected, and the internships will run from May 19th to August 19th. If anyone is interested in being a mentor with Nick, let me know and I'll start the process of subscribing you to lists, etc. Nick, can you update http://kernelnewbies.org/OPWIntro with a project description for the AR5513 support? I'd like to at least have that project description in place before the application period starts. Thanks, Sarah Sharp -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
I'm happy to be a mentor for the AR5523 support. Who knows, I may end up learning how the hardware works! I'll see if I can dig up my AR5523 and get the basic probe/attach working. -a On 24 February 2014 10:39, Sarah Sharp sarah.a.sh...@intel.com wrote: On Mon, Feb 24, 2014 at 10:19:20AM +, Nick Kossifidis wrote: On 09/11/13 19:14, Bob Copeland wrote: On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. Hello all, So the application period for the next OPW round starts tomorrow, I'm CCing Sarah Sharp who is coordinating things to let you know about the details in case anyone else is interested. I'm already in on AR5513 support and we can also go for power saving, tx completion etc stuff (Bob ?) and more. It sounds like Luis might be interested in volunteering to be a mentor too. Looks like there are plenty of ath5k/ath9k project ideas, so it would be fine to have multiple mentors (or have two people co-mentor an intern). Bob and Adrian, if you're interested in being an OPW mentor, please take a look at this page: http://kernelnewbies.org/OPWMentor As Nick mentioned, the application period opens tomorrow (Feb 25th), and continues until March 19th. After that interns will be selected, and the internships will run from May 19th to August 19th. If anyone is interested in being a mentor with Nick, let me know and I'll start the process of subscribing you to lists, etc. Nick, can you update http://kernelnewbies.org/OPWIntro with a project description for the AR5513 support? I'd like to at least have that project description in place before the application period starts. Thanks, Sarah Sharp ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Rookie needs helps with ath5k basics
... because some of the 802.11p NICs are actually ath5k NICs that have the relevant bandpass filters for 5.9GHz and high output amplifiers. -a On 17 February 2014 01:27, Holger Schurig holgerschu...@gmail.com wrote: Okay, I admit that I cannot help you, I have no clue on the driver level. But maybe I can help with the methodology. :-) You mention 802.11p (car-to-car-communication). Is there any specific reason you base it on ath5k and not on ath9k? If you look at the number of commits, then you should see that ath9k is much more lively. People are actively working with that code and might be able to be answer more specific questions. Another thing that I noted: I have seen over the years many requests of information from uni projects in this mailing list. But I'm quite unsure if ever something came back into the Linux kernel. How do you plan to tackle that? I have the feeling that people are more likely to cooperate if the work doesn't end up in yet another black hole ... And one tip: ask specific questions, not broad ones. For example, look at what features you need to implement 802.11p. Now look at what OSI level this has to be done, e.g. at hardware level (frequency, bandwidth), driver level, or protocoll layer (mac80211, user-space layer (e.g. wpa_supplicant). That would allow you to ask questions not like Tell me everything, but Oh, I need to do XYZ, where can I do it?. It might even help you in finding your way, e.g. by looking into git commits inside the ath/ath9k subdirectories that might have something to do with what you need. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On 9 November 2013 05:40, Nick Kossifidis mickfl...@gmail.com wrote: Adrian/Bob, these fixes (along with power saving etc) are very interesting projects and I was thinking to submit them in OPW (http://kernelnewbies.org/OPWIntro). Are you interested in mentoring (http://kernelnewbies.org/OPWMentor) ? I'm happy to provide guidance for the technical / chip side of things, sure. I'm planing to submit ar5513 support and ar5210 fixes there and mentor (for the next period -June to September-). Cool! I hope you beat me to ar5513 support. The HAL is sufficiently different that even bringing it up on the latest madwifi or freebsd requires a lot of manual love. -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On 7 November 2013 06:20, Bob Copeland m...@bobcopeland.com wrote: On Wed, Nov 06, 2013 at 09:17:46AM -0800, Adrian Chadd wrote: The TL;DR version - you need to keep the the final descriptor around for each hardware queue. The legacy madwifi/freebsd way of doing it was to keep the last descriptor that was handled. This wasn't enough. It needs to be per TX queue. You also must never program TxDP after you've programmed it once - you can only program it again after you've completely torn down TX DMA for the particular queue. This is a goldmine -- thank you for taking the time to write it up! I believe we can clean up ath5k's transmit loop a lot now... You're very welcome. I spent quite a lot of time waist deep in this crap. It turns out I had to go to the hardware guys and wade through the verilog to figure out what the hell was actually going on. * read-and-clear bugs * PHY register read problems, and why ANI may occasionally look whacked One thing at a time for me... but do we even want to know? :) If you want to avoid crazy crashes and hangs, yes? :) Also, ask me about key cache corruption too. -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On 6 November 2013 05:41, Bob Copeland m...@bobcopeland.com wrote: Hi Adrian (and anyone else who wants to chime in), I'm looking to fix some accounting issues in the ath5k tx path, which arise because we always try to keep one descriptor available at the end for the hardware's sake. I believe you have some concrete, hard-won knowledge about when the hardware marks a descriptor complete versus when the 'next' pointer in the descriptor is accessed -- do you mind sharing? Sure! The TL;DR version - you need to keep the the final descriptor around for each hardware queue. The legacy madwifi/freebsd way of doing it was to keep the last descriptor that was handled. This wasn't enough. It needs to be per TX queue. You also must never program TxDP after you've programmed it once - you can only program it again after you've completely torn down TX DMA for the particular queue. This is relevant for ath5k _and_ ath9k chips! The long version: The DMA engine follows the TX descriptor link list to process things. Once it finishes a descriptor, it'll read the link descriptor pointer to see what the next descriptor is. If it's NULL, it'll keep the address of the link pointer around so it can re-read it when it needs to start DMA again. The reason for this is because TX DMA can restart at any time for any reason. It can be gated by timers, by beacon reception, by burst / ready time, etc; it can be pre-empted by traffic from a higher priority queue. It stores this per QCU, so you need to store the last descriptor per QCU, rather than just the last it handled. Now, since the intended use case is that software will just write to the link pointer if there's a new packet to transmit, it needs to be handled in an atomic way. So, here are the conditions: * no transmit, no past transmit. TxDP[n] is 0x0. It's never transmitted anything before. You queue a frame to TxDP[n], set TxE[n] to 1, and it starts. * transmit is going on, TxDP[n] is non-NULL. You add something to the link pointer and then you set TxE[n] to 1 to kick things along. The DMA engine was NOT already sending the final frame in the queue to the air, so it'll just keep reading the list as normal. * transmit is going on, TxDP[n] is non-NULL and it points to the last frame. You sneak in an update to the link pointer before the hardware completes the frame, tickle TxE[n] and the hardware will keep going. * transmit is going on, TxDP[n] is non-NULL and it points to the last frame. It fnishes it, reads the NULL pointer, sees its NULL, stops transmitting. You update the link pointer, tickle TxE[n], but .. and here's the problem. So to make the last option work, the only sane way is for the hardware to re-read the link pointer to see if it's updated. It'll then always do the right thing - if it's just read a NULL link pointer it'll re-read it to see the updated value and continue transmitting. The _other_ option (which i think freebsd/madwifi did) was to just update link pointer and write a new TxDP before transmitting. The TDMA code in FreeBSD did this. Now this would also get around the race, right? If you hit the end of the list and it hit NULL, then you write a new TxDP[n] and set TxE to 1, it should start the new list, right? Then, comes the weird crap' I found when digging through the RTL (chip source.) There are erm, situations where the chip won't actually process a TxDP update. Thus, even if you write a new TxDP out, even if the hardware is not transmitting, it may ignore the write. This is why I took the time in FreeBSD to do this: * staging descriptor is now per-QCU; * if i've never transmitted before, I will update TxDP * otherwise, if I've transmitted before, I will always append a frame to the transmit queue by adding it to the last descriptor (and if this is a done staging descriptor, so be it), and poke TxE[n] This works really, really well. Now for the ath9k relevant bits! All the ath9k chips behave the same. Even the EDMA chips. So, for EDMA, you _can_ just queue one frame per TX FIFO slot. You don't have the above behaviour. However, if you queue multiple frames to a TX FIFO slot (_not_ A-MPDU frames, but say, you append 15 frames to the cabq or 15 non-aggregate frames to a normal data queue by appending 15 frames to one TX FIFO entry, rather than one frame per FIFO entry) then the same behaviour as above may occur. You still need to keep a staging descriptor around whilst you're processing TX completions, as TX completions are per-frame, _not_ per TX FIFO slot. Once you've processed the whole slot, you don't need to keep the staging descriptor around for the next slot. FreeBSD does this for TX EDMA descriptor handling. I hope this clears things up! Next - ask me about: * read-and-clear bugs * PHY register read problems, and why ANI may occasionally look whacked -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org
Re: [ath5k-devel] AR5513 HAL from Qualcomm Atheros ad ath5k driver
Yup! That was my doing, before i left Qualcomm Atheros. -adrian On 5 October 2013 16:45, Andrea Scoppettone scop...@gmail.com wrote: Hi there is the HAL for AR5513 https://github.com/qca/qca-ar5513-hal The AR5513 is a 2-antenna MIMO 11abg (not 11n) device that was sold into a few markets. As far as I'm aware, it's the only legacy PCI(e) chipset which the open source Atheros drivers are missing support for. The HAL is from an earlier development effort, before things had fully migrated to using a Madwifi derivative. Thus, the HAL API isn't (easily) compatible with the Madwifi or FreeBSD Atheros driver code. However, it should be sufficient to bring up chipset support for the AR5513 in ath5k. We've opened this up in the hope that the opensource crowd will add support to ath5k for this chipset. Thanks,Scoppy PS I have a Dlink G520M PCI with ar5513 :00:0c.0 Ethernet controller: Atheros Communications, Inc.: Unknown device 0020 (rev 01) Subsystem: D-Link System Inc: Unknown device 3a68 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at e100 (32-bit, non-prefetchable) [size=128K] Capabilities: [44] Power Management version 2 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] mac80211 and kernel 3.8.13 1/2 speed as with madwifi and kernel 2.6.23 and bad respons time
... I think you should start doing some more in-depth system profiling to see where that CPU is actually being used. Saying ksoftirqd is only a little helpful. See if it's handling way too much interrupts, or whether there's lots of card error conditions, or the TX/RX queues are being too frequently checkeed, or ... -adiran ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Integrating sectorised antenna with a Wi-Fi node
Hi, Yes you can do this. The trick is changing the antenna config for each frame you send out. If you do it with an rs232 port then you have to only hand the hardware one packet at a time. If you hand it multiple packets to different nodes, you won't be able to do per-destination antenna configuration. Yes, I wish there were some NICs that just exposed the antenna configuration bits, RX_CLEAR line and GPIO pins. That would make this particular thing easier to do. adrian On 14 May 2013 08:38, Mofolo Mofolo mofol...@gmail.com wrote: Hi Adrian, Thanks for the reply. I am realize there might be hardware constraint for me to use sectorised antenna. I currently have a NIC with only one antenna exposed . I have reconsidered my scenario and now I am planning to use switched beam antennas (specifically ESPAR antenna). This antenna technology has only one feed line similar to the omnidirectional antenna. In this case, I don't have to worry about modifying HAL code. ESPAR antenna can be configured as either omnidirectional or directional. Directional beams can be achieved by electronically controlling the parasitic elements, for instance by sending a byte value via a serial port on a per packet basis. If I can rephrase the idea, this is what I would like to explore. I want to create a scenario where upon start up, each node uses omnidirectional antenna. Then, once a neigboring node requests association, i want to perform a scan using each of the 4 antenna beams and based on the beam which gives me max RSSI, I assume it is the best sector/beam to be used to communicate with that neighbor. So an extra parameter can be introduced in the neighbor's table to flag the antenna sector/sector which has to be used whenever a node communicates with that specific neighbor. I am assuming the all nodes receive using omnidirectional antenna configuration but transmit (per packet level) using directional beam configuration. It would be more interesting if such a routine is automatically performed within the driver for every station that is added into the neighbor's table. For simplicity I am assuming static network topology. The directional beam configuration is achieved by sending appropriate byte value via serial port (RS232) to control and direct the antenna radiation pattern towards desired direction. I have already achieved this by modifying MADAWIFI. I have to try it using mac80211 and ath5k driver. The only challenge is achieving neighbor discovery especially in ad-hoc mode. With thanks, Mofolo On 13 May 2013 19:29, Adrian Chadd adr...@freebsd.org wrote: Hi, I figure I'll give a 30 second introduction into sectored antenna support. So the AR5212 era chips have four antenna control bits. They're ANTA - ANTD. Now, there's some switch table registers. By default the HAL code sets these up so BB_ANTENNA_CONTROL, BB_SWITCH_TABLE1 and BB_SWITCH_TABLE2 map to idle, stuff with antenna 1 and stuff with antenna 2. This is for non-sectored operation. I can go into more detail here if you'd like. For sectored operation, you don't leave ANTA:ANTD up to the switch table. You control the TX antenna configuration and you use the single omni antenna for receiving frames (normal RX, RTS, listening for ACK too I guess.) There's four antenna config bits in the TX descriptor for each rate attempt, along with DEFANT for the omni antenna configuration. In this mode (sector AP mode) its up to the driver and wifi stack to track the per-client, per-sector behaviour and choose an optimal sector configuration for that. The 11n chips have something but not quite similar for this kind of antenna selection. So, if you have a modified NIC that exposes ANTA-ANTD and you can make up a sectored antenna configuration + omni antenna configuration, I can attempt to help you. I haven't done this myself; I'm just going on what I have here. Thanks, Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Integrating sectorised antenna with a Wi-Fi node
.. in fact, what I'd really _really_ like is if someone would build an open source phased antenna array that's intended to be used by three-stream (ie, three transmit/receive chain) antenna devices. That way we could do both phased array station operation (when it directs its transmit power _to_ a specific location _AND_ leave the default receive antenna configured to the best receive antenna configuration) and phased array AP operation (when it directs its transmit power to specific antenna configurations, one per associated station; with a default omni receive configuration.) If someone's happy to design, implement and open source that, I could have my arm twisted to hack on the basic rate control and driver code to make that stuff work. For ath5k NICs you only have 4 bits of antenna control. For ath9k NICs you have 24 bits of antenna control shifted out two GPIO pins. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: Remove AHB bus support.
... is anyone using this on openwrt?
Adrian
On 13 May 2013 08:03, Paul Bolle pebo...@tiscali.nl wrote:
AHB bus support was added in v2.6.38, through commit a0b907ee2a (ath5k:
Add AHB bus support.). That code can only be build if the Kconfig
symbol ATHEROS_AR231X is set. But that symbol has never been added to
the tree. So AHB bus support has always been dead code.
Let's remove all code that depends on ATHEROS_AR231X. If that symbol
ever gets added to the tree the AHB bus support can be re-added too.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
0) Compile tested (I do not think I have hardware that use the ath5k
driver).
1) I mentioned the missing ATHEROS_AR231X symbol three times before (in
August 2011, in July 2012 and in March 2103). Nobody stepped forward to
tell me they were actually working on adding that symbol somehow. So
let's see how people react when I submit a patch to remove the (dead)
AHB bus support.
drivers/net/wireless/ath/ath5k/Kconfig | 14 +-
drivers/net/wireless/ath/ath5k/Makefile | 1 -
drivers/net/wireless/ath/ath5k/ahb.c| 239
drivers/net/wireless/ath/ath5k/ath5k.h | 28
drivers/net/wireless/ath/ath5k/base.c | 14 --
drivers/net/wireless/ath/ath5k/led.c| 6 -
6 files changed, 3 insertions(+), 299 deletions(-)
delete mode 100644 drivers/net/wireless/ath/ath5k/ahb.c
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig
b/drivers/net/wireless/ath/ath5k/Kconfig
index c9f81a3..93caf8e68 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -1,13 +1,12 @@
config ATH5K
tristate Atheros 5xxx wireless cards support
- depends on (PCI || ATHEROS_AR231X) MAC80211
+ depends on PCI MAC80211
select ATH_COMMON
select MAC80211_LEDS
select LEDS_CLASS
select NEW_LEDS
select AVERAGE
- select ATH5K_AHB if (ATHEROS_AR231X !PCI)
- select ATH5K_PCI if (!ATHEROS_AR231X PCI)
+ select ATH5K_PCI
---help---
This module adds support for wireless adapters based on
Atheros 5xxx chipset.
@@ -52,16 +51,9 @@ config ATH5K_TRACER
If unsure, say N.
-config ATH5K_AHB
- bool Atheros 5xxx AHB bus support
- depends on (ATHEROS_AR231X !PCI)
- ---help---
- This adds support for WiSoC type chipsets of the 5xxx Atheros
- family.
-
config ATH5K_PCI
bool Atheros 5xxx PCI bus support
- depends on (!ATHEROS_AR231X PCI)
+ depends on PCI
---help---
This adds support for PCI type chipsets of the 5xxx Atheros
family.
diff --git a/drivers/net/wireless/ath/ath5k/Makefile
b/drivers/net/wireless/ath/ath5k/Makefile
index 1b3a34f..51e2d86 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -17,6 +17,5 @@ ath5k-y += ani.o
ath5k-y+= sysfs.o
ath5k-y+= mac80211-ops.o
ath5k-$(CONFIG_ATH5K_DEBUG)+= debug.o
-ath5k-$(CONFIG_ATH5K_AHB) += ahb.o
ath5k-$(CONFIG_ATH5K_PCI) += pci.o
obj-$(CONFIG_ATH5K)+= ath5k.o
diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
b/drivers/net/wireless/ath/ath5k/ahb.c
deleted file mode 100644
index 8e8bcc7a..000
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/*
- * Copyright (c) 2008-2009 Atheros Communications Inc.
- * Copyright (c) 2009 Gabor Juhos juh...@openwrt.org
- * Copyright (c) 2009 Imre Kaloz ka...@openwrt.org
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-#include linux/nl80211.h
-#include linux/platform_device.h
-#include linux/etherdevice.h
-#include linux/export.h
-#include ar231x_platform.h
-#include ath5k.h
-#include debug.h
-#include base.h
-#include reg.h
-
-/* return bus cachesize in 4B word units */
-static void ath5k_ahb_read_cachesize(struct ath_common *common, int *csz)
-{
- *csz = L1_CACHE_BYTES 2;
-}
-
-static bool
-ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
-{
- struct ath5k_hw *ah = common-priv;
- struct platform_device
Re: [ath5k-devel] [PATCH] ath5k: Remove AHB bus support.
On 13 May 2013 09:39, Jonathan Bither jonbit...@gmail.com wrote: ... is anyone using this on openwrt? I am. I am also reworking AR2131X drivers and will submit a patch to linux-mips shortly. Sweet. Someone say NACK then? :) Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Integrating sectorised antenna with a Wi-Fi node
Well, I can help you with the hardware tweaks for sectored antennas. But first you need to tell me how you plan on hooking up said sectored antenna to the ath5k NIC. Adrian On 7 May 2013 00:27, Holger Schurig holgerschu...@gmail.com wrote: You're probably 5 years too late. The MADWIFI driver is quite out of fashion nowadays and few people are still hacking on it. I wouldn't base any new development on it. What you describe is a bit like diversity: receive with all antennas, determine which antenna had the highest RSSI, use that antenna for transmits towards the client. For this you'd need to maintain your own mac-hashed neightborhood table in the driver. However, to my best knowledge the hardware doesn't support 4 antennas. You'd need some circuitry to use only some or all of those antenna (all antennas in the beacon case). And that for the tx and rx case. As the chips usually only suport 2 antennas, you'd need some koax switching circuitry, and sync that to the transmits. Things get ugly and complex pretty fast. In the end it might be cheaper to just use one AP with one sectional antenna ... and simply put 3 or 4 of those APs into one casing. :-) 2013/5/6 Mofolo Mofolo mofol...@gmail.com Hi, I am integrating sectorised antenna with a Wi-Fi node, basically a PC running Ubuntu. The network network is setup on ad-hoc mode. Currently installed driver is MADWIFI Please advise on how can a node perform neighbor discovery while using sectorised antennas. That means for every station in a neighbor's table, an appropriate antenna sector has to be recorded so as for every packet transmitted, the node can select and use suitable antenna sector. For example: If we say each node is equipped with an antenna with 4 sectors, then the node has to determine which sector to use when communicating with neighbors. in the case where nodes A, B, C and D are aligned in a straight line; node 'B' has to use a different antenna sector when communicating with node 'A', as opposed to when communicating to node 'C'. A B C D How can this mapping of neigbouring nodes with specific antenna sectors be achieved, if maybe RSSI is used as the determining factor during building up of neighbor's table? Thanks. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Integrating sectorised antenna with a Wi-Fi node
Hi, I figure I'll give a 30 second introduction into sectored antenna support. So the AR5212 era chips have four antenna control bits. They're ANTA - ANTD. Now, there's some switch table registers. By default the HAL code sets these up so BB_ANTENNA_CONTROL, BB_SWITCH_TABLE1 and BB_SWITCH_TABLE2 map to idle, stuff with antenna 1 and stuff with antenna 2. This is for non-sectored operation. I can go into more detail here if you'd like. For sectored operation, you don't leave ANTA:ANTD up to the switch table. You control the TX antenna configuration and you use the single omni antenna for receiving frames (normal RX, RTS, listening for ACK too I guess.) There's four antenna config bits in the TX descriptor for each rate attempt, along with DEFANT for the omni antenna configuration. In this mode (sector AP mode) its up to the driver and wifi stack to track the per-client, per-sector behaviour and choose an optimal sector configuration for that. The 11n chips have something but not quite similar for this kind of antenna selection. So, if you have a modified NIC that exposes ANTA-ANTD and you can make up a sectored antenna configuration + omni antenna configuration, I can attempt to help you. I haven't done this myself; I'm just going on what I have here. Thanks, Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Announcement: AR5513 HAL
Hi, I've just pushed a copy of the AR5513 HAL from Qualcomm Atheros into the QCA github repository. https://github.com/qca/qca-ar5513-hal The AR5513 is a 2-antenna MIMO 11abg (not 11n) device that was sold into a few markets. As far as I'm aware, it's the only legacy PCI(e) chipset which the open source Atheros drivers are missing support for. The HAL is from an earlier development effort, before things had fully migrated to using a Madwifi derivative. Thus, the HAL API isn't (easily) compatible with the Madwifi or FreeBSD Atheros driver code. However, it should be sufficient to bring up chipset support for the AR5513 in ath5k. We've opened this up in the hope that the opensource crowd will add support to ath5k for this chipset. Thanks, Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Bit rate selection algorithms
On 22 March 2013 14:41, Colleen Josephson cjos...@mit.edu wrote: Which bit rate selection protocols are available in the ath5k driver? How does this compare to what's available in the madwifi and the ath9k drivers? I am trying to set up an experiment to measure the performance of the various bit rate selection algorithms available (for academic purposes), and this information would be very helpful. I think it uses minstrel. It likely can use whatever other rate control modules appear in mac80211, but I don't know if any have shown up that get used. madwifi has a few others (sample, onoe, amrr) and they're well documented and researched. HTH, Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Question . . How do I
On 27 February 2013 04:39, Lynne Stevens jackie...@gmail.com wrote: * So how do I install the drive for AR5B95 . . ie the ath5k driver as when I did this it kicked in and seen all the wifi connections I just could not get it to work as it did not have the driver * * modprobe ath5k sudo ip link set wlan1 up sudo iwconfig wlan1 essid any* Hi, The AR5B95 is the AR9285, which is an 802.11n NIC. It's handled by ath9k, not ath5k. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] NAV timer statistics, specifically CTS received count
On 16 January 2013 18:45, Hugh O'Brien hugh.obr...@ul.ie wrote: Hi there, I'm doing some research on CTS based co-existence with wifi for other 2.4GHz protocols. I've been using packet injection to get the CTS frames on the air, which I can verify, but I'm not sure that certain stations are receiving them, as their radio occupancy seems unaffected. Is there a way to see how many CTS packets the ath5k driver has seen? I'm unsure if NAV properties make it up to the driver level, would anyone know if the chipset could be interrogated for those values? Hm, it doesn't _look_ like the chips have a CTS received counter. There's AR_RTS_OK / AR_RTS_FAIL but I don't know if that's a MAC TX RTS counter, or a MAC RX RTS counter. And that doesn't help for CTS-to-self, which doesn't have an RTS exchange. What about just enabling promisc mode and counting the RTS/CTS/ACK exchanges? adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] NAV timer statistics, specifically CTS received count
There's a PCU NAV register that you can read, yes. Adrian On 17 January 2013 15:18, Hugh O'Brien hugh.obr...@ul.ie wrote: Hi Adrian, thank you for taking a look. I have a monitor device next to the target which is in promiscuous mode from which I can see that the device injecting CTS frames (another device) is functioning. It's just that the target's behaviour is puzzling as it doesn't necessarily respect the CTS, or doesn't receive it. One theory I have is that the power saving mode is preventing it from receiving the frame, so it unwittingly wakes up to send its frame when the channel _should_ be kept clear. Unfortunately CSMA doesn't help here as I'm trying to clear the channel for another protocol. Do you think it might be possible to get some visibility into the current value of the NAV timer? That would certainly be informative for MAC research. Hugh On 17 January 2013 15:37, Adrian Chadd adr...@freebsd.org wrote: On 16 January 2013 18:45, Hugh O'Brien hugh.obr...@ul.ie wrote: Hi there, I'm doing some research on CTS based co-existence with wifi for other 2.4GHz protocols. I've been using packet injection to get the CTS frames on the air, which I can verify, but I'm not sure that certain stations are receiving them, as their radio occupancy seems unaffected. Is there a way to see how many CTS packets the ath5k driver has seen? I'm unsure if NAV properties make it up to the driver level, would anyone know if the chipset could be interrogated for those values? Hm, it doesn't _look_ like the chips have a CTS received counter. There's AR_RTS_OK / AR_RTS_FAIL but I don't know if that's a MAC TX RTS counter, or a MAC RX RTS counter. And that doesn't help for CTS-to-self, which doesn't have an RTS exchange. What about just enabling promisc mode and counting the RTS/CTS/ACK exchanges? adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
Hi, It may be; that's the problem. :/ Adrian On 12 November 2012 10:53, Thomas Pedersen tho...@cozybit.com wrote: This is true for at least AR5213, and shouldn't be different for other ath5k PHYs. Signed-off-by: Thomas Pedersen tho...@cozybit.com --- drivers/net/wireless/ath/ath5k/base.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index 9f31cfa..ae1a2fe 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1335,20 +1335,9 @@ ath5k_receive_frame(struct ath5k_hw *ah, struct sk_buff *skb, * 15bit only. that means TSF extension has to be done within * 32768usec (about 32ms). it might be necessary to move this to * the interrupt handler, like it is done in madwifi. -* -* Unfortunately we don't know when the hardware takes the rx -* timestamp (beginning of phy frame, data frame, end of rx?). -* The only thing we know is that it is hardware specific... -* On AR5213 it seems the rx timestamp is at the end of the -* frame, but I'm not sure. -* -* NOTE: mac80211 defines mactime at the beginning of the first -* data symbol. Since we don't have any time references it's -* impossible to comply to that. This affects IBSS merge only -* right now, so it's not too bad... */ rxs-mactime = ath5k_extend_tsf(ah, rs-rs_tstamp); - rxs-flag |= RX_FLAG_MACTIME_MPDU; + rxs-flag |= RX_FLAG_MACTIME_END; rxs-freq = ah-curchan-center_freq; rxs-band = ah-curchan-band; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
On 12 November 2012 11:40, Sam Leffler sleff...@google.com wrote: From my experience doing tdma on ath chipsets I know the timestamp is a snapshot of the tsf recorded by the dma engine when it writes the descriptor on dma completion. This was only legacy frames; don't know how things work for aggregate frames. RIght. Thomas did some testing (see ath9k-devel) and sees the TSF for aggregate frames as being the timestamp of the first frame. No idea if it's the TS of the end of the first frame in an aggregate, or the beginning of the first frame in the aggregate. Quite likely at anything other than the lowest MCS, it's going to be well within a handful of 100uS. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
This is why I asked for a bit of a summary. What specific behaviour are you chasing from the keycache, source/destination MAC address matching and encryption engine? There've apparently been some keycache matching bugs in the past .. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Multi-channel support in AR2313
Hi, I can't point you to any working implementations, sorry. I know that channel change on the older platforms takes time; even fast channel change wasn't terribly fast and came with a _lot_ of restrictions. There was some attempt at a virtualised phy with mac80211 and ath9k in the past. It may be worth looking into what was done there. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
Hiya, Yeoh - can you please email me privately with a summary of what you implemented, what you've tested and what worked / what didn't work? I can do some digging into what changed with the encryption stuff and see if I can figure it out in my (limited) spare time. I can try to do it sometime next week. I've been meaning to do MFP for FreeBSD's ath/net80211 driver so I guess now it's a fine time to dig into the older chipset code and figure out what's going on. Thanks, Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Multi-channel support in AR2313
Hi, The problem with doing multi-channel single radio work is that channel change will take quite a bit of time; so you will have to take that into account when implementing this. Then you have to ensure all the whacky power save stuff works absolutely correctly.. :-) Adrian On 4 September 2012 18:16, Sivateja Patibandla patibandl...@vcu.edu wrote: Hi guys, I'm new to the ath5k driver development. I wanted to implement a multi-channel single radio based MAC on AR2313 hardware. I'm using openWRT distribution. Is multi-channel support dependent more on hardware? If so, does AR2313 support multi-channel? If not, is it possible to add this capability in the ath5k driver? Any suggestions and commented will be appreciated. Thanks Regards, Siva. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: add support of HW encryption in management frames
On 31 August 2012 08:24, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote: Hi, Adrian Appreciate your testing on this. Hi, I don't have time to test ath5k stuff. I'm just an Atheros employee who hacks on FreeBSD in his spare time. I'm lurking to provide feedback. :-) I suggest that you at least wrap this in a run-time configuration item that defaults to off or something. i'd be really worried about this stuff having subtle bugs that aren't well documented; it may work for you but it may induce weird behaviour in other setups. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Please add PCI id
Hi,
0xff1b indicates the device wasn't correctly setup post power on.
So I'd try to find out exactly why that is.
Adrian
On 13 April 2012 08:32, Yoshinori Sato ys...@users.sourceforge.jp wrote:
This device works fine of ath5k.
Details bellow
05:00.0 0200: 168c:ff1b (rev 01)
05:00.0 Ethernet controller: Atheros Communications Inc. Device ff1b (rev 01)
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at febf (64-bit, non-prefetchable) [size=64K]
Capabilities: access denied
Kernel driver in use: ath5k
ath5k :05:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19
ath5k :05:00.0: setting latency timer to 64
ath5k :05:00.0: registered as 'phy0'
ath: EEPROM regdomain: 0x67
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x67
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
diff --git a/drivers/net/wireless/ath/ath5k/pci.c
b/drivers/net/wireless/ath/ath5k/pci.c
index eaf79b4..1be418c 100644
--- a/drivers/net/wireless/ath/ath5k/pci.c
+++ b/drivers/net/wireless/ath/ath5k/pci.c
@@ -44,6 +44,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath5k_pci_id_table) = {
{ PCI_VDEVICE(ATHEROS, 0x001b) }, /* 5413 Eagle */
{ PCI_VDEVICE(ATHEROS, 0x001c) }, /* PCI-E cards */
{ PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
+ { PCI_VDEVICE(ATHEROS, 0xff1b) }, /* AR5BXB63 */
{ 0 }
};
MODULE_DEVICE_TABLE(pci, ath5k_pci_id_table);
--
Yoshinori Sato
ys...@users.sourceforge.jp
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] 10 MHz bandwidth with incorrect bitrate
hi, I'm -pretty- sure that the PLCP will indicate the normal 802.11 rate, but it's just modulated on half/quarter size carriers. adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics
Hi all,
I'd like some help in writing a GUI toolkit for recording, playing
back and visualising some of the PHY/MAC statistics the Atheros NICs
expose.
What I can do: help with the MAC/PHY side of things, identify what
initial things would be good to support and what would actually be
useful.
What I can't do: dedicate time to write a GUI. :-)
What I'd like to see: something completely free/open source written so
we can improve the foss wireless development process.
(Why I'm doing this: I'm fed up staring at printf() debugging in
ath9k/FreeBSD and it's hard to have others visualise what's going on
..)
I'd like it to be in C++/QT (before you ask - if you can make python
or ${OTHER_LANG} handle the sheer rates of wifi traffic, MAC counters
and PHY errors, _live_, and on tablet/atom class hardware, then please
by all means do so..) and I'd like it to be platform portable. That
way it can be used as a visualisation tool on other platforms, even if
it's unable to do live capture itself (think MacOSX/Windows.)
I'm talking about peaking on upwards of 10,000 PHY events a second in
a very noisy environment, as well as the potential for some frequency
domain analysis of time series data. This is why I think C++ is a more
suitable target language over anything scripting-y.
If you're interested in this then please drop me a private line and
we'll get this off the ground.
Thanks,
Adrian
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics
On 23 March 2012 10:18, Ben Greear gree...@candelatech.com wrote: I wouldn't ask someone to do it and then tell them what language. Just suggest to them what it needs to do instead. I'm sorry if it came across as demanding. It's more that I've looked at how/where people tend to use these kinds of visualisation tools and they're not on quad-core i7 laptops. They're on little itty atom netbooks (or tablets these days, I guess) with comparitively limited CPU. I've also had people suggest C#. Which is fine, but as I'd like this to be totally open source, I don't want it to depend upon any closed source C# libraries or any microsoft only runtime bits. Same holds for any other language. The other thing is keeping multiple threads going so your UI doesn't become unresponsive when you're falling behind doing network/disk IO or math operations. Yes, I've written some GUI stuff, so I have a basic idea of what's going on. If someone wants to me prove me wrong by demonstrating it done in python or some other scripting language then fine. The big question for me is: How do you propose to get the info out of the driver and up to user-space? I'll worry about that later. For FreeBSD, the PHY errors come out via radiotap, so it'll look like a BPF stream. Just in case it matters...while benchmarking my Linux ethtool patch to ath9k, I found it took around 35us to make the ethtool ioctl call to get the stats. This was on a dual-core Atom system. Right, but you can fetch a whole lot of statistics each call. The ath/HAL ioctl API doesn't return a single stat on each invocation. It returns a whole swath of them. I'm not worried about extracting the data from the various flavours of wifi stacks we're working with in BSD/Linux. :-) Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH wireless-next 2/3] ath5k: Introduce _ath5k_printk to reduce code/text
On 18 March 2012 22:18, Joe Perches j...@perches.com wrote: Otherwise compiling in debugging will cause a _lot_ of spurious register reads to occur that are then tossed. This was one of the big reasons for instability and slow performance when AH_DEBUG was enabled. That doesn't make any sense in this case. It's either a call to printk or _ath5_printk but it's still a call to a function. The FreeBSD HAL used to be like this. I changed it so it didn't evaluate the arguments before it figured out whether or not to do the (k)printf(). I'm just pointing it out as you're (currently) knee deep in the debugging code and it may be useful for you to also think about implementing. adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH wireless-next 2/3] ath5k: Introduce _ath5k_printk to reduce code/text
Hi, So the reason this is a macro in the FreeBSD HAL is so that the args aren't evaluated unless the level (or debug bitmap in my case) fires off. Otherwise compiling in debugging will cause a _lot_ of spurious register reads to occur that are then tossed. This was one of the big reasons for instability and slow performance when AH_DEBUG was enabled. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Combined rate and antenna selection algorithm
Hi! There's a couple of things I can think of. Firstly, it'd be nice if we had per-packet TPC working on some of those earlier chips. Then you could throw in TX power into the mix. Secondly, yes - you can do per-packet TX antenna selection on these NICs. You could modify the rate control API in mac80211/ath5k to let you walk the list of available antennas and do some probing to determine which antenna gives you the lowest PER or something. The BSD/madwifi ath(4) driver would do dynamic antenna selection (which worked on for STA mode, kind of) which would look at the antenna selected by the hardware on RX and use that as the default.. it leveraged using fast antenna diversity on the chip and paid attention to which antenna the hardware would choose. I don't know how much of that code is left in ath5k; it however is based on RX rather than TX statistics. It's useful to look at though. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Ath5k Hardware Timestamping of Transmitted Packets
Hi! On 14 March 2012 13:57, Alexander Watson zredli...@gmail.com wrote: Hello, I am working on a project where I need to be able to accurately timestamp both transmitted and received packets from an Atheros NIC. I am aware that in its normal mode of operation and that Ath5k only timestamps received packets and beacons. I believe all AR5212 and later NICs have a TX and RX timestamp in the completion descriptor. Does it not do what you want? Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k phy0: gain calibration timeout
On 10 March 2012 10:56, David Fries da...@fries.net wrote: http://nbd.name/gitweb.cgi?p=openwrt.git;a=blob_plain;f=package/mac80211/patches/440-ath5k_calibrate_no_queue_stop.patch;hb=HEAD http://nbd.name/gitweb.cgi?p=openwrt.git;a=blob_plain;f=package/mac80211/patches/441-ath5k_no_agc_recalibration.patch;hb=HEAD No problems running with the above two patches after 12 days. No calibration timeout messages either. Thanks. Sweet. I did do a bit of digging (and forgot to email the list) - yes, those initial calibrations should only be done once, after a (full) chip cold reset. They shouldn't be done periodically. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k disassociates when physical carrier sensing is disabled
On 29 February 2012 09:19, srinivas prasad wasimpra...@gmail.com wrote: Thanks for the reply. Just to make it clear, So are you saying that the patch is buggy? I thought it is supposed to disable carrier sensing (physical and virtual) by turning on and off some flags. I don't think that patch does what you think it does, at least not guaranteed on all chips. In fact, I wonder how early those misc mode bits do go back.. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k disassociates when physical carrier sensing is disabled
.. and you'll be able to sense ACKs how? :-) Adrian On 29 February 2012 14:25, srinivas prasad wasimpra...@gmail.com wrote: I thought that it will enable me to transmit without sensing the carrier. I am a bit new to this so maybe I interpreted it wrong. My aim is to induce overlaps as many overlaps as possible in our network in our experiments. I thought by physical carrier sense, i would be able to transmit without sensing the carrier. Thank you Srinivas On Wed, Feb 29, 2012 at 4:02 PM, Nick Kossifidis mickfl...@gmail.com wrote: 2012/2/29 srinivas prasad wasimpra...@gmail.com: Thanks for the reply. Just to make it clear, So are you saying that the patch is buggy? I thought it is supposed to disable carrier sensing (physical and virtual) by turning on and off some flags. Define buggy. This patch disables carrier sensing on PHY by forcing the RX_CLEAR signal to always be high (that means the PHY always reports the channel as idle, e.g. allowing you to transmit all the way ignoring any other users -some people use that for DoS attacks/testing/research etc-) and virtual carrier sensing on MAC by telling the PCU to ignore it. It does what's supposed to and as Felix told you it effectively kills RX (until you switch them back on). What did you expect from such a patch/approach ? -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Disable MAC layer ack
If it's anything like what ath9k does, there's a flag that the upper layers can set which marks that particular frame as not requiring an ACK. So you wouldn't require it to be done via an iw command - you'd just appropriately tag your data frames. Adrian On 19 January 2012 00:35, David Murray d.mur...@murdoch.edu.au wrote: Hi, I am interested in disabling the MAC layer ack. I have read http://www.mail-archive.com/ath5k-devel@lists.ath5k.org/msg04587.html Is there any chance of a hook being put into ath5k so that it could be enabled or disabled with an iwpriv or something similar. It seems like it is part of the 802.11e framework http://en.wikipedia.org/wiki/IEEE_802.11e-2005#NoAck It would also be useful for anyone doing long distance networking or experimenting with TDMA based MAC layers. Thanks for your time, Dave ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Disable MAC layer ack
There's a bit in the TX descriptor which should be labelled something like noack / NOACK. Just start there and work your way up. :) Sorry, I'm knee deep in radar pattern matching code at the moment... Adrian On 19 January 2012 17:08, David Murray d.mur...@murdoch.edu.au wrote: Thank you very much for the response Luis. it seems like ath_hw_set_bssid_mask() is really about filtering out external BSSIDs. Adrian, do you have any information or links that might explain how the higher layers set the QoS flags of NoAck in 802.11? I would happily buy ath9k compatible devices if I thought this would be possible. Thanks Dave On 20/01/12 05:59, Luis R. Rodriguez wrote: On Thu, Jan 19, 2012 at 07:45:52AM -0800, Adrian Chadd wrote: If it's anything like what ath9k does, there's a flag that the upper layers can set which marks that particular frame as not requiring an ACK. ath_hw_set_bssid_mask() http://git.kernel.org/?p=**linux/kernel/git/linville/** wireless-testing.git;a=blob;f=**drivers/net/wireless/ath/hw.c;**h=** 19befb33107348e949cf958c05ee26**83f9ba28d9;hb=HEAD#l27http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=blob;f=drivers/net/wireless/ath/hw.c;h=19befb33107348e949cf958c05ee2683f9ba28d9;hb=HEAD#l27 Luis ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Radar detection test
.. and as a DFS when? followup: * hostap's are expected to listen out for radar pulses whilst traffic is on-going. * in an IBSS, a DFS 'master' is elected which does radar detection. * a hostap can request that stations be quiet for a certain period after a beacon, so it can sample the air for radar events. This is called Quiet time. It's not yet publicly implemented anywhere. I've got some mostly working code in FreeBSD but I won't be able to sit down and debug it for a couple of weeks. So you'll be handling radar phy error events at the same time you're RX'ing traffic. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH v2 01/12] ath5k: Switch from read-and-clear to write-to-clear method when handling PISR/SISR registers
On 28 November 2011 03:59, Nick Kossifidis mickfl...@gmail.com wrote: Oh wait. Where are you clearing these bits? It doesn't look like you're even clearing the ah_txq_isr bits in the most recent ath5k tree I have here. This means you're likely not missing events; but you're likely always scanning those queues. Making this code a bit pointless. :) Yup we don't clean them but that's not a bug, we still only check active queues that produced interrupts, not everything. Anyway we have txq-lock already so it's not a big deal to implement this I'll post a patch on top of this patchset. Right. but you're likely only using one active TXQ (and then CAB and beacon queues, which you may not be actually checking the completion status of) it won't matter. It just means if people start using 1 hardware TXQ, you're going to check the completion status on all of them. That's not a big deal, it just means you'll spend some CPU cycles and memory accesses checking queues you don't need to. You can't protect that interrupt field behind the TXQ lock either, since you'll have multiple reader/writers from outside the TXQ. Hence why I put it behind my PCU lock (which I use to protect shared PCU state, rather than PCU access like how felix did with ath9k.) Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH v2 01/12] ath5k: Switch from read-and-clear to write-to-clear method when handling PISR/SISR registers
Hi, Review #2: One thing that I discovered whilst debugging some silly races in FreeBSD was that the update of the txq active mask wasn't done atomically. Ie, when you check this: +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1689,7 +1689,7 @@ ath5k_tasklet_tx(unsigned long data) struct ath5k_hw *ah = (void *)data; for (i = 0; i AR5K_NUM_TX_QUEUES; i++) - if (ah-txqs[i].setup (ah-ah_txq_isr BIT(i))) + if (ah-txqs[i].setup (ah-ah_txq_isr_txok_all BIT(i))) ath5k_tx_processq(ah, ah-txqs[i]); The way that the original code did it was: * update the HAL TX mask bits inside the HAL getisr routine, so it would just update the HAL idea of txqactive; * Then, ath_hal_gettxintrtxqs() would pass back to the driver the set of txq bits currently active, and reset those that are active (with a mask, so you can read only a few) * the ath_intr() routine would simply schedule a tasklet call when a TX interrupt came in; * .. and then the TX completion tasklet would call ath_hal_gettxintrtxqs() for each task bit to see if it needed servicing. Now, in previous generations of hardware/kernel, this may not have raced - ath_intr() may have been a fast interrupt handler and thus would occur atomically on a single CPU - so you don't have any races. But these days, ath_intr() is just a software interrupt and can occur in parallel with another CPU executing the completion handler. So since there was no locking around the TXQ bit updates and clear, it was very possible that a very busy TX device would miss TX queue notifications, as the CPU running the TX completion would read-and-clear the TXQ active bits in the HAL, whilst another CPU was running ath_intr() which was trying to do a read/modify/write of those same bits. I _think_ felix fixed this in ath9k by hiding this stuff behind the PCU lock. I've also fixed it in FreeBSD. I think it's worth re-evaluating what is going on in ath5k and maybe add some similar locking. Oh wait. Where are you clearing these bits? It doesn't look like you're even clearing the ah_txq_isr bits in the most recent ath5k tree I have here. This means you're likely not missing events; but you're likely always scanning those queues. Making this code a bit pointless. :) Anyway, I'd tidy this all up in a subsequent patchset. Get the interrupt changes in, then figure out how to properly lock the interrupt TXQ bit set path (the isr) and the clear path (once you've tested whether the TXQ needed servicing and then cleared the bit.) HTH, adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] A weird hw crypto bug...
Well, unless that vendor spun their own silicon, or there's something funky on the board that'd change crypto behaviour, the only thing I can really think of are EEPROM settings. Or maybe the MAC revision is slightly different, I dunno. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] A weird hw crypto bug...
On 21 November 2011 19:16, Albert Gall ss3...@gmail.com wrote: The same problem described in this thread appear AR2414 hardware. Loading ath5k with nohwcrypt = 1 everything works fine, attached information and evidence that I hope will be useful. If you need more please just ask. Well, what would be useful is figuring out why the frames are being dropped in the first place. Nick, did you get verification whether this is a bug with crypto TX, RX or both? Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] A weird hw crypto bug...
2011/11/22 Gábor Stefanik netrolller...@gmail.com: My guess is that they are using some king of ES/pre-production silicon that should have been destroyed, but was instead dumped on the black/grey-market. That should be pretty clear by the MAC major/minor revision. Maybe if someone can write down the exact part number from the MAC itself. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] A weird hw crypto bug...
On 21 November 2011 12:08, Nick Kossifidis mickfl...@gmail.com wrote: Some time ago we had a few reports of AR2413 cards being unable to encrypt packets of specific lengths. From https://bugs.launchpad.net/ubuntu/+source/linux/+bug/568090, user Musaraigne did some further investigation/debuging on this: The cause of the high and unpredictable latencies is that packets are dropped depending on their size. According to my tests, packet sizes of the form size = 128*k + 81 + m or size = 128*k + 105 + m for any k=2 and 0=m=7 are dropped randomly in 90-95% of the cases. Conversely, all other packet sizes work fine. That seems a bit odd. Erm, how do they fail? * Does the hardware just plain fail at encrypting the frame? * Does the hardware just plain fail to _TX_ the frame of that size? (ie, if you disable crypto and take padding into account, does it fail?) * What about other encryption types? AES? TKIP? WEP? None? :-) * This is a PCIe NIC, right? Are there some kind of weird bus bugs that you're seeing with this particular NIC and this particular bus glue? Since Madwifi works, I wonder if FreeBSD also works. If so, there's only a few places I'd bet you'll find weird stuff: * how the bus is setup during attach (eg overriding PCI values); * which crypto key slots are allocated; * are you still doing split keys on that hardware? or are they combined like the ar5416+ chips are? * are you perhaps doing multi-descriptor TX frames and you've not set the encryption bits correctly? IIRC, the enctype field needs to match on all descriptors of a frame (eg, if your packet is a chain rather than a single skb, you need to make sure you're copying the descriptor fields right.) * what about the frame and header length fields? and encryption padding? are they all setup the same with madwifi versus ath5k? I bet a bit of methodical poking is going to reveal this bug. I find it rather annoying that ath5k/ath9k have lots of encryption issues but I've not had any reports of encryption on FreeBSD failing (save where the AP is totally lying about which keyidx a frame is encrypted with.) It's possible that you're seeing these errors because more people are using ath5k then FreeBSD, but still: * does freebsd-9 (wifi) work on the same hardware? Nick, can you find out if someone can send us one of these weird NICs? I'll throw it into my pile-o-old-stuff-to-test and do some regression testing with it. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] force AR5212 to sleep
Hm, have you looked to see whether you're then touching any of the registers you shouldn't touch? Ie, some parts of the chip are now asleep, so you may not be able to do things like calibration whilst it's asleep. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Performance regression between Madwifi/net80211 and ath5k/mac80211
.. does madwifi have that net80211 aggressive mode by default, where it overrides the best-effort WME queue parameters to allow for bursting? I see exactly that difference in FreeBSD (33mbit vs 22mbit) when I disable that aggressive mode code. Thanks, Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Unexpected transmission delay following beacons
Is there stuff in the cabq? Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [RFT][PATCH] ath5k: Add rfkill_disable module parameter
I haven't read the ath5k code, but I do know the HAL code has stuff to glue the GPIO pin in question to the baseband so it becomes a hard kill. Also, as I said privately, I think interrupt may be broken on some NICs. Have you guys thought about doing polling to see if the GPIO pin is actually measurably going up/down, and just not sendng an interrupt? (Going by conjecture/reading here; I've not tinkered with rfkill yet.) Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Computing packet transmission time in ath5k
You should only add to your channel usage estimate it if the buffer has been marked complete - ie: * the status bit in the descriptor indicates DMA is complete; * .. and the relevant flags say that it did go on the air or try to go on the air - ie, it can fail but still have been attempted. I don't have the code open in front of me but i bet it's pretty clear when the descriptor has been classified as complete, successful or otherwise. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Computing packet transmission time in ath5k
On 13 September 2011 00:27, Bob Copeland m...@bobcopeland.com wrote: The hardware handles it - the tx descriptor specifies a list of rates and number of attempts to retry the frame and the hardware reports back how many tries at which rates were used (of course upper layers might retransmit packets unknown to ath5k but that is a different matter.) And for the sake of completeness (and freebsd-specific; someone can figure out how this is done in ath5k) there's configuration to determine: * the CW min, max values; * the backoff algorithm used - it should be a binary exponential by default * the frame RTS/CTS try limit - according to the documentation, the try count in the descriptor is the number of air attempts (ie, the frame is put in the air but not ACKed) - ie long retries, versus RTS attempts (short). The relevant bits from the FreeBSD ar5212 HAL: cwmin, cwmax, aifs: /* set cwMin/Max and AIFS values */ OS_REG_WRITE(ah, AR_DLCL_IFS(q), SM(cwMin, AR_D_LCL_IFS_CWMIN) | SM(qi-tqi_cwmax, AR_D_LCL_IFS_CWMAX) | SM(qi-tqi_aifs, AR_D_LCL_IFS_AIFS)); Retry limit values: /* Set retry limit values */ OS_REG_WRITE(ah, AR_DRETRY_LIMIT(q), SM(INIT_SSH_RETRY, AR_D_RETRY_LIMIT_STA_SH) | SM(INIT_SLG_RETRY, AR_D_RETRY_LIMIT_STA_LG) | SM(qi-tqi_lgretry, AR_D_RETRY_LIMIT_FR_LG) // Frame short retries (RTS) before the current TX series is failed | SM(qi-tqi_shretry, AR_D_RETRY_LIMIT_FR_SH) // Frame long retries (data TX with no ACK) before the current TX series is failed ); The TX descriptor completion status indicates RTSFail and DataFail counts - which are valid for the final TX series. FinalTsIdx tells you what the final Tx series was. I'm sure there's code in ath5k which will figure out how many actual failures that is based on the TX queue config. You can get a decent enough idea of the attempted TX time. Just please keep in mind that this doesn't tell you how long the hardware waited to try and transmit the frame. You can likely calculate the per-attempt duration and cumulative backoff times, but not the time after backoff whilst it waits for a quiet period to TX in. I _think_ that's all correct. Good luck. :) Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Computing packet transmission time in ath5k
Hi, This isn't strictly involved in fixing your problem, but when you do get it fixed, you're going to notice a bunch of discrepancies: * the ack calculation is lifted from elsewhere in the code, but please note that they use the basic rate for ACKs, not the current TX rate. Please re-read the code in qcu.c that calculates the ack_tx_time :-) * your airtime calculation isn't taking into account the hw rate being used when doing multi-rate retry. * your airtime calculation doesn't take into account how many short/long retries were taken. * what about the RTS frame (and the rate it's TXed at, which can be different to the frame rate) ? And then the time spent on the return CTS? Just stuff to think about :) adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k fails to activate card
You could just look at the code in ath5k/rfkill.c and just comment out
the code that glues together the rfkill GPIO pin to the rfkill
personality.
(ie, GPIO pins have personalities, they can be configured as input,
output, rfkill to the baseband, other stuff..)
If the pin isn't configured as having the rfkill personality and if
rfkill isn't configured in general, then the state of pin 13 shouldn't
matter..
adrian
On 4 August 2011 16:40, Antonis Tsolomitis antonis.tsolomi...@gmail.com wrote:
I am sorry, I do not understand anything from the below technical message.
Does this mean that the only solution is to cover pin13?
Can't it be done with ath5k? It was working fine with ath_pci. So the
code in ath_pci exists.
It can't be so difficult to fix...
Antonis.
Στις 04/08/2011 01:58 πμ, ο/η Adrian Chadd έγραψε:
Obviously, something is wrong with ath5k. If the device is hard
blocked, how come it can be enabled by disabling rfkill? We need to
change the logic here. If the pin 13 can be overridden, it should be
treated like an input device, not as a hardware block.
It looks like you can disable the GPIO personality by disabling that
its wired to the baseband rfkill.
ath5k seems to let you program the GPIO pin value and have that
control rfkill in software.
I haven't tried that though. The point is, the GPIO pin is configured
as an input to rfkill, rather than a generic input pin.
The reference driver doesn't enable it for interrupts for all hardware:
if (capability == 3) { /* rfkill interrupt */
return ((IS_5424(ah) || IS_2425(ah)) ?
HAL_ENOTSUPP : HAL_OK);
}
.. looks like FreeBSD may need to be taught this too. I'll have to do
some digging to see why this is the case.
Adrian
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] disable ACK at MAC layer in ath5k/ath9k
On 11 June 2011 11:15, Liang leonc...@gmail.com wrote: Hi Adrian, It really works! When adding the REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_ACK_DIS) after ath9k_hw_process_ini(), Wireshark monitors no IEEE ACK any more. There is another question. It is found the transmission rate is really low even with UDP packets after disable the ACK. Does it mean some related setting/code is needed in the transmitter side to cooperate the receiver's no ACK? Well, if you're disabling ACK, then the receiving side won't be able to tell you that it's been successful so you can't retransmit. :) That means any and all collisions, any transient noise, etc is going to be hurting you. Wireless isn't, you know, perfect. :-) I suggest looking at the receiver errors (CRC for example) and see if they're coinciding with your UDP traffic flow. I also suggest looking at using RTS/CTS as well to see if this helps. Since you're not using any ACKs (and if you're not using contention-free periods and WME/QoS), then it's possible other devices are colliding with your TX. Using RTS may reduce this collision rate somewhat. HTH, Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] disable ACK at MAC layer in ath5k/ath9k
Best thing to do is look at the code that disables ACK in the TX descriptor and set that. There's also the DIAG register, as mentioned. For ath9k: reg.h:#define AR_DIAG_SW 0x8048 reg.h:#define AR_DIAG_ACK_DIS 0x0002 Find where AR_DIAG_SW is set in the ath9k code (it's fiddled with in a few places) and call the REG_SET_BIT() appropriately. Do the same for ath5k once you find the right register/field definition. HTH, Adrian On 9 June 2011 15:03, Liang leonc...@gmail.com wrote: Hi Adrian, Thank you. May I ask how to set these registers to disable the ACK in the ath5k/ath9k driver? Best, Leon On Thu, Jun 9, 2011 at 2:32 PM, Adrian Chadd adr...@freebsd.org wrote: No, retry doesn't stop ack's, it just stops the hardware from retrying a packet if it hasn't heard an ACK. You can fiddle with the diag register, or you can just ensure that the relevant bit in the TX descriptor isn't set. fgrep NOACK ath9k/*.h mac.h:#define ATH9K_TXDESC_NOACK 0x0002 fgrep NOACK ath5k/*.h fgrep NOACK *h desc.h:#define AR5K_2W_TX_DESC_CTL1_NOACK_5211 0x0080 /* [5211] no ACK */ desc.h:#define AR5K_4W_TX_DESC_CTL1_NOACK 0x0100 /* no ACK */ desc.h:#define AR5K_TXDESC_NOACK 0x0002 /*[5211+]*/ There's likely some API you can use at a higher level to signify to the TX code that no, you don't want an ACK for the packet. Eg, look at ath9k/setup_tx_flags(): struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb); ... if (tx_info-flags IEEE80211_TX_CTL_NO_ACK) flags |= ATH9K_TXDESC_NOACK; HTH, Adrian On 9 June 2011 13:55, Liang leonc...@gmail.com wrote: Hi, I want to know if the ACK at 802.11 MAC layer can be turned off in the ath5k/ath9k, and how can it be done? On the other hand, does the command iwconfig wlan0 retry 0 disable the MAC retransmission? Is it the same to turnoff the ACK? Thank you! Best, Leon ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Connecting BlackBerry to hotspot
On 9 June 2011 20:00, Bob Copeland m...@bobcopeland.com wrote: http://linuxwireless.org/en/users/Documentation/Bluetooth-coexistence From that page: Apart from AFS and channel skipping techniques Bluetooth coexistence is typically tested with bundled 802.11 and Bluetooth devices. This becomes more evident with 2-wire and 3-wire which relies on GPIO pins for signaling. In other words, the devices have to be in the same system so that the 802.11 device can tell the BT device to stop transmitting by asserting some signals on the shared lines. This is how I understand ath9k's bt coex to work, at least. Right, and the original poster: Today after installing compat-wireless modules with still no luck as a last resort i decided to turn of BT and take out BT dongles from hotspot's USB HUB. Guess even if AR5212 did have bluetooth coexistence support, there's no IO lines coming from the bluetooth device which are twiddling the btcoex GPIOs. Damn. :-) Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] disable ACK at MAC layer in ath5k/ath9k
I'd likely slide it in somewhere after ath9k_hw_process_ini() in ath9k_hw_reset(). Good luck! Adrian On 9 June 2011 21:54, Liang leonc...@gmail.com wrote: Hi, There are three functions where AR_DIAG_SW is set with REG_SET_BIT(), but I'm not sure in which function I should add REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_ACK_DIS). Do you have any suggestions? function1: ath9k_hw_abort_tx_dma() REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_FORCE_CH_IDLE_HIGH); function2: ath9k_hw_setrxabort() REG_SET_BIT(ah, AR_DIAG_SW, (AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT)); function3: ath9k_hw_abortpcurecv() REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_RX_ABORT | AR_DIAG_RX_DIS); Thank you. Best, Liang On Thu, Jun 9, 2011 at 4:07 PM, Adrian Chadd adr...@freebsd.org wrote: Best thing to do is look at the code that disables ACK in the TX descriptor and set that. There's also the DIAG register, as mentioned. For ath9k: reg.h:#define AR_DIAG_SW 0x8048 reg.h:#define AR_DIAG_ACK_DIS 0x0002 Find where AR_DIAG_SW is set in the ath9k code (it's fiddled with in a few places) and call the REG_SET_BIT() appropriately. Do the same for ath5k once you find the right register/field definition. HTH, Adrian On 9 June 2011 15:03, Liang leonc...@gmail.com wrote: Hi Adrian, Thank you. May I ask how to set these registers to disable the ACK in the ath5k/ath9k driver? Best, Leon On Thu, Jun 9, 2011 at 2:32 PM, Adrian Chadd adr...@freebsd.org wrote: No, retry doesn't stop ack's, it just stops the hardware from retrying a packet if it hasn't heard an ACK. You can fiddle with the diag register, or you can just ensure that the relevant bit in the TX descriptor isn't set. fgrep NOACK ath9k/*.h mac.h:#define ATH9K_TXDESC_NOACK 0x0002 fgrep NOACK ath5k/*.h fgrep NOACK *h desc.h:#define AR5K_2W_TX_DESC_CTL1_NOACK_5211 0x0080 /* [5211] no ACK */ desc.h:#define AR5K_4W_TX_DESC_CTL1_NOACK 0x0100 /* no ACK */ desc.h:#define AR5K_TXDESC_NOACK 0x0002 /*[5211+]*/ There's likely some API you can use at a higher level to signify to the TX code that no, you don't want an ACK for the packet. Eg, look at ath9k/setup_tx_flags(): struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb); ... if (tx_info-flags IEEE80211_TX_CTL_NO_ACK) flags |= ATH9K_TXDESC_NOACK; HTH, Adrian On 9 June 2011 13:55, Liang leonc...@gmail.com wrote: Hi, I want to know if the ACK at 802.11 MAC layer can be turned off in the ath5k/ath9k, and how can it be done? On the other hand, does the command iwconfig wlan0 retry 0 disable the MAC retransmission? Is it the same to turnoff the ACK? Thank you! Best, Leon ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Connecting BlackBerry to hotspot
On 9 June 2011 04:34, Piotr Kaczorek piotrkaczo...@bluetrace.eu wrote: Sorry for no new packet dumps yet but i wanted to tell you that i've found a possible reason. Bluetooth. Our hotspot has 'a lot of bluetooth going on' on it. Today after installing compat-wireless modules with still no luck as a last resort i decided to turn of BT and take out BT dongles from hotspot's USB HUB. Magically BB started showing pages on atheros. Doe's anyone know a solution for that (except not using WiFi or BT:) ) ? I guess I blamed ath5k driver without a reason, sorry for that. Hm, is there BT coexistance support for ath5k? Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Connecting BlackBerry to hotspot
On 9 June 2011 09:01, Bob Copeland m...@bobcopeland.com wrote: Hm, is there BT coexistance support for ath5k? No, but my understanding is that BT coex support is only for co-located devices, so unless the phone is using ath5k it wouldn't help here. From my understanding, bluetooth coexistance is so devices don't tx/rx interfere with each other. Ie, what you don't want is the wifi device RX'ing whilst the bluetooth device is TX'ing; you don't want the wifi device TX'ing whilst the bluetooth device is also TX'ing. I could be off though, I haven't yet written any btcoex code for FreeBSD (as I just don't currently have any hardware that supports it.) http://linuxwireless.org/en/users/Documentation/Bluetooth-coexistence I guess one could try using a different channel for the AP or fiddling with the transmit power in hopes of making the channel avoidance on the BT device work better, but I don't know if there's anything more that could be done. There's mention on that page of bluetooth devices being able to be told about BT channel ranges which they shouldn't use; you could then program the ap and BT device to use non-conflicting channel ranges. How this is done though is an exercise left to the reader. Also, I've no idea if the AR5212 era devices support bluetooth coexistance. I'd have to do some further digging into the historical archives to check. FreeBSD (which uses the older HAL based code) certainly doesn't have btcoex code for the chipsets. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Connecting BlackBerry to hotspot
It may also be the different 802.11 layer; it doesn't have to be ath5k specific. I know there's an outstanding bug with FreeBSD (which uses net80211, like madwifi does) with power save queue management timers being off-whack and that appears like this, also I found this comment in the source: /* * NB: We used to deauth the station but it turns out * the Blackberry Curve 8230 (and perhaps other devices) * sometimes send the wrong AID when WME is negotiated. * Being more lenient here seems ok as we already check * the station is associated and we only return frames * queued for the station (i.e. we don't use the AID). */ That's in hostap_recv_pspoll(), which is handling the power-save polling stuff. Good luck! Adrian On 12 May 2011 05:14, Piotr Kaczorek piotrkaczo...@bluetrace.eu wrote: W dniu 11.05.2011 06:05, Bob Copeland pisze: On Tue, May 10, 2011 at 9:42 AM, Piotr Kaczorek piotrkaczo...@bluetrace.eu wrote: Is there any known problem with BlackBerry phones? I've set up hotspot (ath5k + hostapd). Any device can connect to it and use it (SE P1i, few laptops, iPhone) except BlackBerry (Curve 8520) phone. It connects to Wifi but i cannot access any website (it displays can't find server message). Maybe it's an issue with power management My guess is this. Probably blackberry is going to sleep and missing (or ath5k is not sending) the beacons along with all of the buffered traffic. (http://thread.gmane.org/gmane.os.freebsd.current/110707)? A timeout? I have no idea where to look further for a solution. Try to get a packet capture with a second device, and see if the AP is sending when the station is in power save mode. Thanks for your suggestions, i'll probably try that if i will stay with ath5k. Confirmed this is definately a matter of ath5k driver. I tried madwifi and BlackBerry worked. Of course i've got the Stuck beacon problem on madwifi. Now I'll have to make a decision - try to fix ath5k, try to find working madwifi or leave atheros at all and try different wifi card/chipset. ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Regression - adhoc mode awful throughput
The obvious question - have you bisected the kernel versions to find which one introduced this regression? Adrian On 30 April 2011 03:13, Denis Periša de...@si-wifi.org wrote: Hello to all, I have problem since 2.6.38 kernel. I use link in ad-hoc mode between two nods. Link is 5ghz (channel doesn't seem to matter.. let's say 120). On 2.6.37 kernel I have link speeds up to 25mbit/s.. with 2.6.38 (and latest wireless-testing.git) I have like 1,2mbit/s When I force 54M rate, then it goes up to maximum 7mbit !! This is disaster... I've been waiting long time for someone to fix it in wireless-testing but nothing so far.. I'm I first to report this? Thank you! ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] Coverage Class troubles?
This is just my off-the-morning-coffee calculation without (yet) having any experience with the coverage class parameters, but: * light travels roughly 300m/microsecond sec; * means you're going to travel 36.6 microseconds for 11,000 metres, so call it 37 microseconds. * the AR_D_GBL_IFS_MISC_SIFS_DURATION_USEC field is yes, mask 0x3f which gives it a total value of 63 microseconds. Turbo mode fiddles with the clocks-per-usec parameters, but the SIFS duration above is in microseconds, not core clocks. Not changing the ACK/CTS timeout values (which -are- in core clocks) when turbo or XR mode is engaged is also likely a bug; would the person who recently committed the speed changes please stand up and review these, like I suggested when the patch first came out? :) Thanks for reminding me that I should fix this in my own tree, btw. :) Adrian On 22 March 2011 01:45, Steve Brown sbr...@cortland.com wrote: I'm trying to replace an existing 900MHz 11000 meter link w/ two Alix boxes with Ubiquiti XR9's. These are Atheros Communications Inc. AR5413 802.11abg NIC (rev 01) radios that down convert to the 900MHz ISM band. I'm using a 5MHz channel. The units run flawlessly at short distances, but repeatedly connect and drop out at 11000 meters. As the current link's signal is 6dB over noise, I've discounted signal strength as the problem. My spec analyzer says the part of the band I'm using is fairly quiet and that the bandwidth of the radios is 5MHz. So, that leaves coverage class. Without the knowledge to verify the coverage class logic, I compared the values of the IFS_SIFS, IFS_SLOT, IFS_EIFS, IFS_MISC and TIME_OUT registers for various values of coverage class with the closed hal madwifi r3314. I used a 20MHz channel. The comparisons are attached. Given the same coverage class, the values are quite different between the two drivers. I also collected the register values for various coverage classes for ath5k using a 5MHz channel. The madwifi driver doesn't do 5MHz channels. The value computed for SIFS_DUR_USEC is 0x40 which is larger than the mask for that field (0x3f) in IFS_MISC. So that computation is suspect. Also, the ack/cts timeout values don't get changed from the default values to the 5MHz values unless a set coverage class command is issued. I've attached that collection as well. I'm not sure where to go from here. Steve ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k power drops in the presence of interference
Does it do the same in 11bg mode? Does madwifi behave the same way? Don't forget to include the MAC/radio chipset and revision details; those who know how the radios work will likely need that. Adrian On 17 March 2011 16:45, Alex alfr...@gmail.com wrote: Hi, the last few days i've been experimenting with ath5k and its behaviour under interference (through a jammer in a neighbour channel). I used a sender and a reveiver in IEEE 802.11a and in adhoc mode. I collected SNR measurements in the receiver node. Whenever jammer was on, SNR dropped at the receiver. I then used airmagnet to monitor the signal strength of the sender. Suprisingly i noticed that the tranmission power of the sender drops frequently when jammer was on; therefore SNR at the receiver dropped because the signal of the sender dropped and not because noise was increased. Then i connected the sender and the receiver through an airlive AP. I monitored the SNR at the receiver, capturing airlive's packets only. No SNR drops when jammer was on. So i conlcude: 1) Ath5k's transmission power for some reason drops when interference is present. 2) SNR does not drop in the presence of interference (when an AP with a stable transmission power is used), meaning that the noise measured does not include interference. Any comments are welcome. Alex ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] RSSI (or SNR) for IEEE 802.11a and b/g
Have you also added a hook or two to monitor what's going on to the noise floor? IIRC, atheros radios report RSSI as an offset from the current NF; if the NF raises but the signal doesn't, RSSI will decrease. Adrian On 3 March 2011 11:50, Alex alfr...@gmail.com wrote: Hi, i'd list to ask the members of this list regarding the value rs-rs_rssi ath5k reports in the ath5k_receive_frame function. I use a monitor node (its interface set to promiscuous mode) and i collect the rssi values (rs-rs_rssi) in a per packet basis (i' ve modified base.c). I use an interferer (this is an IEEE 802.11 compatible node working in adjacent channels) and i monitor the rssi of the packets sent by an access point . Whenever i work in IEEE 802.11a, i can see that RSSI (or SNR) drops when interferer is on. However, whenever i work in IEEE 802.11g there are no SNR drops, although the interferer succesfully jams the channel. I've repeated the experiments with ANI disablesd but still SNR does not drop in g. Any ideas? Thanks, Alex ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] RSSI (or SNR) for IEEE 802.11a and b/g
Well, the first thing that immediately springs to mind there is 11g == OFDM and CCK, but 11a == OFDM only. You may find the CCK stuff behaves differently in the presence of noise. You could also try fiddling with ANI (is there ani in ath5k?) which has some parameters for controlling CCK sensitivity/threshold/trigger levels. HTH, Adrian On 3 March 2011 12:24, Alex alfr...@gmail.com wrote: I'll try this thanks. Another thing i've noticed is that whenever Ath5k works in g mode, it reports no PHY or CRC errors, although inteferer is running. This is not the case when the driver is in 802.11a mode. Alex On 3/3/2011 9:59 μμ, Adrian Chadd wrote: Have you also added a hook or two to monitor what's going on to the noise floor? IIRC, atheros radios report RSSI as an offset from the current NF; if the NF raises but the signal doesn't, RSSI will decrease. Adrian On 3 March 2011 11:50, Alex alfr...@gmail.com wrote: Hi, i'd list to ask the members of this list regarding the value rs-rs_rssi ath5k reports in the ath5k_receive_frame function. I use a monitor node (its interface set to promiscuous mode) and i collect the rssi values (rs-rs_rssi) in a per packet basis (i' ve modified base.c). I use an interferer (this is an IEEE 802.11 compatible node working in adjacent channels) and i monitor the rssi of the packets sent by an access point . Whenever i work in IEEE 802.11a, i can see that RSSI (or SNR) drops when interferer is on. However, whenever i work in IEEE 802.11g there are no SNR drops, although the interferer succesfully jams the channel. I've repeated the experiments with ANI disablesd but still SNR does not drop in g. Any ideas? Thanks, Alex ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k phy0: can't reset hardware (-5)...
Just as a reference, does madwifi exhibit this behaviour? Adrian On 3 March 2011 13:14, Fabrice fabricedey...@agilemesh.com wrote: I'm now able able to prevent the CM9 to lock up. I changed the RX/TX DMA burst size from 128 bytes to 16 bytes. When I stream TCP data, I still some issues. The TX queue gets stuck and when it tries to reset it cannot stop the RX dma. ath5k phy0: (ath5k_tx_complete_poll_work:2306): TX queue stuck 2 ath5k phy0: (ath5k_tx_complete_poll_work:2321): TX queues stuck, resetting ath5k phy0: (ath5k_reset:2665): resetting ath5k phy0: (ath5k_hw_stop_rx_dma:77): failed to stop RX DMA ! ath5k phy0: (ath5k_rx_start:1120): cachelsz 32 rx_bufsize 2368 As a result my TCP connection is interrupted and recovers. Here are the queue stats from debugfs: available txbuffers: 196 00: setup len: 0 bufs: 0 stuck: 0 01: setup len: 0 bufs: 0 stuck: 0 02: setup len: 4 bufs: 4 stuck: 16 03: setup len: 0 bufs: 0 stuck: 0 04: not setup 05: not setup 06: setup len: 0 bufs: 0 stuck: 0 07: not setup 08: not setup 09: not setup As a side note, on the same platform (ARM9-297 Mhz)I can have an AR9160 or AR9220 (using ath9k) it works great. Any idea why with ath5k I'm running inot these issues? ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] (multicast) key search documentation and behaviour for the AR5213?
Hi all, I'm working on fixing up the FreeBSD ath codebase, both for new 11n chipsets and older chipsets that ath5k supports. I've noticed something strange with the AR5213. (I don't have any AR5212 chips or variants thereof.) It happens on MIPS, not on i386. It doesn't happen with exactly the same software when using an AR9160. For broadcast packets sent w/ WPA encryption, matching a keycache entry, I see corruption which always begins in the packet half-way through the IV word. So, the first four bytes of the IV are fine, but everything after byte 5 (and the payload) are corrupt. After the first group rekeying from hostap, the problem rights itself. If I disable hardware encryption (which still uses keycache entries, they're just clear entries), I still see the packet corruption until the first group rekey. If I then disable the keyid on packets sent w/ a group key, the packets are correctly TX'ed verbatim. WEP and OPEN are fine. Has anyone seen this behaviour before? Is there any documentation available on the AR5213 keycache behaviour, both normal and broadcast? Why would this occur even when it's not doing hardware encryption? There's a couple of hints in the codebases: * AR_KEYTABLE_VALID is in the ath9k/ath5k shared code, but from what I can gather it's involved in packet RX, not TX. Is this right? * Is the multicast keycache search behaviour briefly touched on here and there in the codebases for packet TX, RX, or both? * This comment seems a bit misleading: /* * Group key allocation must be handled specially for * parts that do not support multicast key cache search * functionality. For those parts the key id must match * the h/w key index so lookups find the right key. On * parts w/ the key search facility we install the sender's * mac address (with the high bit set) and let the hardware * find the key w/o using the key id. This is preferred as * it permits us to support multiple users for adhoc and/or * multi-station operation. */ But if I program the hardware with the high bit set in the MAC entry, then TX packets without a key id set, it doesn't seem to match the keycache entry and the packet isn't encrypted. Any/all help and pointers will be very appreciated, thankyou. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
