I solved the problem with brute force (see my other e-mail today), but I wanted
to reply here to see if learn some more.
On Tue June 5 2007 14:11, G T Smith wrote:
> Carlos F Lange wrote:
> > On Tue June 5 2007 09:37, G T Smith wrote:
>
> <snip>
>
> >> A very faint possibility is that there
> >> may be an issue with connection negotiation (Duplex, 10/100 mbps
> >> etc).
> >
> > Would there be any log for this negotiation?
>
> What are the reported packet stats from ifstatus/netstat like? Lots
> of incoming error packets would be a strong indicator.
ifstatus:
eth0 device: nVidia Corporation MCP51 Ethernet Controller (rev a1)
eth0 configuration: eth-id-00:15:f2:bf:d8:2c
eth0 dhcpcd is still waiting for data
eth0 is up
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:15:f2:bf:d8:2c brd ff:ff:ff:ff:ff:ff
inet6 fe80::215:f2ff:febf:d82c/64 scope link
valid_lft forever preferred_lft forever
netstat is too big, but it did not have _anything_ under "Active Internet
connections".
> With a consumer router you are unlikely to get this kind of report of
> connection status. So even if the driver configuration switches were
> available to force the type of connection it would be guesswork to
> get the right configuration in place.
>
> The suggestion made elsewhere of an iffy cable is worth considering,
> but could be easily eliminated by connecting with a cable you know
> has been working before.
Not the case.
> >>>> b) Which NIC?
> >>>
> >>> nVidia Corporation MCP51 Ethernet Controller
>
> <snip>
>
> > No. Every machine is unique. This one just got a new NIC, which
> > worked fine in Suse for 2 days before I first booted into Windows.
> > When I booted back into Linux, then my problems started. That is
> > why I suspected the DHCP server had some hiccup, but resetting it
> > did not help.
>
> The suggestion of making certain that all traces of the previous card
> configuration are removed which has also been made is also sound. I
> do not entirely trust YaST in this area.
I tried deleting the content in:
/etc/resolv.conf
/etc/HOSTNAME
/etc/sysconfig/network/routes
> If the machine had not powered down for 2 days before booting into
> windows I would take a hard look at the udev persistant names rules
> and associated settings. These can generate the odd surprise.
OK. I deleted the 2 entries in
/etc/udev/rules.d/30-net_persistent_names.rules
But this cleaning did not solve the problem. Did I forget anything?
Thanks for all the help,
Carlos FL
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
