Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135

Hi,

  I'm just wondering if you had any time to look at this? I'm happy to test
any patches or diffs.

Regards,
Tom

On Tue, Mar 11, 2014 at 11:03:20AM -0700, Adrian Chadd wrote:
> I still don't have any ideas here. I do however want to try hacking
> the driver to transmit EAPOL frames at the management rate, and then
> ensure the management rate is non-MCS.
> 
> 
> -a
> 
> 
> On 28 February 2014 15:14, Adrian Chadd <adrian_at_freebsd.org> wrote:
> > Hi,
> >
> > the interesting bits:
> >
> >
> > Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 3 len 129 nsegs 2 rate
> > 0002 plcp 0x0000420a
> > Feb 28 22:55:22 kernel: iwn_tx_data: qid 3 idx 4 len 129 nsegs 2 rate
> > 0002 plcp 0x0000420a
> > Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 3 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:22 kernel: iwn5000_tx_done: qid 3 idx 4 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 5 len 129 nsegs 2 rate
> > 0002 plcp 0x0000420a
> > Feb 28 22:55:23 kernel: iwn_tx_data: qid 3 idx 6 len 129 nsegs 2 rate
> > 0002 plcp 0x0000420a
> > Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 5 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:23 kernel: iwn5000_tx_done: qid 3 idx 6 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 7 len 129 nsegs 2 rate
> > 0002 plcp 0x0000420a
> > Feb 28 22:55:24 kernel: iwn_tx_data: qid 3 idx 8 len 129 nsegs 2 rate
> > 0002 plcp 0x0000420a
> > Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 7 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> > Feb 28 22:55:24 kernel: iwn5000_tx_done: qid 3 idx 8 retries 16 nkill
> > 0 rate 80006902 duration 2815 status 83
> >
> > .. so it's failing to transmit the management frames after association
> > - they're being transmitted at MCS0 and the AP is just plain not
> > ACKing them.
> >
> > Now, I don't know why this is. It's trying to transmit the initial
> > frame at non-MCS rates, but I have a feeling the multi-rate retry
> > table thing is confusing it and it's trying to send it as MCS. So
> > maybe the AP doesn't like management frames at MCS rates.
> >
> > I'll have to think about this a little.
> >
> > -a
> >
> >
> > On 28 February 2014 15:07, Tom Murphy <freebsd_at_pertho.net> wrote:
> >> I've attached my iwn debug messages to this email starting
> >> with the point I tried to associate to the Wifi.
> >>
> >> Thanks again for looking at this!
> >>
> >> Kind regards,
> >> Tom
> >>
> >> On Thu, Feb 27, 2014 at 12:13:51PM -0800, Adrian Chadd wrote:
> >>> On 26 February 2014 23:52, Alexandr <shuriku_at_shurik.kiev.ua> wrote:
> >>> > Tom, could you:
> >>> >
> >>> > 1. compile kernel WITH_IWNDEBUG
> >>> > 2. sysctl dev.iwn.0.debug=0x1
> >>> > 3. wlandebug -i wlan0 auth+assoc
> >>> > 4. Associate with AP in 11n mode
> >>> > 5. Send us appropriate /var/log/messages
> >>> >
> >>> > Then I try to compare it with my log.
> >>>
> >>> Please do. I've been trying to track down the source of this "ht just
> >>> doesn't work!" but it works fine with all of the Intel NICs I have
> >>> here.
> >>>
> >>> Can someone see if they can find a mtaching NIC online (amazon,ebay?)
> >>> Owning one that I can whack in a laptop is likely going ot help things
> >>> a lot.
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> -a