Re[2]: pf reply-to malfunction after r258468 (seems r258479)
Dear Gleb, Yesterday I (finally) got my server back to work and the problem disappear. Can't reproduce it anymore on r258865. On Tue, Dec 03, 2013 at 07:54:08PM +0200, Vladimir Sharun wrote: V Dear Gleb, V Unfortunately can't boot both revisions kernel, it hangs on trying to mount root from ssdzfs (which is my zfs root). V Vladimir, You can run the kernel that boots, but update only sys/netpfil/pf directory to suspected revision(s), if you think this is related to changes in pf. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re[2]: pf reply-to malfunction after r258468 (seems r258479)
Dear Gleb, Is kernel rebuilding enuff ? 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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re[2]: pf reply-to malfunction after r258468 (seems r258479)
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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org