Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Feb 2003 07:12:30 +1100
From:      Rudolph Pereira <memetical@yahoo.com.au>
To:        stable@freebsd.org, net@freebsd.org
Subject:   wi card problem on 440lx motherboard
Message-ID:  <20030223201230.GB350@starfleet.org.au>

next in thread | raw e-mail | index | archive | help
Hello,
I am trying to get a wireless PCI card working on an old PC with an
intel 440lx chipset and it appears that the card is only intermittently
working.

First, the specs:
motherboard: msi-6111 (440lx chipset)
wi pci card: sparklan wl-360f; pciconf output is:

wi0@pci0:16:0:  class=0x028000 card=0x38731260 chip=0x38731260 rev=0x01
hdr=0x00
    vendor   = 'Intersil Americas Inc (Was: Harris Semiconductor)'
    device   = 'PRISM 2.5 802.11b 11Mbps Wireless Controller'
    class    = network

I'm testing by pinging between this machine and a wi in my laptop (which
stays constant throughout my tests), the cards are in ad-hoc mode,
11Mbps, and about 2 metres from each other with no obvious sources of
interference.

results:
- if I put the card into another (newer, completely different
  configuration) machine running 4-stable, everything works fine
- if I ping with a freebsd 4-stable or 5-current configuration on the
  problem machine, I get ~20% packet loss (this is just a straight
ping), with the dropped packets being corrupted as described below
- if I run the same ping test under netbsd (1.6), there's at most 3%
  packet loss, but usually none

The corruption looks random. I've only seen it in packet headers (e.g
checksums, protocols etc), but I can't say it's only happening there.

Examples: (laptop == 192.168.0.2, faulty card == 192.168.0.1); I've
listed the tcpdump output from the src first

1.
06:19:14.698259 192.168.0.2 > 192.168.0.1: icmp: echo request (ttl 64,
id 51178, len 84)
                         4500 0054 c7ea 0000 4001 316b c0a8 0002
                         c0a8 0001 0800 04f0 0e09 0500 b21e 593e
                         dfa6 0a00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435
06:19:13.419329 truncated-ip - 51094 bytes missing! 192.168.0.2 >
192.168.0.1: icmp: echo request (ttl 64, id 51178, len 51178, bad cksum
316b!)
                         4500 c7ea c7ea 0000 4001 316b c0a8 0002
                         c0a8 0001 0800 04f0 0e09 0500 b21e 593e
                         dfa6 0a00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435

2.
06:31:56.804103 192.168.0.2 > 192.168.0.1: icmp: echo request (ttl 64,
id 53536, len 84)
                         4500 0054 d120 0000 4001 2835 c0a8 0002
                         c0a8 0001 0800 7f4c 230c 0500 ac21 593e
                         5444 0c00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435

06:31:56.471654 192.168.0.2 > 192.168.0.1: (frag 53536:64@8) (ttl 64,
len 84, bad cksum 2835!)
                         4500 0054 d120 4001 4001 2835 c0a8 0002
                         c0a8 0001 0800 7f4c 230c 0500 ac21 593e
                         5444 0c00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435

3.
06:41:05.800243 bad-hlen 0
                         0054 0054 d7de 0000 4001 2177 c0a8 0002
                         c0a8 0001 0000 7b6f 3d01 0300 d123 593e
                         232a 0c00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435

06:41:06.119715 192.168.0.2 > 192.168.0.1: icmp: echo reply (ttl 64, id
55262, len 84)
                         4500 0054 d7de 0000 4001 2177 c0a8 0002
                         c0a8 0001 0000 7b6f 3d01 0300 d123 593e
                         232a 0c00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435

4.
06:43:32.892415 192.168.0.2 > 192.168.0.1: gre gre-proto-0xAA06 (ttl 32,
id 55590, len 84, bad cksum 202f!)
                         4500 0054 d926 0000 202f 202f c0a8 0002
                         c0a8 0001 0000 aa06 3e01 0100 6424 593e
                         6192 0d00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435
06:43:33.208366 192.168.0.2 > 192.168.0.1: icmp: echo reply (ttl 64, id
55590, len 84)
                         4500 0054 d926 0000 4001 202f c0a8 0002
                         c0a8 0001 0000 aa06 3e01 0100 6424 593e
                         6192 0d00 0809 0a0b 0c0d 0e0f 1011 1213
                         1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
                         2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
                         3435


Lastly, the message "wi0: oversized packet received ...." is
occasionally displayed on the problematic machine's console.

So, does anyone have any ideas about this? I've tried putting some
printfs in the wi driver and it _seems_ like the corruption/duplication
is happening before it gets to the driver, but I'm not a kernel hacker
and could've got it wrong (then again, corruption there would be obvious
to other wi users I would think).
Any suggestions on how I can debug this?

Thanks in advance.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030223201230.GB350>