pf reply-to malfunction after r258468 (seems r258479)

[Gleb Smirnoff]

  Vladimir,

On Tue, Dec 03, 2013 at 11:52:26AM +0200, Vladimir Sharun wrote:
V> I have a test setup with direct internet connection Reail_IP_A and netgraph tunnel with Real_IP_B. 
V> I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if 
V> it came via tunnel: 
V> 
V> pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ 
V> proto tcp from any to Real_IP_B port 443 
V> 
V> And it works at least in r258468. After harware change/reboot yesterday I got strange performance 
V> via netgraph tunnel. Investigation shows clear: this is not tunnel itself, because endpoint can 
V> saturate wire speed, but when we run routable schema we got very low throughput. Deeper analyzing 
V> shows packet duplication from reply-to, looks like that: 
V> 09:36:59.576405 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 
V> 09:36:59.576413 IP Real_IP_B.443 > Testbed.43775: Flags [.], seq 523587:525035, ack 850, win 1040, options [nop,nop,TS val 3415853201 ecr 44833816], length 1448 
V> 09:36:59.577583 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 
V> 09:36:59.577713 IP Testbed.43775 > Real_IP_B.443: Flags [.], ack 525035, win 1040, options [nop,nop,TS val 44834046 ecr 3415853201], length 0 

I doubt that r258479 can cause a regression in reply-to.

Can you please test r258478 and r258479 and confirm or decline that?

-- 
Totus tuus, Glebius.