Feature

Release 0.41 + Makefile patch

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

This issue is still being seen in 0.41.

% 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 - See this whenever I need 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

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).  --> IS THIS IN THE BUG DB?  IF NOT, NEED TO PUT IT IN.  I'M SEEING THE SAME STUFF.

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

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

After I do the 'ifdown eth1,' 'ifconfig eth1' still shows data.  'ifconfig' shows nothing.  Is this an 'ifconfig' issue?

% 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.  This sounds like expected behavior.

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.

Works, except if I do 'ifup eth1,' I end up associating with the nearest non-WEP AP.  The only way that I can get WEP to work is if I let my machine auto associate as in 935969.

Not sure if this is a bug ore not.

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

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

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

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.

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.

I only did for the 1 and 500Mb b/c of time.

It would be nice to do a 'date' before and after to know exactly how long this transfer is taking as well.  (Would also be good to time with and without WEP.)  Would also be nice to get power consumption during these tests.

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.

I only did for the 1Mb.  The 500Mb took _way_ too long.  Should get data on this and document as a potential issue.

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

Something about:
% iwconfig eth1 power on
% iwconfig eth1 power off
After that, I'm not sure what I will test.

Something about:
% iwconfig eth1 power period XX (u, m, and s)
After that, I'm not sure what I will test.

Something about:
% iwconfig eth1 power timeout XX (u, m, and s)
After that, I'm not sure what I will test.

Something about:
% iwconfig eth1 power <command> all
After that, I'm not sure what I will test.

Something about:
% iwconfig eth1 power <command> unicast
After that, I'm not sure what I will test.

Something about:
% iwconfig eth1 power <command> multicast
After that, I'm not sure what I will test.

Something about:
% iwconfig eth1 power min timeout XX max timeout YY
% iwconfig eth1 power min power XX max power YY
After that, I'm not sure what I will test.

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

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

Saw on another tester's machine when the old version of iwconfig tools was used.

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