Feature

Release 0.44

Pass/Fail

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Most tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  They also assume the driver is not currently loaded.  Tests also assume you are using eth1 and that eth1 is not up.

All tests below are performed as root on laptop.

Steps specific to Averatec models are shown in blue.

Using Fedora Core release 1.

Using 2.6.5 kernel.

Using wireless tools version 27.

% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.
% modprobe -v av5100 <- Verify no error messages appear.
% modprobe -v ipw2100 <- Verify no error messages appear.
% ifup eth1 <- Verify no error messages appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifconfig eth1 <- Verify valid IP address has been assigned.
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.
% modprobe -v av5100 (if not already done)
% insmod -p /lib/modules/2.6.*/kernel/drivers/net/wireless/ipw2100/ipw2100.ko <- Verify no error messages appear.
% ifup eth1 <- Verify no error messages appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifconfig eth1 <- Verify valid IP address has been assigned.
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.
% modprobe -v ipw2100 <- Verify no error messages appear.
% modprobe -v av5100 <- Verify no error messages appear.
% ifup eth1 <- Verify no error messages appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifconfig eth1 <- Verify valid IP address has been assigned.
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

Issues

Just ISSUE 931396 in DB b/c I had to manually do the 'ifup eth1'

% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.
% modprobe -v ipw2100 <- Verify no error messages appear.
% rmmod ipw2100
Verify response happens quickly and no error messages are seen.
% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.

Note:  Test twice.  Once with a long delay between second and third step and once with no delay.

Issues

Well, I know now why I'm seeing the error I've seen before on the quick removal, it's probably b/c ipw2100 was trying to load eth1 and couldn't because av5100 wasn't loaded, and it hadn't finished that process before I tried to remove it.  Not a bug.

% ifdown eth1 <- Bring network interface down before test.
% modprobe av5100 (if not already done)
% modprobe ipw2100 <- Verify no error messages appear.
% ifup eth1
Ensure no hangs or unexpected behavior.
% ifconfig eth1 <- Verify interface is up.
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

Issues

Just ISSUE 931396 in DB b/c I had to manually do the 'ifup eth1'

% ifdown eth1 <- Bring interface down
% rmmod ipw2100 <- Remove module
% modprobe av5100 (if not already done)
% ifup eth1 <- Try to bring network interface up before driver load (should fail)
% modprobe ipw2100
Ensure no hangs or unexpected behavior.  Note:  This is not the correct load conditions, so error messages may appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifconfig eth1
% ping <machine on network> -I eth1
the last two commands should come back with errors because eth1 should not be loaded yet.

NOT ATTEMPTING (until fixed) ISSUE 935966 in DB

Notes:  If I try to do an ifup eth1 afterwards, I get the error:

ipw2100 device eth1 does not seem to be present, delaying initialization

This is the message I see the first time I try to do the ifup eth1 as well.

If I try to do an ifdown eth1, I get the error:

SIOCGIFFLAGS:  No such device.

Then, I can never get the interface back up and have to reboot.

Note:  I tried this with my network cable unplugged and the 8139too and got different messages.

Do continue investigating since a reboot is required.

% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.
% modprobe av5100 (if not already done)
% modprobe ipw2100 <- Verify no error messages appear.
% ifup eth1
Wait 1 minute.  Verify system does not hang (regression issue).
% ifconfig eth1 <- Verify interface is up.
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.
% modprobe ipw2100 <- Verify no error messages appear.
Run the next two commands immediately after one another.
% ifup eth1
% iwconfig eth1 essid <new essid>
Verify system does not hang (regression issue).
% ifconfig eth1 <- Verify interface is up.
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

Configure system to load driver on startup, restart machine, and verify driver is loaded.

% find / &
% lsmod | grep ipw2100 <- Verify ipw2100 module is not loaded.
% modprobe ipw2100 <- Verify no error messages appear.
% ifup eth1
% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifconfig eth1 <- Verify valid IP address has been assigned.
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.
Verify output from all above commands comes back within 1 second.

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Most tests assume you have loaded the firmware as described in INSTALL before v to load the driver.  Tests also assume you are using eth1.

All tests below are performed as root on laptop.

% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifdown eth1 <- Verify no error messages appear.
% ifconfig eth1 <- Verify no IP address is assigned.
% modprobe -r ipw2100 <- Verify no error messages appear.
% modprobe -r av5100 <- Verify no error messages appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is no longer loaded.
% lsmod | grep av5100  <- Verify av5100 module is no longer loaded.

Issues

I noticed in 'dmesg' the message:
"hostap_crypt:  unregistered algorithm 'NULL' (deinit)"
wonder if I need to investigate?

% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifdown eth1 <- Verify no error messages appear.
% ifconfig eth1 <- Verify no IP address is assigned.
% rmmod ipw2100 <- Verify no error messages appear.
% rmmod av5100 <- Verify no error messages appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is no longer loaded.
% lsmod | grep av5100  <- Verify av5100 module is no longer loaded.

% ifconfig eth1 <- Verify IP address is assigned (network is up)
% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% rmmod ipw2100 <- Verify no error messages appear.
% rmmod av5100 <- Verify no error messages appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is no longer loaded.
% lsmod | grep av5100  <- Verify av5100 module is no longer loaded.
% ifdown eth1 <- Verify no error messages appear.

% find / &
% lsmod | grep ipw2100 <- Verify ipw2100 module is loaded.
% ifdown eth1 <- Verify no error messages appear.
% ifconfig eth1 <- Verify no IP address is assigned.
% rmmod ipw2100 <- Verify no error messages appear.
% rmmod av5100 <- Verify no error messages appear.
% lsmod | grep ipw2100 <- Verify ipw2100 module is no longer loaded.
% lsmod | grep av5100  <- Verify av5100 module is no longer loaded.

- Configure system to not load driver on startup.  With driver still loaded, restart system.  Verify driver not loaded on startup and no errors received.
- Configure system to reload driver on startup.  With driver still loaded, restart system.  Verify driver reloaded on startup and no errors received.

STA
Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Most tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests also assume you are using eth1.

These tests assume that the driver is already loaded using:
% modprobe -v ipw2100 <- Verify no error messages appear.
Tests assume eth1 has not yet been brought up.

AP (need 2 for some tests)
Hardware - b AP

Tests assume AP is configured using its web interface as described in the AP's manual.  Tests assume AP's SSID is <APSSID>

All tests below are performed as root on laptop.

AP:

Configure for channel 4, and open authentication.
Configure SSID to APSSID.  Ensure that APSSID is different than current SSID so that the test actually verifies association takes place.

Driver:

% ping <machine on network> -I eth1 <- Verify ping fails because SSID hasn't been configured yet.
% iwconfig eth1 key off
% iwconfig eth1 essid <APSSID>
% iwconfig eth1 channel 4
% iwconfig <-- Verify essid  has been set.
% ifup eth1
Driver should be associating.  Verify with:
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

Association with invalid AP SSID

% ifdown eth1
% iwconfig eth1 key off (if needed)
% iwconfig eth1 channel 4 (if needed)
% iwconfig eth1 essid invalidSSID
% ifup eth1
Wait 1 minute.
Ensure no hard lockups or hangs occur.  Verify no association has taken place via:
% ping <machine on network> -I eth1 <- Verify no data is returned.

AP1 - Set SSID to APSSID1; set channel to 3
AP2 - Set SSID to APSSID2; set channel to 4

% ifdown eth1
% iwconfig eth1 key off
% iwconfig eth1 essid <APSSID1>
% iwconfig eth1 channel 3
% iwconfig <-- Verify essid has been set to APSSID1.
% ifup eth1
Driver should be associating.  Verify with:
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.
% iwconfig <-- Verify essid  is still APSSID1.
% iwconfig eth1 essid <APSSID2>
% iwconfig <-- Verify essid has been set to APSSID2.
Driver should be associating.  Verify with:
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.

Issues ISSUE 938926 in DB - It appears that the nearest SSID is generally the one associated with, and the essid command does not matter.  I was told that this is because the essid command isn't binding, but the nwid command is.  However, since we currently don't support nwid, I added this issue into the DB.

Driver:
% rmmod ipw2100
% ifdown eth1

AP:  Turn AP off.

Driver:
% modprobe ipw2100
% ifup eth1

Ensure that the only error message received is the one stating the AP cannot be found (I get a ping failure for this.)

Note:  There was a regression where loading when not in range of AP gave ipw2100: Fatal interrupt. Scheduling firmware restart. ipw2100: eth1: Restarting adapter. errors.

Ensure two machines on the AP's network can share data (either a text file or web page).

In an area with multiple APs configured:

% modprobe ipw2100
% iwconfig eth1 essid any
% ifup eth1 <- ensure a close AP is associated with
Walk into the domain of another AP, and ensure that, as you leave the domain of the first AP, a new AP is associated with.

AP:

Configure for channel 4, and open authentication.
Configure SSID to APSSID.  Ensure that APSSID is different than current SSID so that the test actually verifies association takes place.
Configure AP for WEP, key 0123456789, ideally open authentication.

Driver:

% ping <machine on network> -I eth1 <- Verify ping fails because SSID hasn't been configured yet.
% iwconfig eth1 essid <APSSID>
% iwconfig eth1 key 0123456789
% iwconfig <-- Verify essid  and key have been set.  Verify encryption is on.
% ifup eth1
Driver should be associating.  Verify with:
% ping <machine on network> -I eth1 <- Verify ping command comes back with data.
% iwconfig  <-- Verify essid  and key are still set.  Verify encryption is still on.

Same ESSID issue as 938926.  'ifconfig eth1 up' works.

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests assume debug output is compiled in.  Tests also assume you are using eth1.

These tests assume that the driver is already loaded using:
% modprobe -v ipw2100 <- Verify no error messages appear.
% ifup eth1

All tests below are performed as root on laptop.

Before running tests, set /proc/net/ipw2100/debug_level to 8192 in order to display debug info when fragmentation is occurring (and verify the code path of the test).

% iwconfig eth1 frag 300
% iwconfig <-- Verify fragmentation threshold is 300B
Now, the laptop is configured to fragment when packet size > 300.  So, if we can send a ping with size > 300, and it actually makes it to the other machine (as verified by a valid response), then we know that the fragmented packets were able to be reassembled.
% ping -c 3 -I eth1 <machine on network> <-- Verify response received.
% ping -c 3 -I eth1 -s 400 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 500 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 600 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 700 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% dmesg <-- Verify fragmentation did occur.  For 400, 500 it should be 2 or more frames.  For 600, 700 it should be 3 or more frames.
% iwconfig
Verify Tx numbers have been incremented (can check against ifconfig).

HERE

% iwconfig eth1 frag off
Configure the AP frag threshold to 300 from another laptop.  So, if we can receive a response from a ping with a packet size > 300, then we know that the laptop was able to reassemble the fragmented packets from the AP.
% ping -c 3 -I eth1 ipw2100_laptop_ip <-- Verify response received.
% ping -c 3 -I eth1 -s 400 ipw2100_laptop_ip <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 500 ipw2100_laptop_ip <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 600 ipw2100_laptop_ip <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 700 ipw2100_laptop_ip  <-- Verify final output says "3 packets transmitted, 3 received"
% dmesg <-- Verify fragmentation did occur.
% iwconfig
Verify Rx numbers have been incremented (can check against ifconfig).

It's not saying that fragmentation occurred with dmesg.  But, should it?  (since this is at the AP)

Well, after a while, I get the message "expiring fragment cache entry seq=151 last_frag=2"

Repeat above two tests with a different fragmentation threshold (ex. 290, 2200) --> range is 256-2346

Rx -  Pass

% echo "768" > /proc/net/ipw2100/debug_level
% iwconfig eth1 rts 300
% iwconfig
% ping -c 3 -I eth1 <machine on network> <-- Verify response received.
% ping -c 3 -I eth1 -s 400 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 500 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 600 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% ping -c 3 -I eth1 -s 700 <machine on network> <-- Verify final output says "3 packets transmitted, 3 received"
% dmesg
% iwconfig

Repeat with packet size 1000, pinging 500, 1000, 1500.
NOTE:  You can also look in /proc/net/ipw2100/eth1/ordinals for information on the RTS/CTS values.

Except, I have no way of knowing RTS actually happened.

Run through all tests above, except enable WEP on the AP, and on the driver do the extra step of:
% iwconfig eth1 key <key on AP>
after the % modprobe ipw2100.

Rx - Pass

Repeat for larger values -  Tx - didn't try; Rx - Pass

RTS/CTS - Pass

% iwconfig eth1 frag fixed
% iwconfig
TBD how I should verify this.

It doesn't appear to have a fixed setting.  Fixed appears to do nothing.  Updated issue 931399 in DB.

% iwconfig eth1 frag auto
% iwconfig
Verify fragmentation happens automatically (Need to expand verification here when this works.)

% iwconfig eth1 frag off
% iwconfig
Verify fragmentation has been turned off (via ping and looking at dmesg).

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

These tests use the Ethereal software at http://www.ethereal.com.  They assume you have configured and built the latest version as defined in its INSTALL file.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests assume debug output is compiled in.  Tests also assume you are using eth1.

All tests below are performed as root on laptop.

Connect laptop A to AP on channel 4.

On laptop B:
% iwconfig mode monitor
% iwconfig eth1 channel 4
Open up Ethereal.
Capture...Start
Set up a filter with string 'host <machine on network>'.
OK

On laptop A:
% ping -I eth1 <machine on network>

On laptop B:
Stop capture.
Ensure the ping packets appear in the output.

Connect laptop A to AP with WEP enabled on channel 4.

On laptop B:
% iwconfig mode monitor
% iwconfig eth1 channel 4
Open up Ethereal.
Capture...Start
Set up a filter with string 'host <machine on network>'.
OK

On laptop A:
% ping -I eth1 <machine on network>

On laptop B:
Stop capture.
Ensure that ping packets cannot be seen in the output.

On machine with monitor mode enabled:
% ifdown eth1
% iwconfig eth1 mode managed
% iwconfig eth1 essid "<valid SSID>"
% iwconfig <-- Verify changes are made.
% ifconfig eth1 up
% ifconfig <-- Verify IP address has been assigned.
% ping -I eth1 <machine on network>
Verify ping comes back with data.

Valid IP address isn't assigned.

On machine with managed mode enabled and network up:
% ifdown eth1
% iwconfig eth1 mode monitor
% iwconfig eth1 channel 4
% iwconfig <-- Verify changes are made.
Verify using ethereal as in basic test above.

On machine with managed mode enabled and network up:
% iwconfig eth1 mode monitor
% iwconfig eth1 channel 4
Verify using ethereal as in basic test above.

I had an issue once with the bring the network down option, but couldn't reproduce it.

Pass
One time, this locked up my keyboard and mouse, but it's not reproducible.  Added it as 954268 since I heard others have seen it as well.

Hardware - 2 ipw2100 laptops with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests assume debug output is compiled in.  Tests also assume you are using eth1.

All tests below are performed as root on laptops.

On Laptop A:
% iwconfig eth1 mode ad-hoc essid testing channel 4
% ifconfig eth1 up 192.168.3.1

On Laptop B:
% iwconfig eth1 mode ad-hoc essid testing channel 4
% ifconfig eth1 up 192.168.3.2
% ping -I eth1 192.168.3.1 <- Verify ping comes back with data.

On Laptop A:
% ping -I eth1 192.168.3.2 <- Verify ping comes back with data.

On Laptop A:
% iwconfig eth1 mode ad-hoc essid testing channel 4 key open 0123456789
% ifconfig eth1 up 192.168.3.1

On Laptop B:
% iwconfig eth1 mode ad-hoc essid testing channel 4 key open 0123456789
% ifconfig eth1 up 192.168.3.2
% ping -I eth1 192.168.3.1 <- Verify ping comes back with data.

On Laptop A:
% ping -I eth1 192.168.3.2 <- Verify ping comes back with data.

I used to get some duplicate packets with my ping (I don't anymore.).

Set up machines as in Basic Association test.

On laptop A:
% scp < 1Mb file> 192.168.3.2 <- Verify data is received on the other end using md5sum.
% scp 192.168.3.2:< 1Mb file> . <- Verify data is received using md5sum.
% scp < 500Mb file> 192.168.3.2 <- Verify data is received on the other end using md5sum.
% scp 192.168.3.2:< 500Mb file> . <- Verify data is received using md5sum.

Didn't do the larger files b/c took too long.

Set up machines as in Association with WEP test.

On laptop A:
% scp < 1Mb file> 192.168.3.2 <- Verify data is received on the other end using md5sum.
% scp 192.168.3.2:< 1Mb file> . <- Verify data is received using md5sum.
% scp < 500Mb file> 192.168.3.2 <- Verify data is received on the other end using md5sum.
% scp 192.168.3.2:< 500Mb file> . <- Verify data is received using md5sum.

I used to get disconnected immediately after trying to transfer.  I don't anymore.

On both laptops:
% echo "8192" > /proc/net/ipw2100/debug_level

Tx
Laptop A:
% iwconfig eth1 frag 300
% iwconfig <-- Verify fragmentation threshold is 300B
% ping -c 3 -I eth1 -s 400 192.168.3.2 <-- Verify final output says "3 packets transmitted, 3 received"
% dmesg <-- Verify fragmentation did occur for 2 or more frames.

Rx
Laptop A:
% iwconfig eth1 frag off
Laptop B:
% iwconfig eth1 frag 300
Laptop A:
% ping -c 3 -I eth1 -s 400 192.168.3.2 <-- Verify final output says "3 packets transmitted, 3 received"
Laptop B:
% dmesg <-- Verify fragmentation did occur for 2 or more frames.

RTS/CTS
Laptop A:
% echo "768" > /proc/net/ipw2100/debug_level
% iwconfig eth1 rts 300
% iwconfig
% ping -c 3 -I eth1 -s 400 192.168.3.2 <-- Verify final output says "3 packets transmitted, 3 received"
% dmesg <-- Verify RTS/CTS code was used.
Laptop B:
% dmesg <-- Verify RTS/CTS code was used.

Repeat above tests with WEP enabled.

Rx - Pass

RTS/CTS - Pass

Rx w/WEP - Fail ISSUE 939689 in DB

RTS/CTS w/WEP - Pass

Add a laptop C to the network using:
% iwconfig eth1 mode ad-hoc essid testing channel 4
% ifconfig eth1 up 192.168.3.3
% ping -I eth1 192.168.3.1 <- Verify ping comes back with data.
% ping -I eth1 192.168.3.2 <- Verify ping comes back with data.
% scp < 1Mb file> 192.168.3.1 <- Verify data is received on the other end using md5sum.
% scp 192.168.3.1:< 1Mb file> . <- Verify data is received using md5sum.
% scp < 500Mb file> 192.168.3.2 <- Verify data is received on the other end using md5sum.
% scp 192.168.3.2:< 500Mb file> . <- Verify data is received using md5sum.

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests assume debug output is compiled in.  Tests also assume you are using eth1.  Tests assume WEP is compiled in.

All tests below are performed as root on laptop.

On laptop connected to an AP via WEP, do:

% scp < <1Mb file> machine_on_network <- Verify data is received on the other end using md5sum.
% scp <500Mb file> machine_on_network <- Verify data is received on the other end using md5sum.
% scp <1Gb file> machine_on_network <- Verify data is received on the other end using md5sum.
% scp <1.5Gb file> machine_on_network <- Verify data is received on the other end using md5sum.

Only did for the 500Mb so far.  I'm noticing that Tx only does ~300kb/s.

On laptop connected to an AP via WEP, do:

% scp machine_on_network:< <1Mb file> . <- Verify data is received on the other end using md5sum.
% scp machine_on_network:<500Mb file> . <- Verify data is received on the other end using md5sum.
% scp machine_on_network:<1Gb file> . <- Verify data is received on the other end using md5sum.
% scp machine_on_network:<1.5Gb file> . <- Verify data is received on the other end using md5sum.

Rx of the 500Mb causes multiple firmware restarts.  Also, because it only does 30-60Kb/s, this test takes too long to run.

I notice this with non-WEP and ftp as well (i.e., the multiple firmware restarts).

With a laptop configured to use a key, try to associate with an AP that does not have WEP enabled.  Verify association takes place, and 'iwconfig' shows that encryption has been turned off.

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests assume debug output is compiled in.  Tests also assume you are using eth1.

All tests below are performed as root on laptop.

- For every test where applicable, check the kernel log messages to ensure they are valid.
- One regression test is to make sure they point to /proc/net/ipw2100.
- Check debug log to ensure all messages are valid.

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests also assume you are using eth1.

All tests below are performed as root on laptop.

- iwconfig eth1
Verify the data in red below is what was configured.
Verify the data in green below is correct.

Regression issue where Noise level wasn't being set correctly.  Should be fixed after 0.38.

eth1      IEEE 802.11b  ESSID:"ESSID"  Nickname:"nickname"
          Mode:Managed  Channel:0  Access Point: 00:00:00:00:00:00
          Bit Rate=0kb/s   Tx-Power=0 dBm
          Retry:on   RTS thr=2304 B   Fragment thr:2332 B
          Encryption key:off
          Link Quality:0/0  Signal level:-90 dBm  Noise level:-75 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

- iwconfig eth1 essid <- Verify error message received because blank
- iwconfig eth1 essid 0 <- Verify essid set to 0
- iwconfig eth1 essid abcdefghijklmnopqrstuvwxyz <- Verify essid set to this long string
- iwconfig eth1 essid "essid with spaces in it" <- Verify essid set to 'essid with spaces in it'
- iwconfig eth1 essid any  <- Connect to network and verify any essid can be connected to.

- iwconfig eth1 nwid <valid network id>
Configure two machines to be in the same network and ensure they can communicate.
- Configure two machines to be in different networks and ensure they cannot communicate. (? Valid?)

- iwconfig eth1 nwid on; iwconfig eth1 nwid off --> Do not run until promiscuous mode enabled.

Just do some parameter testing:

- iwconfig eth1 freq 2.333G
- iwconfig eth1 freq 1001
- iwconfig eth1 freq 1000 (should error)
- iwconfig eth1 freq 0 (should error)
- iwconfig eth1 freq -1 (should error)

None of my changes are taken, and the ones that should error aren't.

Just do some parameter testing:

- iwconfig eth1 mode monitor
- iwconfig eth1 channel 1000
- iwconfig eth1 channel 999
- iwconfig eth1 channel 1
- iwconfig eth1 channel 2.333G (should error)
- iwconfig eth1 channel 1001 (should error)
- iwconfig eth1 channel 0 (should error)
- iwconfig eth1 channel -1 (should error)

I have no clue why I marked this pass last time.  I suspect it may have been failing with 0.40-pre2 as well.

- iwconfig eth1 sens -## Set the threshold to be various values and ensure correct behavior (or error messages received):  0, 80, 120, 1000, -1

Just do parameter testing to verify all can be set.  Don't test functionality as not all is available yet.

- iwconfig eth1 mode ad-hoc
- iwconfig eth1 mode managed

The tests below do not change the mode.  That should be fine since these will probably not be supported.
- iwconfig eth1 mode master
- iwconfig eth1 mode repeater
- iwconfig eth1 mode secondary
- iwconfig eth1 mode auto

Just parameter testing:

- iwconfig eth1 ap <valid AP>
- iwconfig eth1 ap 00:00:00:00:00:00

Not sure if this is a bug or not.  AP command doesn't seem to set the AP (I thought it did previously.).

Perform tests listed above for essid, except replace essid with 'nickname'

Note:  These tests only work on cards that support multiple bit rates.

Just perform parameter testing, such as:

- iwconfig eth1 rate 11M
- iwconfig eth1 rate 15000000
- iwconfig eth1 rate 0
- iwconfig eth1 rate -1

Just do parameter testing with numbers -1 (should fail), 0 (should fail), 250, auto, fixed, off.  Other tests need to verify this functionality.

Doesn't look like auto or off are supported yet.  Need to write this into DB (will do with next week's test pass).

Do parameter testing with -1 (should fail), 0 (should fail), 1 (should fail), 270, 1000, 3000 (should fail).

- Test that you can change which key is the active key.
- Test that you can enter a key as a string and as a hex.
- Test that you can set open and restricted.

Just do parameter tests around the five key parameters to ensure that the mapping from input to five key values is valid.

TODO - Add these tests when power management has been implemented.

- iwconfig eth1 retry 5
- iwconfig eth1 retry lifetime 5
- iwconfig eth1 retry lifetime 5u
- iwconfig eth1 retry lifetime 5m
- iwconfig eth1 min limit 5
Need to look at dmesg with debug enabled to verify this.

No tests.  Use this when running tests and want to ensure commits have taken place.

% ifdown eth1
% iwconfig eth1
Ensure that output received reflects that there is no AP:
- ESSID is blank
- Channel is 0
- AP is all 0s
- Bit rate is 0
- Link quality is 0%  (Regression issue where link quality was showing as 100%.)

May want to add these to WEP tests.

May want to add these to WEP tests.

Says nothing, which is to be expected until functionality is added.

Doesn't appear to be supported yet.

Doesn't appear to be supported yet.

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests assume debug output is compiled in.  Tests also assume you are using eth1.

All tests below are performed as root on laptop.

Tests assume:
% echo "1024" > /proc/net/ipw2100/debug level
is performed before testing to get relevant dmesg output.

Test that
% iwconfig eth1 power on
% iwconfig
Shows a period with the default value.
% iwconfig eth1 power off
% iwconfig
Removes the line with a period.

Off - Pass

Test using
% iwconfig eth1 power period XX
where XX is 300m, 600m, 900m, 1.2s, and ensure
% iwconfig
shows the correct period (Note:  It's a mapping, so not exact.).

Note out to James on correct mapping data, but it's consistent, so I think this is a pass.

Test using
% iwconfig eth1 power timeout XX (u, m, and s)
where XX is 250m, 150m, 100m, 75m, 50000u and ensure
% iwconfig
shows the correct period (Note:  It's a mapping, so not exact.).

Note out to James on correct mapping data, but it's consistent, so I think this is a pass.

Test using
% iwconfig eth1 power timeout XX all
% ping -c 100 -i YY <machine on network>
Where XX is each of the 5 different period parameters.
Where YY is Rx/Tx avg. timeout+period/2.
Ensure all packets are received.  Note rtt avg vs. with no power.
NOTE:  NEED TO ALSO LOOK AT POWER CONSUMED NEXT TIME!!!

rtt avg:
1-7.052
2-8.320
3-7.820
4-7.023
5-8.226
no power - 6.415

Test setting
% iwconfig eth1 power <command> unicast
for now.  TBD how to test in the future.

Test setting
% iwconfig eth1 power <command> multicast
for now.  TBD how to test in the future.

Test setting
% iwconfig eth1 power min timeout XX max timeout YY
% iwconfig eth1 power min power XX max power YY
for now.  TBD how to test in the future.

Hardware - ipw2100 laptop with 802.11b wireless capabilities.
OS - Fedora 9 (or Gentoo 1.4).
Kernel version - 2.6.x (x = version required per main website)
Driver and helper software - Latest version as defined by main website.  Follow INSTALL for installation.

Tests assume you have loaded the firmware as described in INSTALL before attempting to load the driver.  Tests assume debug output is compiled in.  Tests also assume you are using eth1.

All tests below are performed as root on laptop.

% scp <1.5Gb file> machine_on_network <- Verify data is received on the other end using md5sum.

% scp machine_on_network:<1.5Gb file> . <- Verify data is received on the other end using md5sum.

Perform the command:
% ping -f <AP> &
tweny times for 5 minutes and note behavior.  (Per 931280, this should cause failures until fixed.)

TBD the steps

% ping -c 3 -I eth1 -s 400 <machine on network>
Run this command multiple times on laptop while also using a cell phone nearby.  Verify that all packets are received.  If delay is significant, may want to try graphing the degradation in quality.  Other tools to cause interference:  microwave ovens, Bluetooth enabled devices, other wireless LANS.  Ideally, test with a 2.4 GHz wireless phone.

This test is the closest we get to verifying that fragmentation actually occurs.

Set up collision monitor tool to monitor the number of collisions on the network.

Run through Tx and Rx tests with the fragmentation threshold set to various values between 256 and 2, 048 bytes.  Ensure that the collision rate is smaller when the fragmentation threshold is smaller.

Verify that RTS/CTS works by:
- Set up two machines and disable RTS/CTS.
- Place a script that performs multiple pings to a machine on the LAN (TODO - create script) on both machines.
- Run script and verify that collisions occur.
- Enable RTS/CTS on both machines.
- Run script again and verify that no collisions occur.

Enable C3.  After using the system for a while look for a "Packet Payload Too Large" message in the kernel log followed by a firmware reset.  Log how often this happens.

Workaround is to disable C3 (either via the patch on the website to processor.c or by unloading the ACPI processor module).

After testing, check the kernel log for a message like:
>>ipw2100: Fatal interrupt. Scheduling firmware restart.
>>ipw2100: wlan0: Restarting adapter.
>
> ipw2100: attempt to use fw ordinals before they have been loaded.

Log how often this happens.

% ping -f <machine on network>
Per the mailing list, this will cause a kernel OOPs after a few packets are sent.

Need to find a way to easily go into suspend.  Could use apmsleep -s  and -S, but I'd need to compile them into the kernel.

% modprobe av5100 <- Verify radio LED turns on (will blink when coming up)
% rmmod av5100  <- Verify radio LED turns off

• Driver load/unload - Covered
• Infrastructure Mode - Covered
• Adhoc Mode - NEED TO ADD
• WEP - Current tests only cover that Infrastructure mode functions as desired with WEP enabled.  Tests do not check that data is truly encrypted or test the encryption modes.
• Wireless extension support - Need to clean up these tests
• 802.11 fragmentation - Current tests only verify fragmentation happens by looking at debug output.  No tests exist to ensure that packets actually are fragmented.
• Long/short preamble support - NEED TO ADD
• "Shared" authentication - NEED TO ADD
• Transmit power control - NEED TO ADD
• Power states support - NEED TO ADD