Date: Wed, 27 Oct 1999 10:22:13 -0400 From: "Chanderpaul, Pradesh" <Pradesh_Chanderpaul@stratus.com> To: "Chanderpaul, Pradesh" <Pradesh_Chanderpaul@stratus.com>, "'questions@freebsd.org'" <questions@freebsd.org>, "'sderdau@ne.mediaone.net'" <sderdau@ne.mediaone.net> Subject: SOLVED : RE: IS: Network lost after replacing NIC - suspect routi ng Message-ID: <1D1A4EF7AD4DD211A80D00A0C9D7DB667E685E@exna1.stratus.com>
next in thread | raw e-mail | index | archive | help
Hello I solved the problem listed earlier by me. The problem was related to an incorrect IO setting. I booted DOS and ran two tools downloaded from 3COM, which gave conflicting results (none of which worked) Autolink.exe gave : IRQ 10 - I/O 0x300 <== SAME AS MINE 3c5x9cfg.exe : IRQ 10 - I/O 0x220 (with PnP setting) So I booted with boot -c and set the values to both. The boot process reported no device at 0x220. Fine. Using the 3c5x9cfg.exe tool, I disabled PnP and used the auto-config option. This set the values to :- IRQ : 10 - I/0 0x210 Success. A posting from a NetBSD archive provided a clue :- http://www.monkey.org/openbsd/archive/tech/9807/msg00009.html <http://www.monkey.org/openbsd/archive/tech/9807/msg00009.html> Allow me to paste an extract which I think will be useful. (Not sure how accurate, but it got me thinking.) <snip> <snip> One idea: Could it be that the IRQ is configured wrongly on A, but correctly on B? Scenario: from A: ping B - A sends out ARP, B responds (activity on both ports at the hub), but A misses the responses because of the wrong IRQ - After some seconds, ARP times out and A gives "Host is down" errors during the negative ARP caching timeout. from B: ping A - from above, B still knows A's MAC address (that was an ARP packet, and that gets entered into the ARP cache also for ARP requests) - So B sends out ICMPs right ahead (-> activity from B to A at the hub) - A misses the packets, again, so doesn't send anything back. If you wait a bit longer between the A->B test and the B->A test, B will lose the ARP cache entry, try to resolve A's MAC address (a few packets from B->A at the hub, no responses) and after the timeout also generate "Host is down" (and not send out packets any more till the negative ARP cache entry expires). <snip> <snip> Regards =============================================================== Pradesh Chanderpaul Phone: +27 12 663 3260/6 Stratus Computer Systems FAX : +27 12 663 3281 South Africa CAC Email: Pradesh_Chanderpaul@stratus.com <mailto:Pradesh_Chanderpaul@stratus.com> =============================================================== -----Original Message----- From: Chanderpaul, Pradesh Sent: Wednesday, October 27, 1999 1:19 PM To: 'questions@freebsd.org' Subject: IS: Network lost after replacing NIC - suspect routing Hello all I seemed to have lost network connectivity after replacing my NIC. My situation is this :- - I installed FreeBSD 3-2.RELEASE with a working SMC Ultra ethernet NIC. No problems here - I replaced the NIC device with a 3COM 3C509 NIC. Same network addresses as old NIC. - The card is recognised at boot ep0 at 0x300-0x30f irq 10 on isa ep0: utp[*UTP*] address 00:60:08:7c:64:bd - The card has a link light. - I obtain similar results with and without link2 passed to ifconfig. - The card is configured for TCP/IP (I've changed the actual addresses) $ ifconfig ep0 ep0: flags=c843<UP,BROADCAST,RUNNING,SIMPLEX,LINK2,MULTICAST> mtu 1500 inet 111.222.333.44 netmask 0xffffff00 broadcast 111.222.333.255 ether 00:60:08:7c:64:bd - I can ping the IP address defined on the card ok, so I deduce the TCP stack is loaded. $ ping 111.222.333.44 --- 111.222.333.44 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss - However, I cannot reach the defined gateway. $ ping 111.222.333.1 ping: sendto: Host is down ping: sendto: Host is down . . <blah> <blah> <blah> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1D1A4EF7AD4DD211A80D00A0C9D7DB667E685E>