Re: [ath9k-devel] ath9k_htc test release: please test
Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Virtual AP spanning multiple radios for transparent roaming?
Hi everybody! I'm having issues with roaming - switching from one AP to another AP (different bssid, same ssid) takes in the order of seconds, which disturbs voice over ip calls and streaming. I'm quite new to 802.11 networking and did a bit of reading and fiddling around sending/receiving frames in monitor mode, and had the following idea (not sure if good or bad though): - all access points are tuned to the same channel - all access points use the same bssid - the access points use a wired network to interchange association information: which AP is responsible to what STAs (by mac address). - handling authentication frames is done centralized - the access point responsible for a STA will ACK and pass a received frame - frames to be transmitted are forwarded to the AP handling the STA and send there. - all APs see all frames in their range, and keep a list of the RSSI for each STA, if a station moves another AP can take over the responsibility for a station. The expected result is that a station only sees one access point which is always nearby and always has good signal strength. Now there are some problems: 1. first of all, sending ACK/CTS/RTS frames seems to be done in the driver firmware (I'm using ath9k), at least nothing that can be handled using monitor mode. 2. using the same channel could increase contention 3. as said I'm not really familiar with 802.11, there are probably other things i've missed. Has anyone an idea for me how to get started or why to leave it altogether? I'm not subscribed to this list, please include my email in answers. Thank you very much, Moritz smime.p7s Description: S/MIME cryptographic signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi Vikranth, i cant find detailed description of this problem. Can you please attach patches you use for debugging and information about your testing setup, hw, usb controller, etc. Please describe symptom of this problem, for example connection lost etc. Am 16.10.2013 12:19, schrieb vikranth reddy: Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe its only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless its really obvious to fix, Im just going to leave this as-is as its the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Virtual AP spanning multiple radios for transparent roaming?
Hi Kyle, for this scheme to work it would be required that all access points operate on the same channel. Changing the channel would require a different bssid so the station would reassociate, which is what I want to avoid, as it causes the network connectivity to be unavailable for nearly 5 seconds (which I still do not understand; reassociation should only take a couple of ms) Thank you! Moritz On 16.10.2013, at 16:24, Kyle Bassett kylebass...@gmail.com wrote: Same channel configurations are evil. Make one change: assign the APs to different channels and report back. Do you have a physical topography diagram to scale? What brand APs? What is the average range with only one unit turned on? Good luck! On Oct 16, 2013 9:09 AM, Moritz Möller mmoel...@mxs.de wrote: Hi everybody! I'm having issues with roaming - switching from one AP to another AP (different bssid, same ssid) takes in the order of seconds, which disturbs voice over ip calls and streaming. I'm quite new to 802.11 networking and did a bit of reading and fiddling around sending/receiving frames in monitor mode, and had the following idea (not sure if good or bad though): - all access points are tuned to the same channel - all access points use the same bssid - the access points use a wired network to interchange association information: which AP is responsible to what STAs (by mac address). - handling authentication frames is done centralized - the access point responsible for a STA will ACK and pass a received frame - frames to be transmitted are forwarded to the AP handling the STA and send there. - all APs see all frames in their range, and keep a list of the RSSI for each STA, if a station moves another AP can take over the responsibility for a station. The expected result is that a station only sees one access point which is always nearby and always has good signal strength. Now there are some problems: 1. first of all, sending ACK/CTS/RTS frames seems to be done in the driver firmware (I'm using ath9k), at least nothing that can be handled using monitor mode. 2. using the same channel could increase contention 3. as said I'm not really familiar with 802.11, there are probably other things i've missed. Has anyone an idea for me how to get started or why to leave it altogether? I'm not subscribed to this list, please include my email in answers. Thank you very much, Moritz ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel smime.p7s Description: S/MIME cryptographic signature ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc test release: please test
Hi, Is this for aggregate frames? If it is, I _think_ aggregate frames only have a valid timestamp in the _last_ subframe. -adrian On 16 October 2013 08:11, Oleksij Rempel li...@rempel-privat.de wrote: Hi Vikranth, i can't find detailed description of this problem. Can you please attach patches you use for debugging and information about your testing setup, hw, usb controller, etc. Please describe symptom of this problem, for example connection lost etc. Am 16.10.2013 12:19, schrieb vikranth reddy: Hi Adrian, List, We are still finding the same negative timestamp difference (between consecutive packets) issue with some of packets, with latest ath9_htc open-source firmware version. Adrian, Did you add this fix into open-source version of ath9k_htc firmware already? or still its not updated in it. Thanks Vikranth On Tue, Dec 4, 2012 at 11:36 AM, vikranth reddy vikranth.reddydevelo...@gmail.com mailto:vikranth.reddydevelo...@gmail.com wrote: Hi Adrian, Sorry for delayed reply! Here the debug-logs are added only for the cases where there is negative time-difference, not for success case. Logs below, that you pointed out, are not from consecutive packets. Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 All the guys here, who reported as successfully working, have tested with AR9271 not with AR7010+AR9280. Not sure if there is any difference between two firmwares (htc_7010.fw and htc_9271.fw). ? Like you mentioned we are measuring time-difference between two consecutive packets, irrespective of packet-type. That might have an issue still. Hope to see a fix for this issue in next official release Thanks for your support on this issue. Thanks Vikranth On Fri, Nov 30, 2012 at 11:13 PM, Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org wrote: As I said, the cozybit guys reported that the TSF increment is behaving correctly. Maybe it's only behaving correctly for beacons here, hm. Also, look: Nov 29 10 36 49 [ 122.787519] ###now = 64609 prev = 2683598441314 diff = -2683598376705 Nov 29 10 36 49 [ 122.947963] ###now = 2683598748946 prev = 2684354687871 diff = -755938925 Your now/prev values are all messed up, the second prev should been 64609, right? In any case, unless it's really obvious to fix, I'm just going to leave this as-is as it's the same behaviour as previous firmware. (Which is my aim here..) Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] rfkill-regulator.c:58:22: error
Hello getting the following error while make. Could somebody please help me to solve this. thanks in advance, BR, Namal I am gw namal@ubuntu:~/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new$ sudo make make -C /lib/modules/3.8.0-31-generic/build M=/home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new modules make[1]: Entering directory `/usr/src/linux-headers-3.8.0-31-generic' CC [M] /home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.o /home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.c:58:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rfkill_regulator_probe’ /home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.c:125:22: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘rfkill_regulator_remove’ /home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.c:139:11: error: ‘rfkill_regulator_probe’ undeclared here (not in a function) /home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.c:140:2: error: implicit declaration of function ‘__devexit_p’ [-Werror=implicit-function-declaration] /home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.c:140:24: error: ‘rfkill_regulator_remove’ undeclared here (not in a function) cc1: some warnings being treated as errors make[3]: *** [/home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.o] Error 1 make[2]: *** [/home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill] Error 2 make[1]: *** [_module_/home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-3.8.0-31-generic' make: *** [modules] Error 2 -- *Suneth Namal* Research Scientist/Doctoral Student, Center for Wireless Communication, University of Oulu, Finland Mobile: +358-41-728-2646 Mail: sune...@gmail.com msa...@gmail.com skype: sunethnamal ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] rfkill-regulator.c:58:22: error
On Thu, 17 Oct 2013 01:03:42 +0530 suneth namal sune...@gmail.com wrote: Hello getting the following error while make. Could somebody please help me to solve this. The problem has nothing to do with the ath9k driver. The compile error is in rfkill. /home/namal/compat-wireless-2012-07-16/compat-wireless-2012-07-16.new/net/rfkill/rfkill-regulator.o Your compat-wireless is more than a year old. Any problems in it are likely solved. Please try the latest kernel backports (successor to compat-wireless) and use their channels to report problem if any. https://backports.wiki.kernel.org/index.php/Main_Page -- Regards, Pavel Roskin ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
