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

    Long delay pinging FW from LAN

    Hardware
    3
    9
    4.9k
    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.
    • C
      cyruspy
      last edited by

      Hi, last night people accessing inet from Windows machines complaining about it being "slow". So i checked with a ping to the pfsense box and got intermittent responses (sometimes timeouts). Then tried from my linux laptop and didn't get timeouts, but intermittently got up to 5000ms of delay pinging to the FW!!!

      So, i tried switching the CAT5 cable for a new one, but got the same issue. All i could see on the system messages is:

      Jul 16 05:34:23 kernel: dc0: TX underrun – using store and forward mode
      Jul 16 05:34:23 kernel: dc0: dc_setcfg: failed to force rx to idle state
      Jul 16 04:01:20 kernel: dc0: TX underrun -- using store and forward mode
      Jul 16 04:01:20 kernel: dc0: dc_setcfg: failed to force rx to idle state
      Jul 16 03:30:41 kernel: dc0: dc_setcfg: failed to force rx to idle state
      Jul 16 03:30:41 kernel: dc0: watchdog timeout

      I'm not sure this messages are related, because they just appeared here and there, not in the whole period the problem was noticed...

      The problem continued this morning until an hour ago, when the delay came down to something between 0.8 to 3 ms in average...

      I didn't change anything before the problem was solved, so i assume the issue could reappear...

      Any hints?

      EDIT:
      Hardware: OLD PCCHIPS M598LMR + K6-2@550Mhz + 160 MB RAM + 2GB HDD

      1 Reply Last reply Reply Quote 0
      • C
        cyruspy
        last edited by

        It's starting again

        Pinging from laptop to firewall:

        64 bytes from 10.1.1.2: icmp_seq=14150 ttl=64 time=459 ms
        64 bytes from 10.1.1.2: icmp_seq=14151 ttl=64 time=21.4 ms
        64 bytes from 10.1.1.2: icmp_seq=14152 ttl=64 time=539 ms
        64 bytes from 10.1.1.2: icmp_seq=14153 ttl=64 time=11.9 ms
        64 bytes from 10.1.1.2: icmp_seq=14154 ttl=64 time=260 ms
        64 bytes from 10.1.1.2: icmp_seq=14154 ttl=64 time=261 ms (DUP!)
        64 bytes from 10.1.1.2: icmp_seq=14156 ttl=64 time=616 ms
        64 bytes from 10.1.1.2: icmp_seq=14161 ttl=64 time=1373 ms
        64 bytes from 10.1.1.2: icmp_seq=14162 ttl=64 time=376 ms
        From 10.1.1.11 icmp_seq=14194 Destination Host Unreachable
        From 10.1.1.11 icmp_seq=14197 Destination Host Unreachable
        From 10.1.1.11 icmp_seq=14200 Destination Host Unreachable
        From 10.1.1.11 icmp_seq=14203 Destination Host Unreachable
        From 10.1.1.11 icmp_seq=14206 Destination Host Unreachable
        64 bytes from 10.1.1.2: icmp_seq=14208 ttl=64 time=877 ms
        64 bytes from 10.1.1.2: icmp_seq=14209 ttl=64 time=477 ms
        64 bytes from 10.1.1.2: icmp_seq=14210 ttl=64 time=1067 ms
        64 bytes from 10.1.1.2: icmp_seq=14211 ttl=64 time=69.2 ms
        64 bytes from 10.1.1.2: icmp_seq=14212 ttl=64 time=747 ms
        64 bytes from 10.1.1.2: icmp_seq=14213 ttl=64 time=1003 ms
        64 bytes from 10.1.1.2: icmp_seq=14214 ttl=64 time=7.52 ms
        64 bytes from 10.1.1.2: icmp_seq=14215 ttl=64 time=1123 ms
        64 bytes from 10.1.1.2: icmp_seq=14216 ttl=64 time=123 ms
        64 bytes from 10.1.1.2: icmp_seq=14217 ttl=64 time=594 ms
        64 bytes from 10.1.1.2: icmp_seq=14218 ttl=64 time=92.6 ms
        64 bytes from 10.1.1.2: icmp_seq=14219 ttl=64 time=136 ms
        64 bytes from 10.1.1.2: icmp_seq=14220 ttl=64 time=2004 ms
        64 bytes from 10.1.1.2: icmp_seq=14221 ttl=64 time=1004 ms
        64 bytes from 10.1.1.2: icmp_seq=14222 ttl=64 time=5.52 ms
        64 bytes from 10.1.1.2: icmp_seq=14223 ttl=64 time=752 ms
        64 bytes from 10.1.1.2: icmp_seq=14224 ttl=64 time=2123 ms

        Pinging from laptop to workstation (at the same time):
        64 bytes from 10.1.1.10: icmp_seq=221 ttl=64 time=0.725 ms
        64 bytes from 10.1.1.10: icmp_seq=222 ttl=64 time=0.627 ms
        64 bytes from 10.1.1.10: icmp_seq=223 ttl=64 time=1.46 ms
        64 bytes from 10.1.1.10: icmp_seq=224 ttl=64 time=0.768 ms
        64 bytes from 10.1.1.10: icmp_seq=225 ttl=64 time=0.686 ms
        64 bytes from 10.1.1.10: icmp_seq=226 ttl=64 time=0.640 ms
        64 bytes from 10.1.1.10: icmp_seq=227 ttl=64 time=0.735 ms
        64 bytes from 10.1.1.10: icmp_seq=228 ttl=64 time=0.827 ms
        64 bytes from 10.1.1.10: icmp_seq=229 ttl=64 time=0.667 ms
        64 bytes from 10.1.1.10: icmp_seq=230 ttl=64 time=0.787 ms
        64 bytes from 10.1.1.10: icmp_seq=231 ttl=64 time=1.00 ms
        64 bytes from 10.1.1.10: icmp_seq=232 ttl=64 time=0.660 ms
        64 bytes from 10.1.1.10: icmp_seq=233 ttl=64 time=0.654 ms
        64 bytes from 10.1.1.10: icmp_seq=234 ttl=64 time=1.39 ms
        64 bytes from 10.1.1.10: icmp_seq=235 ttl=64 time=1.59 ms
        64 bytes from 10.1.1.10: icmp_seq=236 ttl=64 time=1.36 ms
        64 bytes from 10.1.1.10: icmp_seq=237 ttl=64 time=1.45 ms
        64 bytes from 10.1.1.10: icmp_seq=238 ttl=64 time=0.723 ms
        64 bytes from 10.1.1.10: icmp_seq=239 ttl=64 time=0.791 ms
        64 bytes from 10.1.1.10: icmp_seq=240 ttl=64 time=0.627 ms
        64 bytes from 10.1.1.10: icmp_seq=241 ttl=64 time=0.782 ms
        64 bytes from 10.1.1.10: icmp_seq=242 ttl=64 time=2.40 ms
        64 bytes from 10.1.1.10: icmp_seq=243 ttl=64 time=0.672 ms

        And logs report the same error as before:
        Jul 16 13:27:48 sshd[17090]: Accepted keyboard-interactive/pam for admin from 10.1.1.11 port 55881 ssh2
        Jul 16 13:26:52 kernel: dc0: TX underrun – using store and forward mode
        Jul 16 13:26:52 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:25:41 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:25:41 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:25:10 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:25:10 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:24:56 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:24:56 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:24:11 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:24:11 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:23:21 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:23:21 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:21:03 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:21:03 kernel: dc0: watchdog timeout
        Jul 16 13:19:47 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:19:47 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:18:47 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:18:47 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:17:08 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:17:08 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:15:07 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:15:07 kernel: dc0: watchdog timeout
        Jul 16 13:14:38 sshd[87597]: Timeout, client not responding.
        Jul 16 13:13:43 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:13:43 kernel: dc0: watchdog timeout
        Jul 16 13:11:43 kernel: dc0: TX underrun – using store and forward mode
        Jul 16 13:11:43 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:09:54 kernel: dc0: dc_setcfg: failed to force rx to idle state
        Jul 16 13:09:54 kernel: dc0: watchdog timeout
        Jul 16 13:07:47 kernel: dc0: TX underrun -- using store and forward mode
        Jul 16 13:07:47 kernel: dc0: dc_setcfg: failed to force rx to idle state

        I'm not sure what's triggering it ???

        1 Reply Last reply Reply Quote 0
        • S
          sullrich
          last edited by

          Out of states?  Look on the main system status page.

          1 Reply Last reply Reply Quote 0
          • C
            cyruspy
            last edited by

            Doesn't seem to be the problem

            info.jpg
            info.jpg_thumb

            1 Reply Last reply Reply Quote 0
            • S
              sullrich
              last edited by

              Try changing your nics.  I have never used dcX and would not trust them personally.

              Intel nics are your best bet.

              1 Reply Last reply Reply Quote 0
              • C
                cyruspy
                last edited by

                This is a fw built from spare parts, just for home use, so i wouldn't buy a high end card… Got an unused Encore nic, but i read somewhere else that realtek chips aren't a good option either....
                Checking the supported hardware, i can see the davicom chipset as supported.....

                Maybe i can tune some parameters for that module or something.... Is there any other option?

                1 Reply Last reply Reply Quote 0
                • S
                  sullrich
                  last edited by

                  Are you using the traffic shaper?

                  If not, FreeBSD is picky about its hardware.  You need to design the machine around parts that work well with FreeBSD instead of the other way around to guarantee that it will be happy with your piece-milled solution.

                  1 Reply Last reply Reply Quote 0
                  • Cry HavokC
                    Cry Havok
                    last edited by

                    The little firewall box I've got that runs pfSense is using Realtek chips and (so far) I've had no problems with it.  There is the occasional slowdown, but that's more to do with my opening a few dozen tabs in Firefox at the same time and overloading Squid :)

                    1 Reply Last reply Reply Quote 0
                    • C
                      cyruspy
                      last edited by

                      According to http://forum.pfsense.org/index.php/topic,25.0.html, the DM9102 chipset is supported. I didn't wan't to disable that interface (it's onboard) but given i can't find the problem, i'll have to try with another NIC..

                      I'll let you know.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.