I was testing my pf.conf rules, and I ran across something rather odd
while sending odd ICMP frames. I wrote a quick app to send raw
ICMP/UDP/TCP frames, and ran it from an OSX box to send raw ICMP.
I ran simultaneous tcpdumps on the OSX box sending the frame, the
OpenBSD (-stable, as of a couple of weeks ago) box le0 receiving the
frame, and pflog0.
On OSX (which includes the link-level in -xxx:
...ethertype IPv4
(0x0800), length 38: IP (tos 0x0, ttl 255, id 24192, offset 0, flags
[none],
length: 24) 192.168.1.9 > 192.168.1.1: [|icmp]
0x0000: 0800 2077 a479 000a 9579 cb8a 0800 4500
...w.y...y....E.
0x0010: 0018 5e80 0000 ff01 da09 c0a8 0109 c0a8
..^.............
0x0020: 0101 0800 f7ff ......
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?
Moreover, on pflog0:
Mar 08 20:04:23.030298 rule 4294967295/3(short): pass in on le0:
192.168.1.9 >
192.168.1.1: [|icmp] (ttl 255, id 24192)
4500 0018 5e80 0000 ff01 da09 c0a8 0109
c0a8 0101 0800 f7ff
The only reference I could find to matching that rule (4294967295 ==
0xffffffff) was in reference to a patch fixing a problem with backing
out of anchors. I have no anchors.
ICMP frames with 4 bytes of payload don't do this, and match their
appropriate rule. Any idea what's going on? UDP and TCP with no
payload don't do this, just ICMP. Is the frame being reported properly
-- that is, is it actually being passed, or is it being dropped but
being reported as a pass?
Thanks,
JMF
