Re[2]: pf reply-to malfunction after r258468 (seems r258479)

From: Vladimir Sharun <atz_at_ukr.net>
Date: Tue, 03 Dec 2013 19:54:08 +0200

('binary' encoding is not supported, stored as-is) Dear Gleb, Unfortunately can't boot both revisions kernel, it hangs on "trying to mount root from ssdzfs"  (which is my zfs root). 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. Received on Tue Dec 03 2013 - 16:54:16 UTC