lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130506153044.GB1602@redhat.com>
Date:	Mon, 6 May 2013 17:30:45 +0200
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Jake Edge <jake@....net>
Cc:	linux-wireless@...r.kernel.org,
	Johannes Berg <johannes.berg@...el.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Johannes Berg <johannes@...solutions.net>
Subject: Re: Bisected 3.9 regression for iwl4965 connection problem to
 1672c0e3

On Mon, May 06, 2013 at 08:37:59AM -0600, Jake Edge wrote:
> On Mon, 6 May 2013 14:38:06 +0200 Stanislaw Gruszka wrote:
> 
> > > I bisected the problem to:
> > > 
> > > commit 1672c0e31917f49d31d30d79067103432bc20cc7
> 
> > > What more information is needed from me?  I may still mess around
> > > with trying to revert that patch just to nail it down for sure, but
> > > two separate bisection exercises ended up at the same place.
> > 
> > Below patch should restore old mac80211 behaviour, by stop
> > telling mac that 4965 supports TX ACK status. Does it help?
> 
> Yup, that fixed the problem, thanks.  So did reverting Johannes's
> commit above, fwiw, but just turning off that flag in 3.9 as your patch
> does fixes it.
> 
> seems like that needs to head to Linus and the stable folks ...

We can fix the problem that way, but I'm not sure if that is the best
way. IEEE80211_HW_REPORTS_TX_ACK_STATUS is nice to have as long hardware
really supports that feature.

I thought this happen because 4965 firmware does not mark tx status
ack for PROBE_REQUEST frame, because it is not acked by standard 
ACK frame, but by PROBE_RESPONSE frame. But if so, I would also see
the breakage on my setup, but I don't - it works quite well here. So
perhaps something different is broken on commit
1672c0e31917f49d31d30d79067103432bc20cc7 , that make we can not
associate with some APs.

Let me think a bit longer about this issue. Also maybe Johannes will
have some thoughts.

Stanislaw 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ