On 28 October 2013 12:20, Ben Greear <gree...@candelatech.com> wrote:
>
> On 10/28/2013 07:34 AM, Джонатан Вашингтон wrote:
> > On 2013-09-19 17:01, James Hogan:
> >> I think I have stumbled on to the real issue. I'm sorry if I have been
> >> wasting your time at all. Apparently, the network is having problems
> >> with all wireless-n mode cards.
> >> The network doesn't like how wireless-n is roaming to the different AP's
> >> and is registering as me disconnecting when the wireless card tries to
> >> connect to roam to the other AP.
> >> It's not just ath9k though, Ra-Link and other cards are having these
> >> issues as well. Is there a way to disable or to make it possible to
> >> disable the wireless-n mode of the card and just
> >> use wireless abg? On a note, I noticed when I passed to the command line
> >> "iw event -r" that at about the time my card would scan, that is when I
> >> would stop receiving service even though
> >> my cards never registered as being disconnected. After the scan, the
> >> card just continues to reissue scans. Sometimes however, it will try to
> >> reconnect me to the network.  I was talking to one of the IT employees
> >> in my class today and he said that they have been having this issue with
> >> all of the newer higher-end cards.
> >
> > I've been having a similar problem, potentially the same.  My
> > university updated the firmware in their access points in August, and
> > while I can still associate with the APs with no trouble, I can only
> > get traffic through for short periods of time.  As in James's case, I
> > seem to lose service around when my card scans.
> >
> > I have been told by my university's wireless team that they are aware
> > that this issue affects most linux users on campus, but don't
> > currently have any solution.  Their suggested work-around is to
> > disable 11n speeds, which apparently "solves" the problem for most
> > users.  However, while iwconfig can be used to set various rates when
> > connected to my 11g router at home, the speed seems to be locked at
> > 65Mbps when I'm associated with the router on campus.  That is, "sudo
> > iwconfig wlan0 rate 54M" and similar directives seem to have no
> > effect.
> >
> > For reference, I have an AR9285 card and so far have been using the
> > ath9k driver that comes with my 3.2.0 debian stock kernel (which might
> > technically be 3.2.41?).  I have noticed nothing unusual about using
> > any other networks, including 11n ones elsewhere.
> >
> > On 2013-09-21 05:40, Ben Greear wrote:
> >> If you are using ath9k rate control, please try disabling that and use
> > the minstrel-ht rate control instead.
> >>
> >> With a modern wpa_supplicant and kernel you can just disable HT in
> > the supplicant config, by the way.
> >>
> >>
> >> # disable_ht: Whether HT (802.11n) should be disabled.
> >> # 0 = HT enabled (if AP supports it)
> >> # 1 = HT disabled
> >> #
> >> # disable_ht40: Whether HT-40 (802.11n) should be disabled.
> >> # 0 = HT-40 enabled (if AP supports it)
> >> # 1 = HT-40 disabled
> >
> > I found I had an older version of wpa_supplicant (v1.0, which is what
> > appears to be current in debian unstable) that did not support
> > disable_ht and disable_ht40, so I downloaded a newer version (v2.0)
> > and compiled it with CONFIG_HT_OVERRIDES enabled.  Using that, I was
> > able to add disable_ht=1 and disable_ht40=1 to the network block of my
> > wpa_supplicant configuration file.
> >
> > When I run wpa_supplicant now in debug mode, it seems to parse these
> > directives, and even outputs lines like "wlan0: set_disable_ht40: 1"
> > where it seems to be telling the driver to disable the mode.  However,
> > iwconfig still indicates that the speed is 65Mbps, and no number of
> > times manually telling it otherwise seems to have any impact on it.
> >
> > I don't know whether this limitation is due to an issue with the ath9k
> > driver, with wpa_supplicant, or with something else, or is simply my
> > misperception of how things should work.  Either way, I'm tempted to
> > apply the patch to my ath9k source that James posted so that I can
> > disable 11n modes altogether, but I'm more than willing to try other
> > suggestions.
>
> I think your kernel is too old to support that feature, it is relatively
> recent.
>
> And, while I know it works with ath9k, I'm not sure it works with other
> drivers.
>
> Thanks,
> Ben
>
> --
> Ben Greear <gree...@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>



On 28 October 2013 11:47, Sujith Manoharan <suj...@msujith.org> wrote:
> Джонатан Вашингтон wrote:
>> For reference, I have an AR9285 card and so far have been using the
>> ath9k driver that comes with my 3.2.0 debian stock kernel (which might
>> technically be 3.2.41?).  I have noticed nothing unusual about using
>> any other networks, including 11n ones elsewhere.
>
> 3.2 is really old...
>
>> I don't know whether this limitation is due to an issue with the ath9k
>> driver, with wpa_supplicant, or with something else, or is simply my
>> misperception of how things should work.  Either way, I'm tempted to
>> apply the patch to my ath9k source that James posted so that I can
>> disable 11n modes altogether, but I'm more than willing to try other
>> suggestions.
>
> Can you try the latest backports release, using just wpa_supplicant and
> Network Manager disabled ?
>
> https://lkml.org/lkml/2013/10/27/149
>
> Sujith


With the driver from backports-3.10.17-1 (using my current kernel,
which turns out to be from debian testing, not debian unstable), I'm
able to adjust the speed manually, and disable 11n speeds in
wpa_supplicant config files.

However, as I found from other users who've encountered the same
limitation at my university, I must actually entirely disable 11n
speeds at the driver level.  It has something to do with speeds
presented as available during authentication, I guess?  Anyway, the
driver I compiled from backports doesn't seem to support this.  Would
the patch presented by James in September be a viable solution, or is
there some reason for me to avoid it?

-- 
Jonathan
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Reply via email to