WAN dropped connection on 2.1
-
and here are the log entries starting at the fail at 20:20:14
May 21 18:55:37 check_reload_status: Reloading filter
May 21 20:20:14 check_reload_status: Linkup starting ue0
May 21 20:20:14 kernel: ue0: link state changed to DOWN
May 21 20:20:14 kernel: ue0: link state changed to UP
May 21 20:20:14 kernel: ue1: link state changed to DOWN
May 21 20:20:14 kernel: ue1: link state changed to UP
May 21 20:20:14 check_reload_status: Linkup starting ue0
May 21 20:20:14 check_reload_status: Linkup starting ue1
May 21 20:20:14 check_reload_status: Linkup starting ue1
May 21 20:20:18 php: rc.linkup: DEVD Ethernet detached event for opt1
May 21 20:20:18 php: rc.linkup: DEVD Ethernet attached event for wan
May 21 20:20:18 php: rc.linkup: HOTPLUG: Configuring interface wan
May 21 20:20:18 php: rc.linkup: DEVD Ethernet detached event for wan
May 21 20:20:18 php: rc.linkup: DEVD Ethernet attached event for opt1
May 21 20:20:18 php: rc.linkup: HOTPLUG: Configuring interface opt1
May 21 20:20:19 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:19 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:19 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:19 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:19 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:23 php: rc.linkup: Clearing states to old gateway 172.23.23.23.
May 21 20:20:23 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:23 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:23 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:23 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:24 check_reload_status: rc.newwanip starting ue0
May 21 20:20:24 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:24 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:24 php: rc.linkup: Clearing states to old gateway 50.130.28.1.
May 21 20:20:24 check_reload_status: rc.newwanip starting ue1
May 21 20:20:25 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:25 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:25 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:25 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:26 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:26 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:26 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:26 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:27 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:27 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:27 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:27 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:27 php: rc.newwanip: rc.newwanip: Informational is starting ue0.
May 21 20:20:27 php: rc.newwanip: rc.newwanip: on (IP address: ) (interface: OPT1[opt1]) (real interface: ue0).
May 21 20:20:27 php: rc.newwanip: rc.newwanip: Failed to update opt1 IP, restarting…
May 21 20:20:27 check_reload_status: Configuring interface opt1
May 21 20:20:27 php: rc.newwanip: rc.newwanip: Informational is starting ue1.
May 21 20:20:27 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:27 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:27 php: rc.newwanip: rc.newwanip: on (IP address: ) (interface: WAN[wan]) (real interface: ue1).
May 21 20:20:27 php: rc.newwanip: rc.newwanip: Failed to update wan IP, restarting…
May 21 20:20:28 check_reload_status: Configuring interface wan
May 21 20:20:28 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:28 check_reload_status: updating dyndns wan
May 21 20:20:28 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:28 php: rc.linkup: The command '/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid ale0' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.2.6 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Wrote 17 leases to leases file. Can't backup lease database /var/db/dhcpd.leases to /var/db/dhcpd.leases~: File exists Listening on BPF/ale0/00:23:54:0b:73:24/192.168.3.0/24 Sending on BPF/ale0/00:23:54:0b:73:24/192.168.3.0/24 Can't bind to dhcp address: Address already in use Please make sure there is no other dhcp server running and that there's no entry for dhcp or bootp in /etc/inetd.conf. Also make sure you are not running HP JetAdmin software, which includes a bootp server. If you did not get this software from ftp.isc.org, please get the latest from ftp.isc.org and install that before requesting help. If you did get this soft
May 21 20:20:28 check_reload_status: updating dyndns opt1
May 21 20:20:29 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:29 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:29 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:29 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:30 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:30 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:30 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:30 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:30 php: rc.interfaces_wan_configure: The command '/sbin/dhclient -c /var/etc/dhclient_opt1.conf ue0 > /tmp/ue0_output 2> /tmp/ue0_error_output' returned exit code '1', the output was ''
May 21 20:20:31 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:31 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:31 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:31 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:32 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:32 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:32 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:32 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:32 php: rc.interfaces_wan_configure: The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf ue1 > /tmp/ue1_output 2> /tmp/ue1_error_output' returned exit code '1', the output was ''
May 21 20:20:32 php: rc.dyndns.update: The command '/sbin/route change -inet default dynamic' returned exit code '68', the output was 'route: bad address: dynamic'
May 21 20:20:32 php: rc.dyndns.update: The command '/sbin/route change -inet default dynamic' returned exit code '68', the output was 'route: bad address: dynamic'
May 21 20:20:33 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:33 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:33 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:33 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:34 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:34 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:34 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:34 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:35 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:35 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:35 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:35 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:36 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:36 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:36 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:36 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:37 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:37 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:37 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:37 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:38 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:38 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:38 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:38 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:39 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:39 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:39 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:39 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:40 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:40 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:40 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:40 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:41 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:41 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:41 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:41 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:42 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:42 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:42 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:42 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:43 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:43 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:43 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:43 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:43 check_reload_status: updating dyndns GW_WAN
May 21 20:20:43 check_reload_status: Restarting ipsec tunnels
May 21 20:20:43 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 21 20:20:43 check_reload_status: Reloading filter
May 21 20:20:43 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:43 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:43 check_reload_status: updating dyndns GW_OPT1
May 21 20:20:43 check_reload_status: Restarting ipsec tunnels
May 21 20:20:43 check_reload_status: Restarting OpenVPN tunnels/interfaces
May 21 20:20:43 check_reload_status: Reloading filter
May 21 20:20:44 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:44 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:45 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:45 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:45 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:45 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:46 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:46 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:46 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:46 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:47 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:47 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:47 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:47 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:48 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:48 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:48 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:48 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:49 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:49 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:49 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:49 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:50 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:50 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:50 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:50 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:50 php: rc.dyndns.update: The command '/sbin/route change -inet default dynamic' returned exit code '68', the output was 'route: bad address: dynamic'
May 21 20:20:50 php: rc.dyndns.update: The command '/sbin/route change -inet default dynamic' returned exit code '68', the output was 'route: bad address: dynamic'
May 21 20:20:50 php: rc.dyndns.update: MONITOR: GW_WAN is down, removing from routing group combine
May 21 20:20:50 php: rc.dyndns.update: MONITOR: GW_OPT1 is down, removing from routing group combine
May 21 20:20:50 php: rc.dyndns.update: MONITOR: GW_WAN is down, removing from routing group combine
May 21 20:20:50 php: rc.dyndns.update: MONITOR: GW_OPT1 is down, removing from routing group combine
May 21 20:20:50 php: rc.dyndns.update: Gateways status could not be determined, considering all as up/active. (Group: combine)
May 21 20:20:50 php: rc.dyndns.update: Gateways status could not be determined, considering all as up/active. (Group: combine)
May 21 20:20:50 php: rc.filter_configure_sync: The command '/sbin/route change -inet default dynamic' returned exit code '68', the output was 'route: bad address: dynamic'
May 21 20:20:50 php: rc.filter_configure_sync: MONITOR: GW_WAN is down, removing from routing group combine
May 21 20:20:50 php: rc.filter_configure_sync: MONITOR: GW_OPT1 is down, removing from routing group combine
May 21 20:20:50 php: rc.filter_configure_sync: Gateways status could not be determined, considering all as up/active. (Group: combine)
May 21 20:20:51 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:51 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:51 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:51 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:52 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:52 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:52 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:52 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:52 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:52 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:53 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:53 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:53 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:53 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan).
May 21 20:20:53 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan).
May 21 20:20:53 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan).
May 21 20:20:53 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (opt1).
May 21 20:20:53 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:54 kernel: arpresolve: can't allocate llinfo for 172.23.23.23
May 21 20:20:54 kernel: arpresolve: can't allocate llinfo for 50.130.28.1
May 21 20:20:54 php: rc.filter_configure_sync: The command '/sbin/route change -inet default dynamic' returned exit code '68', the output was 'route: bad address: dynamic'
May 21 20:20:54 php: rc.filter_configure_sync: MONITOR: GW_WAN is down, removing from routing group combine
May 21 20:20:54 lighttpd[34060]: (network_writev.c.107) writev failed: Operation not permitted 15
May 21 20:20:54 lighttpd[34060]: (connections.c.619) connection closed: write failed on fd 15
May 21 20:20:54 lighttpd[34060]: (network_writev.c.107) writev failed: Operation not permitted 14
May 21 20:20:54 lighttpd[34060]: (connections.c.619) connection closed: write failed on fd 14
May 21 20:20:54 php: rc.filter_configure_sync: MONITOR: GW_OPT1 is down, removing from routing group combine
May 21 20:20:54 php: rc.filter_configure_sync: Gateways status could not be determined, considering all as up/active. (Group: combine)
May 21 20:20:54 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan).
May 21 20:20:54 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan).
May 21 20:20:54 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan).
May 21 20:20:54 php: rc.filter_configure_sync: Could not find IPv4 gateway for interface (opt1).
May 21 21:05:13 check_reload_status: rc.newwanip starting ue0
May 21 21:05:17 php: rc.newwanip: rc.newwanip: Informational is starting ue0.
May 21 21:05:17 php: rc.newwanip: rc.newwanip: on (IP address: 50.130.29.69) (interface: OPT1[opt1]) (real interface: ue0). -
May 21 20:20:18 php: rc.linkup: DEVD Ethernet detached event for opt1
May 21 20:20:18 php: rc.linkup: DEVD Ethernet attached event for wan
May 21 20:20:18 php: rc.linkup: HOTPLUG: Configuring interface wan
May 21 20:20:18 php: rc.linkup: DEVD Ethernet detached event for wan
May 21 20:20:18 php: rc.linkup: DEVD Ethernet attached event for opt1
May 21 20:20:18 php: rc.linkup: HOTPLUG: Configuring interface opt1It looks like the driver is seeing the actual ethernet link go down as though the cable has been unplugged or the upstream device has been rebooted. What are the WAN and OPT1 interfaces connected to?
There is a bug in rc.renewwanip which may be relevant here:
https://forum.pfsense.org/index.php?topic=76735.msg421118#msg421118Steve
-
Steve,
Thanks for your quick response. I was surprised that this thread was still open. I just saw that there was a new release and thought I would upgrade and try it out. Unfortunately, my problem with the USB nic drivers is apparently still present.
Specifically, answering your questions, the hardware was not touched or unplugged or changed in any way at that time.
The WAN is plugged into an ATT dsl 2WIRE model modem, which has its wireless features disabled; is plugged into a phone jack in the wall; and is powered by a ups. It is set to provide a 172.23.x.x address in response to a dhcp request from the pfsense box.
The OPT1 is plugged into a motorola surfboard cable modem, which is plugged into the cable coax in the wall; is also powered by a UPS; and delivers an external IP address in response to a dhcp request from the pfsense box.
It is unlikely that both networks dropped connection to my house simultaneously, two days after upgrading from 1.2.3, when they have been stable for the 6 months I have not been using pfsense 2.1.
I will check into the bug report this evening.
-ram
-
I agree, more likely that the USB driver is resetting the PHY for some reason.
pfSense 1.2.3 was built on FreeBSD 7.X. pfSense 2.0.X on 8.1 and 2.1.X on 8.3, both FreeBSD 8 branch so the drivers are probably similar if not identical. You might try a 2.2 snapshot because they are built on FreeBSD 10 so will likely have better drivers, less bugs (but also may have new bugs! ;))
http://snapshots.pfsense.org/Steve
-
My experience with USB NICs on FreeBSD and pfSense is pretty much that USB NICs should be used only when no other option is available. They are not in the same league with PCI/PCIx/PCIe NICs in terms of reliability and performance.
-
Kpa,
Well thanks for your thoughts, but I can't just shove a couple cards into the eeepc's I've been using for pfsense over the past several years. Further, I have been using USB nics in them since 2009, and have had no problems with them. In fact, my 701 surf, which is running 1.2.3, has been up for over a year without a single problem, and its USB NICs have been in continuous use since 2009. My experience says that USB NICs perform well, are robust, and reliable.
I cannot say the same for the ue drivers bundled in pfsense 2.1.X They have been a constant headache, since I first upgraded from 2.0.1 rel, and still are. I am hoping Steve's note that 2.2 is based on a different build will bring some relief.
-ram
-
I want to concur with Trussent here.
Only in my case problems started after upgrading to 2.1.3
Before that I was running 2.1 in a VM and a usb adapter in pass through mode and they performed great.
Sure there were multiple interface down and up once in a while but they seemed never to affect the actual connection.
Since I installed 2.1.3 it has been nothing but pain and frustration.
First the same ue0 down and up events are now actually causing the wan connection to reset.
Secondly the pppoe dialer has a bug so it is unable to reconnect so I wrote a php script to invoke configure_interface function whenever this happens (to be more precise just put it at cronjob running each minute.
Third I just attempted something that may alleviate this problem.
I simply commented out interface_bring_down function from the the /etc/rc.linkup.
This of course breaks unplug replug cable functionality, but hopefully it will stop reacting to the usb nic driver behaving badly and showing as if network cable got disconnected.
Can't comment yet on the results as I haven't had ue0 event just yet so it remains to be seen how this works. -
How did you go with this Matrix?
I've just jumped into the world of pfSense and started with the latest version 2.1.3. I'm using a Belkin F4U047bt network card for my WAN connection to my Netgear DG834G in modem mode. I know the modem and cable are both fine because they ran fine for years under ClearOS.
The USB NIC is new however and it’s plugged into a EEEbox (same as Trussent).
I’m having exactly the same symptoms but I’m not really as keen to go back so many versions to get it to work consistently.
-
Unfortunately I didn't
Since I run pfsense in a VM I did the following:
1. I installed an old intel 100 pro nic into the host machine.
2. Using Virtualbox I briged it with a virtual adapter (intel pro 1000).
3. Hooked up the modem to this nic.
4. In order to make sure the nic is exclusively used only by the VM I removed any ip addresses that might have been assigned to it.No Internet disconnects since
-
Steve,
I have been messing with 2.2 alpha builds for a while now, and they are just too unstable for me to be able to know if the USB drivers are better. (By unstable I mean that they throw exceptions and drop into the db when reloading the interfaces after a reboot, or a reconfiguration of the network architecture.) Perhaps as 2.2 matures, I can do some system tests that can add information about this problem with respect to 2.2.
As for 2.1.3, I have swapped the wan and opt1 and done a few other experiments. None have changed the fundamental problem with the ue usb drivers reporting a HOTPLUG event within a short time (5 minutes to 2 days). The only new symptom is that prior to dropping out the gateway monitor is reporting 66% packet loss for a while (at least a few minutes), but there is nothing about this in the logs. I can't really say if it is new or I just didn't notice it before.
Matrix200,
Did your code change:
I simply commented out interface_bring_down function from the the /etc/rc.linkup.
work? I haven't tried that yet.
-ram
-
That's funny, I was about to come here and write my experience with 2.2 over the last 5-6 days.
I did the same as you and tried with one of the latest 2.2 nightly images and it has been pretty much perfect for me since. I haven't had any drop outs for the USB nic (it's been about 4-5 days now) and pfSense itself has been running fine.
I probably have a much simpler setup than you but for me, it's running exactly how I need it to. Snort is also running as it should.
-
nug,
Thanks for the note. What you describe is very encouraging. Based on it, I built a system on 2.01 and then upgraded it to today's 2.2 alpha. I will get it configured for my network and then insert it into my network architecture and see how it works.
-ram
-
trussent, no it didn't help.
The connection would still die and I still had to reconnect on each usb device disappearing event. -
The last week or so would have been a particularly bad time to start playing with 2.2 snapshots, some large bugs crept in that prevented some major components running like the webgui! It had been relatively stable for sometime before that. It's fixed now though, I have a couple of test boxes here running fine. None using USB NICs though. ;)
Steve
-
Matrix200,
Thanks for the info, I will work on getting 2.2 working instead of messing with the code.
Steve,
Yes, I agree that the recent 2.2 builds have been hard to use. However, the build from yesterday seems to have installed correctly onto an eeePC 900HA and the pfsense web-configuration tool is working. Also encouraging is that the new build recognizes two newer model d-link brand USB NICs that were not recognized by 2.1.x; so, some serious progress has been made in this version with respect to the USB NIC ue drivers.
I am hosting a server right now with my prior architecture, and will wait to substitute the newly built box until it is not being used, or the current 2.1.3 build drops the connections. I expect to be able to do the swap and provide comments about the change sometime during the next 24 hours.
-ram
-
I must have been lucky with the nightly that I grabbed because I haven't had any issues and it hasn't dropped the connection once.
FYI - I'm on 2.2-ALPHA built on Fri June 06
-
Ok, I have reloaded a 2.2alpha snapshot (June 9) on an eeepc901ha and put it into place. The new dlink usb nics are not able to obtain dhcp leases, although they are recognized as devices. The ancient usb nics I have been using for years are recognized and also able to attach to the networks and obtain dhcp leases. Everything has been working for about 10 minutes without packet drops or ip drops. I will leave this configuration in place for a few days to see if it is stable. There are a number of reasons that this cannot be my final stable configuration, but it is ok to test in this mode for the next few days.
Thanks to everyone who has been working with me on this thread. More to follow.
-ram
-
The usb nics are working fine, but there seems to be a problem with port forwarding in the June 9 build. Updating to June 12 to see if it abates.
-ram
-
After a 72 hour test, the 2.2 usb drivers are not more reliable or different in performance than the 2.1.3 drivers (recognizing, but not utilizing, newer usb nics is nice but does not contribute to performance). Moreover, 2.2 is incompatible with port-forwarding for teamspeak, and a bunch of other servers, that worked in versions up to and including 2.1.3.
I am now just fed up and am unwilling to keep wasting my time messing pfsense, which is regressing in functionality with every revision. For now, I am installing 2.0.1, which has worked on other systems of mine with similar hardware, for a long time, and trying to forget these last few weeks.
This is so frustrating for me, because I have been using pfsense for several years, and it has been really good. But every single build after 2.0.1 is unusable for me. Not, limited, not flaky, not buggy, but unusable, because of the inability to maintain continuous server functionality, either because of firewall or driver failures.
Thanks to all the folks who have suggested solutions for my issues and to the development team, who is no doubt trying hard to make the software better. I will return to this thread in a few months, because by then I expect that my innate but seemingly irrational hope for a better future will have overcome my current despair for this project.
-ram
-
:( Sad to hear.
Yes the current 2.2 snapshots have issues but that's the nature of development snapshots. Try a Beta snapshots when they reach that stage.Steve
