bge0: discard frame w/o packet header

Sam Leffler sam at errno.com
Thu Feb 15 21:32:31 UTC 2007


John Polstra wrote:
> I have a Dell SC1435 server running an i386 -current system from
> around the end of December, with a few selected updates applied.  It
> had been running reliably until early this morning, when the
> following sequence of events happened.  First, this message was
> logged:
> 
>   Feb 15 07:14:29 rock kernel: bge0: discard frame w/o packet header
> 
> About 2 minutes later, at 07:16:30, the last /var/log/maillog entry
> was logged.  (This machine is under constant assault from spambots
> trying dictionary attacks.  It is rare for more than 15 seconds to
> pass without something being logged in the maillog file.)
> 
> 30 seconds after that came another bge message:
> 
>   Feb 15 07:17:00 rock kernel: bge0: discard frame w/o packet header
> 
> At that point, all network connectivity was gone.  The machine didn't
> respond to pings.  Worse, its remote management controller, which uses
> ASF and shares the same network interface, was also unresponsive to
> pings.  To get the machine back, I had to ask somebody working at the
> colocation facility to power-cycle it.
> 
> The "discard frame w/o packet header" message comes from ether_input()
> if it gets an mbuf that doesn't have the M_PKTHDR flag set.  That
> can't happen unless something is very wrong with the system.  I'd like
> to make it a panic.  At least then the machine would reboot instead of
> just becoming unreachable.  Any objections?
> 
> Some other nearby warnings should also be panics, in my opinion:
> 
>   discard frame w/o leading ethernet header ...
> 
>   discard frame w/o interface pointer ...
> 
> and, maybe:
> 
>   discard oversize frame ...
> 
> Opinions?

There are several diagnostics in ether_input I added mostly because
drivers "shouldn't do that"; this is one of them.  However some are
questionable.  I'm not sure about the panic but at the least we should
rate limit the messages so they can't be used as a DOS mechanism.
Replacing them with counters and sticking the printf's under IFF_DEBUG
is another option.

	Sam


More information about the freebsd-net mailing list