We have a laptop with a Xircom network card, running RH 6. It works fine on its home LAN. When switching it to a new location, Windows 98 is fine (the hardware is OK), but Linux won't talk on the new network. Having changed /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/pcmcia/network.opts /etc/hosts ifconfig and route report the correct values. Attempting to ping on the network causes no activity on eth0; however, the RX/TX count on the loopback device increases sporadically (ie it only increases when attempting to ping, but not unless the ping has been trying for a moderate number of packets). Also worth noting was that when I ran ifconfig eth0 up a route for the LAN would be automatically added; however, if I tried to delete this route, I'd get a "SIOCDELRT: no such process" error (the same as trying to delete a route that did not exist). This behaviour could just be a Redhat-ism (I normally use Debian, and it certainly doesn't add undeleteable routes...) I just put the machine back on the original network and Redhat is working fine again....
The report above mentions modifying the /etc/pcmcia/network.opts file. It seems that the RedHat version of the PCMCIA tools do not include the "network" script from the standard PCMCIA package. This certainly causes all network.opts configurations to fail (they are ignored). If the reason for this is to coexist with the control-panel application, then couldn't that goal be achieved far less intrusively via a default scheme in network.opts using the start_fn() and stop_fn() settings?
Assigned to dledford
When configuring PCMCIA networking through netcfg the config options end up in /etc/sysconfig/networking-scripts, not in /etc/pcmcia/network.opts. Is that intentional? Peter
(updating an ancient bug) Can you try to reproduce on a current Red Hat or kernel.org kernel?
I am unable to duplicate this bug on an Inspiron 8000 with Xircon card running Red Hat Linux 7.3/8.0 I am feeling that this bug has been fixed by time.