Re: NPF (mis?)behaviour vs. distant site (mis?)behaviour ...

>> I've never seen this myself.  But I'd hazard a guess that
>> 90.102.115.81 - or, in that particular case, perhaps more likely
>> some kind of firewall in front of it - is trying to do OS
>> fingerprinting of the connection-initiating host.
> Well, this does not happen 100% of the time.  So that would be a bit
> weird, and not really compliant, no?

A bit weird, yes.  Compliant?  I'm not sure compliance has anything to
say about it.  I don't think anything says that a host MUST NOT send
out-of-window packets; if nothing else, that would be violated by a
host sending to a stale connection after a peer reboot.

>> I'd further guess that it's getting eaten because your "stateful" is
>> causing npf to pass only packets that make sense as traffic
>> belonging to an interior-established connection (and that ACK
>> doesn't belong).
> Yes, makes sense.  But then the RST never happen, which is an issue,
> no?

Yes.  Most firewalling breaks the assumptions underlying IP networking.
It breaks various protocols to various extents; that so few break is a
testament to their robustness.  (And, of course, in some cases breaking
them is the whole point.  If firewalling doesn't break _something_ it's
not doing anything.)

And, while I didn't go back to check, as I recall, that RST is
apparently not critical to your connection - I think your traces showed
the connection being established apparently fine in either case.

> Shouldn't the ACK be considered as part of the SYN_SENT connection,
> and later detected as invalid, so that it can be RST?

It's out-of-window.  An RST is the correct response from a TCP spec
point of view.  The firewalling you have enabled appears to disagree; I
didn't design or write it, so I'm not comptent to speak to its choices.

> I noticed that in the SYN_RECEIVE case, a bare ack reply is
> considered OK (with an XXX comment "ACK of late SYN in simultaneous
> case?").

Well, don't forget that a "bare ack" is not the whole story.  A bare
ack can be in-window or out-of-window, and I expect (but have not
checked) that the behaviour prescribed by the TCP specs differ.

>> Remember, tcpdump - and bpf captures in general - normally take
>> place _outside_ any firewalling done on the capturing host.  [...]
> I did the tcpdump on the "npflog0" interface, logging either passed
> or blocked packets, to track down NPF behaviour.

Okay, that's well beyond my knowledge of NPF.  I've never even so much
as used it as far as I can recall.  I should probably bow out of the
conversation at this point, as it looks as though I've reached the
limits of my relevant knowledge.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B