Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    NIC stopped working with 1.2.3-RC3

    1.2.3-PRERELEASE-TESTING snapshots - RETIRED
    3
    11
    6026
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wpc last edited by

      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>

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob last edited by

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

        1 Reply Last reply Reply Quote 0
        • W
          wpc last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • E
            Eugene last edited by

            what do you see in ifconfig -a

            1 Reply Last reply Reply Quote 0
            • W
              wpc last edited by

              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>

              1 Reply Last reply Reply Quote 0
              • W
                wallabybob last edited by

                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.)

                1 Reply Last reply Reply Quote 0
                • W
                  wpc last edited by

                  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>

                  1 Reply Last reply Reply Quote 0
                  • W
                    wallabybob last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • W
                      wpc last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • W
                        wpc last edited by

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

                        ifconfig fxp5 -txcsum -rxcsum
                        

                        I just wanted to report that it works!

                        Thanks!

                        1 Reply Last reply Reply Quote 0
                        • W
                          wallabybob last edited by

                          @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.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post

                          Products

                          • Platform Overview
                          • TNSR
                          • pfSense
                          • Appliances

                          Services

                          • Training
                          • Professional Services

                          Support

                          • Subscription Plans
                          • Contact Support
                          • Product Lifecycle
                          • Documentation

                          News

                          • Media Coverage
                          • Press
                          • Events

                          Resources

                          • Blog
                          • FAQ
                          • Find a Partner
                          • Resource Library
                          • Security Information

                          Company

                          • About Us
                          • Careers
                          • Partners
                          • Contact Us
                          • Legal
                          Our Mission

                          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                          Subscribe to our Newsletter

                          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                          © 2021 Rubicon Communications, LLC | Privacy Policy