From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 12:16:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 174A11065675; Wed, 2 Apr 2008 12:16:13 +0000 (UTC) (envelope-from fbsd.questions@rachie.is-a-geek.net) Received: from snoogles.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 94A048FC13; Wed, 2 Apr 2008 12:16:12 +0000 (UTC) (envelope-from fbsd.questions@rachie.is-a-geek.net) Received: from localhost (localhost [127.0.0.1]) by snoogles.rachie.is-a-geek.net (Postfix) with ESMTP id 215CD1CD60; Wed, 2 Apr 2008 04:00:06 -0800 (AKDT) From: Mel To: freebsd-mobile@freebsd.org Date: Wed, 2 Apr 2008 14:00:02 +0200 User-Agent: KMail/1.9.7 References: <47C078EC.4020907@student.utwente.nl> <47E1088A.8090203@clearchain.com> In-Reply-To: <47E1088A.8090203@clearchain.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804021400.04442.fbsd.questions@rachie.is-a-geek.net> Cc: Yousif Hassan , Sam Leffler , Benjamin Close , Alphons Fonz van Werven , freebsd-net@freebsd.org Subject: Re: [Wireless] Can't connect to wlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 12:16:13 -0000 On Wednesday 19 March 2008 13:35:22 Benjamin Close wrote: > Yousif Hassan wrote: > > Benjamin Close wrote: > >> Sam Leffler wrote: > >>> Yousif Hassan wrote: > >>>> On Wed, 2008-03-12 at 08:06 +1030, Benjamin Close wrote: > > > > > > > >>>> The slightly wonky: > >>>> - As reported by someone else: > >>>> wpi0: timeout resetting Tx ring 1 > >>>> wpi0: timeout resetting Tx ring 3 > >>>> wpi0: timeout resetting Tx ring 4 > >>>> appear on startup and occasionally on kldload - however they don't > >>>> appear to adversely affect too much > > > > > > > >>> wpi doesn't yet support background scan so doing an explicit scan > >>> from the command line will disconnect you from any ap you care > >>> connected to. It shouldn't be hard to add bgscan--but that's easy > >>> for me to say :) > >> > >> It's certainly on my todo list! > > > > Thanks for reminding me about the bgscan thing. I had read that > > somewhere before and completely forgotten! > > > > Ben, are the > > wpi0: timeout resetting Tx ring 1 > > wpi0: timeout resetting Tx ring 3 > > wpi0: timeout resetting Tx ring 4 > > (and other variants thereof) > > messages anything to be concerned about? It doesn't seem to affect > > stuff but it does show up on initial startup and every other scan I do. > > > > Thanks to everyone who worked on wpi for a most excellent driver. > > The timeouts are related to the firmware not being able to reset the tx > ring. Normally this isn't too bad as the first thing after resetting the > tx rings is to stop the firmware and reinit it. Whilst it won't cause a > crash, it still a bug that needs fixing. I think I finally found the issue with the connection dropping. It is related to a beacon miss and the driver not getting back to authenticated state. The /root/bin/testwpi.sh script mentioned below pings the AP 50 times sends it to syslog and does it again. Apr 1 09:20:30 laptop kernel: Beacon miss: 20 >= 7 Apr 1 09:20:30 laptop kernel: Beacon miss: 21 >= 7 Apr 1 09:20:30 laptop kernel: wpi_newstate: RUN -> ASSOC Apr 1 09:20:30 laptop kernel: wpi0: link state changed to DOWN Then this Beacon miss continues incrementing until: Apr 1 09:20:56 laptop kernel: Beacon miss: 274 >= 7 At this point the packet loss is still 100%: Apr 1 09:21:04 laptop /root/bin/testwpi.sh: 50 packets transmitted, 14 packets received, 72.0% packet loss round-trip min/avg/max/stddev = 0.513/0.599/1.046/0.131 ms Apr 1 09:22:05 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets received, 100.0% packet loss Apr 1 09:23:06 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets received, 100.0% packet loss Then for no apparent reason, it tries again: Apr 1 10:49:41 laptop kernel: Beacon miss: 20 >= 7 Apr 1 10:49:41 laptop kernel: Beacon miss: 21 >= 7 Apr 1 10:49:41 laptop kernel: Beacon miss: 22 >= 7 ... Apr 1 10:50:07 laptop kernel: Beacon miss: 273 >= 7 Apr 1 10:50:37 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets received, 100.0% packet loss Apr 1 10:51:38 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets received, 100.0% packet loss Apr 1 10:53:40 laptop last message repeated 2 times Apr 1 11:03:51 laptop last message repeated 10 times ... Then for no apparent reason (as far as I know, no one was near the machine at the time): Apr 1 16:34:00 laptop kernel: wpi_newstate: ASSOC -> AUTH Apr 1 16:34:00 laptop kernel: wpi_ops: command: 16 Apr 1 16:34:00 laptop kernel: config chan 1 flags 8035 cck f ofdm 15 Apr 1 16:34:00 laptop kernel: wpi_ops: command: 1 Apr 1 16:34:00 laptop kernel: wpi_ops: command: 8 Apr 1 16:34:00 laptop kernel: Ignoring WPI_SET_CHAN Apr 1 16:34:00 laptop kernel: wpi_ops: command: 2 Apr 1 16:34:00 laptop kernel: Scanning Essid: "MYSSID" Apr 1 16:34:00 laptop kernel: Scanning 1 Passive: 0 Apr 1 16:34:00 laptop kernel: wpi_newstate: AUTH -> AUTH Apr 1 16:34:00 laptop kernel: wpi_ops: command: 16 Apr 1 16:34:00 laptop kernel: config chan 1 flags 8035 cck f ofdm 15 Apr 1 16:34:00 laptop kernel: scanning channel 1 status 1 Apr 1 16:34:00 laptop kernel: scan finished nchan=0 status=2 chan=0 Apr 1 16:34:00 laptop kernel: wpi_ops: command: 4 Apr 1 16:34:36 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets received, 100.0% packet loss Apr 1 16:35:37 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets received, 100.0% packet loss Apr 1 16:36:38 laptop /root/bin/testwpi.sh: 50 packets transmitted, 0 packets received, 100.0% packet loss Apr 1 16:46:49 laptop last message repeated 10 times And then my girl came home from work and did the "down and list scan trick": Apr 1 17:53:06 laptop sudo: rachie : TTY=ttyp1 ; PWD=/home/rachie ; USER=root ; COMMAND=/sbi n/ifconfig wpi0 down Apr 1 17:53:06 laptop kernel: Disabling Firmware execution Apr 1 17:53:06 laptop kernel: wpi_newstate: AUTH -> INIT Apr 1 17:53:10 laptop sudo: rachie : TTY=ttyp1 ; PWD=/home/rachie ; USER=root ; COMMAND=/sbi n/ifconfig wpi0 up list scan Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 1 Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 3 Apr 1 17:53:11 laptop kernel: wpi0: timeout resetting Tx ring 4 Apr 1 17:53:11 laptop kernel: Disabling Firmware execution Apr 1 17:53:11 laptop kernel: wpi_newstate: INIT -> INIT Apr 1 17:53:11 laptop kernel: Resetting the card - clearing any uploaded firmware Apr 1 17:53:11 laptop kernel: Attempting Loading Firmware from wpi_fw module Apr 1 17:53:11 laptop kernel: Firmware Version: Major 2, Minor 14, Driver 4, Apr 1 17:53:11 laptop kernel: runtime (text: 80524, data: 32768) init (text: 2668, data 32768) boot (text 900) Apr 1 17:53:11 laptop kernel: rtext 0xf802020 Apr 1 17:53:11 laptop kernel: rdata 0x0 Apr 1 17:53:11 laptop kernel: itext 0xf802020 Apr 1 17:53:11 laptop kernel: idata 0x0 Apr 1 17:53:11 laptop kernel: btext 0xf802020 Apr 1 17:53:11 laptop kernel: Loading microcode size 0x384 Apr 1 17:53:11 laptop kernel: firmware status=0xffff0000, val=0x40400000, result=0x40400000 Apr 1 17:53:11 laptop kernel: Status Match! - ntries = 0 Apr 1 17:53:11 laptop kernel: microcode alive notification version 10e02 alive 1 Apr 1 17:53:11 laptop kernel: microcode alive notification version 10e02 alive 1 Apr 1 17:53:11 laptop kernel: Firmware loaded to driver successfully Apr 1 17:53:11 laptop kernel: wpi_newstate: INIT -> SCAN Apr 1 17:53:11 laptop kernel: wpi_ops: command: 1 Apr 1 17:53:11 laptop kernel: wpi_ops: command: 8 Apr 1 17:53:13 laptop kernel: scan finished nchan=1 status=1 chan=165 Apr 1 17:53:13 laptop kernel: wpi_newstate: SCAN -> AUTH Apr 1 17:53:13 laptop kernel: wpi_ops: command: 4 Apr 1 17:53:13 laptop kernel: wpi_ops: command: 8 Apr 1 17:53:13 laptop kernel: Ignoring WPI_SET_CHAN Apr 1 17:53:13 laptop kernel: wpi_ops: command: 8 Apr 1 17:53:13 laptop kernel: Ignoring WPI_SET_CHAN Apr 1 17:53:13 laptop kernel: wpi_ops: command: 16 Apr 1 17:53:13 laptop kernel: config chan 1 flags 8005 cck f ofdm 15 Apr 1 17:53:13 laptop kernel: wpi_newstate: AUTH -> ASSOC Apr 1 17:53:13 laptop kernel: wpi_newstate: ASSOC -> RUN Apr 1 17:53:13 laptop kernel: wpi_ops: command: 32 Apr 1 17:53:13 laptop kernel: config chan 1 flags 8035 Apr 1 17:53:13 laptop kernel: wpi0: link state changed to UP At this point it's working again, connection is flakey with packet loss ranging from 0 to 50% but it's working. This is wpi from 7-RELEASE with patch mentioned in this thread. -- Mel Problem with today's modular software: they start with the modules and never get to the software part.