The first strange thing that happened was that the NICs swapped device IDs. What was eth0 became eth1 and vice versa. I always thought that which NIC became eth0 was BIOS dependent not kernel dependent. The swap did not present a big problem, it is just a curiosity. Has anyone else seen this happen when going from Dachstein 1.02 to Bering 1.2?
The NIC numbering is *DRIVER* dependent, although the driver may use methods that are dependent on the motherboard or NIC chipset, BIOS, PC layout (ie ordering of the PCI connectors), MAC addressing of the NICs, or whatever else the device driver writer found handy.
Since Bering runs with an updated kernel, I suspect you are encountering an issue with a new (or updated) driver for the NICs you're using.
The second strange thing is a problem. Please understand that this system ran months under Dachstein with no failures, and switching back to Dachstein makes the problem go away. It seems that every time any kind of load is placed on the system (say a 10 meg download), the inside NIC, eth1 a (3Com 3c509), stops responding. If the load stays low, the system runs normally. Do an FTP or pull something of any size down from the Web and eth1 goes away. I have looked in very log file and I can find no error messages.
When the problem happens I can not access the LEAF eth1 interface from any of the PCs, nor can I ping any of the local PCs from the LEAF console. While eth1 is down eth0 is up and running. From the LEAF console I can ping the Internet and hosts over the VPNs, I continue to be able to collect SNMP data from the LEAF across the VPN. In short everything seems to be working just as it should except eth1 is dead..
In trying to fix the problem I have tried the usual things. I have tried shutting down and restarting eth1 with ifconfig, done a network restart, restarted Shorewall, everything I could think of that might be the problem. Nothing brings back eth1. The only thing that seems to work is a reboot. I am at the point of grasping at straws on this one. If anyone on the list has seen this before, or can tell me where to start looking, or what tests to perform to provide the list with more useful information, please let me know.
I've not seen this particular problem before, but I'd bet it's a problem with the updated driver. I don't remember offhand if the 3c509's are the ISA or PCI cards, but if they're the ISA cards, it wouldn't be real suprising if a bug hasn't creapt into the current driver. There isn't a lot of regression testing that goes on for the older cards that are supported by the same driver as a current chipset (I ran into a problem with this and the AIC7xxx driver using an old EISA Adaptec card...the new driver worked great with recent PCI hardware, but it failed to work with my EISA controller, although previous drivers had worked perfectly, so I knew the hardware was solid).
I suggest you track down which version of the 3Com driver you're running in Dachstein and Bering. I think there are several drivers for the 3Coms floating around, so if you have an alternate choice of driver for Bering, that's the first thing I'd try...otherwise, I suggest you do a bit of googling for others having the same problem with the 3Com driver, and you may have to build your own version of the driver from the latest source, an earlier release, or possibly a patched version.
-- Charles Steinkuehler [EMAIL PROTECTED]
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
