Disparity between download and upload traffic
Morning, everyone, I recently migrated my bridge relay over to a VM and everything seems to be working fine except for one oddity. I consistently see lines like this in tor's log file on the new machine: Dec 25 23:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 5:59 hours, with 43 circuits open. I've sent 1.78 GB and received 28.37 GB. Dec 25 23:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients. Dec 26 05:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 11:59 hours, with 105 circuits open. I've sent 1.87 GB and received 29.24 GB. Dec 26 05:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients. Notice the amount of data sent and received. Can anyone think of why there would be such a large discrepancy between the amount of traffic downloaded versus uploaded? This behavior persists after reboots, as well. I thought maybe it was downloading a ton of directory data, but is there really a GB's worth of directory data to download every six hours?? Also, the logs on my old machine (pre-migration, one line pasted below for reference) indicated that nearly the same amount of data was being sent as was being received. Any ideas on why would this have changed? Dec 07 06:02:03.000 [notice] Heartbeat: Tor's uptime is 4 days 6:12 hours, with 78 circuits open. I've sent 33.71 GB and received 33.47 GB. Any help is greatly appreciated. Thanks a bunch and merry Christmas! gp
On 27 Dec 2016, at 03:47, Gage Parrott <gcparrott@gmail.com> wrote:
Morning, everyone,
I recently migrated my bridge relay over to a VM and everything seems to be working fine except for one oddity. I consistently see lines like this in tor's log file on the new machine:
Dec 25 23:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 5:59 hours, with 43 circuits open. I've sent 1.78 GB and received 28.37 GB. Dec 25 23:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients. Dec 26 05:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 11:59 hours, with 105 circuits open. I've sent 1.87 GB and received 29.24 GB. Dec 26 05:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients.
Notice the amount of data sent and received. Can anyone think of why there would be such a large discrepancy between the amount of traffic downloaded versus uploaded? This behavior persists after reboots, as well.
I thought maybe it was downloading a ton of directory data, but is there really a GB's worth of directory data to download every six hours?? Also, the logs on my old machine (pre-migration, one line pasted below for reference) indicated that nearly the same amount of data was being sent as was being received. Any ideas on why would this have changed?
Dec 07 06:02:03.000 [notice] Heartbeat: Tor's uptime is 4 days 6:12 hours, with 78 circuits open. I've sent 33.71 GB and received 33.47 GB.
Any help is greatly appreciated. Thanks a bunch and merry Christmas!
It looks like you have very few clients. Perhaps those clients have switched to using interactive protocols? Or, more precisely, perhaps those clients are sending almost-empty cells, and then receiving back almost-full cells in response? (This could be an amplification attack, or simply lots of downloads.) On the other hand, your bridge could be repeatedly asking for directory documents. If this is the case, we'd *really* like to know what is causing the issue. Please send more logs, at info-level if possible. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Teor, Yes, I can absolutely do that, let me set up logging and give it a couple of hours to get some data for you. I can't say that I'm terribly comfortable sending the logs via a public, archived distribution list. Mind if I email them to you (or a non-public distribution) directly? We can update this thread later if we figure out that there is indeed an issue so anyone else in this position can learn. Thanks again! gp On Tue, Jan 3, 2017 at 12:13 AM, teor <teor2345@gmail.com> wrote:
On 27 Dec 2016, at 03:47, Gage Parrott <gcparrott@gmail.com> wrote:
Morning, everyone,
I recently migrated my bridge relay over to a VM and everything seems to be working fine except for one oddity. I consistently see lines like this in tor's log file on the new machine:
Dec 25 23:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 5:59 hours, with 43 circuits open. I've sent 1.78 GB and received 28.37 GB. Dec 25 23:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients. Dec 26 05:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 11:59 hours, with 105 circuits open. I've sent 1.87 GB and received 29.24 GB. Dec 26 05:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients.
Notice the amount of data sent and received. Can anyone think of why there would be such a large discrepancy between the amount of traffic downloaded versus uploaded? This behavior persists after reboots, as well.
I thought maybe it was downloading a ton of directory data, but is there really a GB's worth of directory data to download every six hours?? Also, the logs on my old machine (pre-migration, one line pasted below for reference) indicated that nearly the same amount of data was being sent as was being received. Any ideas on why would this have changed?
Dec 07 06:02:03.000 [notice] Heartbeat: Tor's uptime is 4 days 6:12 hours, with 78 circuits open. I've sent 33.71 GB and received 33.47 GB.
Any help is greatly appreciated. Thanks a bunch and merry Christmas!
It looks like you have very few clients. Perhaps those clients have switched to using interactive protocols? Or, more precisely, perhaps those clients are sending almost-empty cells, and then receiving back almost-full cells in response? (This could be an amplification attack, or simply lots of downloads.)
On the other hand, your bridge could be repeatedly asking for directory documents. If this is the case, we'd *really* like to know what is causing the issue. Please send more logs, at info-level if possible.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, Jan 3, 2017 at 12:13 AM, teor <teor2345@gmail.com> wrote:
On 27 Dec 2016, at 03:47, Gage Parrott <gcparrott@gmail.com> wrote:
Morning, everyone,
I recently migrated my bridge relay over to a VM and everything seems to be working fine except for one oddity. I consistently see lines like this in tor's log file on the new machine:
Dec 25 23:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 5:59 hours, with 43 circuits open. I've sent 1.78 GB and received 28.37 GB. Dec 25 23:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients. Dec 26 05:48:14.000 [notice] Heartbeat: Tor's uptime is 4 days 11:59 hours, with 105 circuits open. I've sent 1.87 GB and received 29.24 GB. Dec 26 05:48:14.000 [notice] Heartbeat: In the last 6 hours, I have seen 2 unique clients.
Notice the amount of data sent and received. Can anyone think of why there would be such a large discrepancy between the amount of traffic downloaded versus uploaded? This behavior persists after reboots, as well.
I thought maybe it was downloading a ton of directory data, but is there really a GB's worth of directory data to download every six hours?? Also, the logs on my old machine (pre-migration, one line pasted below for reference) indicated that nearly the same amount of data was being sent as was being received. Any ideas on why would this have changed?
Dec 07 06:02:03.000 [notice] Heartbeat: Tor's uptime is 4 days 6:12 hours, with 78 circuits open. I've sent 33.71 GB and received 33.47 GB.
Any help is greatly appreciated. Thanks a bunch and merry Christmas!
It looks like you have very few clients. Perhaps those clients have switched to using interactive protocols? Or, more precisely, perhaps those clients are sending almost-empty cells, and then receiving back almost-full cells in response? (This could be an amplification attack, or simply lots of downloads.)
On the other hand, your bridge could be repeatedly asking for directory documents. If this is the case, we'd *really* like to know what is causing the issue. Please send more logs, at info-level if possible.
With gp's permission, here is my response to the bridge logs: I think that some of the disparity is normal: your relay checks its ORPort bandwidth, and downloads directory documents. But it does seem to be suffering from bug #20535 when downloading microdesc consensuses - when tor gets a 304, it should probably wait around an hour for the next consensus. https://trac.torproject.org/projects/tor/ticket/20535 Requests: REDACTED_DATE 16:59:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:00:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:01:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:03:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:09:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:10:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:11:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:12:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:13:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:16:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:22:15.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 17:31:16.000 [info] update_consensus_networkstatus_downloads(): Launching ns standard networkstatus consensus download. REDACTED_DATE 18:46:16.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 18:47:16.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 18:48:16.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 18:49:16.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 18:50:16.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 18:56:16.000 [info] update_consensus_networkstatus_downloads(): Launching microdesc standard networkstatus consensus download. REDACTED_DATE 19:02:16.000 [info] update_consensus_networkstatus_downloads(): Launching ns standard networkstatus consensus download. REDACTED_DATE 19:50:16.000 [info] update_consensus_networkstatus_downloads(): Launching ns standard networkstatus consensus download. ... Responses: (These requests go to a small number of IP addresses: the bridge's directory guards) REDACTED_DATE 16:59:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:00:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:01:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:03:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:10:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:11:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:12:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:13:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:16:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 17:22:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 18:47:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 18:48:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 18:49:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 18:50:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. REDACTED_DATE 18:56:16.000 [info] Received http status code 304 ("Not modified") from server 'REDACTED_IP' while fetching consensus directory. ... (I have redacted the bridge's directory guards and the date.) T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
participants (2)
-
Gage Parrott -
teor