Feature

Release 0.40-pre2

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.

Issues ISSUE 935969 in DB

I'm also seeing that no 'ifup eth1' is needed.  Ethernet is loaded automatically after modprobe.  Note out to James to see if this is expected.

% 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.

Issues

Same issue as above.

% 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

ISSUE 931396 in DB - saw this once

% 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

No issues on the long delay test, but seeing the same issues on the no delay test.  However, dmesg output is not as severe (before it was showing module loading and unloading multiple times).

% 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

Same 'ifup eth1' issue as before.

% 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.

Fail ISSUE 935966 in DB

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.

Did get some funnies with that "unregister_netdevice: waiting for eth1 to become free"

Also, had an issue where I brought down eth1, but it didn't really come down (Note:  It may be a timing issue from when I do ifdown to when I do ifconfig.).  Investigate more during next week's test pass.

% 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.

Actually, what the ipw2100 does is it must recognize that that's an invalid SSID and associates with the next best thing.

I'm assuming this is expected behavior, but I should check before this test is run the next test pass.

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.

Ensure two different STAs running ipw2100 driver can associate with the same AP.

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.

Configure two machines to associate to the same AP.  Put a web server on one machine.  Ensure when both machines are associated that the second machine can view the first machine's web page.

Perform basic BSS test above, except move one of the machines into a different room during testing and ensure the web page is always viewable.

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.

AP - Configure AP to channel 3.

Driver -
% iwconfig eth1 channel 3
% ifup eth1
% ifconfig <- Verify internet is up

I actually did this with channels 4 and 6.

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 packet 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 frames.  For 600, 700 it should be 3 frames.
% iwconfig
Verify Tx numbers have been incremented (can check against ifconfig).

I'm not sure that my last iwconfig test is valid.  Otherwise, this looks good.

% 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

% 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.

% 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.

RTS/CTS Two Machines

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.

% 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.)

Get error:

Error for wireless request "Set Fragmentation Threshold" (8B24) :
  SET failed on device eth1; Invalid argument

iwconfig shows no change in fragmentation.

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

Updated 931399 with this new info.

Not doing these tests now, since ad hoc support is not yet available.

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.

Send large amounts of data through the network (200Mb-400Mb) with WEP enabled and verify send/receive works correctly.

- Associate with an AP with WEP enabled laptop and AP.
- Associate with an AP with WEP enabled laptop, not AP.
- Check that iwconfig always shows WEP enabled.
- Basic Tx/Rx with WEP
- Higher load Tx/Rx with WEP (above)
- May also want to just do the network, power consumption, and other stress tests with and without WEP.

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

Note from James about Tx excessive retries:

In looking at the code, it appears we are actually reporting the wrong statistic here. Currently, iwconfig is displaying the number of Tx retries--but not the # of retries that exceed the retry limits (which is what I believe iwconfig really wants).

There isn't an ordinal we can query from the firmware to get the failures due to short/long rety limits. Perhaps we should change this to IPW_ORD_STAT_TX_FAILURES to indicate the number of Tx packets that failed. It isn't clear if this total is based on retry limits or just plain failures of any kind.

If you could do a large transfer such that what iwconfig is reporting is a large number, then do:

% grep -i tx /proc/net/ipw2100/[IF_NAME]/ordinals

and see what the values of ordinals [0x2A] thru [0x95] report? A different ordinal may be more appropriate for use on this item.

- 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 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)

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

Get the error:

"Error for wireless request "Set Sensitivity" (8B08) :
    SET failed on device eth1 ; Operation not supported."

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
- iwconfig eth1 mode master
- iwconfig eth1 mode repeater
- iwconfig eth1 mode secondary
- iwconfig eth1 mode auto

Stopped testing after managed.  Per the mailing list, monitor mode is not yet supported.

Note:  It is not a defect to not connect to the closer AP, this is merely a guideline.  Need to add network tests similar to those below because the network requires to connect to the network specified in iwconfig.

- Configure two access points.  Run iwconfig eth1 ap <less close AP> and verify driver connects to that AP.  Run iwconfig eth1 ap any and verify driver connects back to the closer AP.
- Configure two access points.  Run iwconfig eth1 ap <less close AP> and verify driver connects to that AP.  Run iwconfig eth1 ap off and verify driver is still connected to the less close AP.  Turn that AP off.  Verify driver connects to the other AP.
- Configure two access points.  Run iwconfig eth1 ap <closer AP> and verify driver connects to that AP.  Run iwconfig eth1 ap any and verify driver stays connected to the current AP.

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.

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

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.

This functionality isn't implemented yet.  Get the error :

"Error for wireless request "Commit changes" (8B00) :
    SET failed on device eth1 ; Operation not supported."

% 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%.)

I still need to start looking into verifying the Rx and Tx metrics.

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.

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

I guess?  Will be able to do more when you can actually use iwconfig with retry.

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.

TBD the steps

TBD the steps

TBD the steps

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.

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.

% ifconfig eth1 up
Verify that during connection process, the LED is flashing.
Verify that after connection, internet LED goes on and stays on.
% ifconfig eth1 down
Verify that the LED goes off and stays off (regression issue where it came back on after a few seconds because the hang check timer was restarting the firmware and bringing the adapter back up).

Note:  This should match /proc/net/ipw2100/state.

I did notice it was a little slow.  Unsure if this is a defect, though, or if it is even a driver issue.

% modprobe av5100 <- Verify radio LED turns on
% 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