AccountingMax 48 GBytes is not working
Hi Tor operators, I have relay with AccountingMax 48 GBytes AccountingStart day 09:00 MaxMemInQueues 512 ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed The accounting seems stopped working since upgrade to tor-0.3.0.10 or enabling obfs4proxy. I am not fully sure, what do you think? https://atlas.torproject.org/#details/DFBF5EA4F70DC6639156BB71593F2A2E8FDA8F... Oct 16 09:00:00 venator Tor[3519]: Configured hibernation. This interval began at 2017-10-16 09:00:00; the scheduled wake-up time was 2017-10-16 09:00:00; we expect to exhaust our quota for this interval around 2017-10-17 09:00:00; the next interval begins at 2017-10-17 09:00:00 (all times local) Oct 16 09:00:00 venator Tor[3519]: Hibernation period ended. Resuming normal activity. Oct 16 09:00:00 venator Tor[3519]: Opening Directory listener on 45.76.39.74:8080 Oct 16 09:00:00 venator Tor[3519]: Opening OR listener on 45.76.39.74:9090 Oct 16 09:00:00 venator Tor[3519]: Opening Extended OR listener on 45.76.39.74:46396 Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 0:46 hours, with 11 circuits open. I've sent 192.00 GB and received 192.01 GB. Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. Oct 16 09:46:11 venator Tor[3519]: Average packaged cell fullness: 12.851%. TLS write overhead: 2% Oct 16 09:46:11 venator Tor[3519]: Circuit handshake stats since last time: 12/12 TAP, 66/66 NTor. Oct 16 09:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 35405 v4 connections; and received 16 v1 connections, 17 v2 connections, 1 v3 connections, and 29675 v4 connections. Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Oct 16 14:45:07 venator Tor[3519]: Going dormant. Blowing away remaining connections. Oct 16 15:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 6:46 hours, with 0 circuits open. I've sent 239.99 GB and received 239.98 GB. We are currently hibernating. Oct 16 15:46:11 venator Tor[3519]: Circuit handshake stats since last time: 27077/27077 TAP, 747536/747536 NTor. Oct 16 15:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 44017 v4 connections; and received 17 v1 connections, 22 v2 connections, 2 v3 connections, and 37042 v4 connections.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/16/2017 09:52 PM, Artur Pędziwilk wrote:
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed
May I asked why you enable obfs4 at an (at atlas & friends) visible relay ? - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWeUR9BccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTq1GAQCHzmfq7Q5YCST0J/uMs4n44lbF yO5j+sVseJHoWUEBeQD/YY+BRRN6CKY10WPztFjFjDCya5MdUtgTpfwcRwapnyI= =898C -----END PGP SIGNATURE-----
-------- Original Message -------- Subject: Re: [tor-relays] AccountingMax 48 GBytes is not working Local Time: 16 października 2017 10:09 PM UTC Time: 16 października 2017 20:09 From: toralf.foerster@gmx.de To: tor-relays@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 10/16/2017 09:52 PM, Artur Pędziwilk wrote:
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed
May I asked why you enable obfs4 at an (at atlas & friends) visible relay ?
I don't know I should not enable it.
On Mon, 16 Oct 2017 at 21:52 Artur Pędziwilk < cb86eb08b7299219c1af5dbcaddd4ede@protonmail.ch> wrote:
Hi Tor operators, I have relay with AccountingMax 48 GBytes AccountingStart day 09:00 MaxMemInQueues 512 ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy managed
The accounting seems stopped working since upgrade to tor-0.3.0.10 or enabling obfs4proxy. I am not fully sure, what do you think?
https://atlas.torproject.org/#details/DFBF5EA4F70DC6639156BB71593F2A2E8FDA8F...
Oct 16 09:00:00 venator Tor[3519]: Configured hibernation. This interval began at 2017-10-16 09:00:00; the scheduled wake-up time was 2017-10-16 09:00:00; we expect to exhaust our quota for this interval around 2017-10-17 09:00:00; the next interval begins at 2017-10-17 09:00:00 (all times local) Oct 16 09:00:00 venator Tor[3519]: Hibernation period ended. Resuming normal activity. Oct 16 09:00:00 venator Tor[3519]: Opening Directory listener on 45.76.39.74:8080 Oct 16 09:00:00 venator Tor[3519]: Opening OR listener on 45.76.39.74:9090 Oct 16 09:00:00 venator Tor[3519]: Opening Extended OR listener on 45.76.39.74:46396 *Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 0:46 hours, with 11 circuits open. I've sent 192.00 GB and received 192.01 GB.* Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. Oct 16 09:46:11 venator Tor[3519]: Average packaged cell fullness: 12.851%. TLS write overhead: 2% Oct 16 09:46:11 venator Tor[3519]: Circuit handshake stats since last time: 12/12 TAP, 66/66 NTor. Oct 16 09:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 35405 v4 connections; and received 16 v1 connections, 17 v2 connections, 1 v3 connections, and 29675 v4 connections. Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Oct 16 14:45:07 venator Tor[3519]: Going dormant. Blowing away remaining connections. *Oct 16 15:46:11 venator Tor[3519]: Heartbeat: Tor's uptime is 6:46 hours, with 0 circuits open. I've sent 239.99 GB and received 239.98 GB. We are currently hibernating.* Oct 16 15:46:11 venator Tor[3519]: Circuit handshake stats since last time: 27077/27077 TAP, 747536/747536 NTor. Oct 16 15:46:11 venator Tor[3519]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 44017 v4 connections; and received 17 v1 connections, 22 v2 connections, 2 v3 connections, and 37042 v4 connections.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Your log also states: Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, *Used: 6.90 MB / 48.00 GB, Rule: max*. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. ... Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted Also notice that 192 + 48 = 240, which coinsides with your observed increase. Regards
Your log also states: Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. ... Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted
Also notice that 192 + 48 = 240, which coinsides with your observed increase.
Yeah, I have noticed so it seems I should not enable obfs4 on my relays. I misunderstood something somewhere. Disabling for now and going to learn more. Thank you,
On 16 Oct 2017, at 16:23, Artur Pędziwilk <cb86eb08b7299219c1af5dbcaddd4ede@protonmail.ch> wrote:
Your log also states: Oct 16 09:46:11 venator Tor[3519]: Heartbeat: Accounting enabled. Sent: 5.42 MB, Received: 6.82 MB, Used: 6.90 MB / 48.00 GB, Rule: max. The current accounting interval ends on 2017-10-17 09:00:00, in 23:13 hours. ... Oct 16 14:45:03 venator Tor[3519]: Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted
Also notice that 192 + 48 = 240, which coinsides with your observed increase.
Yeah, I have noticed so it seems I should not enable obfs4 on my relays. I misunderstood something somewhere. Disabling for now and going to learn more.
It is weird that your traffic figures are 5x the limit. We should fix this bug. Do you know which traffic figure is correct? (For example, from your provider's monitoring?) Did you intend to use the "max" AccountingRule or the "sum" rule? Does this issue occur after the first day as well? T
-------- Original Message -------- Subject: Re: [tor-relays] AccountingMax 48 GBytes is not working Local Time: 16 października 2017 10:36 PM UTC Time: 16 października 2017 20:36 From: teor2345@gmail.com To: tor-relays@lists.torproject.org
It is weird that your traffic figures are 5x the limit. We should fix this bug.
Do you know which traffic figure is correct? (For example, from your provider's monitoring?)
Did you intend to use the "max" AccountingRule or the "sum" rule?
Does this issue occur after the first day as well?
The high value is correct from according to other source metrics of metrics. I intend to use the "max" as whatever comes first I wish to hibernate. The issue occur randomly with different values of data and different hours but just before hibernation the sum is that value + correct limit so it really seems like traffic over obfs4proxy. Not sure if it is correct to see that as a bug. I learn more, I leave that public relay without obfs4proxy and I run additional instance just as bridge relay with obfs4proxy and accounting enabled to check if counting is correct.
Hi, Artur Pędziwilk:
From: teor2345@gmail.com
It is weird that your traffic figures are 5x the limit. We should fix this bug.
Do you know which traffic figure is correct? (For example, from your provider's monitoring?)
Did you intend to use the "max" AccountingRule or the "sum" rule?
Does this issue occur after the first day as well?
The high value is correct from according to other source metrics of metrics. I intend to use the "max" as whatever comes first I wish to hibernate. The issue occur randomly with different values of data and different hours but just before hibernation the sum is that value + correct limit so it really seems like traffic over obfs4proxy. Not sure if it is correct to see that as a bug. I learn more, I leave that public relay without obfs4proxy and I run additional instance just as bridge relay with obfs4proxy and accounting enabled to check if counting is correct.
Great let us know if the issue persists and/or you can reproduce it to the bridge relay that uses obfs4proxy as a ServerTransportPlugin. Thanks for running an extra bridge. :) Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162
participants (5)
-
Artur Pędziwilk -
r1610091651 -
teor -
Toralf Förster -
Vasilis