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

2013-12-04 Thread Vladimir Sharun
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: pf reply-to malfunction after r258468 (seems r258479)

2013-12-04 Thread Gleb Smirnoff
On Wed, Dec 04, 2013 at 10:14:09AM +0200, Vladimir Sharun wrote:
V Dear Gleb, 
V Yesterday I (finally) got my server back to work and the problem disappear. 
Can't reproduce it anymore on r258865. 

That is strange.

Ok, let's count issue as resolved if it doesn't show up again.

-- 
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


pf reply-to malfunction after r258468 (seems r258479)

2013-12-03 Thread Vladimir Sharun
I have a test setup with direct internet connection Reail_IP_A and netgraph 
tunnel with Real_IP_B. I have used a reply-to pf ruleset to sent all the 
traffic back via tunnel, if it came via tunnel: pass in quick on $tunnel_if 
reply-to ($tunnel_if 10.1.0.1) \ proto tcp from any to Real_IP_B port 443 And 
it works at least in r258468. After harware change/reboot yesterday I got 
strange performance via netgraph tunnel. Investigation shows clear: this is not 
tunnel itself, because endpoint can saturate wire speed, but when we run 
routable schema we got very low throughput. Deeper analyzing shows packet 
duplication from reply-to, looks like that: 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 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 09:36:59.577583 
IP Testbed.4
 3775  Real_IP_B.443: Flags [.], ack 525035, win 1018, options [nop,nop,TS val 
44834046 ecr 3415853201], length 0 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 
___
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


pf reply-to malfunction after r258468 (seems r258479)

2013-12-03 Thread Vladimir Sharun
I have a test setup with direct internet connection Reail_IP_A and netgraph 
tunnel with Real_IP_B. 
I have used a reply-to pf ruleset to sent all the traffic back via tunnel, if 
it came via tunnel: 

pass in quick on $tunnel_if reply-to ($tunnel_if 10.1.0.1) \ 
proto tcp from any to Real_IP_B port 443 

And it works at least in r258468. After harware change/reboot yesterday I got 
strange performance 
via netgraph tunnel. Investigation shows clear: this is not tunnel itself, 
because endpoint can 
saturate wire speed, but when we run routable schema we got very low 
throughput. Deeper analyzing 
shows packet duplication from reply-to, looks like that: 
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 
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 
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 
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 

___
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: pf reply-to malfunction after r258468 (seems r258479)

2013-12-03 Thread 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.
___
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)

2013-12-03 Thread Vladimir Sharun
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: pf reply-to malfunction after r258468 (seems r258479)

2013-12-03 Thread Gleb Smirnoff
On Tue, Dec 03, 2013 at 02:09:14PM +0200, Vladimir Sharun wrote:
V Dear Gleb, 
V Is kernel rebuilding enuff ? 

Should be enough wrt pf(4), no API or ABI changes in it.

-- 
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


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

2013-12-03 Thread Vladimir Sharun
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

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

2013-12-03 Thread Gleb Smirnoff
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