Yup, I found a 2100 and 2200. And yes it does dump out a bunch of
statistics stuff when the NIC is running.

I'll see about exposing the statistics messages via some API soon.

-a


On 14 March 2014 18:55, Adrian Chadd <adrian.ch...@gmail.com> wrote:
> Nope; there's no code for handling the messages yet.
>
> I'll dig around to see if I can find a 2200 series NIC in a laptop
> here or in my collection. I know I have 3945 NICs, but not the 2200..
>
> -a
>
>
> On 14 March 2014 18:06, Jim Long <ja...@museum.rain.com> wrote:
>> Thank you for your reply.
>>
>> This would be via syslog in /var/log/messages?  Nothing that I see:
>>
>> $ zgrep -il notification /var/log/messages*
>> $
>>
>>
>>
>> On Fri, Mar 14, 2014 at 05:50:12PM -0700, Adrian Chadd wrote:
>>> It'd be stuff like this:
>>>
>>>         case IWI_NOTIF_TYPE_CALIBRATION:
>>>         case IWI_NOTIF_TYPE_NOISE:
>>>         case IWI_NOTIF_TYPE_LINK_QUALITY:
>>>                 DPRINTFN(5, ("Notification (%u)\n", notif->type));
>>>                 break;
>>>
>>>
>>>
>>> -a
>>>
>>>
>>> On 14 March 2014 17:18, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>> > Hi,
>>> >
>>> > I'm not sure what kind of statistics or diagnostics iwi spits out.
>>> > It's likely worth reviewing the linux and freebsd drivers to see if it
>>> > does spit out any kind of statistics messages. That's a good starting
>>> > point.
>>> >
>>> > Thanks!
>>> >
>>> >
>>> > -a
>>> >
>>> >
>>> > On 14 March 2014 16:00, Jim Long <ja...@museum.rain.com> wrote:
>>> >> I have a long-standing problem that involves the iwi interface on
>>> >> my Thinkpad T42 running 9.2-PRERELEASE circa 28 Aug 2013.
>>> >>
>>> >> Some wifi connections I make show good signal strength, but poor
>>> >> latency and/or packet loss to the WAP IP.  I can't find other
>>> >> wifi users who perceive the wifi performance as poor, so I am
>>> >> assuming the problem is local to me.
>>> >>
>>> >> I will say this is generally repeatable by location: good
>>> >> locations are usually good, bad locations are usually bad.  My
>>> >> theory is that the 2200BG likes some WAPs that I use more than it
>>> >> likes others.  I'd like to find out what I can do to either fix
>>> >> the problem, or at least be able to accurately tell the WAP owner
>>> >> what their problem is.
>>> >>
>>> >> I'm ignorant about how to troubleshoot problems like this, so
>>> >> please suggest some diagnostic information I can provide to guide
>>> >> either of us toward a solution.
>>> >>
>>> >> Thank you,
>>> >>
>>> >> Jim
>>> >>
>>> >> from dmesg:
>>> >>
>>> >> iwi0: <Intel(R) PRO/Wireless 2200BG> mem 0xc0214000-0xc0214fff irq 11 at 
>>> >> device 2.0 on pci2
>>> >> wlan0: Ethernet address: 00:12:f0:ca:5c:85
>>> >>
>>> >> I get this a lot, but don't know if it's relevant.  It seems
>>> >> to appear during both good and bad connections:
>>> >>
>>> >> iwi0: need multicast update callback
>>> >>
>>> >>
>>> >> Here's 61db of S/N ratio, resulting in almost 50% packet loss:
>>> >>
>>> >> $ wlanstats ; ping -c20 wap2
>>> >> 36       rx frame too short
>>> >> 5        rx from wrong bssid
>>> >> 374      rx discard 'cuz dup
>>> >> 5        rx discard 'cuz mcast echo
>>> >> 3        rx discard mgt frames
>>> >> 1347     rx beacon frames
>>> >> 4151     rx element unknown
>>> >> 42       rx frame chan mismatch
>>> >> 7        rx disassociation
>>> >> 7        beacon miss events handled
>>> >> 6        active scans started
>>> >> 1446     rx management frames
>>> >> 2        tx failed 'cuz vap not in RUN state
>>> >> 28752    total data frames received
>>> >> 8679     unicast data frames received
>>> >> 20073    multicast data frames received
>>> >> 12186    total data frames transmit
>>> >> 12186    unicast data frames sent
>>> >> 54M      current transmit rate
>>> >> 61       current rssi
>>> >> -95      current noise floor (dBm)
>>> >> -34      current signal (dBm)
>>> >> PING wap2 (192.168.2.1): 56 data bytes
>>> >> 64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=20.726 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.974 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.278 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1.942 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.008 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.921 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=1.755 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=0.934 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=2.803 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=16 ttl=64 time=1.698 ms
>>> >> 64 bytes from 192.168.2.1: icmp_seq=18 ttl=64 time=2.382 ms
>>> >>
>>> >> --- wap2 ping statistics ---
>>> >> 20 packets transmitted, 11 packets received, 45.0% packet loss
>>> >> round-trip min/avg/max/stddev = 0.921/3.311/20.726/5.540 ms
>>> >>
>>> >> To my knowledge the OS is using the latest 3.1 firmware for the
>>> >> interface:
>>> >>
>>> >> $ cd /usr/src/sys/contrib/dev/iwi
>>> >> $ grep ^FW Makefile; md5 *
>>> >> FW_VERSION=3.1
>>> >> MD5 (LICENSE) = 11963afae1fb1117b86fde8187152b9a
>>> >> MD5 (Makefile) = 2e4c774520e878e5cf8f3be7373fec02
>>> >> MD5 (ipw2200-bss.fw.uu) = 7c15a60e1ccf28c332d3d795af99012b
>>> >> MD5 (ipw2200-ibss.fw.uu) = b529089d6eee6c12a918f361ee2c8347
>>> >> MD5 (ipw2200-sniffer.fw.uu) = 9e6c7a76cb528cb1d9f1996189d9c699
>>> >>
>>> >> _______________________________________________
>>> >> freebsd-wireless@freebsd.org mailing list
>>> >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>>> >> To unsubscribe, send any mail to 
>>> >> "freebsd-wireless-unsubscr...@freebsd.org"
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to