Bad hdr length messages in logs (Dell R200 Machines)

AudiAddict

Arg.. spent 2 hours trying to fix it in the data center :

Checked bios version (latest was already installed)
Did a complete reinstall of the dell R200 –> set uni processor instead of multi
Changed disk setup from onboard raid to --> sata (single drive)
Turned off tso for all interfaces
Switched lan/wan interface to expansion card
Tested both Dell R200 units
Did memtest on both units

Still getting the hdr length messages..


11-04-2008	23:18:07	Local0.Info	Nov  4 23:18:40 pf: 211054 rule 145/0(match): block in on bge0: (tos 0x0, ttl 54, id 22968, offset 0, flags [DF], proto TCP (6), length 60) 80.85.189.226.2325 > x.x.130.130.23:  tcp 24 [bad hdr length 16 - too short, < 20]
11-04-2008	23:18:04	Local0.Info	Nov  4 23:18:37 pf: 1\. 009550 rule 145/0(match): block in on bge0: (tos 0x0, ttl 54, id 20379, offset 0, flags [DF], proto TCP (6), length 60) 80.85.189.226.2325 > x.x.130.130.23:  tcp 28 [bad hdr length 12 - too short, < 20]

To be safe I connected the old firewall… (P4 2.4ghz machine) on pfsense 1.2 to the exact same network (Just swapped network cables) and the bad hdr length messages are gone.. (or are not displayed in syslog on 1.2?)

I'm running out of idea's.. anybody know how to solve this issue?

dotdash

Is the firewall not performing as expected, or are the errors in the log the only problem?
This seems to suggest that it may be a cosmetic issue due to the default snaplength of tcpdump:
(http://kerneltrap.org/mailarchive/freebsd-pf/2008/10/28/3840344)
_> In some of these lines, there is mention of "[bad hdr length 0 - too

short, < 20]" BUT NOT IN ALL.

That's because you're using tcpdump against a pflog interface. You need
to increase the snaplen from 68 bytes to something larger; try -s 256
and that message will go away. It's harmless._

This is from the tcpdump man page:
If the snapshot was small enough that tcpdump didn't capture the full
TCP header, it interprets as much of the header as it can and then
reports [|tcp]'' to indicate the remainder could not be interpreted. If the header contains a bogus option (one with a length that's either too small or beyond the end of the header), tcpdump reports it as [bad opt]'' and does not interpret any further options (since it's
impossible to tell where they start). If the header length indicates
options are present but the IP datagram length is not long enough for
the options to actually be there, tcpdump reports it as ``[bad hdr
length]''.

AudiAddict

Is there anyway to verify/check that it's just cosmetic?

Is there a way to modify the tcdump output to syslog? I have a rulle to allow all and this is set to log, after that I have my block rules (this way I acn log all traffic with a syslog daemon).

cmb

This was caused by a FreeBSD regression, which we have worked around now. Update to a new 1.2.1 snapshot and it should be gone. Let us know how it goes.

AudiAddict

Thanks CMB, I will update the firewall tonight (it's in production) and have it rebooted.

I will verify the logs tomorrow morning and report back.

Right now the firewall is installed with a singlethreaded base OS (there is a xeon with 2 cores in the system) and setup without raid.

I did this to troubleshoot the firewall, is it safe to put it back on the SAS 6i/R Internal Controller RAID PCIe? Also reinstall with a multithreaded base instead of single?

Or should I leave it connected without raid 1 directly to the motherboard sata ports?

edit: I assume the snapshot is also available as an iso? pfSense-20081105-1030.iso.gz ?

AudiAddict

Still no hdr messages in the logs!! So far so good!! Thanks a bunch guys!!

I'm still running on in " safe mode" though, meaning, I'm not using the SAS raid controller or the multithreaded base OS.

Not sure If I should reinstall with multithreaded os and raid controller.

plunger

hey AudiAddict,

any new developments over the weekend? we were getting ready to pull the trigger on a pair of R200s w/ the SAS6iR controllers and the onboard nics specifically for pfsense. it sounds like you've come to some resolution but i didn't know if you were out of "safe mode" yet and whether or not you're on the road a dell/pfsense utopia, etc.

just curious,

-dp

AudiAddict

Hey Plunger,

Right now I'm running stable on non raid R200 onboard Sata with 1.2.1RC .

With the following settings :

One 7200RPM Disk (Western Digital 160GB)
Directly connected to SATA Port 1
Install done with external DVD burner (dvd drive in the r200 didn't work properly)
Intel VT turned off in bios
Xeon 2.0GHZ cpu with 2 cores enabled in bios
Running SINGLE threaded and not multithreaded Pfsense install

This seems to be rock stable, will try the sas 6ir raid 1 setup + multithreaded pfsense version this weekend.

I'm indeed a dell guru ;-) I manage about 70 dell servers 8)

olejak

Hi AudiAddict,

Have you tried the multithreaded pfSense install yet?

AudiAddict

I'm running on a Singlethreaded OS, which is running perfect for 7 days now.

I've done a major DDOS on it and it had no problems taking that on singlethreaded. So i'm going to leave it for now.

I've been to the datacenter and reinstalled too often to try another trial of multithreaded etc etc.