Project

General

Profile

Actions

Bug #3748

closed

Interface in extended down state, not functional when link is brought back up

Added by Tim Nelson over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
07/08/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1.x
Affected Architecture:
i386

Description

Environment:
-pfSense 2.1.3/2.1.4
-Default/base installation (single DHCP WAN, LAN as 192.168.1.1 with DHCP server)
-Various hardware, but all with Intel Gigabit NICs

Duplication Steps:
1. Test traffic can pass through pfSense system from LAN to WAN (internet), etc
2. Disconnect LAN interface cable from switch/PC
3. Let sit for a period of time (our testing has found 'overnight' to be sufficient, but actual problem could surface sooner. Testing has shown the issue does not exist when link is down for 1 hour or less)
4. After a period of time has passed, reconnect the link on the LAN interface
5. The interface physically comes up (link light), but traffic will not pass. Unable to ping LAN IP, no DHCP present, etc.

Solution is to (from the console) issue an 'ifconfig em1 down; ifconfig em1 up'. This resets the link, and traffic will flow.

The problem appears to be in how pfSense is (mis)handling the link up event, not bringing it fully online.

Actions #1

Updated by Chris Buechler over 9 years ago

What we do to the NIC is the same whether it lost link for a minute or a year or anywhere in between. Our code actually has no concept of how long a NIC was down. An additional ifconfig down/up tends to kick things in a way it can fix driver issues, so I suspect that's the cause. Could you try on the most recent 2.2 snapshot and report back?

Actions #2

Updated by Tim Nelson over 9 years ago

Issue seems to be resolved with pfSense-LiveCD-2.2-DEVELOPMENT-i386-20140708-0814 with the exact same testing environment and methodology. As per your description of pfSense's handling of link up/down events, it is assumed the updated interface drivers and/or supporting daemons resolve this issue.

It should be noted that the original reported issue does also occur with non-Intel NICs as well. Those tested include Realtek and Broadcom.

Actions #3

Updated by Chris Buechler over 9 years ago

  • Status changed from New to Resolved
  • Target version set to 2.2

thanks for confirming

Actions

Also available in: Atom PDF