https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068
--- Comment #8 from joss.up...@yahoo.com ---
(In reply to Konstantin Belousov from comment #7)
Not sure why you can't reproduce, but I'm doing the equivalent of the shell
script below. Note the ",usr" and the lowercase p.
On a 4 core mac
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #13 from g_amana...@yahoo.com ---
Created attachment 166886
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166886&action=edit
tcpdump.txt
I did a tcpdump while an android client tries to access a webpage
(www.gutefrag
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #12 from g_amana...@yahoo.com ---
I did some thorough testing with a simplified IPFW ruleset (only in-kernel NAT
enabled and allow everything on the local and WAN interfaces). Enabling
"net.inet.ip.fastforwarding" in kernels befo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #11 from g_amana...@yahoo.com ---
I tried with IPSEC_NAT_T and VIMAGE disabled and it doesn't resolve it.
--
You are receiving this mail because:
You are on the CC list for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #10 from g_amana...@yahoo.com ---
Created attachment 166885
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166885&action=edit
netstat.txt
Output of "netstat -s" attached.
In the local network the problem concerns prim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #9 from George V. Neville-Neil ---
Can you try this without VIMAGE, and then possibly without IPSEC_NAT_T and tell
me if the problem persists? Also, can you share the output of netstat -s for
all protocols including tcp, esp, a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087
--- Comment #8 from g_amana...@yahoo.com ---
Kernels before this commit (e.g. r295264) with "net.inet.ip.fastforwarding=1"
do not exhibit this symptoms.
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068
--- Comment #7 from Konstantin Belousov ---
(In reply to joss.upton from comment #6)
I believe that the behaviour of reading MSR 0xc1 is architectural ? Anyway, on
sandybridge:
sandy% sudo cpucontrol -m 0xc1=0x8000 /dev/cpuctl0
sandy%
