> To: misc@openbsd.org > Subject: Re: pflog0, ICMP rule 4294967295/3(short)
John L. Scarfone wrote: > On Wed, Mar 09, 2005 at 07:42:16PM -0500, Jim Fron said: >> John L. Scarfone wrote: >> > On Tue, Mar 08, 2005 at 08:49:18PM -0500, Jim Fron mentioned: >> >> OpenBSD on le0: >> >> ...0800 60: >> >> 192.168.1.9 > 192.168.1.1: icmp: echo request (id:5555 seq:21845) >> >> (ttl 255, id 24192) >> >> 4500 0018 5e80 0000 ff01 da09 c0a8 0109 >> >> c0a8 0101 0800 f7ff 5555 5555 5555 5555 >> >> 5555 5555 5555 5555 5555 5555 5555 >> >> tcpdump sees extra 0x55's? Is this reading past the short message >> >> into init'ed memory? >> >> > Looks like OSX is incorrectly padding your short frame with non-nulls. >> >> Padding it, and then failing to report it in its own tcpdump, and >> OpenBSD subsequently removes the padding AFTER tcpdump on le0 sees it, >> but before tcpdump on pflog0 sees it? I _suppose_ that's possible. >> I'd need a machine that was neither OpenBSD nor OSX -- or an >> oscilloscope -- to test that theory. > Padding is required because your frame is below the Ethernet minimum but > the requirement is for null padding, not anything else. Okay, so it's padding with crap. I'll go along with "it's OSX f'ing up," as that's easy to believe. Makes perfect sense, as that's padded to 46 bytes of data (ethernet minimum). I guess OBSD would fail to show the padding if it were actually 0's. rather than 0x55's. (?) > The OSX dump is showing it to you before the padding is done > (before it's on the wire). Also the dumps of le0 and pflog0 have > different link types. There's no Ethernet info in the pflog0 dump. True, okay. > Hopefully I resolved the inconsistency. Yes, thank you. > If I send malformed (short) ICMP, > TCP, or UDP out of a 3.6 box I get the same behavior, they're being blocked. > Stuff like: > rule 4294967295/3(short): pass out on bge0: 192.168.1.63 > 192.168.1.4: > icmp: echo request > rule 4294967295/3(short): pass out on bge0: [|udp] > rule 4294967295/3(short): pass out on bge0: truncated-tcp That's what threw me, I guess. I can't do that. When I try to send short TCP and UDP (from either OSX or OBSD 3.6), they aren't being logged. Only the short ICMP show up. >> I'm willing to accept that the short frames are "passed" for some >> reason, perhaps for the ability to detect just this sort of bad >> traffic. I'm willing to accept that they'll flood pflog. I >> guess I'm just expecting someone to tell me "that's perfectly >> normal behavior, by design." I wouldn't be surprised. >> Disgruntled, perhaps, but not surprised. > They're not being passed. They come in on le0 because they're on > the wire and that's what a tcpdump there shows. pf will not pass > them though. Hmm, if that's true, perhaps it oughtn't say "pass" when it logs them, then? I don't have a problem with them being logged against rule 0xffffffff, either, just it'd have been nice if the PF documentation would have noted that would happen. That is, while pflogd (8) indicates that short packets will be logged (by listing it as a logging option, under the assumption that "all" options are default, it would have helped if it had indicated that the rule for such packets would be undefined (-1). >> How about this question, then: presuming this is all 100% >> expected, is there any way to prevent these from being logged? > Not that I know of but they're being blocked and I tend to log > blocked things anyway. If I log everything I block, I fill /var. But I'll answer my own question: pflogd reason match Also pflogd (8) Also accepts "bad-offset", "fragment", "bad-timestamp", "short", "normalize" and "memory". I guess my only question, then, would be what options to use to specify multiple "reasons"? `pflogd reason match reason normalize` JMF
