getting an old NIC to work

On Fri, 4 Nov 2005, Steve Bertrand wrote:

>> the relevant dmesg output is:
>> pcn0: <AMD PCNet/PCI 10/100BaseTX> port
0xbcc0-0xbcdf mem
>> 0xfedfcc00-0xfedfcc1f irq 11 at device 19.0 on pci0
>> pcn0: Ethernet address: 00:66:b0:4a:bc:1c
>> miibus0: <MII bus> on pcn0
>> lxtphy0: <LXT970 10/100 media interface> on
miibus0
>> lxtphy0:100baseFX, 100baseFX-FDX, 10baseT,
10baseT-FDX,
>> 100baseTX, 100baseTX-FDX, auto
>>
>> ifconfig:
>> pcn0:
flags=8843<UP,BRODADCAST,RUNNING,SIMPLEX,MULTICAST>
mtu 1500
>>  	inet 192.168.1.10 netmask 0xffffff00 broadcast
192.168.1.255
>>  	inet6 fe80::260:b0ff:fea4:bc1c%pcn0 prefixlen 64
scopeid 0x1
>>  	ether 00:66:b0:4a:bc:1c
>>  	media: Ethernet autoselect (10baseT/UTP)
>>  	status: active
>>
>> the machine can ping itself at 192.168.1.10.  It
can't ping
>> the defaultrouter (192.168.1.1) set in rc.conf, or
anything
>> else on the local network.
>
> Everything looks fine up to this point, so the problem
you describe (not
> being able to ping anything aside from itself). So,
first reply back
> with the defaultrouter line in rc.conf so we can ensure
it's accurate.

defaultrouter="192.168.1.1"

>
> Second (relevant to the question below, paste us the
output from:
>
> # netstat -rn
Internet:
Destination	Gateway		Flags	Refs	Use	Netif	Expire
default		192.168.1.1	UGSc	0	0	pcn0
127.0.0.1	127.0.0.1	UH	1	6	lo0
192.168.1	link#1		UC	2	0	pcn0
192.168.1.1	link#1		UHLW	1	3	pcn0
192.168.1.10	00:66:b0:4a:bc:1c UHLW	3	8	lo0

(typed by hand, but doublechecked for errors.)

> One more thing...is this a clean install? Have you
built yourself a new
> kernel adding any extra options? (ie IPFW)..and are you
absolutely sure
> that the upstream gateway is indeed 192.168.1.1 (ie:
can you ping it
> from a different workstation?

Nope, generic kernel, not rebuilt at all.  Yes, 192.168.1.1
does work from 
other machines on the local network.  For example, here's
the netstat from 
the machine I'm writing on this minute:

working_machine>$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use
 Netif Expire
default            192.168.1.1        UGSc        2        0
   ed0
127.0.0.1          127.0.0.1          UH          1    22924
   lo0
192.168.1          link#1             UC          4        0
   ed0
192.168.1.1        00:09:5b:50:37:76  UHLW        3     9263
   ed0   1199
192.168.1.2        00:40:05:55:aa:68  UHLW        5      102
   lo0
192.168.1.3        00:0c:41:0c:95:d0  UHLW        0    12790
   ed0   1134
192.168.1.4        00:c0:26:c0:ec:89  UHLW        1    21435
   ed0    847

this one's working fine.


--
David Fleck
david.fleckmchsi.com

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

> Nope, generic kernel, not rebuilt at all.  Yes,
192.168.1.1 
> does work from other machines on the local network. 
For 
> example, here's the netstat from the machine I'm
writing on 
> this minute:
> 
> working_machine>$ netstat -rn
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs    
 Use  
> Netif Expire
> default            192.168.1.1        UGSc        2    
   0    ed0
> 127.0.0.1          127.0.0.1          UH          1   
22924    lo0
> 192.168.1          link#1             UC          4    
   0    ed0
> 192.168.1.1        00:09:5b:50:37:76  UHLW        3    
9263  
>   ed0   1199
> 192.168.1.2        00:40:05:55:aa:68  UHLW        5    
 102    lo0
> 192.168.1.3        00:0c:41:0c:95:d0  UHLW        0   
12790  
>   ed0   1134
> 192.168.1.4        00:c0:26:c0:ec:89  UHLW        1   
21435  
>   ed0    847
> 
> this one's working fine.

It appears as though everything is in order. The routes are
in place,
IP/SN is all correct etc.

You are going to have to take a step down now to the lower
layers of the
network stack.

Perform this command while plugged into the network and let
it run a
while:

# tcpdump -n -i pcn0

What this will do is see if the nic can see traffic coming
from other
machines. Throw some pings at it from another box, and even
if the other
box doesn't get a reply, tcpdump will tell you if the nic
can at least
see the incoming traffic. Also, run tcpdump on another box,
and repeat
the process, but ping from the box with the 'bad' nic in it.
Perhaps it
can send traffic, but just not receive. Doing this both ways
will
indicate either way and may give you a clue.

Further that, even farther down, try a different cable and
switch port
(one at a time). I know that may seem silly, but weirder
things have
happened.

If all of that fails, due to the fact there is a driver
loaded for the
device, and it is taking all of it's parameters ok, I would
say slap a
new nic in the box and see if you can rx/tx traffic via it.
If you can,
I'd say then there is a problem with the nic itself, and you
have
confirmed it logically and completely.

Regards,

Steve

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"