Bug 207633 - bce0: Discard frame w/o leading ethernet header (len 0 pkt len 0) - pfSense 2.2.6 and 2.3 Beta
Summary: bce0: Discard frame w/o leading ethernet header (len 0 pkt len 0) - pfSense 2...
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-02 02:21 UTC by Matt
Modified: 2016-11-26 20:14 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt 2016-03-02 02:21:56 UTC
I recently my physical pfSesne install to a virtual machine. I have tried both pfSense 2.5.6 and 2.6 in kvm and am passing two physical interfaces through, using a Proxmox (debian) host. Each interface is a BCM5709, in a Dell PowerEdge R710.

I have found that in order to work around the issue, I have to disconnect the ethernet cables and allow pfSense to fully boot to the login prompt before reconnecting them, or else all interfaces spam discard frame errors with len 0 and pkt klen 0. Occasionally, even this workaround fails.

This is problematic in the case of a power event, as it means I will need to be physically present for the network to come back up. While I realize I'm thankfully not using this in an enterprise environment, it would be nice to fix this issue if possible.

Original bug on pfSense tracker: https://redmine.pfsense.org/issues/5649
Comment 1 Matt 2016-03-02 23:14:30 UTC
I should mention that I think pfSense is based on 10.1, and not 11 as I mistakenly selected.
Comment 2 Matt 2016-03-03 07:08:57 UTC
As of tonight's nightly build this issue seems to have gone away (pfSense snapshot).
Comment 3 Matt 2016-11-26 20:14:18 UTC
I should note that it was a false positive on the fix being related to anything within FreeBSD or pfSense, for the most part:

After using pci-stub on the Linux host for the two NIC's in question, which prevents the host from loading firmware for the cards (previously wasn't possible for a variety of reasons), coupled with the wiki entry below, I seem to have this issue no longer.

https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Broadcom_bce.284.29_Cards

That saves me buying a dual Intel NIC. I hope this information can help others with similar issues.