<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
Thank you to both Michael and Jim for useful replies. Now it starts to get weird. <BR>
<BR>
Here is the configuration that has worked for years, but started acting up: <BR>
<BLOCKQUOTE>
AT&T Uverse router -> LAN port<BR>
Sonicwall TZ190 Firewall Router <BR>
LinkSys 10/100 Workgroup Switch<BR>
Centos 6 HP Pavillion - couldn't see Sonicwall<BR>
Windows 7/10 Dell Optiplex - intermittently could/could not see Sonicwall<BR>
Dell Laser Printer - neither system could print. <BR>
Other stuff<BR>
</BLOCKQUOTE>
<BR>
I lost any connectivity to/from the Centos box on Saturday and rebooted several times and got it back each time temporarily. <BR>
<BR>
Attempting to isolate, I have re-jiggered the wiring temporarily: <BR>
<BLOCKQUOTE>
AT&T Uverse router -> LAN port<BR>
Sonicwall TZ190 Firewall Router <BR>
Centos 6 HP Pavillion - can see Sonicwall<BR>
Windows 7/10 Dell Optiplex - can see Sonicwall and Centos<BR>
Win 10 Acer notebook - can see Sonicwall and Centos<BR>
Dell Laser Printer - All workstations can print to it.<BR>
LinkSys 10/100 Workgroup Switch <BR>
Other stuff<BR>
<BR>
</BLOCKQUOTE>
And the Centos box has been connected with no interruptions since. Everything seems to work. <BR>
<BR>
My suspicion has shifted to the LinkSys 10/100 Workgroup Switch. Got to think about how one tests non-managed switch. <BR>
<BR>
<BR>
On Mon, 2015-09-14 at 00:00 -0400, Jim Kinney wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
I agree. Script up a tool that checks for connection to the gateway. If it fails, stop network, unload module, load module, start network and retest conn to gateway. If that works, it proves absolutely nothing except the connection will restart.<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On Sep 13, 2015 5:25 PM, "Michael Trausch" <<A HREF="mailto:mike@trausch.us">mike@trausch.us</A>> wrote:<BR>
<BLOCKQUOTE>
Check your available modules and use a chip which can be driven. Realtek chips are relatively safe as they use the same ones for a long long time.<BR>
<BR>
A diagnostic for you: does removal and reinsertion of module work? That'd be able to eliminate many aspects (but not all) of software causes. I don't believe it's possible to do a power cycle from software on the PCI-e bus, or if suggest that as an interim solution. If you bounce the chip as soon as malfunction is detected most tcp sessions will survive it.<BR>
<BR>
Sent from my iPhone<BR>
<BR>
> On Sep 13, 2015, at 5:02 PM, Neal Rhodes <<A HREF="mailto:neal@mnopltd.com">neal@mnopltd.com</A>> wrote:<BR>
><BR>
> Any recommendations for an inexpensive no-drama PCI x1 card that works out of the box with Centos 6?<BR>
<BR>
_______________________________________________<BR>
Ale mailing list<BR>
<A HREF="mailto:Ale@ale.org">Ale@ale.org</A><BR>
<A HREF="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</A><BR>
See JOBS, ANNOUNCE and SCHOOLS lists at<BR>
<A HREF="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</A>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
_______________________________________________
Ale mailing list
<A HREF="mailto:Ale@ale.org">Ale@ale.org</A>
<A HREF="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</A>
See JOBS, ANNOUNCE and SCHOOLS lists at
<A HREF="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>