Long delay pinging FW from LAN
-
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 timeoutI'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 -
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 msPinging 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 msAnd 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 stateI'm not sure what's triggering it ???
-
Out of states? Look on the main system status page.
-
Doesn't seem to be the problem
-
Try changing your nics. I have never used dcX and would not trust them personally.
Intel nics are your best bet.
-
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?
-
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.
-
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 :)
-
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.