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

>> 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.
> The whole point of my questions is that the RST _is_ critical to this
> particular host.  Without it, the SYN-ACK is not recognized, the dump
> indicates apparently random sequence numbers, and the connection
> eventually times out.

> Another capture with the SYN retransmissons:
>     1   0.000000 82.65.226.80 â?? 90.102.115.81 TCP 74 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=1 TSecr=0
>     2   0.031213 90.102.115.81 â?? 82.65.226.80 TCP 62 443 â?? 53505 [ACK] Seq=1 Ack=2722589159 Win=16384 Len=0
>     3   5.990620 82.65.226.80 â?? 90.102.115.81 TCP 74 [TCP Retransmission] 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=13 TSecr=0
>     4   6.022537 90.102.115.81 â?? 82.65.226.80 TCP 62 [TCP ACKed unseen segment] [TCP Retransmission] [TCP Port numbers reused] 443 â?? 53505 [SYN, ACK] Seq=3330557921 Ack=1758179783 Win=16384 Len=0 MSS=1460
>     5  17.990532 82.65.226.80 â?? 90.102.115.81 TCP 74 [TCP Retransmission] 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=37 TSecr=0
>     6  18.022124 90.102.115.81 â?? 82.65.226.80 TCP 62 [TCP Previous segment not captured] [TCP Port numbers reused] 443 â?? 53505 [SYN, ACK] Seq=354568170 Ack=1 Win=16384 Len=0 MSS=1460
>     7  41.990326 82.65.226.80 â?? 90.102.115.81 TCP 74 [TCP Retransmission] 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=85 TSecr=0
>     8  42.020440 90.102.115.81 â?? 82.65.226.80 TCP 62 [TCP Retransmission] [TCP Port numbers reused] 443 â?? 53505 [SYN, ACK] Seq=3720531063 Ack=1 Win=16384 Len=0 MSS=1460

> This capture does not make sense to me at all.

Me neither.  I obviously didn't read the trace in enough detail; my
apologies.

>     1   0.000000 82.65.226.80 â?? 90.102.115.81 TCP 74 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=1 TSecr=0

Ordinary initial SYN.  Your end is now SYN-SENT.

>     2   0.031213 90.102.115.81 â?? 82.65.226.80 TCP 62 443 â?? 53505 [ACK] Seq=1 Ack=2722589159 Win=16384 Len=0

ACK with no SYN.  As I read 9293, since it's out of window, this should
draw an RST.  But that particular RST must not be necessary for correct
operation, since it could be lost by the network.

>     3   5.990620 82.65.226.80 â?? 90.102.115.81 TCP 74 [TCP Retransmission] 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=13 TSecr=0

You retransmit your SYN.

>     4   6.022537 90.102.115.81 â?? 82.65.226.80 TCP 62 [TCP ACKed unseen segment] [TCP Retransmission] [TCP Port numbers reused] 443 â?? 53505 [SYN, ACK] Seq=3330557921 Ack=1758179783 Win=16384 Len=0 MSS=1460

The peer sends another SYN-ACK, but it's also out-of-window.  This too
should draw an RST.  Again, it could be lost, but for such packets to
be _consistently_ lost is implausible.  But...

>     5  17.990532 82.65.226.80 â?? 90.102.115.81 TCP 74 [TCP Retransmission] 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=37 TSecr=0

You retransmit again.

>     6  18.022124 90.102.115.81 â?? 82.65.226.80 TCP 62 [TCP Previous segment not captured] [TCP Port numbers reused] 443 â?? 53505 [SYN, ACK] Seq=354568170 Ack=1 Win=16384 Len=0 MSS=1460

...finally, a reasonable SYN-ACK.  It looks to me as though your end
should have sent an ACK packet and transitioned from SYN-SENT to
ESTABLISHED.

>     7  41.990326 82.65.226.80 â?? 90.102.115.81 TCP 74 [TCP Retransmission] 53505 â?? 443 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=8 SACK_PERM=1 TSval=85 TSecr=0

??  It looks to me as though your firewalling ate either packet 6 (the
SYN-ACK) or the ACK that should have resulted.

>     8  42.020440 90.102.115.81 â?? 82.65.226.80 TCP 62 [TCP Retransmission] [TCP Port numbers reused] 443 â?? 53505 [SYN, ACK] Seq=3720531063 Ack=1 Win=16384 Len=0 MSS=1460

Again, the peer responds with a valid SYN-ACK.  Again, your end should
have generated an ACK and gone to ESTABLISHED.

The peer behaviour looks odd, yes.  But from a network-behaviour point
of view, your end is not conforming to the spec, failing to send RSTs
in response to out-of-window packets and failing to send a third
handshake packet in response to an acceptable SYN-ACK.  Since the peer
eventually does send a valid SYN-ACK, it looks to me as though it's the
latter failure that's ultimately breaking interoperation.

/~\ 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