Re: tor inside vmm, horribly slow?!

2018-02-14 Thread Thomas Weinbrenner 


> Am 14.02.2018 um 02:09 schrieb Chris Cappuccio :
> 
> Revert uipc_socket.c rev 1.90. Does tor work properly again?

Because of https://marc.info/?l=openbsd-ports=151855574502582
I tried a newer snapshot and now tor works properly again.


signature.asc
Description: Message signed with OpenPGP

Re: tor inside vmm, horribly slow?!

2018-02-13 Thread Chris Cappuccio 
Oops, actually uipc_socket2.c

Re: tor inside vmm, horribly slow?!

2018-02-13 Thread Chris Cappuccio 
Revert uipc_socket.c rev 1.90. Does tor work properly again?

Thomas Weinbrenner [m...@tweinbrenner.net] wrote:
> 
> 
> > Am 12.02.2018 um 00:38 schrieb Jiri B :
> > 
> > Hi,
> > 
> > has anybody tried to run tor inside vmm guest?
> > 
> > it's horrible slow, just doing 'tor-resolve $dnsname' takes
> > sometimes ages.
> 
> Perhaps this has nothing to do with vmm.
> 
> I am not a computer expert, just a normal user (so please don't ask me
> to difficult questions), but I run tor on my computer at home (so it's
> real hardware and no vmm).
> 
> Since upgrading OpenBSD from
> 
> | OpenBSD 6.2-current (GENERIC.MP) #399: Fri Feb  2 18:28:58 MST 2018
> |dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> to
> 
> | OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018
> |dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> my tor server also has problems.
> 
> 
> /var/log/daemon:
> | Feb 11 20:15:50 server Tor[54286]: Your system clock just jumped 115 
> seconds forward; assuming established circuits no longer work.
> | Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. 
> Looks like client functionality is working.
> | Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. 
> Looks like client functionality is working.
> | Feb 11 20:24:43 server Tor[54286]: Your system clock just jumped 299 
> seconds forward; assuming established circuits no longer work.
> | Feb 11 20:26:24 server Tor[54286]: tor_assertion_failed_: Bug: 
> src/or/channel.c:1503: channel_closed: Assertion CHANNEL_CONDEMNED(chan) 
> failed; aborting. (on Tor 0.3.2.9 9e8b762fcecfece6)
> | Feb 11 20:26:24 server Tor[54286]: Bug: Assertion CHANNEL_CONDEMNED(chan) 
> failed in channel_closed at src/or/channel.c:1503. (Stack trace not 
> available) (on Tor 0.3.2.9 9e8b762fcecfece6)
> 
> dmesg:
> 
> OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8351621120 (7964MB)
> avail mem = 8091496448 (7716MB)
> enter_shared_special_pages: entered idt page va 0x8001 pa 
> 0x1d5c000
> enter_shared_special_pages: entered kutext page va 0x81833000 pa 
> 0x1833000
> enter_shared_special_pages: entered kutext page va 0x81834000 pa 
> 0x1834000
> enter_shared_special_pages: entered kutext page va 0x81835000 pa 
> 0x1835000
> enter_shared_special_pages: entered kudata page va 0x81acb000 pa 
> 0x1acb000
> cpu_enter_pages: entered tss+gdt page at va 0x81aa2000 pa 0x1aa2000
> cpu_enter_pages: entered t.stack page at va 0x81aa3000 pa 0x1aa3000
> cpu_enter_pages: cif_tss.tss_rsp0 = 0x81aa33e0
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedc10 (87 entries)
> bios0: vendor LENOVO version "FBKTCQAUS" date 12/16/2017
> bios0: LENOVO ThinkServer TS140
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP APIC FPDT FIDT TCPA DBGP LUFT SSDT SSDT MCFG
> HPET SSDT SSDT ASF! DMAR EINJ ERST HEST BERT BGRT
> acpi0: wakeup devices UAR1(S0) PXSX(S0) RP01(S0) PXSX(S0) PXSX(S0)
> PXSX(S0) RP04(S0) PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) GLAN(S0)
> EHC1(S0) EHC2(S0) XHC_(S0) HDEF(S0) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> lapic_map: entered lapic page va 0x81aa6000 pa 0xfee0
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3492.47 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> acpitimer0: recalibrated TSC frequency 3292379149 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
> cpu1 at mainbus0cpu_enter_pages: entered tss+gdt page at va
> 0x80002200 pa 0x10f184000
> cpu_enter_pages: entered t.stack page at va 0x800022001000 pa 0x10f185000
> cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220013e0
> : apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3491.92 MHz
> cpu1:
>

Re: tor inside vmm, horribly slow?!

2018-02-12 Thread Thomas Weinbrenner 


> Am 12.02.2018 um 00:38 schrieb Jiri B :
> 
> Hi,
> 
> has anybody tried to run tor inside vmm guest?
> 
> it's horrible slow, just doing 'tor-resolve $dnsname' takes
> sometimes ages.

Perhaps this has nothing to do with vmm.

I am not a computer expert, just a normal user (so please don't ask me
to difficult questions), but I run tor on my computer at home (so it's
real hardware and no vmm).

Since upgrading OpenBSD from

| OpenBSD 6.2-current (GENERIC.MP) #399: Fri Feb  2 18:28:58 MST 2018
|dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

to

| OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018
|dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

my tor server also has problems.


/var/log/daemon:
| Feb 11 20:15:50 server Tor[54286]: Your system clock just jumped 115 seconds 
forward; assuming established circuits no longer work.
| Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. 
Looks like client functionality is working.
| Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. 
Looks like client functionality is working.
| Feb 11 20:24:43 server Tor[54286]: Your system clock just jumped 299 seconds 
forward; assuming established circuits no longer work.
| Feb 11 20:26:24 server Tor[54286]: tor_assertion_failed_: Bug: 
src/or/channel.c:1503: channel_closed: Assertion CHANNEL_CONDEMNED(chan) 
failed; aborting. (on Tor 0.3.2.9 9e8b762fcecfece6)
| Feb 11 20:26:24 server Tor[54286]: Bug: Assertion CHANNEL_CONDEMNED(chan) 
failed in channel_closed at src/or/channel.c:1503. (Stack trace not available) 
(on Tor 0.3.2.9 9e8b762fcecfece6)

dmesg:

OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8351621120 (7964MB)
avail mem = 8091496448 (7716MB)
enter_shared_special_pages: entered idt page va 0x8001 pa 0x1d5c000
enter_shared_special_pages: entered kutext page va 0x81833000 pa 
0x1833000
enter_shared_special_pages: entered kutext page va 0x81834000 pa 
0x1834000
enter_shared_special_pages: entered kutext page va 0x81835000 pa 
0x1835000
enter_shared_special_pages: entered kudata page va 0x81acb000 pa 
0x1acb000
cpu_enter_pages: entered tss+gdt page at va 0x81aa2000 pa 0x1aa2000
cpu_enter_pages: entered t.stack page at va 0x81aa3000 pa 0x1aa3000
cpu_enter_pages: cif_tss.tss_rsp0 = 0x81aa33e0
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedc10 (87 entries)
bios0: vendor LENOVO version "FBKTCQAUS" date 12/16/2017
bios0: LENOVO ThinkServer TS140
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC FPDT FIDT TCPA DBGP LUFT SSDT SSDT MCFG
HPET SSDT SSDT ASF! DMAR EINJ ERST HEST BERT BGRT
acpi0: wakeup devices UAR1(S0) PXSX(S0) RP01(S0) PXSX(S0) PXSX(S0)
PXSX(S0) RP04(S0) PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) GLAN(S0)
EHC1(S0) EHC2(S0) XHC_(S0) HDEF(S0) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
lapic_map: entered lapic page va 0x81aa6000 pa 0xfee0
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3492.47 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpitimer0: recalibrated TSC frequency 3292379149 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0cpu_enter_pages: entered tss+gdt page at va
0x80002200 pa 0x10f184000
cpu_enter_pages: entered t.stack page at va 0x800022001000 pa 0x10f185000
cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220013e0
: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3491.92 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0cpu_enter_pages: entered tss+gdt page at va
0x800022011000 pa 0x10f18f000
cpu_enter_pages: entered t.stack page at va 0x800022012000 pa 0x10f19
cpu_enter_pages: cif_tss.tss_rsp0 =

Re: tor inside vmm, horribly slow?!

2018-02-12 Thread Jiri B 
On Mon, Feb 12, 2018 at 12:38:00AM -0800, Mike Larkin wrote:
> > > > it's horrible slow, just doing 'tor-resolve $dnsname' takes
> > > > sometimes ages.
> > > > [...]
> [...]
>
> What did the guest pick for timecounter? (sysctl kern.timecounter.hardware)
> 
> Your hardware is nearly a decade old. I wouldn't be surprised if vmm
> picked some ancient timecounter hardware. For the example below, my guest
> chose 'tsc' (I have a 2013-era Ivy Bridge CPU). All my hosts/VMs are
> -current. And we know if your hardware is shit, we do the best we can but
> no promises as to how precise time is going to be. With tsc timecounter,
> my VMs that have been up for weeks have drifted maybe a second or two from
> the host.
> 
> [...]
>
> In other words, I don't see anything odd here. The vm appears to actually
> be running faster than the host. I'm not concerned about the 2-3 second
> difference on the first resolve. I bet if I ran it a hundred times I'd see
> things pretty much the same.

Mike, thank you for your time. The VM picked 'tsc' as timecounter.

Putting CC Pascal, Tor port maintainer, as I am suspicious that this slowness
is related to what tor itself is doing in that time.

Pascal, any idea what could cause slowness of tor when using onion service
inside VMM? Info below (plus history 
https://marc.info/?l=openbsd-misc=151839235419514=2):

Feb 12 10:30:25 onion Tor[96278]: connection_connect_sockaddr: Connection to 
socket established (sock 4).
Feb 12 10:32:55 onion Tor[96278]: connection_edge_reached_eof: conn (fd 4) 
reached eof. Closing.
Feb 12 10:32:55 onion Tor[96278]: Your system clock just jumped 151 seconds 
forward; assuming established circuits no longer work.
^^^ 2 mins gap?

Tor tests, if this is general issue or not.

- scenario 1

* loop date + tor-resolve $dnsname + sleep 1
* torsocks curl -s -I http://www.openbsd.org

^^  this works ok

- scenario 2

make tor to have local onion service with httpd enabled

* install -d -o _tor -g _tor -m 700 /var/tor/onion

* modify /etc/tor/torrc:

Log debug syslog
HiddenServiceDir /var/tor/onion/
HiddenServicePort 80 127.0.0.1:80

* enable httpd & tor
* loop date + tor-resolve $dnsname + sleep 1
* get your .onion service address

cat /var/tor/onion/hostname

* access your .onion service from other (tor)browser

...
Feb 12 10:30:24.519 [warn] Got SOCKS5 status response '4': host is unreachable
Mon Feb 12 10:30:26 CET 2018
129.128.5.194
Mon Feb 12 10:32:58 CET 2018
129.128.5.194
Mon Feb 12 10:33:00 CET 2018
...

^^ tor-resolve $dnsnanme gets slow downed in a while, 2 mins gap

Feb 12 10:30:24 onion Tor[96278]: rend_service_rendezvous_has_opened: Done 
building circuit 2327426966 to rendezvous with cookie D92E6387 for service 

Feb 12 10:30:24 onion Tor[96278]: internal circ (length 4): 
$0FBE018DADAB416DE17A10C5D4AD3EBF0E243561(open) 
$BF50E09EED25B82861CF95E1AAA42DCFEF53E5D1(open) 
$F80FDE27EFCB3F6A7B4E2CC517133DBFFA78BA2D(open) 
$CCF0E904BAD135F6B2180BD89D19E487F83786A5(open)
Feb 12 10:30:24 onion Tor[96278]: connection_handle_listener_read: New SOCKS 
connection opened from 127.0.0.1.
Feb 12 10:30:24 onion Tor[96278]: rep_hist_note_used_port: New port prediction 
added. Will continue predictive circ building for 1967 more seconds.
Feb 12 10:30:24 onion Tor[96278]: connection_edge_process_inbuf: data from edge 
while in 'waiting for circuit' state. Leaving it on buffer.
Feb 12 10:30:24 onion Tor[96278]: exit circ (length 3): 
$0FBE018DADAB416DE17A10C5D4AD3EBF0E243561(open) 
$594252BFEE13625AC120F50F3015CB3C1DA55690(open) 
$1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA(open)
Feb 12 10:30:24 onion Tor[96278]: pathbias_count_use_attempt: Used circuit 2 is 
already in path state use succeeded. Circuit is a General-purpose client 
currently open.
Feb 12 10:30:24 onion Tor[96278]: link_apconn_to_circ: Looks like completed 
circuit to [scrubbed] does allow optimistic data for connection to [scrubbed]
Feb 12 10:30:24 onion Tor[96278]: connection_ap_handshake_send_resolve: Address 
sent for resolve, ap socket 4, n_circ_id 2260876578
Feb 12 10:30:25 onion Tor[96278]: connection_connect_sockaddr: Connection to 
socket established (sock 4).
Feb 12 10:32:55 onion Tor[96278]: connection_edge_reached_eof: conn (fd 4) 
reached eof. Closing.
Feb 12 10:32:55 onion Tor[96278]: Your system clock just jumped 151 seconds 
forward; assuming established circuits no longer work.

^^ 2 mins gap

So just slow HW issue?

Jiri

Re: tor inside vmm, horribly slow?!

2018-02-12 Thread Mike Larkin 
On Mon, Feb 12, 2018 at 03:07:31AM -0500, Jiri B wrote:
> On Sun, Feb 11, 2018 at 04:47:02PM -0800, Mike Larkin wrote:
> > > has anybody tried to run tor inside vmm guest?
> > > 
> > > it's horrible slow, just doing 'tor-resolve $dnsname' takes
> > > sometimes ages.
> > > [...]
> > > is it related to vmm ssl issue reported in the past?
> > 
> > no
> > 
> > > [...]
> > This report sucks. no dmesg, no information about what the VM config is, 
> > what
> > version the guest is, what version the host is, etc.
> 
> Big apologize, I thought it could be something known.
> Info below. Thank you for help.
> 
> Jiri
> 

What did the guest pick for timecounter? (sysctl kern.timecounter.hardware)

Your hardware is nearly a decade old. I wouldn't be surprised if vmm
picked some ancient timecounter hardware. For the example below, my guest
chose 'tsc' (I have a 2013-era Ivy Bridge CPU). All my hosts/VMs are
-current. And we know if your hardware is shit, we do the best we can but
no promises as to how precise time is going to be. With tsc timecounter,
my VMs that have been up for weeks have drifted maybe a second or two from
the host.

In any case, in my amd64 VM, the first time I do your command I see this:

 time tor-resolve www.openbsd.org 
129.128.5.194
0m20.30s real 0m00.00s user 0m00.00s system

And the second time:

time tor-resolve www.openbsd.org 
129.128.5.194
0m00.20s real 0m00.00s user 0m00.00s system




Now, on the host, the first time:

 time tor-resolve www.openbsd.org
129.128.5.194
0m17.54s real 0m00.00s user 0m00.01s system

And the second time on the host:

 time tor-resolve www.openbsd.org 
129.128.5.194
0m00.54s real 0m00.00s user 0m00.02s system

In other words, I don't see anything odd here. The vm appears to actually
be running faster than the host. I'm not concerned about the 2-3 second
difference on the first resolve. I bet if I ran it a hundred times I'd see
things pretty much the same.

-ml

> Another try inside vmm guest:
> ~
> 
> # time tor-resolve www.openbsd.org
> 129.128.5.194
> 0m00.14s real 0m00.00s user 0m00.00s system
> # time tor-resolve www.openbsd.org
> 129.128.5.194
> 0m52.96s real 0m00.00s user 0m00.00s system
> 
> # tail /var/log/daemon
> Feb 12 08:19:59 onion Tor[21861]: Bootstrapped 100%: Done
> Feb 12 08:20:04 onion ntpd[51629]: adjusting local clock by 0.384653s
> Feb 12 08:23:01 onion ntpd[51629]: adjusting local clock by -0.063873s
> Feb 12 08:42:58 onion Tor[21861]: Your system clock just jumped 150 seconds 
> forward; assuming established circuits no longer work.
> Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit. 
> Looks like client functionality is working.
> Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit. 
> Looks like client functionality is working.
> Feb 12 08:45:55 onion Tor[21861]: Your system clock just jumped 150 seconds 
> forward; assuming established circuits no longer work.
> Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit. 
> Looks like client functionality is working.
> Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit. 
> Looks like client functionality is working.
> Feb 12 08:47:05 onion ntpd[51629]: adjusting clock frequency by -7.934969 to 
> -23.542969ppm
> 
> VMM:
> 
> 
> (Originally I forgot 'group internal' in vm.conf, so I put tap1 into group
> 'internal' manually via ifconfig.)
> 
> vm "onion" {
> disable
> owner jirib
> memory 512M
> boot $kernel
> local interface tap
> disk $onion_osdisk
> disk $onion_datadisk
> }
> 
> Networking on host:
> ~~~
> 
> # route -nv show -inet | grep ^default
> default176.74.xxx.xxx UGS538658 - 8 em0   
> "internet4"
> 
> # sysctl net.inet.ip.forwarding   
>   
> 
> net.inet.ip.forwarding=1
> 
> em0: flags=8843 mtu 1500
> lladdr 90:e2:ba:xx:xx:xx
> index 1 priority 0 llprio 3
> groups: public egress
> media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
> status: active
> inet 176.74.xxx netmask 0xffe0 broadcast 176.74.xxx
> 
> tap1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d2:f7:28
> description: vm2-if0-onion
> index 17 priority 0 llprio 3
> groups: tap internal
> status: active
> inet 100.64.2.2 netmask 0xfffe
> 
> PF on host (uses 'group internal'):
> ~~~
> 
> # pfctl -sr | egrep '(on egress.*nat-to|on internal.*all)'
> pass out quick on egress from any to route "internet4" flags S/SA nat-to 
> (egress) round-robin
>

Re: tor inside vmm, horribly slow?!

2018-02-12 Thread Jiri B 
On Sun, Feb 11, 2018 at 04:47:02PM -0800, Mike Larkin wrote:
> > has anybody tried to run tor inside vmm guest?
> > 
> > it's horrible slow, just doing 'tor-resolve $dnsname' takes
> > sometimes ages.
> > [...]
> > is it related to vmm ssl issue reported in the past?
> 
> no
> 
> > [...]
> This report sucks. no dmesg, no information about what the VM config is, what
> version the guest is, what version the host is, etc.

Big apologize, I thought it could be something known.
Info below. Thank you for help.

Jiri

Another try inside vmm guest:
~

# time tor-resolve www.openbsd.org
129.128.5.194
0m00.14s real 0m00.00s user 0m00.00s system
# time tor-resolve www.openbsd.org
129.128.5.194
0m52.96s real 0m00.00s user 0m00.00s system

# tail /var/log/daemon
Feb 12 08:19:59 onion Tor[21861]: Bootstrapped 100%: Done
Feb 12 08:20:04 onion ntpd[51629]: adjusting local clock by 0.384653s
Feb 12 08:23:01 onion ntpd[51629]: adjusting local clock by -0.063873s
Feb 12 08:42:58 onion Tor[21861]: Your system clock just jumped 150 seconds 
forward; assuming established circuits no longer work.
Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit. Looks 
like client functionality is working.
Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit. Looks 
like client functionality is working.
Feb 12 08:45:55 onion Tor[21861]: Your system clock just jumped 150 seconds 
forward; assuming established circuits no longer work.
Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit. Looks 
like client functionality is working.
Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit. Looks 
like client functionality is working.
Feb 12 08:47:05 onion ntpd[51629]: adjusting clock frequency by -7.934969 to 
-23.542969ppm

VMM:


(Originally I forgot 'group internal' in vm.conf, so I put tap1 into group
'internal' manually via ifconfig.)

vm "onion" {
disable
owner jirib
memory 512M
boot $kernel
local interface tap
disk $onion_osdisk
disk $onion_datadisk
}

Networking on host:
~~~

# route -nv show -inet | grep ^default
default176.74.xxx.xxx UGS538658 - 8 em0   
"internet4"

# sysctl net.inet.ip.forwarding 


net.inet.ip.forwarding=1

em0: flags=8843 mtu 1500
lladdr 90:e2:ba:xx:xx:xx
index 1 priority 0 llprio 3
groups: public egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 176.74.xxx netmask 0xffe0 broadcast 176.74.xxx

tap1: flags=8843 mtu 1500
lladdr fe:e1:ba:d2:f7:28
description: vm2-if0-onion
index 17 priority 0 llprio 3
groups: tap internal
status: active
inet 100.64.2.2 netmask 0xfffe

PF on host (uses 'group internal'):
~~~

# pfctl -sr | egrep '(on egress.*nat-to|on internal.*all)'
pass out quick on egress from any to route "internet4" flags S/SA nat-to 
(egress) round-robin
pass in quick on internal all flags S/SA

Storage on host:


'disk's are located on softraid RAID1 array:

1# bioctl sd8   

 
Volume  Status   Size Device  
softraid0 2 Online   536871947776 sd8 RAID1 
  0 Online   536871947776 2:0.0   noencl 
  1 Online   536871947776 2:1.0   noencl 

# dmesg | grep ^sd[23]
sd2 at scsibus1 targ 2 lun 0:  SCSI3 0/direct 
fixed naa.5000c5009387182f
sd2: 953869MB, 512 bytes/sector, 1953525168 sectors
sd3 at scsibus1 targ 3 lun 0:  SCSI3 0/direct 
fixed naa.5000c500939203ed
sd3: 953869MB, 512 bytes/sector, 1953525168 sectors

dmesg on host:
~~

with disabled lm driver because of issue with bad fan RPM.

OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8564375552 (8167MB)
avail mem = 8297807872 (7913MB)
enter_shared_special_pages: entered idt page va 0x8001 pa 0x1d5a000
enter_shared_special_pages: entered kutext page va 0x81831000 pa 
0x1831000
enter_shared_special_pages: entered kutext page va 0x81832000 pa 
0x1832000
enter_shared_special_pages: entered kutext page va 0x81833000 pa 
0x1833000
enter_shared_special_pages: entered kudata page va 0x81ac8000 pa 
0x1ac8000
cpu_enter_pages:

Re: tor inside vmm, horribly slow?!

2018-02-11 Thread Mike Larkin 
On Sun, Feb 11, 2018 at 06:38:49PM -0500, Jiri B wrote:
> Hi,
> 
> has anybody tried to run tor inside vmm guest?
> 
> it's horrible slow, just doing 'tor-resolve $dnsname' takes
> sometimes ages.
> 
> # dmesg | head -n 4
> OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 520093696 (496MB)
> avail mem = 497381376 (474MB)
> 
> is it related to vmm ssl issue reported in the past?
> 

no

> # vmstat ; time tor-resolve www.openbsd.org 
>  procsmemory   pagediskstraps  cpu
>  r   s   avm fre  flt  re  pi  po  fr  sr sd0 sd1  int   sys   cs us sy id
>  1  35   42M302M  176   0   0   0   0   0  17   0  124   544   29  0 88 12
> 129.128.5.194
> 0m46.07s real 0m00.00s user 0m00.00s system
> 
> # vmstat ; time tor-resolve www.openbsd.org 
>  procsmemory   pagediskstraps  cpu
>  r   s   avm fre  flt  re  pi  po  fr  sr sd0 sd1  int   sys   cs us sy id
>  1  35   42M302M  166   0   0   0   0   0  15   0  122   514   28  0 88 12
> 129.128.5.194
> 0m00.13s real 0m00.00s user 0m00.00s system
> 
> Jiri
> 

This report sucks. no dmesg, no information about what the VM config is, what
version the guest is, what version the host is, etc.