Discard frame w/o leading ethernet header (len 4294967294??)
-
Hello,
on my secondary machine, on the LAN card, I have thousands of this errors (see picture)…
I am running pfSense 2.0 Release x86... this is something strange, on RC3 I didn't have this problems... do you have any idea about it?Thanks,
Michele

 -
Maybe I solved this, it is 4 days I don't see any of this messages.
I created an ad-hoc VLAN for the "CARP" interface, before it was on the same switch/VLAN of the internal network, and actually when I saw this problem I also had problems on the internal network, and the CARP was inconsistent between the two machines… Last month the two CARP dedicated interface were connected with a cross-over cable, but this gave other problems, so I decided to plug them in the LAN switch, after some days I realized to have this problem...
Do you think that this operation can explain the solution?
Thanks,
Michele -
I'm seeing this without CARP, without your LAN configuration, and on different hardware. I have all the offloading options disabled and have only seen this since upgrading from RC3 to -STABLE. At present it's triggering at intervals between several hours and several days.
Oct 18 00:11:28 kernel: re0: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292)
Oct 18 00:11:28 kernel: re0: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292)
Oct 18 00:11:28 kernel: re0: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292)
Oct 18 00:11:28 kernel: re0: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292)When this happens, my ping responses go up from tenths of milliseconds to 6-10 seconds immediately afterwards and traffic passes at similarly awful rates. (A reboot clears things up). Something isn't right…
-
When this happens, my ping responses go up from tens of milliseconds to 6-10 seconds immediately afterwards and traffic passes at similarly awful rates. (A reboot clears things up). Something isn't right…
Hi,
my CARP problem was solved by removing the outbound NAT entries with "any" as source. Identified the problem, Ermal was adding some code (that we will run on version 2.0.1) to avoid this in any case http://redmine.pfsense.org/issues/1954 (thanks to Ermal for preventing this).What I can suggest you is:
- Do you have any outbound NAT rule with "source=any"? If so try to change it to the needed source network;
- Try to change: cable, switch port of the "re0" interface;
- Do you have more than one interface on the same switch? Try to put them on different switches / VLANs;
- Try to change the NIC.
Right now I don't have this problem anymore, I made all this changes, but in my case I also had the CARP problem, so I can't tell exactly which of this changes fixed the problem.
Ciao,
Michele -
Had a recurrence of this just now, with NAT outbound rules that all specify source addresses.
Trying one variable at a time here (oh, I did change the Ethernet cable for good measure).
Next is swapping the LAN interface to re2 on this card.