Mark Whitis's Website Home Page Linux Book: Linux Programming Unleashed My Resume Genealogical Data Contact Info Security About

[HOME(Mark Whitis)] [linux] [Contact] [Resume] [Browser Friendly] [No Spam] [FEL] [DBD]

Adaptec Quartet 4 port ethernet cards under Linux and other multiport cards

This page has information on using Multiport Ethernet Cards under Linux including those by Adaptec (Cogent), Znyx, Phobos, D-link, and Matrox (not-suported) but with emphasis on the Adaptec Quartets. Many of these cards are availible in single port, dual port, quad port and some are availible in compact PCI as well. There is an 8 port hot swap compact PCI board with a 64 bit PCI interface as well; although it requires a rear transition module instead of bringing the connections out on the main bracket.

Note: Adeptec might have discontinued the tulip based quartets (see below on the DuraLAN/starfire based quartet64s as well as other manufacturers of tulip based cards). They were not listed on adaptecs fast ethernet web page.

The adaptec/cogent Quartet 4 port ethernet cards do work under Linux with recent versions of the tulip driver and a decent bios. Note that there have been a number of revisions of the 21143 chip so if you have a board based on that chip, make sure you are using a recent driver version.

This page is primarily about the Adaptec ANA-6904 (Cogent EM964TP) and ANA-6944/TX because those are the models I am have actually used. it also applies to the following quartet cards as well as cards by many other manufacturers:
AdaptecCogentBusMedia
ANA-6944A/TXn/aPCI 2.1 (pentium pro)4x100BaseTX/10BaseT
ANA-6944/T4EM440T4-PCIPCI4x100BaseT4/10BaseT
ANA-6940/TXEM400TX-PCIPCI4x100BaseTX
ANA-6904/BNCEM964BNCPCI4x10Base2
ANA-6904EM964TPPCI4x10BaseT
There are two names because Adaptec ate Cogent and changed the model numbers.

Make sure you are using a recent version of the driver. The version included in many linux distributions (such as redhat 4.0) is too old. Visit Don Becker's tulip driver page for the latest release versions and the development page for the latest beta versions.

You may have problems if you are using a machine with an AMIBIOS. AMIBIOS is guilty of, in their words, "A legal misinterpretation of the [PCI] spec" that adversely affects devices, such as the quartet cards, which use a PCI to PCI bridge chip. AMI numbers the devices on the other side of bridge in the wrong order. For the quartet cards, this is a problem because the quartet only has an address on the first ethernet port and expects the driver to consequetively number the other three. If you get four ethernet addresses which are not consequetive (perhaps three are and one isn't) this is probably your problem. Don may have put in a patch to work around the defective BIOS. The correct ethernet address on the last port (really the first) is likely to begin with "00 00 92". The incorrect ones will be consequtively numbered starting from the hex equivalent of the text string '\0Linux' (I may not have the capitalization right). I.E. it will begin with "00 4C" or "00 6C". It appears that you can compile the driver with "-DREVERSE_PROBE" or insmod the module with "reverse_probe=1" on more recent tulip drivers to work around this bios bug.

The message "EEPROM not present" is not a cause for concern unless it occurs on the first port listed (in which case, see above). It is normal to get this message on ports 2 throuth 4.

Your bios may set up the ports to use 4 different interupts. This is more likely to be a problem with an AMIBIOS. I believe the driver has two options, one to renumber the ports to use one interrupt and the other to leave them at existing settings. There is a "#define" in the source code which needs to be changed. I think there might also have been another bug in the AMIBIOS that may have lead to interrupts not being properly set on the ports themselves which the driver can fix.

Adaptec/Cogent spec sheets are availible via the Adaptec web site.

Here are some of the distquishing markings on one of the cards (and key chips) which I have:

Emaster+ PCI QUARTET P/N 964001-0001  S/N 436241530
Cogent Data Technologies, Inc. (C) Copyright 1994 Made in U.S.A.
Digital 9616 D486651 VY0687 DECchip 21050 DC7526C
4x Digital 21040-AA DC1012B 21-40593-03 (c) DEC 1995 S15999-25 A 9636
HALO FD12-101G HIPOTED 9628 (ethernet interface)
Linear Tech LT1086CT-3.3 9601
The 21050 chip is the PCI to PCI bridge and the 4 21040 chips are the 10Mbs ethernet controllers.

Some of the chips on the 100Mb/s tulips get quite hot. The 21140s aren't too bad but the bridge chip and the 4 other large chips do get pretty hot.

I am using these boards with an Asus motherboard with AWARD bios.

If you want to use more than one quartet in a system, or use the quartet with any other ethernet card, you should be aware that by default the linux kernel only supported 4 ethernet devices (8 in 2.0.x). The 2.2 kernels support 16 ethernet devices without recompilation. This requires a relatively simple kernel change modification to /usr/src/linux/drivers/net/Space.c to add entries for the extra devices.

static struct device eth7_dev = {
    "eth7", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, NEXT_DEV, ethif_probe };
static struct device eth6_dev = {
    "eth6", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth7_dev, ethif_probe };
static struct device eth5_dev = {
    "eth5", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth6_dev, ethif_probe };
static struct device eth4_dev = {
    "eth4", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth5_dev, ethif_probe };
static struct device eth3_dev = {
    "eth3", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth4_dev, ethif_probe };
static struct device eth2_dev = {
    "eth2", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth3_dev, ethif_probe };
static struct device eth1_dev = {
    "eth1", 0,0,0,0,0xffe0 /* I/O base*/, 0,0,0,0, &eth2_dev, ethif_probe };

static struct device eth0_dev = {
    "eth0", 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, &eth1_dev, ethif_probe };
You need to add additional lines by copying. Note the references between lines needed to preserve the device chain. Don Becker has a page concerning the general issues invovled in using more than one etherenet device in a system.

Don't forget to look in the Ethernet HOWTO for general information.

On Don's tulip web page you will find some references to some multiport ethernet cards made by Znyx. I don't think there is as much experience in the Linux community with these cards as the Adaptec/Cogent cards, but Znyx seems to be supported Linux and now has patched Linux tulip drivers for their tulip based 4 port ethernet adapters available for download from their web site and that kernels >2.0.34 support at least some of the the Zynx cards, such as the regular PCI ZX346. Note that Znyx has CompactPCI models as well.

Adaptec also makes 4 port ANA-62044 quartet64 ethernet adapters which are NOT tulip based. These are based on some AIC-6915 LAN controllers. This is an adaptec DuraLAN chip. There is no mention of these chips in the drivers/net source directory of the 2.2.5 kernel and a quick web search failed to show any info. Note: a reader (chris@onthe.net.au) sent me these URLs on the new DuraLAN/Starfire driver:

The Znyx ZX478 is an 8 port Hot Swap CompactPCI (using rear transition module only, unfortunately) based ethernet card. It is based on intel 21143 (tulip) controllers with a 21554 64 bit PCI to 64 bit PCI bridge. I think the 21143 has a 32 bit bus so I am a little dubious about the 64 bit bus; it might work to decrease overhead on the motherboard/backplane PCI bus if it buffers up bus master DMA bursts from the 21143 and then retransmits them at the higher 64 bit speed; but I doubt it increases the throughput from a given card to the CPU. Znyx claims Linux support on the data sheet, although I havent seen any drivers on their web site.

Phobos makes 4 port ethernet controllers and has advertised them directly to the Linux community. Unfortunately, they seem to be more interested in making their web page as tacky as possible than they are in providing information about the drivers on their web pages.

The matrox shark NS-100/4 is a four port tulip 21140 based card. To be truly asinine, they put the EEPROM on the second (or third if you probe backwards) chip so the tulip driver will not work correctly with or without reverse_probe=1. This was reportedly a deliberate incompatibility.

The D-Link DFE-570TX is a Tulip based 4-port ethernet adapter. There have been a number of reports of trouble with these cards on the tulip mailing list (check the archive). Compiling the driver with these options may help:

gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -c tulip.c \
`[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS`
The D-Link card seems to be about half the price of the adaptec card. Someone reported that the chips on their REV-A1 board where 4x Intel 21143-TD (tulip), 1x Intel 21152-AB (PCI bridge), and 4x National DP83843BJVE (transceiver) chips. $150

The Compu-shack FastLine Quattro 10/100 4 port Ethernet cards reportedly work with the tulip driver. Visit the manufacturer's web site (german language) .

Redhat 6.0 comes with Tulip driver v0.89. Redhat 6.2beta comes with v0.91g-ppc 7/16/99.

Recent Tulip drivers come with a variable reverse_probe which is used to get around the AMIBIOS probe order bug. Add the argument "reverse_probe=1" to the insmod command when the driver is loaded.

Compex supposedly makes four port FL400TX cards. This page has some details on getting the single port FL100TX to work. They apparently used three different dec chips 21143PA, 21143PB, and 21143PD (probably different revisions of the same chip). The tulip 0.90 driver will now work with the 21143PD but the 21143PA apparently still doesn't work. Just because the single port may work, don't assume the four port will.

Note that the newer bridge chips used on some cards don't work on some dec alpha based systems without a patch. The newer bridge chips can pass 32 bits of address instead of just 16 to the remote PCI bus but the PCI code (not the tulip driver) in the alpha kernel does not know about this. On some machines the motherboard bios initializes a register on the bridge chip, enabling those extra bits. A small change to the PCI code resets this register.

Note that the Adaptec/Cogent cards are used in the Beowulf clusters at GSFC and LANL which connect Linux boxes together in a hypercube using 100Mbs Quartet cards to produce relatively inexpensive supercomputers. The principle investigator of the Linux beowulf project, Don Becker, is also the primary maintainer for the linux ethernet drivers. So the author of the tulip driver is very familiar with these cards; I think most of the problems other people may habe experienced have been caused by poor quality bioses.

Yes, I beleive the quartet cards support full duplex under linux, although you may need to issue some parameters to the driver to enable this.

Some of the older boards apparently did not have media descriptions in the EEPROM and did not support N-Way autonegotiation. I think the latter refers to negotiating 10 or 100Mbs and half or full duplex; which I suspect is likely to be even tricker if you are using crossover cables between two NIC's (for example if you are using them in a machine which functions as a bridge, router, hub, or switch or for dedicated communications links). If you have one of the old cards, see the development page for more information on media descriptions and try manually configuring the media type.

The tulip driver has a debug option which can be set at the time you insmod the module.

Some AMIBIOS defects:

So I recommend not buying systems with an AMI BIOS for serious applications, although they may be tolerable for a mundane workstation which is not going to have either a large number of internal peripherals or more exotic peripherals.

Here is a sample of what the messages look like when the driver loads. I cut this from an old message which had a sample from a non-working system (although in this case I think the messags look fine except for the version number). I will have to cut some text from a working system when I get a chance. But I think it might be easier to understand some of the things I wrote here, if you have an example to look at.

tulip.c:v0.66 3/14/97 becker@cesdis.gsfc.nasa.gov
eth0: DEC21040 Tulip at 0x3000, 00 00 92 92 4a f4, IRQ 11
eth1: DEC21040 Tulip at 0x3080, EEPROM not present, 00 00 92 92 4a f5, IRQ 11
eth2: DEC21040 Tulip at 0x3400, EEPROM not present, 00 00 92 92 4a f6, IRQ 11
eth3: DEC21040 Tulip at 0x3480, EEPROM not present, 00 00 92 92 4a f7, IRQ 11

Don Becker, the primary author and maintainer of the Linux ethernet drivers, has a Gigabit and 100Mbps Ethernet Technology Page which describes the availible chipsets.

The DEC Tulip chips include the 21040, 21041, 21140, 21140A, 21142, and 21143. The Lite-On 82c168 "PNIC" PCI Network Interface Controller, and the Macronix MX98713, MX98715, and MX98725, are all tulip clones. These tulip driver has been modified to support these.

The following sections indicate the BIOS PCI probe results and the kernel messages resulting from having one 10/100Mb/s quartets and two 10Mb/s quartets in the same machine (detected in that order). Slots (at least on that ASUS motherboard) are detected from left to right. Note that the messages in /var/log/messages were interleaved (this will happen when you try to bring up 12 interfaces simultaneously) I had to rearange them to make them readable.

bus# dev# func#  vendorID Dev ID  Device Class             IRQ
---- ---- -----  -------- ------  -------------            ---
 0    1     1    8086     7111    IDE Controler            14/15
 0    1     2    8086     7112    Serial bus controller    5

 1    4     0    1011     0009    Network Controller       9
 1    5     0    1011     0009    Network Controller       5
 1    6     0    1011     0009    Network Controller       11
 1    7     0    1011     0009    Network Controller       12

 2    4     0    1011     0002    Network Controller       12
 2    5     0    1011     0002    Network Controller       9
 2    6     0    1011     0002    Network Controller       5
 2    7     0    1011     0002    Network Controller       11

 3    4     0    1011     0002    Network Controller       11
 3    5     0    1011     0002    Network Controller       12
 3    6     0    1011     0002    Network Controller        9
 3    7     0    1011     0002    Network Controller        5 

Note, however, that the interrupt settings above are apparently wrong (this
is a common bug in most BIOSes, including AWARD); all 4 interrupts on
each board are apparently mapped to the same interrupt.

 eth0: Digital DS21140 Tulip at 0xc800, 00 00 92 a7 d7 8c, IRQ 9. 
 eth0:  EEPROM default media type Autosense. 
 eth0:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth0: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth0: Setting full-duplex based on MII Xcvr #1 parter capability of 41e1. 

 eth1: Digital DS21140 Tulip at 0xc400, EEPROM not present, 00 00 92 a7 d7 8d, IRQ 9. 
 eth1:  Controller 1 of multiport board. 
 eth1:  EEPROM default media type Autosense. 
 eth1:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth1: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth1: No link beat on the MII interface, status then 7849 now 7849. 
 [message repeats]

 eth2: Digital DS21140 Tulip at 0xc000, EEPROM not present, 00 00 92 a7 d7 8e, IRQ 9. 
 eth2:  Controller 2 of multiport board. 
 eth2:  EEPROM default media type Autosense. 
 eth2:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth2: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth2: No link beat on the MII interface, status then 7849 now 7849. 
 [message repeats]

 eth3: Digital DS21140 Tulip at 0xb800, EEPROM not present, 00 00 92 a7 d7 8f, IRQ 9. 
 eth3:  Controller 3 of multiport board. 
 eth3:  EEPROM default media type Autosense. 
 eth3:  Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. 
 eth3: ***WARNING***: No MII transceiver found! 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
n eth3: No link beat on the MII interface, status then 7849 now 7849. 
 [ message repeats]

 eth4: Digital DC21040 Tulip at 0xa800, 00 00 92 92 4f 70, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth4: No 10baseT link beat found, switching to AUI media. 

 eth5: Digital DC21040 Tulip at 0xa400, EEPROM not present, 00 00 92 92 4f 71, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth5: No 10baseT link beat found, switching to AUI media. 

 eth6: Digital DC21040 Tulip at 0xa000, EEPROM not present, 00 00 92 92 4f 72, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth6: No 10baseT link beat found, switching to AUI media. 

 eth7: Digital DC21040 Tulip at 0x9800, EEPROM not present, 00 00 92 92 4f 73, IRQ 12. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth7: No 10baseT link beat found, switching to AUI media. 

 eth8: Digital DC21040 Tulip at 0x8800, 00 00 92 92 54 cc, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth8: No 10baseT link beat found, switching to AUI media. 

 eth9: Digital DC21040 Tulip at 0x8400, EEPROM not present, 00 00 92 92 54 cd, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth9: No 10baseT link beat found, switching to AUI media. 

 eth10: Digital DC21040 Tulip at 0x8000, EEPROM not present, 00 00 92 92 54 ce, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth10: No 10baseT link beat found, switching to AUI media. 

 eth11: Digital DC21040 Tulip at 0x7800, EEPROM not present, 00 00 92 92 54 cf, IRQ 11. 
   PCI latency timer (CFLT) is unreasonably low at 0.  Setting to 64 clocks. 
 eth11: No 10baseT link beat found, switching to AUI media. 

The Adaptec 2940 SCSI device driver apparently needs to be modified to remove the SA_INTERRUPT flag to the request_irq() call if it is going to share an interrupt with any other device.

Credits: Much of this information comes from my own tinkering. Some of it comes from a face to face conversation with Don Becker, who was very helpful. Some of it comes from the linux tulip driver mailing list. Some of it comes from the "ethernet HOWTO", some comes from Adaptec's web site, some comes from the Don's tulip web page and some comes from reading the driver source. Jeff Uphoff and Steve Friedman also participated in the tinkering with the tulip driver.

Disclaimer: some of the content of this page is from memory; unfortunately, the warranty on my memory expired quite some time ago. The organization of this page is rather rough.

/etc/conf.modules

You will need to add lines to /etc/conf.modules for each interface. You will want to add lines to the existing content as needed. You will need an "alias ..." line for each ethernet interface. If you need any special options when the module is loaded, use an options line such as the one shown below.
alias eth0 tulip
alias eth1 tulip
alias eth2 tulip
alias eth3 tulip
options tulip reverse_probe=1

General (non-multiport specific) Ethernet information

Charles Spurgeon's Ethernet Web Site has general ethernet, fast ethernet, gigabit ethernet, and fiberchannel information.

High speed wiring is very sensitive. Crosstalk and reflections (echo) can be a significant problem. Cable length should be 100m or less. 100baseT wiring should be done using 4 pair category 5 wiring, wired according to EIA-568B, with a minimum bend radius of 10 times the cable diameter (some special cables may tolerate 4x). It is very important not to untwist the cable any more than is absolutely necessary to make the connection. Simple cable testers will not detect split pairs where the right pins are connected on each end but the wrong wires are paired together. Gigabit ethernet has similar wiring requirements but is even less forgiving; category 5e or Category 6 (not yet fully standardized) is preferred but some CAT5 wiring will work. The MOD-TAP website has a useful Cabling FAQ.

Problem Diagnosis and Reporting

If you have trouble with a card, you can report it to the tulip mailing list. If the problem seems to be specifically related to a 4 port card issue, email me a copy (include my address in the "To:" field not "Cc:"). Links to the tulip mailing list may be found on Don Becker's tulip page Include complete information in your report. Run tulip-diag and mii-diag. Cut and paste the initialization messages which are printed on your console or in /var/log/messages when the card loads. Take the board out of your computer and record the chip numbers on all of the major chips (tulip, bridge, and transceivers) and the board revision number. What model hub/switch are you connected to? What do the link, speed, transmit, receive, and collision lights on the card and the hub, where applicable, indicate? Does the card work immediately after you load or reload the driver and then stop? Have you tried both manual and auto negotiation? Are the interrupts shared with any other devices? Is your BIOS misconfigured to use that interrupt for ISA instead of PCI devices? Include the contents of /proc/pci, /proc/interrupts, and /proc/ioports. What version of the tulip driver are you using? One way to check, besides the messages printed when loading, is to use the following command (assuming you are running the tulip driver which came with your kernel) or look at the source code. "strings /lib/modules/`uname -r`/net/tulip.o | fgrep tulip.c" If you recompiled your kernel, did you remember to do a "make modules"? What BIOS are you using? If you are using an AMIBIOS, you probably need "reverse_probe=1" which is described elsewhere on this page. Many problems are related to autonegotiation or manual negotiation of 10 vs 100Mbs and half vs full duplex. Check /var/log/messages for any messages which might appear several minutes after the driver is loaded (like "transmitter stopped!" or "Link Beat Failure" (probably means you aren't connected to a hub). Beware of uplink ports on hubs, these can often be switched between straight through and crossed over and sometimes these switches are mislabled. If you are connecting two computers directly, you need a crossover cable. Some 10/100 hubs do not include a switch to convert between the two speeds so all connected devices must use the same speed. Did you remember to add routes for the device after bringing it up with ifconfig? Does the problem exist when only one port is enabled or only when more than one is enabled?

Other reported multiport tulip boards

The IntraServer ITI-5232E is apparently a quad ethernet board.

Speed Testing

There is a program called etherspray (I have no idea where to find it) which some people have used. If you try to test the performance with a single FTP session, you will be disatisfied. One TCP connection cannot fill a 10Mb/s line to capacity, let alone fast ethernet. Instead try transfering 5 large files (more for fast ethernet) simultaneously in different FTP sessions and measure the aggregate throughput.

Tulip variations

There are many variations on the tulip chips from many different manufacturers. In some cases, even chips with the same base number may come in various flavors with significant incompatibities; the 21143 chip was notorious for this. Fortunately, I think things have stabilized. And DEC seems to be under the illusion that there name is spelled and pronounced "DIGITAL".

Cheap single port cards

If you are looking for a cheap tulip based single port PCI card, check out the Linksys Etherfast 10/100 cards which are availible for $25 from NECX or $30 at Datacomm Warehouse or your local Office Depot or Staples stores. These are based on tulip clone chips. Linksys has a Linux support page for these cards. If you are using Redhat 5.2 or later, it will work with the existing driver (which means you can use it for install); if you have an older version you will need to upgrade the driver after install. Note that the newer cards are based on a Linksys chip instead of the PNIC (Tulip clone) or tulip chips; hopefully, this chip still works. I have reason to suspect the linksys chip is a relabled PNIC chip, since they and Netgear have been reported to relable PNIC chips. Linksys tech support is terrible, however. One request went unanswered and the other was answered by a complete moron named Ronald Almazan. There is now a note which says that if your board is a Rev 2 board (which has wake on LAN) that you need to use the linux driver supplied on the disk 2; this means you would have trouble with a network install.

Redhat network installation

If you are using a card which does not work with the drivers on the redhat installation disks, here is some advice which should help you configure networking afterwards. Obviously, you cannot do a FTP or NFS install if your network card isn't supported at installation time. You may want to test the cards operation first by editing /etc/conf.modules, insmod'ing the driver, ifconfig'ing each interface, and adding the necessary routes and then using ping or other utilities to test operation.

Alternative to multiport cards

If you need more than 4 ports, an interesting alternative is to use a switch which supports VLAN tagging. The HP procurve supports up to 64 ports. You will probably want to use a gigabit ethernet adapter ($350) in the linux box and a gigabit uplink in the switch. You will need the Linux VLAN patches. Configure the switch to put every port on a separate VLAN. That way, all traffic will be forced to go through the Linux box. The VLAN tags will tell the linux box what port the traffic came from. I haven't tried this yet so I don't know how the different ports look to the firewalling code. There is a problem with the firmware on some switches, however, that allows machines to hop VLANs; if the machine sends its ethernet packets already VLAN tagged, they will be passed on as is with the incorrect VLAN information. This is a feature in some configurations but a definite bug from a security perspective. Ideally, each port would be configurable to allow or reject vlan tags. That way, you could connect other trusted devices such as other switches and DSL racks which also do VLAN tagging to the switch and not need another port on the Linux firewall.

Footing

My personal linux pages are located here.

This file is maintained by Mark Whitis (whitis@freelabs.com).

Senior Engineer for hire
Software Development - Electronic Design - Embedded Systems - Device Drivers - System/Network Administration and Security - Motor Control, RobotCNC - Linux/Un*x - 25+ years experience
The author of these pages is looking for a new gig.
[RESUME]

Engineers and electronic hobbyists: The new Open Symbol Project is creating open schematic symbols and PCB footprints for a variety of different CAD packages.

Mark Whitis's Website Home Page Linux Book: Linux Programming Unleashed My Resume Genealogical Data Contact Info Security About

All email messages received must pass the turing test or they will be considered SPAM. If it could have been written by a machine, it was.

Under no circumstances are you to email me with questions regarding windoze, any other microsoft operating system or application, or any software which runs under any form of windoze.

*