NIC stopped working with 1.2.3-RC3

wpc

I just upgraded my firewall to 1.2.3-RC3 and my network cards are no longer working. Here's the dmesg output on the card:
<intel 10="" 100="" 82559er="" embedded="" ethernet="">This network card was working fine in 1.2.2 and with 1.2.3-RC1. Anyone, have any thoughts on how to get them working again?

Thanks.</intel>

wallabybob

Care to elaborate on "no longer working"? e.g "attach error on startup", "carrier not detected", "link up but no reception", etc

wpc

I didn't get any errors. I just couldn't get network traffic through the NIC. I first tried to connect to the web interface for initial configuration, but wasn't able to do it. The web connection just timed out. I then tried to ping the firewall from a computer and that didn't work. I even tried the reverse of pinging the computer from the firewall, but no response. I had the computer connected to the firewall through a network switch. I then tried connecting the PC to the firewall directly using a cross over cable and still no luck.

I reinstalled 1.2.2 and was able to ping the firewall right away.

Eugene

what do you see in ifconfig -a

wpc

Here's the output of ifconfig -a (I'm only going to list the interface in question as I can't exactly copy and past :) )

fxp5: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=9 <rxcsum,vlan_mtu>ether 00:10:f3:07:55:19
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::210:f3ff:fe07:5519%fxp5 prefixlen 64 scopeid 0x6
media Ethernet autoselect (100baseTX)
status: active</rxcsum,vlan_mtu></up,broadcast,running,simplex,multicast>

wallabybob

The "broken" interface is fxp5. That suggest you also have fxp0, fxp1, fxp2, fxp3 and fxp4 on the system. Presumably at least some of these are in use. Does the ifconfig output of any of those differ from the ifconfig output of fxp5? If so, how?

(Maybe its just a typo, but you said "my network cards are no longer working." and then subsequently discuss a single card.)

I presume fxp5 is the LAN interface and has a static IP address. Correct?

Does a tcpdump show any traffic at all:

tcpdump -i fxp5

Does anything show up when you try to ping over that interface from pfSense? How about when you try to ping that interface from another system?

In both cases what is reported by the ping? (Exact message please.)

wpc

All of the network interface cards are integrated into the system board of my firewall. They are all the same manufacturer and model and all have the same problem. For the sake of simplicity I decided to talk only about one card. I didn't mean to cause any confusion. I have tried configuring other interfaces such as fxp0 and fxp4 to be my LAN interface, but they exhibit the same behavior as fxp5.

At this point I'm using only 1 interface. I planned to configure the others later after gaining access to the web config page. fxp5 just happens to be physically the first interface so I chose to use it for the LAN interface.

I presume fxp5 is the LAN interface and has a static IP address. Correct?

Yes this is correct.

Does a tcpdump show any traffic at all:

When I run tcpdump I do see traffic while trying to ping the interface. Here's an example of the result:

IP truncated-ip - 2 bytes missing! 192.168.1.105.50302 > 63.80.242.19.http: F 1525055747:1525055747(0) ack 1463654551 win 1002 <nop,nop,timestamp 145251602[|tcp]="">IP truncated-ip - 2 bytes missing! 192.168.1.105.50303 > 63.80.242.19.http: F 1537244627:1537244627(0) ack 1460108919 win 1002 <nop,nop,timestamp 145251729[|tcp]="">192.168.1.105 is the computer I'm running the ping from.

In both cases what is reported by the ping? (Exact message please.)

Ping does not give any error message. The output of ping from both my firewall and the client PC are the same. Here's the output from my work station:

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

–- 192.168.1.1 ping statistics ---
50 packets transmitted, 0 received, 100% packet loss, time 48999ms</nop,nop,timestamp></nop,nop,timestamp>

wallabybob

Its dangerous to extrapolate from a sample of size of two :-), but if even a small percentage of your traffic is repeatedly considered to be missing two bytes it will cause severe problems in your communication.

Challenge now is to work out why tcpdump apparently thinks two bytes are missing from the frame and where they might be missing.

(I don't know exactly what the message IP truncated-ip - 2 bytes missing means but it suggests to me that tcpdump thinks the frame is two bytes shorter than it should be. I suspect this means the kernel will discard the received frame early in its processing. If this discard happens on every frame then the link will be in a "no communication" state.

I did a google on freebsd fxp tcpdump "2 bytes missing" which quickly led me to FreeBSD PR (Problem Report) 138135 which suggests the problem you are seeing is related to the fxp driver erroneously thinking the hardware has checksum offload capability. You may be able to get around the problem by disabling hardware checksum offloading. (See System -> Advanced, scroll down to Hardware Options.) Please note and report the current state, change the state, reboot, retest and report the outcome.

The PR suggests that, at worst, problem correction will need a small patch to fxp driver.

wpc

I can't get to the web configuration page. Any idea how I can disable hardware checksum offloading from the command prompt?

Thanks again for all of your help.

wpc

Nevermind I figured out how to disable the hardware checksum offloading:

ifconfig fxp5 -txcsum -rxcsum

I just wanted to report that it works!

Thanks!

wallabybob

@wpc:

I can't get to the web configuration page.

Of course! Sorry. But glad you have it working and presumably can now use the WEB GUI to make sure it stays disabled on reboot.
Thanks for reporting back.