New Intel NIC, no connection, what next?

[freshfeesh]

The onboard LAN on my mobo went belly up long ago while it was still a workstation. Since then I've been using a DLink PCI NIC with a Marvell controller. I got FreeNAS up and running on that. It was working but slow. Based on strong forum preference for Intel NICs for performance and stability, I got one to replace the DLink, specifically the expi9301ct PCIe version. I initially just installed the Intel alongside the DLink, thinking that someday I might play with link aggregation, and rebooted with the cable plugged into the Intel. I was dead in the water, and have been since. I can't even get it to work in the old state, with only the Dlink installed.

With a monitor and keyboard hooked to the NAS box, I've reset and deleted the network interfaces in various combinations multiple times. I power cycled the router. I reinstalled FreeNAS to the compact flash card from the image, still the same thing upon first boot. Right now the Intel is in and hooked up to the cable and the DLink is uninstalled. I have the Intel hooked straight into my (old) Netgear router. The link lights come on on both the router (on each of two different ports that I tried) and the card, but the Intel card (i.e. its MAC address) doesn't show up in the "attached devices" in the router admin page. Setting a static IP on Freenas doesn't work. Two other machines on the network see each other and the internet just fine.

What can I try next? Is there any way a bios setting could subtly affect the functioning, but not the on/off state, of add in network cards?

Thanks.

 

[freshfeesh]

An update: After variously blaming the cards, cables, switch ports, and router, I've been able to verify that each component works at some point or another. Both cards tested good on an XP box (I was able to browse the internet on each after letting Windows download the right driver). Both cards are now installed and hooked up to good ports on the switch with good cables. The Dlink card is operational, and I'm able to access my shares and the web GUI on it. The Intel card still isn't working. Although it's link lights are on, I can't connect to it when it's setup with either a static IP or via DHCP. Freenas reports its address as 0.0.0.0. A little while ago I shut the machine down and pulled the DLink card out, rebooted with just the Intel card in, and still get the same behavior

I really want to get the Intel card working because of its reported better performance on these forums. A couple questions: the chipset is a 82574L (low power). The Freebsd ethernet driver page reports support for the "82574", but not the "L". Is that a meaningful distinction? What's the relationship between the network configuration through the GUI and through the console setup on a keyboard and monitor hooked directly up to the Freenas box? They seem to differ in slight ways, and I'm wondering if I've created some mismatch or conflict through all my fiddling.

 

[jgreco]

The console and GUI network setup systems are quite different. If you think you're getting lost, suggested "fix" is to go to the console, spawn a shell, and configure the system network settings manually.

"ifconfig em0 inet w.x.y.z netmask 255.255.255.0" (or whatever) should be sufficient to configure a standard Intel interface; you should be able to ping other devices on your local network.

"route add default ga.te.wa.y" to install a default route, at which point things on the Internet ought to be pingable.

Neither of those changes will be persistent, but good enough to help localize your problem.

Where'd you pick up the Intel card? The market is occasionally flooded with cheap knock-offs that work poorly (or not-at-all), sometimes so blatantly as to be some other "Realtek"-class chipset. You might want to double-check that the driver you found to work with the card is an Intel driver.

That said, the Intel support in FreeBSD often lags the most recently available chipset by about a release. You might want to pick up a FreeBSD 8.3 or 9.0 live-CD and see if that works.

 

[paleoN]

I have a 9301 CT NIC, chipset 82574L, and it works quite well. Mine does use em0 so I assume it's a real one.

 

[jgreco]

I have a 9301 CT NIC, chipset 82574L, and it works quite well. Mine does use em0 so I assume it's a real one.

Working doesn't prove it's a "real one", sadly. Nor does buying from an authorized retailer. We usually buy cards through the Intel evaluation program, but that takes time. Back around 2006 we purchased some PWLA8492MT dual port cards from NewEgg for an on-site emergency in Virginia, one arrived DOA, one seemed to work but would go into fits of rage every few days. Back in the shop, we eventually got around to looking at it, and discovered that the cards were pretty good fakes, right down to the packaging, but were identifiable because the word "dual" on the serial number label on the side of the box was spelled "daul"...

The box and packaging would not otherwise have been suspicious, the box itself appears identical to other Intel cards, and the board was very similar too, except the soldering was of slightly lower quality. We ran into some other service providers who had also been hit with fakes, similar symptoms. Possibly even Intel manufacturing rejects or something like that.

Fakes happen. Just be cautious. ;-)

 

[freshfeesh]

And now back to this problem.

"ifconfig em0 inet w.x.y.z netmask 255.255.255.0" (or whatever) should be sufficient to configure a standard Intel interface; you should be able to ping other devices on your local network.

"route add default ga.te.wa.y" to install a default route, at which point things on the Internet ought to be pingable.

Neither of those changes will be persistent, but good enough to help localize your problem.

Where'd you pick up the Intel card? The market is occasionally flooded with cheap knock-offs that work poorly (or not-at-all), sometimes so blatantly as to be some other "Realtek"-class chipset. You might want to double-check that the driver you found to work with the card is an Intel driver.

So far no good. I got this card from Newegg, and it's using the 'em' driver. It also has a counterfeit prevention mechanism from a company that I'd never heard of, "Yottamark". It's a holographic sticker with a QR code and a long number. Going to Yottamark's website and entering the number, or scanning the QR code, results in a page declaring that my device is valid, and it gives me the correct MAC ID for the card. This is sort of nice, but I've never heard of Yottamark, and I can't see how this would protect against 1M counterfeit cards all with the same holographic sticker and MAC ID.

I started with just setting parameters via ifconfig. The settings stick, as seen by typing 'ifconfig' by itself, but the box is still unreachable, and pings result in an endless loop of "host not responding" or something like that. Just 'ifconfig' by itself does show an 'lo0' (loopback) connection. Do I need to do anything to that? A few additional questions:

How do I cancel the ping attempts if the box is getting no responses? As I mentioned above, the lack of connection resulted in an endless loop. I couldn't enter any more commands. I managed to escape into debug mode, but that didn't do me any good and I had to reboot the machine.

Right now I have only the intel card installed, with the Dlink card removed. Given that the intel isn't working, I can't use the server. I also can't SSH in to copy command line results. Would I complicate my life by having both cards installed, running the server off the Dlink, while troubleshooting the intel?

Even though paleoN's unit evidently works with the built-in driver, would there be any benefit to trying to load latest intel freebsd driver?

 

[jgreco]

It also has a counterfeit prevention mechanism from a company that I'd never heard of, "Yottamark". It's a holographic sticker with a QR code and a long number. Going to Yottamark's website and entering the number, or scanning the QR code, results in a page declaring that my device is valid, and it gives me the correct MAC ID for the card. This is sort of nice, but I've never heard of Yottamark, and I can't see how this would protect against 1M counterfeit cards all with the same holographic sticker and MAC ID.

Because two cards with the same MAC ID cannot function on the same network. There are ways to "play" that sort of system, but basically a second line of defense will exist that flags an unusual number of queries for a single QR/serial.

It's also possible you have a bad card. That'd suck, you can spin wheels quite a bit trying to isolate issues...

You can cancel ping attempts (and most other programs) run from a UNIX command line with control-C. UNIX is very terminal-oriented and there are lots of other things too.

You can have both network cards installed, but in your situation I kind of advise against it, because bringing up two network interfaces on the same network only brings confusion to the table. If you have a spare PC/workstation available, though, you can definitely set up the Intel as a separate network, hook up the PC/workstation via a direct ethernet cable, giving you a network with only two devices on it, and we can walk through a few simple and easy tests to see if we can isolate what's happening. Sometimes it pays to start out simple. If you want to do that, here's a quick bit of guidance:

Assuming your "normal" net is an RFC1918 net like 192.168.1.0/24 (meaning IP's from 192.168.1.1-192.168.1.254, with a netmask 0xffffff00/255.255.255.0) then you assign the Intel a different RFC1918 net that doesn't overlap. To prevent mistakes you can use a different 1918 range, like 10/8, so configure your FreeNAS as 10.0.0.1 with 255.255.255.0 netmask, and configure the PC as 10.0.0.2, and hook them together. If you can ping from the PC to the FreeNAS, that's great. If not, we debug. You may not be able to ping from the NAS to the PC due to firewalls on many common PC OS's, but you should be able to verify connectivity in other ways.

So that's my suggestion to start out. I'm willing to help you out until we reach a resolution or something that leaves me with no more ideas, but realistically that still means mostly work for you. ;-)

 

[freshfeesh]

Wicked;). Much appreciated, sir. Having a good guide makes the difference between a thankless slog and a fun challenge. You gave me much to google just then, but I think I grasp enough to jump into the work...

My main XP workstation has two interfaces, one from the chipset and one additional Marvell. Until now, I've only ever had one plugged in. I don't have an extra machine that I can use just for this testing. I now have the freenas box configured thus:

Code:

~# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
        ether 68:05:ca:0a:34:82
        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
sk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
        ether 00:21:91:21:1e:07
        inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
[root@freenas] ~#

and the Marvell is configured like this:


I hooked the Freenas Intel to the XP Marvell with a standard (not a crossover) Cat5e ethernet cable, and both link and activity lights are lit up on both nics. I don't have a DNS or gateway configured on the Marvell. I turned off Windows firewall for the Marvell connection. The status in Windows for the Marvell says "connected", whereas the status for the chipset connection says "connected, firewalled", so it looks like the firewall is indeed off for the Marvell.

Pinging 10.0.0.1 from windows returns nothing. Do I need to do anything special to make sure the ping is issued from the Marvell interface, instead of the chipset interface that is hooked up to the internet? What can I do next?

 

[jgreco]

Sorry for the delay, it's been busy here.

The Intel/Marvell connection having link is good. You don't need DNS or a gateway for the connection; you've done precisely just what's needed.

So here's what you do. Go ahead on the XP box and run "ping -t 10.0.0.1", which should send a steady stream of ping requests to the NAS box via the Marvell. Go onto the FreeNAS console, go to the shell. Run "tcpdump -n -i em0" and see if you see something like this:

# tcpdump -n -i em0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
07:15:26.994095 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 512, seq 3072, length 40
07:15:26.994106 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 512, seq 3072, length 40
07:15:27.994716 IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 512, seq 3328, length 40
07:15:27.994731 IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 512, seq 3328, length 40
etc

That's a healthy ping request/response. I don't think you'll be getting that, but that's what is SUPPOSED to happen.

# tcpdump -n -i em0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
07:17:53.243527 ARP, Request who-has 10.0.0.1 tell 10.0.0.2, length 46
07:17:58.725360 ARP, Request who-has 10.0.0.1 tell 10.0.0.2, length 46
07:18:04.225632 ARP, Request who-has 10.0.0.1 tell 10.0.0.2, length 46

That's 10.0.0.2 ARP'ing around for 10.0.0.1. If you get JUST that, you should double-check your configs because it means the FreeNAS box is seeing the requests but not responding. If you see that WITH responses from FreeNAS, then your em0 transmitter's probably busted (we've eliminated the XP receiver as a possibility due to your previous tests). I should point out that the FreeBSD driver is typically pretty good about blatting out noisy console messages if the hardware appears to be having a stroke; make sure "dmesg" and your console show no warning or error messages related to the em device.

My guess? You'll see nothing at all from tcpdump, in which case we can be pretty sure that the em receiver has failed. That *probably* means a bad card, but it is still *possible* for it to be related to settings in the BIOS for your motherboard. That's when it's handy to see if you can stick the card in a different box and see what happens.

 

[Caustic]

I bought the same card today. Manufactured in May 2012 with the same yottamark sticker on it. Got home put it in my freenas box and have the same problems. Freenas finds it, lights working but nothing. Did a google search and found this thread. Will test it on another machine tomorrow. No time to trouble shoot any more tonight.

 

[jgreco]

Keep us posted. Could be a batch of bad cards, or could just be a FreeBSD-driver-is-too-old issue. Hard to say without further testing.

 

[freshfeesh]

I finally ran the check. I get nothing showing from 'tcpdump' in Freenas with the pings coming in from the XP box. XP stops after 4 pings, here's the nothing that I get from those 4 on Freenas:

Code:

~# tcpdump -n -i em0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

No alerts in the web interface. Here are all the dmesg lines for em0:

Code:

em0: Using MSIX interrupts with 3 vectors
em0: [ITHREAD]
em0: [ITHREAD]
em0: [ITHREAD]
em0: Ethernet address: 68:05:ca:0a:34:82

and at the very end:

Code:

em0: promiscuous mode enabled
em0: promiscuous mode disabled

I'm not sure if this is meaningful, but pinging the XP box from Freenas gives a message in Freenas about "no buffer space available":

Code:

~# ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available

Also in the category of "not sure if it's meaningful", here's the part on em0 from the daily email a couple days ago:

Code:

Network interface status:
Name    Mtu Network       Address              Ipkts Ierrs Idrop    Opkts O=
errs  Coll
em0    1500 <Link#1>      68:05:ca:0a:34:82      501 14982     0     2663  =
   0     0
em0    1500 10.0.0.0      10.0.0.1               501     -     -      501  =
   -     -

I did try another PCIe slot in the Freenas box before trying all this business, and still no connectivity. As I mentioned in my second post, though, the intel card did connect to the internet when I put it in my XP box, after XP downloaded the driver for it, so I don't think this is a hardware issue with the card, at least not as low level as the transmitter or receiver being totally defunct. I suppose that doesn't rule out something wierd with power modes or some automatic behavior or another that XP overrides or bypasses. I'd suspect the driver or BIOS before that though.

I'm happy to do more troubleshooting on the interface, or try loading a newer driver. I did a search on the latter, and I'm going to need instructions more detailed than I was able to find. After that I could put the Intel card in the XP box, disconnect the drives, and boot it up on Freenas with a USB drive and see if the card works on there.

 

[jgreco]

The collection of Ierrs suggests to me that the card's seeing something that isn't being handled correctly, which could easily be a driver issue. The "no buffer space available" could be thrown if the system was having troubles sending, though that's a device-driver dependent thing.

Suggest trying to see if FreeBSD (not FreeNAS) 9.1 works, it's not released yet, but it is most likely to have the newest driver.

ftp://ftp.freebsd.org/pub/FreeBSD/r...SO-IMAGES/9.1/FreeBSD-9.1-RC1-amd64-disc1.iso

or whatever. See if it can talk on the 'net. Simply booting the install and configuring the IP is probably enough to get it to be pingable, though I haven't actually checked FreeBSD 9 to see if that's true. If that works, then it's a driver issue.

 

[paleoN]

• pciconf -clv (just the em part)
• netstat -rn
• sysctl -a | grep em.0

 

[freshfeesh]

I'll mess around with this tomorrow. FYI, Ipkts and Ierrs are 501 (no change) and 21361 (obviously up) this morning.

 

[freshfeesh]

paleoN, here's the output of the commands you listed:

• pciconf -clv (just the em part)

Code:

em0@pci0:2:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Intel 82574L Gigabit Ethernet Controller (82574L)'
    class      = network
    subclass   = ethernet
    cap 01[c8] = powerspec 2  supports D0 D3  current D0
    cap 05[d0] = MSI supports 1 message, 64 bit
    cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
    cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 6805caffff0a3482

• netstat -rn

Code:

~# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.1        UGS         0     9356    sk0
10.0.0.0/24        link#1             U           0     3121    em0
10.0.0.1           link#1             UHS         0        0    lo0
127.0.0.1          link#3             UH          0    14975    lo0
192.168.1.0/24     link#2             U           0 138695636    sk0
192.168.1.20       link#2             UHS         0       27    lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::1                               ::1                           UH          lo0
fe80::%lo0/64                     link#3                        U           lo0
fe80::1%lo0                       link#3                        UHS         lo0
ff01:3::/32                       fe80::1%lo0                   U           lo0
ff02::%lo0/32                     fe80::1%lo0                   U           lo0

• sysctl -a | grep em.0 (I ran "grep em.0" right after running "sysctl -a" and it seemed to freeze, so I did a control C. What's below is taken from the log file of the SSH session)

Code:

dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9
dev.em.0.%driver: em
dev.em.0.%location: slot=0 function=0
dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f class=0x020000
dev.em.0.%parent: pci2
dev.em.0.nvm: -1
dev.em.0.debug: -1
dev.em.0.rx_int_delay: 0
dev.em.0.tx_int_delay: 66
dev.em.0.rx_abs_int_delay: 66
dev.em.0.tx_abs_int_delay: 66
dev.em.0.rx_processing_limit: 100
dev.em.0.flow_control: 3
dev.em.0.link_irq: 0
dev.em.0.mbuf_alloc_fail: 0
dev.em.0.cluster_alloc_fail: 0
dev.em.0.dropped: 0
dev.em.0.tx_dma_fail: 0
dev.em.0.rx_overruns: 0
dev.em.0.watchdog_timeouts: 0
dev.em.0.device_control: 1477444168
dev.em.0.rx_control: 67141634
dev.em.0.fc_high_water: 18432
dev.em.0.fc_low_water: 16932
dev.em.0.queue0.txd_head: 815
dev.em.0.queue0.txd_tail: 815
dev.em.0.queue0.tx_irq: 0
dev.em.0.queue0.no_desc_avail: 0
dev.em.0.queue0.rxd_head: 1023
dev.em.0.queue0.rxd_tail: 1023
dev.em.0.queue0.rx_irq: 0
dev.em.0.mac_stats.excess_coll: 0
dev.em.0.mac_stats.single_coll: 0
dev.em.0.mac_stats.multiple_coll: 0
dev.em.0.mac_stats.late_coll: 0
dev.em.0.mac_stats.collision_count: 0
dev.em.0.mac_stats.symbol_errors: 0
dev.em.0.mac_stats.sequence_errors: 0
dev.em.0.mac_stats.defer_count: 0
dev.em.0.mac_stats.missed_packets: 29131
dev.em.0.mac_stats.recv_no_buff: 83
dev.em.0.mac_stats.recv_undersize: 0
dev.em.0.mac_stats.recv_fragmented: 0
dev.em.0.mac_stats.recv_oversize: 0
dev.em.0.mac_stats.recv_jabber: 0
dev.em.0.mac_stats.recv_errs: 0
dev.em.0.mac_stats.crc_errs: 0
dev.em.0.mac_stats.alignment_errs: 0
dev.em.0.mac_stats.coll_ext_errs: 0
dev.em.0.mac_stats.xon_recvd: 0
dev.em.0.mac_stats.xon_txd: 0
dev.em.0.mac_stats.xoff_recvd: 0
dev.em.0.mac_stats.xoff_txd: 29132
dev.em.0.mac_stats.total_pkts_recvd: 30237
dev.em.0.mac_stats.good_pkts_recvd: 1106
dev.em.0.mac_stats.bcast_pkts_recvd: 841
dev.em.0.mac_stats.mcast_pkts_recvd: 4
dev.em.0.mac_stats.rx_frames_64: 495
dev.em.0.mac_stats.rx_frames_65_127: 239
dev.em.0.mac_stats.rx_frames_128_255: 51
dev.em.0.mac_stats.rx_frames_256_511: 49
dev.em.0.mac_stats.rx_frames_512_1023: 272
dev.em.0.mac_stats.rx_frames_1024_1522: 0
dev.em.0.mac_stats.good_octets_recvd: 232401
dev.em.0.mac_stats.good_octets_txd: 1185670
dev.em.0.mac_stats.total_pkts_txd: 32664
dev.em.0.mac_stats.good_pkts_txd: 3532
dev.em.0.mac_stats.bcast_pkts_txd: 13648
dev.em.0.mac_stats.mcast_pkts_txd: 0
dev.em.0.mac_stats.tx_frames_64: 1
dev.em.0.mac_stats.tx_frames_65_127: 32
dev.em.0.mac_stats.tx_frames_128_255: 162
dev.em.0.mac_stats.tx_frames_256_511: 3337
dev.em.0.mac_stats.tx_frames_512_1023: 0
dev.em.0.mac_stats.tx_frames_1024_1522: 0
dev.em.0.mac_stats.tso_txd: 0
dev.em.0.mac_stats.tso_ctx_fail: 0
dev.em.0.interrupts.asserts: 4
dev.em.0.interrupts.rx_pkt_timer: 0
dev.em.0.interrupts.rx_abs_timer: 0
dev.em.0.interrupts.tx_pkt_timer: 0
dev.em.0.interrupts.tx_abs_timer: 0
dev.em.0.interrupts.tx_queue_empty: 0
dev.em.0.interrupts.tx_queue_min_thresh: 0
dev.em.0.interrupts.rx_desc_min_thresh: 0
dev.em.0.interrupts.rx_overrun: 0

Working on putting FreeBSD 9.1 on a bootable flash drive now...

 

[freshfeesh]

I have the machine up on FreeBSD 9.1. Nothing is working right EXCEPT when I ping the XP machine from the Free machine, now I get normal responses. 100% success. Pinging FreeBSD from the XP machine results in all failures.

• When I plug a cable from my Intel card into the switch on my local network, and assign 192.168.1.21 to the card, no pings are successful, to or from FreeBSD.
• Running "route add default [router address]" gives a message that "Network is unreachable"
• There is a difference on the local network though: the response from ping attempts from FreeBSD says "No route to host", even after attempting "route add default [router address]".
• Running 'dhclient em0' results in "No DHCPOFFERS" received.

 

[paleoN]

My pciconf -clv output matches yours.

Do you have any other PCIe NIC cards you can test with?

 

[jgreco]

"No route to host" suggests that there's a networking configuration issue. Double- and triple-check the configuration ("ifconfig em0") to make sure your net address, netmask are correct, and make sure the interface is shown as UP. A sane config should look something like

Code:

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:0a:19:7e:ab:22
        inet 192.168.1.21 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active

I suspect that you might have made a mistake and you were maybe pinging the wrong thing when you say "EXCEPT when I ping the XP machine from the Free machine, now I get normal responses." because in order to do that you need bidirectional communication, which is unlikely to work for one thing but not for others.

 

[freshfeesh]

Thanks for all the help so far gents. Still plugging away here.

My pciconf -clv output matches yours.

Did you have the "1 corrected" AER? I don't know what that means, but presumably an error of some sort. "corrected" sounds good, but a "0" would be better. I have Freenas back up and available, and it looks like I'm not going to be able to dive further into this tonight. I did find some Windows firewall settings that I hadn't looked through before. These settings appear to be global to all connections. Nothing looks like it would block pinging, but let me know if any merrit toggling:


I'll get FreeBSD 9 back up and tripplecheck my settings next, as jgreco suggests. I don't have another PCIe NIC to test, but I'm getting close to just buying a new Intel. The one thing I'll do before that is move the one I'm troubleshooting into my XP machine (where the card worked earlier under Windows), boot that machine to Freenas 8.2, then Freebsd 9, via USB stick, and try to ping it over the LAN from my Win7 living room machine upstairs.