Friday, June 30, 2017

Lessons Learned with Logstash - Part III

I self-marketed my last post on Reddit and got encouraging replies for which I'm truly grateful. In one of the posts, I replied with what will be the latest installment here. I was just too excited! Anyway, this is the nitty-gritty of how to do the proper yeoman's work of proper field mapping in ES-

I use OpenBSD6.1 (on HyperV!) so apologies for OS-specific calls-

  • since I have four distinct types of sources I have each type log to LS on a port specific to that type. So all of my Junipers are logging to LS on 5001, my Fortigates on 5002, my Windows Servers on 5000, and my Nutanix Cluster Nodes reporting on 5005. I comment all but one out at a time to isolate the mapping work.
  • (assuming LS and ES are on the same box) (and not assuming the current state of the setup) (and assuming you want to start over wherever it is), I wrote the following script to stop LS, clear all the storage and logs for LS and ES, kill any existing mappings in ES and then restart it so that the system is ready to start a new round of mapping work:

[root@noc-05: Fri, Jun-30 10:32PM]
/root/#cat /usr/sbin/stopes
echo "\t\t\t ##### stopping logstash ##### \t\t\t"
rcctl stop logstash
sleep 2
echo "\t\t\t ##### clearing ES mappings ##### \t\t\t"
curl -XPOST 'localhost:9200/.kibana/_update_by_query?pretty&wait_for_completion&refresh' -H 'Content-Type: application/json' -d'{  "script": {    "inline": "ctx._source.defaultIndex = null",    "lang": "painless"  },  "query": {    "term": {      "_type": "config"    }  }}'
rcctl stop elasticsearch
sleep 1
echo "\t\t\t ##### clearing ES and LS logs, storage ##### \t\t\t"
rm /var/log/logstash/logstash.log ;touch /var/log/logstash/logstash.log ;chown _logstash:_logstash /var/log/logstash/*;rm -rf /storage/elasticsearch/;rm /var/log/elasticsearch/elasticsearch.log ;touch /var/log/elasticsearch/elasticsearch.log ;chown _elasticsearch:_elasticsearch /var/log/elasticsearch/*
sleep 1
echo "\t\t\t ##### starting ES ##### \t\t\t"
rcctl start elasticsearch
[root@noc-05: Fri, Jun-30 10:32PM]
/root/#

  • For the current source category I'm working with, I pick through my logstash filters for them once again, being sure to not inadvertently introduce a field in two spots with slightly different spellings (equating to two separate fields in ES) like dst-ip and dst_ip.



  • I then start logstash with a single device category reporting in

rcctl -d logstash

watch the stuff come in, re-visiting _grokparsefailures, and repeatedly refreshing the index for new field types coming in (whether dynamically if you still have that on, or a manually defined field simply hasn't seen a log come in that triggers it's use). Some dynamically-mapped errors are ES's fault- others are because you are using the wrong UTF (8 vs 16) or not an appropriate codec that could be used. Either way, now is the time to see those, correct them in LS and restart it until you hone down what's going crazy. Now is when those online grok filter tools come in REAL handy. Keep using the stopes script, correct your logstash filtering, and restart logstash... repeatedly.

  • When you've felt you've a) rooted out all the _grokparsefailures (hint, put the pesky, corner-case logs in a catch-all filter so you can move on with life), b) rooted out the dynamic-mapping crap fields, you're ready to pull down the mapping from ES and convert it to the mapping you tell it to pay attention to (which just so happens to be ONLY the filtering your logstash config files are telling it to pay attention to)-

rcctl stop logstash
curl -XGET http://127.0.0.1:9200/logstash-*/_mapping?pretty > my_mapping.json
cp my_mapping.json my_template.json 

That above gets a file for you to edit, this is where you tighten up the fields themselves. You will notice duplicate field entries (remember dst-ip and dst_ip) and you'll have to go back in LS and mutate => rename one of the two to match the other . Then you'll make decision on every field based on what you observed it's data to be and decide whether it's gong to be treated like text, an integer, an ip address, or time/date, etc. (I say etc. but I don't know anymore lol). Doing this is a huge favor not only to you but to the performance of your system. Improperly typed fields are the bane of our existence. For one thing, I could not get geomapping working in Kibana until I set the geoip fields correctly.

  • And if you are only doing one category of log sources, then you skip to the end and upload the mapping into ES and restart LS and you're in production!

curl -XPUT http://localhost:9200/_template/logstash-*_template?pretty -d @my_template.json
curl -XDELETE http://localhost:9200/logstash-*?pretty
rcctl -d start logstash

The above pushes the template to ES, clears any existing indices, and then fires up logstash to feed it production docs.

Conclusion

If you are like me, you have to repeat this for each category of logging source you deal with, then concatenate each of the sources into a single my_template.json file. I'm not there yet, still working on Windows Server (last of my 4 source categories). Also, the editing tools on this blog platform are deplorable- my Reddit post had better formatting than this blog post, sigh.

Thursday, June 29, 2017

Lessons Learned with Logstash - Part II

In Lessons Learned with Logstash (so far) I went into the some of the problems and challenges of Logstash. Since then, I've discovered what I refer to as the 'chasm' between an out-of-the-box Elasticsearch solution, and a large-scale, full-blown enterprise-level implementation. TLDR; if you're going to use ES out-of-the-box, don't expect to use it like that 'at-scale' for very long.

The Chasm - A field mapping explosion!

The chasm between simple-ES and Hawking-complicated-ES is what is known in the documentation as a 'field mapping explosion'. In a sweet turn of irony, that which draws most newcomers to ES is exactly what will cut them down at certain scale of logging without a major refactoring of their understanding of the stack.

side rant: I suspect this is why most blog articles related to syslogging with ES really only focus on a shallow treatment of Logstash... and never get to Elasticsearch itself- ES is complicated. Sadly this group doesn't just include personal bloggers like yours truly, but commercial vendors (traditional log handling application vendors) vying for a piece of the ES pie -I find their lackluster attempts to market their ES chops especially deplorable. If ES is being used by Netflix and Ebay and Wikipedia, then it stands to reason that the average toe-dipping blog article is wholly insufficient for, well, just about anything seriously related to ES (this article included!).

Back to business: Dynamic field mapping is a feature of ES to bring neophytes in, because it attempts to automatically create fields based on the data being fed to it, without any configuration or interaction by the administrator. Literally feed it a stream or store of information, and ES will get down to work creating all the fields for you, and then populating them with data. Sounds fantastic! What could possibly go wrong?

The Two Strikes Against ES

Unfortunately the key word in all of this isn't 'dynamic' or 'automatically', but rather the word 'attempt', because depending on the data being fed to it, it can either shine or crash and burn. Both are endings bright, but one isn't happy. To help explain, it's useful to know the two strikes against Elastic putting this feature into ES-

  1. Those that rely the most on dynamic mapping are those most likely to suffer from it (newbies).
  2. One of the best use-cases of ES creates an embarrassingly hot mess of an ELK stack when using dynamic field mapping (syslog).

I know this because I fell into both categories- a newbie using ES for syslog analysis.

How does it (not) work?

So what happens? At it's core, ES suffers from separation anxiety- but in the opposite manner we're used to. Instead of being clingy it tries to separate lots of information, and when it's syslog data, much it shouldn't be separated. Specifically, the hyphen signals to ES that whatever is on either side of it should be separated. In the world of syslog, that usually includes hostnames, and dates and times.

If it seems like a glaring issue, that's because it is. Your ES index will be littered with faulty fields, and those fields will contain data, both of which should've been data somewhere else you specifically needed it to be. That's bad when you're using ES to find needles in your haystack, and some needles get permanently lost in those bogus fields.

Your system will start to churn on itself. At one point I thought I needed around 500 to 600 fields. I had 906. Then I had 3342, and that was effectively data corruption on a mass scale (the system takes in ~4 million events per day). It made searches against appropriately stored information undeniably slow.

Simply crafting detailed logstash rules with plenty of fields guarantees nothing. If ES sees some data as a field, it can wreck your grok-parse rules and leave you wondering why they don't work when they once did. Add to this the variability of Unicode amongst your data sources (Juniper and MS-Windows are  UTF-16, Nutanix and Fortinet are UTF-8, for instance) and you can spend a great deal of time hunting down your parsing issues, all while munging your data into oblivion.

The Solution

The solution is to prepare ES ahead of time for exactly what it should expect, using manual field mappings. Via the API, you can turn off dynamic mapping and manually map every field you will be using. The added benefit of this work is that at while defining the fields you set the type of data ES should expect per field. When tuned properly via appropriate data types, ES can index and search significantly faster than if it's left with the default field mapping definition. Speaking of which, Logstash will ship in fields that are of type string. This almost necessitates a static mapping exercise, as there performance and capability penalties for incorrectly typing your data.

Friends with Benefits

For instance, if IP addresses are properly typed as such, then you can do fancy things like search through CIDR subnets and perform IP space calculations. As another example, properly typing number data as integers (whole or floating, of various maximum sizes) allows ES to perform math functions on them, whereas left as the default (type string) will never give that ability. A static field mapping fed to ES ahead of document ingestion will ensure that the right field typing is applied to the incoming data to avoid disaster, wasted CPU cycles, and losses of extended functionality.

How-to, Next Time

In the next article I'll go over the gory details of how to properly define the fields you intend to use. At a basic level, you use strict LS filter rules along with the dynamic field mapping capability to see what fields come across from LS to ES. It allows you to tweak your filter rules until only the fields you want are traversing the stack. From there you feed them back in as a template (along with changes to the field types) and voila! ES and LS suddenly seem to get along with each other.

SPECIAL BONUS TIP: in part one I talked about breaking up your logging devices by port and type. Along with that do not forget to conditionally filter each set of device types via their assigned type before parsing that section of rules. I forgot to do this and ended up having my Nutanix logs parsed by my Nutanix grokparse filters... and then by my Fortinet grokparse filters, leading to all sorts of chaos. Start your constituent logstash configuration files (the ones I described previously as being dedicated to a particular device/vendor/application) with this (using Nutanix as the example):

if [type] == "nutanix" { 

   {nested nutanix-filter_01}
   .
   .
   .
   {nested nutanix-filter_99}
}



Art - Mechlab WIP

Another in my series of "unfinished art projects that shall be finished soon"... here's mechlab!











Art - Quadville WIP shots

IT's been awhile since I've worked on Quadville, but I'm aiming to get back into it. Until then, here's some last screenshots from this work in progress. Enjoy!


















Sunday, May 14, 2017

Lessons Learned with Logstash (so far)

So far my experiences with the Elasticsearch stack (ES) have been very positive. I've had it installed on OpenBSD 6.0 (amd64 on virtualbox on wind10) and 6.1 (amd64 on 2012R2 Hyper-V) with vast version differences between the two. I've learned some things along the way, and thought I'd take a second to account for them, specifically as it relates to Logstash.


Use a grok tool to assist in filter building

A lot of forum/blog posts advocate ditching the tedious process of regex-building, opting instead for the use of the kv filter,and then moving on with your life. Perhaps that's a possibility for some, but in my case the kv filter (which stands for key/value for things like 'box=blah') simply wasn't going to work. In specific, Windows event logs (translated to syslog via syslogagent) often will break any kind of logic from other event logs, and some defy any logic whatsoever.

So if regex filters are as important to you in Logstash as they are to me, you're going to be spending a lot of time working with them. My philosophy regarding the ES stack is that Logstash is on the front-lines of the battle, and can significantly ease Elasticsearch's work as well as the end-user's, so spending a proportionally large amount of time in Logstash versus ES itself or Kibana in my estimation is time well-spent.

Don't beat your head against a wall testing your grok regex's with live (or even test) logs in Logstash. I don't have any affiliation with the following site, but grok constructor  really has been helpful to me. It's probably like a lot of similar sites, where multiple logs can be loaded for multiple parse tests on a single regex, and allow you to specify your list of grok patterns so you can actually test what you will use. Once I successfully testbuild a regex here, I literally copy-n-paste it into my Logstash configuration.

Break up your logging devices by port and type

You can easily and permanently limit any 'damage' done by regexs for some devices that end up catching logs from others by categorizing logging devices by which destination port they report to the Logstash server on. Syslog is 514 and Logstash seems to like 5000, so in my implementations I start with 5001 for Juniper, 5002 for Fortinet, and 5003 for Windows, and on.

This also helps with _grokparsefailure identification in Kibana because now you can easily filter by type and be sure you're only looking at what you really want.

The port/type backstory

I stumbled into this practice on accident, grappling with what is likely Logstash's dirty little secret- that being problems with non-standard reporting devices. If you've scratched your head over a perfectly-constructed grok filter that works but still produces a _grokparsefailure tag, this is for you. It turns out that Logstash uses grok filtering internally on logs of type 'syslog', separately from anything you configure. For devices that don't "play nice" with their syslog reporting (read: Fortinet, Juniper, and more) Logstash will make it's displeasure known by attaching the _grokparsefailure tag to what it ships to ES. 

Once I realized that all these maddening _grokparsefailures where not my fault (a whole bunch more were my fault), I did three things-
  1. Moved my error log file to a larger capacity portion of my filesystem (from /var/log/ to /home/)
  2. Confirmed that every filter had a tag attached to it
  3. Separated incoming devices by port and assigned a type.
This had a great outcome- as soon as I re-classified incoming logs as anything other than syslog, Logstash itself stopped fretting over whether the incoming log was of a 'proper' format or not. That instantly made my failure logs drop, which also slowed the strain on capacity for my filesystem. Lots of big wins here!

I did not find this on my own. Aside from numerous google hits for things related to _grokparsefailure and matching, there was this very helpful article by James Turnbull on kartar.net .

Break up your configuration file

I've found that there is a sense of order and sanity in breaking up your configuration file into multiple configuration files. If there's more than one cook messing with your stew, you can limit any nuclear damage they do in a single file, and you can read multiple files of a configuration easier than one giant file. I've broken my into 
  • intro file with inputs and opening filter invocation
  • files by device or application
  • a general/misc/smaller configuration file for smaller stuff.
  • outro file with closing filter bracket and output stanza.
You'd think it would be easy to keep track of all those nested brackets, but after a couple thousand lines it can be a nightmare.


I'll put more here as I come up with it.

Monday, March 20, 2017

dannomech

I created this a year or two ago and never got around to posting it here- there's more than just this but I think this was decently representative of most of what I'd accomplished




Thursday, November 03, 2016

List of Network Adapters supported by OpenBSD

Though not one of my more exciting posts (or it is, and I have a problem set larger than I first imagined), I remain undeterred in bringing to light some truly esoteric information- when it comes to boring, I am your man. Side note- if you were prescribed to read this by your doctor or certified sleep therapist for insomnia, please let me know in the comments below who your care specialist is, so that I might bill them for services rendered- because I guarantee this will put you to sleep. If you've made it this far you can tell them not to worry as I'll now be forced to lower my rate- but no one gets ambien for free.

Hopefully this will save someone the time it took me to find the actual list of network adapters that could be used on a current OpenBSD system. In previous years' releases, the compiled list commonly was found in the subsection of the site for each supported platform (for that particular release at that time), and thus was quite easy to locate. 

And for some of the more obscure platform releases this still holds true... adding to my confusion when looking for similar information regarding the most popular/used of the platforms, AMD64. Somewhere along the way 'things' must've changed at OBSD-HQ and that handy list was no longer available. But it had to be somewhere, right? Right??? Eventually I found it, and then decided that it was torture and no one else should have to go through it.

Actually, just hours later I've forgotten how I found this, perhaps because I find that hunting in the man pages is much like wikipedia diving- you just end up there. But that matters little, the list is what's important.

So..

PCI slot adapters
http://man.openbsd.org/OpenBSD-current/man4/pci.4

USB adapters
http://man.openbsd.org/OpenBSD-current/man4/usb.4

Yay? No. Unfortunately as you can see on those pages or infer from my attempt at wit, it's not a perfect solution. The two links will lead to a list of man page links to the software drivers the OS uses to interact with the adapters. And on those drivers' man pages are the particular models of hardware supported. The added challenge is understanding which driver is mapped to which actual model of hardware. This isn't a big deal with already-installed network adapters- simply man what you see from issuing ifconfig in the system. But for those in my situation- shopping for new adapters- the situation becomes significantly more difficult, because enough of the less expensive adapter manufacturers do not advertise the specific chipsets being used. I know the OBSD project does not market itself or attempt to become used more in any way, but changing this back might go a long way as far as expanding the user base, or making life easier on the existing user base (of which I am).

Everything so far in this post can be carried forward for years to come- a common risk of blogposts related to OpenBSD technology (because it has changed twice a year for 20 years without fail, making vast amounts of 'current' content stale). So at least you can depend on what you read above. But below, in an effort to save time for users in 2016 (including me in my shopping adventures), I've compiled a list of the models listed in all of those individual driver pages for what is supported in 2016 (6.1)


Wired Adapters

age — Attansic L1 10/100/Gigabit Ethernet device

alc — Atheros AR813x/AR815x 10/100/Gigabit Ethernet device

ale — Atheros AR8121/AR8113/AR8114 10/100/Gigabit Ethernet device

bce — Broadcom BCM4401 10/100 Ethernet device

bge — Broadcom BCM57xx/BCM590x 10/100/Gigabit Ethernet device.The bge driver provides support for various NICs based on the Broadcom BCM570x, 571x, 572x, 575x, 576x, 578x, 5776x and 5778x Gigabit Ethernet controller chips and the 590x and 5779x Fast Ethernet controller chips, including the following:

    • 3Com 3c996-T (10/100/1000baseT)
    • 3Com 3c996-SX (1000baseSX)
    • 3Com 3c996B-T (10/100/1000baseT)
    • Allied-Telesis AT-2972LX10/LC
    • Fujitsu PW0G8GE1U (1000baseSX)
    • Fujitsu PW0G8GE2U (10/100/1000baseT)
    • Fujitsu PW008GE4 (1000baseSX)
    • Fujitsu PW008GE5 (10/100/1000baseT)
    • Fujitsu PW008QG1U (10/100/1000baseT)
    • HP ProLiant NC320T PCI-E Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC320m PCI-E Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC370F PCI-X Gigabit NIC (1000baseSX)
    • HP ProLiant NC370T PCI-X Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC1020 PCI Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC6770 PCI-X Gigabit NIC (1000baseSX)
    • HP ProLiant NC7760 embedded PCI Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC7770 PCI-X Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC7771 PCI-X Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC7780 embedded PCI-X Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC7781 embedded PCI-X Gigabit NIC (10/100/1000baseT)
    • HP ProLiant NC7782 embedded PCI-X Gigabit NIC (10/100/1000baseT)
    • Netgear GA302T (10/100/1000baseT)
    • SysKonnect SK-9D21 (10/100/1000baseT)
    • SysKonnect SK-9D41 (1000baseSX)

bnx — Broadcom NetXtreme II 10/100/Gigabit Ethernet device. The bnx driver supports Broadcom's NetXtreme II product family which is made up of the BCM5706, BCM5708, BCM5709, and BCM5716 Ethernet controller chips. Products using these controller chips include:
    • HP NC370F PCI-X Multifunction Gigabit server adapter (1000baseSX)
    • HP NC370T PCI-X Multifunction Gigabit server adapter (10/100/1000baseT)
    • HP Dual NC370i Multifunction Gigabit embedded server adapter (10/100/1000baseT)
    • HP NC373F PCI Express Multifunction Gigabit server adapter (1000baseSX)
    • HP NC373i PCI Express Multifunction Gigabit embedded server adapter (10/100/1000baseT)
    • HP NC374m PCI Express Multifunction Gigabit embedded server adapter (10/100/1000baseT)
    • HP NC373T PCI Express Multifunction Gigabit server adapter (10/100/1000baseT)
    • HP NC380T PCI Express Dual Port Multifunction Gigabit server adapter (10/100/1000baseT)
    • HP NC382T PCI Express Dual Port server adapter (10/100/1000baseT)

cas — Sun Cassini 10/100/Gigabit Ethernet device
  • Sun GigaSwift Ethernet Adapter (10/100/1000baseT)
  • Sun GigaSwift Ethernet MMF Adapter (1000baseSX)
  • Sun Quad GigaSwift Ethernet UTP Adapter (10/100/1000baseT)
  • Sun Quad GigaSwift PCI-X Adapter (10/100/1000baseT)
  • Sun Dual Gigabit Ethernet and Dual SCSI/P Adapter (10/100/1000baseT)

dc — DEC/Intel 21140/21142/21143/21145 and clones 10/100 Ethernet device
  • DEC 21140 PCI
  • DEC/Intel 21143 PCI and CardBus
  • Intel 21145 PCI
  • Macronix 98713, 98713A, 98715, 98715A, 98725, 98727 and 98732
  • Davicom DM9100, DM9102, and DM9102A
  • ASIX Electronics AX88140A and AX88141
  • ADMtek AL981 Comet, AN983 Centaur-P and ADM9511/ADM9513 Centaur-II PCI
  • ADMtek AN985 Centaur-C CardBus
  • Lite-On 82c168 and 82c169 PNIC
  • Lite-On/Macronix 82c115 PNIC II
  • Xircom X3201-based CardBus

de — DEC DC21x4x (Tulip) 10/100 Ethernet device
  • Asante
  • Cogent EM100FX and EM440TX
  • DEC PCI DE435, EISA DE425, DE450, DE500
  • older Linksys 10, 10/100
  • SMC 8432, 9332, 9334
  • ZNYX ZX3xx
em — Intel PRO/1000 10/100/Gigabit Ethernet device. 
The em driver provides support for PCI, PCI-X and PCI Express Gigabit Ethernet adapters based on the Intel 82540EM, 82540EP, 82541EI, 82541ER, 82541GI, 82541PI, 82542, 82543GC, 82544EI, 82544GC, 82545EM, 82545GM, 82546EB, 82546GB, 82547EI, 82547GI, 82562V, 82563EB, 82564EB, 82566DC, 82566DM, 82571EB, 82571GB, 82572EI, 82572GI, 82573E, 82573L, 82573V, 82574L, 82575EB, 82575GB, 82576EB, 82577LC, 82577LM, 82578DC, 82578DM, 82579LM, 82579V, 82580DB, 82580EB, 82583V, I210, I211, I217, I218, I219, I350, I354 Ethernet controller chips and the embedded chips found on EP80579 platform, including the following:
  • Axiomtek NA-200 EP80579 based board
  • HP ProLiant NC110T PCI Express Gigabit NIC
  • HP ProLiant NC112T PCI Express Gigabit NIC
  • HP ProLiant NC310F PCI-X Gigabit NIC (SX Fiber)
  • HP ProLiant NC340T PCI-X Quad Port Gigabit NIC
  • HP ProLiant NC360T PCI Express Dual Port Gigabit NIC
  • HP ProLiant NC364T PCI Express Quad Port Gigabit NIC
  • HP ProLiant NC365T PCI Express Quad Port Gigabit NIC
  • HP ProLiant NC6132 Upgrade Module (SX Fiber)
  • HP ProLiant NC6133 Upgrade Module (LX Fiber)
  • HP ProLiant NC6134 PCI Gigabit NIC (SX Fiber)
  • HP ProLiant NC6136 PCI Gigabit NIC (SX Fiber)
  • HP ProLiant NC6170 PCI-X Gigabit NIC (SX Fiber)
  • HP ProLiant NC7131 PCI Gigabit NIC
  • HP ProLiant NC7132 Upgrade Module
  • HP ProLiant NC7170 PCI-X Dual Port Gigabit NIC
  • HP ProLiant NC7170LP PCI-X Dual Port Gigabit NIC
  • Intel PRO/1000 Gigabit Server Adapter (SX Fiber) (PWLA8490)
  • Intel PRO/1000F Gigabit Server Adapter (SX Fiber) (PWLA8490SX)
  • Intel PRO/1000T Server Adapter (PWLA8490T)
  • Intel PRO/1000XT Server Adapter (PWLA8490XT)
  • Intel PRO/1000XS Server Adapter (SX Fiber) (PWLA8490XF)
  • Intel PRO/1000T Desktop Adapter (PWLA8390T)
  • Intel PRO/1000XTL Low Profile PCI Server (PWLA8490XTL)
  • Intel PRO/1000MT Desktop Adapter (PWLA8390MT)
  • Intel PRO/1000MT Server Adapter (PWLA8490MT)
  • Intel PRO/1000MT Dual Port Server Adapter (PWLA8492MT)
  • Intel PRO/1000MF Server Adapter (SX Fiber) (PWLA8490MF)
  • Intel PRO/1000MF Dual Port Server Adapter (SX Fiber) (PWLA8492MF)
  • Intel PRO/1000MF Server Adapter (LX Fiber) (PWLA8490LX)
  • Intel PRO/1000MT Quad PCI-X Adapter (PWLA8494MT)
  • Intel PRO/1000GT Quad PCI-X Adapter (PWLA8494GT)
  • Intel PRO/1000PT Desktop Adapter
  • Intel PRO/1000PT Server Adapter
  • Intel PRO/1000PT Dual Port Server Adapter
  • Intel PRO/1000PT Quad Port Server Adapter
  • Intel PRO/1000PF Server Adapter (SX Fiber)
  • Intel PRO/1000PF Dual Port Server Adapter (SX Fiber)
  • Intel PRO/1000ET Dual Port Server Adapter
  • Intel PRO/1000ET Quad Port Server Adapter
  • Intel PRO/1000EF Quad Port Server Adapter (SX Fiber)
  • Intel I340-T4 PCI Express Quad Port Gigabit NIC
  • Intel I350-T2 PCI Express Dual Port Gigabit NIC
  • Intel I350-T4 PCI Express Quad Port Gigabit NIC
  • Soekris Engineering lan1841
  • Sun PCI-E Dual Gigabit Ethernet LP UTP Adapter
  • Sun PCI-E Dual Gigabit Ethernet LP MMF Adapter
  • Sun PCI-E Dual Gigabit Ethernet EM UTP Adapter
  • Sun PCI-E Dual Gigabit Ethernet EM MMF Adapter
  • Sun PCI-E Dual Gigabit Ethernet ExpressModule
  • Sun x4 PCI-E Quad Gigabit Ethernet LP UTP Adapter
  • Sun x4 PCI-E Quad Gigabit Ethernet ExpressModule
  • Sun x8 PCI-E Quad Gigabit Ethernet ExpressModule
  • Supermicro AOC-SG-i2 Dual Port Server Adapter
  • Supermicro AOC-PG-I2+ Dual Port Server Adapter
ep — 3Com EtherLink III and Fast EtherLink III 10/100 Ethernet device
  • 3C509 EtherLink III ISA
  • 3C509B EtherLink III ISA (Plug-and-Play)
  • 3C556 EtherLink III LAN+Modem PC Card (PCMCIA)
  • 3C562 EtherLink III LAN+33.6K Modem PC Card (PCMCIA)
  • 3C574 Fast EtherLink III 10/100 LAN PC Card (PCMCIA)
  • 3C579 EtherLink III EISA
  • 3C589 EtherLink III LAN PC Card (PCMCIA)
  • 3C590 Fast EtherLink III PCI
  • 3C592 EtherLink III EISA Bus Master
  • 3C595 Fast EtherLink III PCI 10/100
  • 3C597 Fast EtherLink III EISA 10/100

epic — SMC 83C170 (EPIC/100) 10/100 Ethernet device

et — Agere/LSI ET1310 10/100/Gigabit Ethernet device.supports PCI Express Ethernet adapters based on the Agere/LSI ET1310 integrated MAC/PHY.

fxp — Intel EtherExpress PRO/100 10/100 Ethernet device
  • Intel EtherExpress PRO/100 PCI
  • Intel EtherExpress PRO/100B PCI
  • Intel EtherExpress PRO/100+ PCI
  • Intel EtherExpress PRO/100 Dual-Port PCI
  • Intel PRO/100 CardBus II PC Card
  • Intel PRO/100 VE
  • Intel PRO/100 VM
  • Intel PRO/100 M
  • Intel PRO/100 S
gem — GEM 10/100/Gigabit Ethernet device
  • Apple GMAC (10/100/1000baseT)
  • Sun ERI (10/100baseT)
  • Sun GEM (10/100/1000baseT)
  • Sun GEM (1000baseSX)

hme — Sun Happy Meal 10/100 Ethernet device
  • Sun FastEthernet PCI
  • Sun FastEthernet SBus
  • Sun Quad FastEthernet PCI
  • Sun Quad FastEthernet SBus
  • Sun SunSwift PCI
  • Sun SunSwift SBus

ix — Intel 82598/82599/X540 PCI Express 10Gb Ethernet device

  • Intel 82598AF 10GbE Adapter (10GbaseSR)
  • Intel 82598AF Dual Port 10GbE Adapter (10GbaseSR)
  • Intel 82598EB 10GbE Adapter (10GbaseCX4)
  • Intel 82598EB 10GbE Adapter (SFP+)
  • Intel 82598EB Dual Port 10GbE Adapter (10GbaseCX4)
  • Intel 82598EB XF 10GbE Adapter (10GbaseLR)
  • Intel 82598AT 10GbE Adapter (10GbaseT)
  • Intel 82598AT Dual Port 10GbE Adapter (10GbaseT)
  • Intel 82599EB 10GbE Adapter (10GbaseCX4)
  • Intel X520-DA2 Dual Port 10GbE Adapter (SFP+)
  • Intel X520-SR1 10GbE Adapter (SFP+/10GbaseSR)
  • Intel X520-SR2 Dual Port 10GbE Adapter (SFP+/10GbaseSR)
  • Intel X520-LR1 10GbE Adapter (SFP+/10GbaseLR)
  • Intel X540-T1 10GbE Adapter (10GbaseT)
  • Intel X540-T2 Dual Port 10GbE Adapter (10GbaseT)
  • HotLava Tambora 64G4/80G4/64G6/120G6 (SFP+)

ixgb — Intel PRO/10GbE 10Gb Ethernet device
  • Intel PRO/10GbE CX4 Server Adapter (PXLA8591CX4)
  • Intel PRO/10GbE LR Server Adapter (PXLA8591LR)
  • Intel PRO/10GbE SR Server Adapter (PXLA8591SR)
  • Sun 10 Gigabit Ethernet PCI-X Adapter (X5544A-4)
jme — JMicron JMC25x/JMC26x 10/100/Gigabit Ethernet device

lge — Level 1 LXT1001 NetCellerator PCI Gigabit Ethernet device

    • Allied Telesis CentreCOM LA1000-PCI-SX
    • D-Link DGE-500SX
    • SMC TigerCard 1000 (SMC9462SX)

lii — Attansic L2 10/100 Ethernet device

mskmskc — Marvell Yukon-2 10/100/Gigabit Ethernet device
  • D-Link DGE-550SX, multimode fiber adapter
  • D-Link DGE-560SX, multimode fiber adapter
  • D-Link DGE-550T B1, copper adapter
  • D-Link DGE-560T, copper adapter
  • SysKonnect SK-9E21 single port, copper adapter
  • SysKonnect SK-9E22 dual port, copper adapter
  • SysKonnect SK-9E81 single port, multimode fiber adapter
  • SysKonnect SK-9E82 dual port, multimode fiber adapter
  • SysKonnect SK-9E91 single port, single mode fiber adapter
  • SysKonnect SK-9E92 dual port, single mode fiber adapter
  • SysKonnect SK-9S21 single port, copper adapter
  • SysKonnect SK-9S22 dual port, copper adapter
  • SysKonnect SK-9S81 single port, multimode fiber adapter
  • SysKonnect SK-9S82 dual port, multimode fiber adapter
  • SysKonnect SK-9S91 single port, single mode fiber adapter
  • SysKonnect SK-9S92 dual port, single mode fiber adapter
  • SysKonnect SK-9E21D single port, copper adapter

mtd — Myson Technology MTD800/MTD803/MTD891 10/100/Gigabit Ethernet device
    • Safeway Lancard SW-10/100 PCI (model 117204)
    • Surecom EP-320X-S

myx — Myricom Myri-10G PCI Express 10Gb Ethernet device
  • Myricom 10G-PCIE-8A-C Adapter (10GbaseCX4)
  • Myricom 10G-PCIE-8A-R Adapter (10GbaseSR/LR)
  • Myricom 10G-PCIE-8A-Q Adapter (10G XAUI)
  • Myricom 10G-PCIE2-8B2-2S Adapter (10GbaseSR/LR)
  • Myricom 10G-PCIE2-8C2-2S Adapter (10GbaseSR/LR/LRM)

ne — NE2000 and compatible 10/100 Ethernet device
  • Accton EN2212, EN2216
  • Addtron W89C926 Ethernet
  • Allied Telesis LA-PCM
  • AmbiCom AMB8002T
  • Arowana FE
  • Belkin F5D5020
  • Billionton Systems CFLT2-10B
  • Billionton Systems CFLT2-10N
  • Billionton Systems LNT-10TN
  • Buffalo LPC-CF-CLT
  • Buffalo LPC4-CLX
  • Buffalo LPC3-CLT
  • CNet NE2000, FastEthernet
  • Compex PCI Ethernet
  • Compex Linkport ENET-B
  • Corega PCC-T, PCC-TD, EtherII PCC-T
  • Corega FastEther PCC-T, FastEther PCC-TX
  • Corega FastEther PCC-TXD, FastEther PCC-TXF
  • D-Link DE-650, DE-660, DE-660+, DFE-670TXD
  • Dayna CommuniCard E
  • Digital DEPCM-XX
  • Dual NE2000
  • Edimax NE2000
  • Genius ME 3000II SE
  • Grey Cell GCS2000 Gold II
  • GVC NIC-2000p, NP0335
  • Hawking CF686TX
  • Hawking PN650TX
  • I-O DATA PCLA, PCLA/TE
  • I-O DATA PCET/TX-R
  • IC-Card
  • Kingston KNE-PC2
  • KTI PCI Ethernet
  • Linksys PCMPC100, EC2T Combo
  • Linksys EthernetCard, Combo EthernetCard
  • Linksys Trust Combo EthernetCard, EtherFast 10/100
  • MACNICA ME1 for JEIDA
  • Melco LPC3-TX
  • National Semiconductor InfoMover
  • NDC Instant-Link
  • Netgear FA410TX, FA410TXC, FA411
  • NetVin NV5000
  • Network Everywhere NP10T
  • New Media LiveWire 10/100
  • Planet SmartCom 2000
  • Planex FNW-3600-T, FNW-3700-T
  • Premax PE-200
  • Realtek RT8029
  • Relia Technologies Ethernet
  • RPTI EP-400, EP-401
  • Seiko Epson EN10B
  • SMC EZCard, 8041
  • SMC EZCard, 8041TX
  • Socket Communications LP-CF, LP-E
  • Socket Communications CF 10/100
  • SVEC PN650TX, ComboCard, LANCard
  • Surecom NE-34
  • Synergy S21810
  • Tamarack TC3299CE
  • Tamarack NE2000
  • Telecom Device TCD-HPC100
  • TRENDnet TE-CF100
  • VIA Technologies VT86C926
  • Winbond W89C940
  • Winbond W89C940F
  • Wisecom T210CT, iPort
  • Xircom CFE-10


nep — Sun Neptune 10Gb Ethernet device
  • Sun Quad GBe UTP x8 PCI Express Card
  • Sun Quad GBe UTP x8 PCIe ExpressModule

nfe — NVIDIA nForce MCP 10/100/Gigabit Ethernet device
The nfe driver supports Fast Ethernet and Gigabit Ethernet adapters based on the NVIDIA nForce Media and Communications Processors (MCP), the nForce, nForce 2, nForce 3, CK804, MCP04, MCP51, MCP55, MCP61, MCP65, MCP67, MCP73, MCP77, MCP79 and MCP89 Ethernet controller chips.



nge — National Semiconductor PCI 10/100/Gigabit Ethernet device
  • Addtron AEG320T
  • Ark PC SOHO-GA2500T (32-bit PCI) and SOHO-GA2000T (64-bit PCI)
  • Asante FriendlyNet GigaNIX 1000TA and 1000TPC
  • D-Link DGE-500T
  • Linksys EG1032v1 (32-bit PCI) and EG1064v1 (64-bit PCI)
  • Netgear GA621
  • Netgear GA622T
  • SMC EZ Card 1000 (SMC9462TX)
  • Surecom Technology EP-320G-TX
  • TRENDnet TEG-PCITX (32-bit PCI) and TEG-PCITX2 (64-bit PCI)

oce — Emulex OneConnect 10Gb Ethernet device
  • Emulex OCe11102 (SPF+/10GbaseSR or 10GbaseT)
  • Emulex OCe10102 (SPF+/10GbaseSR)
  • HP NC550M Flex-10 (10GbaseKR)
  • HP NC552M Flex-10 (10GbaseKR)
  • HP NC550SFP (SPF+/10GbaseSR)
  • HP NC552SFP (SPF+/10GbaseSR)
  • IBM System x 10GbE (SPF+/10GbaseSR)

pcn — AMD PCnet-PCI 10/100 Ethernet device
  • Am79c970 PCnet-PCI Single-Chip Ethernet Controller for PCI Local Bus
  • Am79c970A PCnet-PCI II Single-Chip Full-Duplex Ethernet Controller for PCI Local Bus
  • Am79c971 PCnet-FAST Single-Chip Full-Duplex 10/100Mbps Ethernet Controller for PCI Local Bus
  • Am79c972 PCnet-FAST+ Enhanced 10/100Mbps PCI Ethernet Controller with OnNow Support
  • Am79c973/Am79c975 PCnet-FAST III Single-Chip 10/100Mbps PCI Ethernet Controller with Integrated PHY
re — Realtek 8139C+/8169/816xS/811xS/8168/810xE 10/100/Gigabit Ethernet device
  • Alloy Computer Products EtherGOLD 1439E 10/100 (8139C+)
  • Buffalo LGY-PCI-GT (8169S)
  • Compaq Evo N1015v Integrated Ethernet (8139C+)
  • Corega CG-LAPCIGT (8169S)
  • D-Link DGE-528T (8169S)
  • D-Link DGE-530T C1 (8169/8110SB)
  • D-Link DGE-660TD (8169/8110SB)
  • Gigabyte 7N400 Pro2 Integrated Gigabit Ethernet (8110S)
  • LevelOne GNC-0105T (8169S)
  • Linksys EG1032v3 (8169S)
  • Netgear GA311 (8169S)
  • Netgear GA511 PC Card (8169)
  • PLANEX COMMUNICATIONS Inc. GN-1200TC (8169S)
  • Surecom EP-320G-TX1 (8169S)
  • TTTech MC322 (8139C+)
  • US Robotics USR997902 (8169S)
  • Xterasys XN-152 10/100/1000 NIC (8169)
rl — Realtek 8129/8139 10/100 Ethernet device
  • Accton MPX5030 CardBus
  • Allied Telesyn AT2550
  • Corega FEther CB-TXD 10/100 Ethernet
  • D-Link DFE-520TX C1, DFE-530TX+, DFE-538TX, DFE-690TXD
  • Encore ENL832-TX-RENT 10/100 M PCI
  • Genius GF100TXR
  • KTX-9130TX 10/100 Fast Ethernet
  • Longshine LCS-8038TX-R
  • NDC Communications NE100TX-E
  • Netgear FA311 v2
  • Netronix Inc. EA-1210 NetEther 10/100
  • Nortel BayStack 21
  • OvisLink LEF-8129TX, LEF-8139TX
  • SMC EZ Card 10/100 PCI 1211-TX
  • TRENDnet TE100-PCBUSR CardBus.

se — SiS 190/191 10/100/Gigabit Ethernet device

sf — Adaptec AIC-6915 Starfire PCI 10/100 Ethernet device
  • ANA-62011 64-bit single port 10/100baseTX
  • ANA-62022 64-bit dual port 10/100baseTX
  • ANA-62044 64-bit quad port 10/100baseTX
  • ANA-69011 32-bit single port 10/100baseTX
  • ANA-62020 64-bit single port 100baseFX

sis — SiS 900, SiS 7016, and NS DP83815/6 10/100 Ethernet device
  • @Nifty FNECHARD IFC USUP-TX
  • MELCO LGY-PCI-TXC
  • Netgear FA311, FA312, FA331
  • Soekris Engineering lan1621, lan1641
skskc — SysKonnect XMAC II and Marvell Yukon 10/100/Gigabit Ethernet device
  • 3Com 3c940 single port, copper adapter
  • 3Com 3c2000-T single port, copper adapter
  • Allied Telesis AT-2916T, copper adapter
  • Belkin F5D5005 v1000, copper adapter
  • D-Link DGE-530T A1, copper adapter
  • D-Link DGE-530T B1, copper adapter
  • Fujitsu PP028GE1U, multimode fiber adapter
  • Fujitsu PP028GE1X, multimode fiber adapter
  • Fujitsu PW008GE1U, copper adapter
  • Fujitsu PW008GE1X, copper adapter
  • Linksys EG1032v2, copper adapter
  • Linksys EG1064v2, copper adapter
  • SMC 9452TX, copper adapter
  • SysKonnect SK-9521 V2.0 single port, copper adapter
  • SysKonnect SK-9821 single port, copper adapter
  • SysKonnect SK-9821 V2.0 single port, copper adapter
  • SysKonnect SK-9822 dual port, copper adapter
  • SysKonnect SK-9841 single port, single mode fiber adapter
  • SysKonnect SK-9842 dual port, single mode fiber adapter
  • SysKonnect SK-9843 single port, multimode fiber adapter
  • SysKonnect SK-9843 V2.0 single port, copper adapter
  • SysKonnect SK-9844 dual port, multimode fiber adapter

ste — Sundance Technologies ST201 10/100 Ethernet device
  • D-Link DFE-550TX
  • D-Link DFE-580TX
  • Encore ENL832-TX-ICNT 10/100 M PCI

stge — Sundance/Tamarack TC9021 Gigabit Ethernet device
  • Allied Telesis CentreCOM LA1000-PCI-T
  • Antares Microsystems TC9021
  • Asus NX1101
  • D-Link DGE-550T
thtthtc — Tehuti Networks 10Gb Ethernet device
  • TN3017-S 10 GbE Single Port XAUI Server Controller
  • TN3017-D 10 GbE Dual Port XAUI Server Controller
  • TN7581-D 10 GbE Dual XFP Server Adapter
  • TN7585-D 10 GbE Dual CX4 Low Profile Server Adapter
  • TN7588-S 10 GbE Single 10GBASET Low Profile Server Adapter
  • TN7588-D 10 GbE Dual 10GBASET Low Profile Server Adapter
  • TN7589-S 10 GbE Single CX4 Low Profile Server Adapter
ti — Alteon Networks Tigon I and II Gigabit Ethernet device
  • 3Com 3C985-SX Gigabit Ethernet (1000baseSX)
  • 3Com 3C985B-SX Gigabit Ethernet (1000baseSX)
  • Alteon AceNIC V Gigabit Ethernet (1000baseSX)
  • Alteon AceNIC V Gigabit Ethernet (1000baseT)
  • Digital EtherWORKS 1000SX PCI Gigabit Ethernet (1000baseSX)
  • Farallon PN9000SX Gigabit Ethernet (1000baseSX)
  • Netgear GA620 Gigabit Ethernet (1000baseSX)
  • Netgear GA620T Gigabit Ethernet (1000baseT)
  • Silicon Graphics Gigabit Ethernet (1000baseSX)
  • Silicon Graphics Gigabit Ethernet (1000baseT)
  • Sun Vector Gigabit Ethernet (1000baseSX)

tl — Texas Instruments ThunderLAN 10/100 Ethernet device
This includes a large number of Compaq PCI-bus Ethernet adapters as well as the integrated Ethernet controllers built in to several models of Compaq Prosignia servers and Compaq Deskpro desktop machines. This driver also supports the Olicom OC-2135/2138, OC-2325 and OC-2326 10/100 TX UTP adapters and the Racore 8165 10/100baseTX and 8148 10baseT/100baseTX/100baseFX multi-personality cards.


txp — 3Com 3XP Typhoon/Sidewinder (3CR990) 10/100 Ethernet device
  • 3Com 3CR990-TX-95
  • 3Com 3CR990-TX-97
  • 3Com 3CR990SVR95
  • 3Com 3CR990SVR97

vge — VIA Velocity 10/100/Gigabit Ethernet device
  • ZyXEL GN650-T 64-bit PCI Gigabit Ethernet NIC (ZX1701)
  • ZyXEL GN670-T 32-bit PCI Gigabit Ethernet NIC (ZX1702)

vic — VMware VMXnet Virtual Interface Controller device
  • VMware ESX 2.0 and newer
  • VMware GSX 2.5 and newer
  • VMware Server 1.0 and newer
  • VMware Workstation 4.5 and newer
  • VMware Fusion 1.0 and newer

vmx — VMware VMXNET3 Virtual Interface Controller device

  • VMware ESX/ESXi 4.0 and newer
  • VMware Server 2.0 and newer
  • VMware Workstation 6.5 and newer
  • VMware Fusion 2.0 and newer

vr — VIA Rhine I/II/III 10/100 Ethernet device
  • AOpen/Acer ALN-320
  • D-Link DFE-520TX, DFE-530TX
  • Hawking Technologies PN102TX
  • Soekris Engineering lan1741

vte — RDC R6040 10/100 Ethernet device
commonly found on Vortex86 System On a Chip (SoC).

wb — Winbond W89C840F 10/100 Ethernet device
This includes the TRENDnet TE100-PCIE and various other cheap boards. The 840F should not be confused with the 940F, which is an NE2000 clone and only supports 10Mbps speeds.

xge — Neterion Xframe/Xframe II 10Gb Ethernet device
  • Fujitsu PRIMEQUEST 10GBASE-SR LAN Card (Xframe II)
  • Hitachi PCI-X 10 Gigabit Ethernet Adapter (Xframe II)
  • HP AB287A 10 Gigabit Ethernet Adapter (Xframe)
  • IBM 10GbE SR Server Adapter (Xframe II)
  • IBM 10 Gb Ethernet-LR PCI-X 2.0 DDR Adapter (Xframe II)
  • IBM 10 Gb Ethernet-SR PCI-X 2.0 DDR Adapter (Xframe II)
  • Neterion/S2io Xframe (Xframe)
  • Neterion Xframe II (Xframe II)
  • Neterion Xframe II Sun Fire (Xframe II)
  • Neterion Xframe E (Xframe II)
  • SGI 10 Gigabit Ethernet Network Adapter (Xframe)
xl — 3Com EtherLink XL and Fast EtherLink XL 10/100 Ethernet device
  • 3C555 EtherLink XL Mini PCI
  • 3C556 EtherLink XL Mini PCI
  • 3C556B EtherLink XL Mini PCI
  • 3C575 10/100 LAN CardBus PC Card
  • 3C656 10/100 LAN+Modem CardBus PC Card
  • 3C900 EtherLink XL PCI
  • 3C900B EtherLink XL PCI
  • 3C905 Fast EtherLink XL PCI
  • 3C905B Fast EtherLink XL PCI
  • 3C905C Fast EtherLink XL PCI
  • 3C980 Fast EtherLink Server NIC
  • 3CSOHO OfficeConnect Fast Ethernet NIC
  • 9201 NVIDIA nForce2 integrated 3Com 9201 (nForce2-ST, nForce2-GT)
  • 920BEMB 3c920B-EMB-WNM Integrated Fast Ethernet.


Wireless Adapters

acx — TI ACX100/ACX111 IEEE 802.11a/b/g wireless network device

an — Aironet Communications 4500/4800 IEEE 802.11FH/b wireless network device
(aka Cisco 340), and Cisco 350 IEEE 802.11 wireless network adapters. This includes the ISA, PCI, and PCMCIA varieties.

ath — Atheros IEEE 802.11a/b/g wireless network device with GPIO

athn — Atheros IEEE 802.11a/b/g/n wireless network device
ranging from the AR5008 up to the AR9287.

atw — ADMtek ADM8211 IEEE 802.11b wireless network device

bwi — Broadcom AirForce IEEE 802.11b/g wireless network device

ipw — Intel PRO/Wireless 2100 IEEE 802.11b wireless network device

iwi — Intel PRO/Wireless 2200BG/2225BG/2915ABG IEEE 802.11a/b/g wireless network device

iwn — Intel WiFi Link and Centrino IEEE 802.11a/b/g/n wireless network devices

iwm — Intel 7000/8000 IEEE 802.11a/ac/b/g/n wireless network devices

malo — Marvell Libertas IEEE 802.11b/g wireless network device

pgt — Conexant/Intersil Prism GT Full-MAC IEEE 802.11a/b/g wireless network device
can support the Full-Mac firmware, using the ISL3877, ISL3880, and ISL3890 chips.

ral — Ralink Technology/MediaTek IEEE 802.11a/b/g/n wireless network device
supports PCI/PCIe/CardBus wireless adapters based on the Ralink RT2500, RT2501, RT2600, RT2700, RT2800, RT3090 and RT3900E chipsets.

rtw — Realtek RTL8180L IEEE 802.11b wireless network device
A variety of radio transceivers can be found in these devices, including the Philips SA2400A, Maxim MAX2820, and GCT GRF5101.

rtwn — Realtek RTL8188CE PCIe IEEE 802.11b/g/n wireless network device

wi — WaveLAN/IEEE, PRISM 2-3, and Spectrum24 IEEE 802.11b wireless network device

wpi — Intel PRO/Wireless 3945ABG IEEE 802.11a/b/g wireless network device





That's it!