Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server '154.35.32.5:80'):
It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
On 14/11/14 17:59, Austin Bentley wrote:
Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server
'154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the
Sounds like something is broken here, maybe a daylight saving issue? Are you running ntp?
Chris
time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Check your ntp port and also your ntp sync server you are using. I hope you are not tunneling the NTP protocol through TOR.
Am 14. November 2014 05:59:49 MEZ, schrieb Austin Bentley ab6d9@mst.edu:
Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server
'154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
- -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net
Encrypted messages are welcome. 0x84DF1F7E6AE03644
- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux)
mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL - -----END PGP PUBLIC KEY BLOCK-----
That's strange. I was working off of the hardware clock and I figured that the resolution would be fine enough (because it was the exact same as CET if I set it to EET.)
Additionally, I thought tzsetup utilized ntp, however it was based off of the jail host's clock (which was not synchronized via ntp.)
The messages have since stopped. Silly mistake, easy fix. Thanks fellas.
On Thu, Nov 13, 2014 at 11:34 PM, Elrippo elrippo@elrippoisland.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Check your ntp port and also your ntp sync server you are using. I hope you are not tunneling the NTP protocol through TOR.
Am 14. November 2014 05:59:49 MEZ, schrieb Austin Bentley ab6d9@mst.edu:
Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server
'154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo@elrippoisland.net
Encrypted messages are welcome. 0x84DF1F7E6AE03644
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)
mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE----- Version: APG v1.1.1
iQJcBAEBCgBGBQJUZZRJPxxlbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0 ZWQpIDxlbHJpcHBvQGVscmlwcG9pc2xhbmQubmV0PgAKCRAkQ93r2VDR64zJD/sH D2TakVZNhIBxDuzObfYlYoSrqk+NMgvTZSPrCnh+As52W2xEXYy8iLtOXEEtJVMM YFUx0e0dmnS4mzXy14WroWD4Mvl0INEeEvZrhrUBrdvEa8WXABSnh96A2gjw46ab OPdUZ51BV8i3pGQMVM2lUBChEJt28GhKwTCJ+qDMB46f9wQOWynl3RSwJzFQqArc rHQMfy/Ym99NH2RSe+ewojsjU4aCLGWCcyIhGbtWc5vcSseOvj4gV9Hpxk0lg9XM lv64Wtt9+shajiEskfOoZrUaT+ia/hIA7lAvGS3vBFzdNllFzUbRw9nccQeslvjV G4tEHE48K9gEo9Kc5aVB2KAOz69rf5O5InR1VBdNJLuxEWoUVGTUXnHib87UZOxA QrzqAtqLPNOfVK4fRJdxDocu/c3kiJNt9OfJXCWNyl7cH5mayCfPJ197QXJF6tvU X6RAIm4XXfRo2v86XpsUmEMXS752erjettPWCQ6fc4zFvHoVRQum/sa0cQPRYmju DkEox3/z3m8MWfYpx+no/+Vky+zCOXI0zXNyQnUd2kXgLWEGPVPUk+ZuXPyYaJtJ Q32UfxPMC6dVQOzA0gN3vCET3DXyTnazEEk6RQrhLnyh+vGeBCK4a1O/NUVQnrFW 5ODM+qz4GDOoDE1W7EgqsMfevG64NVMDJB+9DimUPg== =pglw -----END PGP SIGNATURE-----
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Austin,
The clock is very important to Tor, you need accurate clock all the time.
Do you run NTPDATE or NTPD service inside your VPS? The virutal servers are sometimes problematic, depending on virtualization, when coming to hwclock and dedicated time.
You need to open a ticket with your VPS provider and ask them what virtualization technique they use and if there is a NTP daemon on the hypervisor (physical host server) which sets the time inside the guests (virtual machines). Make sure the time is correct on your master host server and rely on that time instead of trying to run your own NTP service. If they say the master server doesn't run this service or set the time inside guests (i doubt it), you can then run NTP inside your VPS as follows:
(NTP and NTPDATE are included in FreeBSD base system so you don't have to install anything). Run these commands:
$ service ntpd stop (or onestop if stop doesn't work, if it says ntpd is not running just proceed with the following commands)
$ echo 'ntp_enable="YES"' >> /etc/rc.conf $ echo 'ntpdate_enable="YES"' >> /etc/rc.conf $ ntpdate 0.rhel.pool.ntp.org $ service ntpd start
Your timezone does not matter. Tor calculates the time in UNIX time format, so you can be in any time zone, GMT +1, UTC, EET, whatever - Tor will work just fine if the UNIX time format is accurate. The localtime via timezone is just a translation/calculation of UNIX timestamp.
On 11/14/2014 6:59 AM, Austin Bentley wrote:
Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server
'154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
If your vps provider is openvz, you are shit out of luck because you can't set time.
On Fri, Nov 14, 2014 at 4:37 AM, s7r s7r@sky-ip.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello Austin,
The clock is very important to Tor, you need accurate clock all the time.
Do you run NTPDATE or NTPD service inside your VPS? The virutal servers are sometimes problematic, depending on virtualization, when coming to hwclock and dedicated time.
You need to open a ticket with your VPS provider and ask them what virtualization technique they use and if there is a NTP daemon on the hypervisor (physical host server) which sets the time inside the guests (virtual machines). Make sure the time is correct on your master host server and rely on that time instead of trying to run your own NTP service. If they say the master server doesn't run this service or set the time inside guests (i doubt it), you can then run NTP inside your VPS as follows:
(NTP and NTPDATE are included in FreeBSD base system so you don't have to install anything). Run these commands:
$ service ntpd stop (or onestop if stop doesn't work, if it says ntpd is not running just proceed with the following commands)
$ echo 'ntp_enable="YES"' >> /etc/rc.conf $ echo 'ntpdate_enable="YES"' >> /etc/rc.conf $ ntpdate 0.rhel.pool.ntp.org $ service ntpd start
Your timezone does not matter. Tor calculates the time in UNIX time format, so you can be in any time zone, GMT +1, UTC, EET, whatever - Tor will work just fine if the UNIX time format is accurate. The localtime via timezone is just a translation/calculation of UNIX timestamp.
On 11/14/2014 6:59 AM, Austin Bentley wrote:
Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server
'154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUZdtcAAoJEIN/pSyBJlsRMzMH/3F1MeX9Z1y7z4G+zNNDENin Yytg5YsXrWrwFCiC90j6rmKIY2rFvu5YTqpnoZ28bmC8+ZePuCXM1srK62YnUlvP YVYJO1bCP0gl7ER1MhffS5pcpvXZ4Mb+uPdk1MlKcO+yD7xgP0EwbojBRJp/23Ct jjkeLIg9fkDb+TRVd3KKFfvgHaItGYAoMc3Jn9yVUrH1vmKUDWe4XeSt37ejx4iE 6431+KUeFkEzPMJII2hBDJ3HFGx+VFAfBa+V2jQ+5DzIUwTc710jgmjSy7xhv/4Z +V7JDniU6bDt0U1SIpKfZBGThrIiT7vsBg9EWQcQf1IHTvXe5boDkoveUdyIytk= =Kczu -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Or FreeBSD Jail system... anyway your provider has the interest to have an accurate time on the host server... so it shouldn't be a problem at all - it can be fixed in few seconds.. it's just a misconfiguration.
No sane person will refuse to set the correct time on a host server...
On 11/14/2014 12:49 PM, eric gisse wrote:
If your vps provider is openvz, you are shit out of luck because you can't set time.
On Fri, Nov 14, 2014 at 4:37 AM, s7r s7r@sky-ip.org wrote: Hello Austin,
The clock is very important to Tor, you need accurate clock all the time.
Do you run NTPDATE or NTPD service inside your VPS? The virutal servers are sometimes problematic, depending on virtualization, when coming to hwclock and dedicated time.
You need to open a ticket with your VPS provider and ask them what virtualization technique they use and if there is a NTP daemon on the hypervisor (physical host server) which sets the time inside the guests (virtual machines). Make sure the time is correct on your master host server and rely on that time instead of trying to run your own NTP service. If they say the master server doesn't run this service or set the time inside guests (i doubt it), you can then run NTP inside your VPS as follows:
(NTP and NTPDATE are included in FreeBSD base system so you don't have to install anything). Run these commands:
$ service ntpd stop (or onestop if stop doesn't work, if it says ntpd is not running just proceed with the following commands)
$ echo 'ntp_enable="YES"' >> /etc/rc.conf $ echo 'ntpdate_enable="YES"' >> /etc/rc.conf $ ntpdate 0.rhel.pool.ntp.org $ service ntpd start
Your timezone does not matter. Tor calculates the time in UNIX time format, so you can be in any time zone, GMT +1, UTC, EET, whatever - Tor will work just fine if the UNIX time format is accurate. The localtime via timezone is just a translation/calculation of UNIX timestamp.
On 11/14/2014 6:59 AM, Austin Bentley wrote:
Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server
'154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
You'd think, but not always. Relying on an openvz hypervisor to be "not fucked up" is a gamble.
I, for example, routinely run into openvz hosts that don't have the most *basic* iptables modules loaded in the kernel for connection tracking (read: stateful firewall).
I have to seriously have specific checks in my puppet manifests to make sure I'm not running on openvz, otherwise fierwalls will fail more often than not.
On Fri, Nov 14, 2014 at 5:10 AM, s7r s7r@sky-ip.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Or FreeBSD Jail system... anyway your provider has the interest to have an accurate time on the host server... so it shouldn't be a problem at all - it can be fixed in few seconds.. it's just a misconfiguration.
No sane person will refuse to set the correct time on a host server...
On 11/14/2014 12:49 PM, eric gisse wrote:
If your vps provider is openvz, you are shit out of luck because you can't set time.
On Fri, Nov 14, 2014 at 4:37 AM, s7r s7r@sky-ip.org wrote: Hello Austin,
The clock is very important to Tor, you need accurate clock all the time.
Do you run NTPDATE or NTPD service inside your VPS? The virutal servers are sometimes problematic, depending on virtualization, when coming to hwclock and dedicated time.
You need to open a ticket with your VPS provider and ask them what virtualization technique they use and if there is a NTP daemon on the hypervisor (physical host server) which sets the time inside the guests (virtual machines). Make sure the time is correct on your master host server and rely on that time instead of trying to run your own NTP service. If they say the master server doesn't run this service or set the time inside guests (i doubt it), you can then run NTP inside your VPS as follows:
(NTP and NTPDATE are included in FreeBSD base system so you don't have to install anything). Run these commands:
$ service ntpd stop (or onestop if stop doesn't work, if it says ntpd is not running just proceed with the following commands)
$ echo 'ntp_enable="YES"' >> /etc/rc.conf $ echo 'ntpdate_enable="YES"' >> /etc/rc.conf $ ntpdate 0.rhel.pool.ntp.org $ service ntpd start
Your timezone does not matter. Tor calculates the time in UNIX time format, so you can be in any time zone, GMT +1, UTC, EET, whatever - Tor will work just fine if the UNIX time format is accurate. The localtime via timezone is just a translation/calculation of UNIX timestamp.
On 11/14/2014 6:59 AM, Austin Bentley wrote:
Hello everyone,
I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings:
05:56:12 [WARN] Received directory with skewed time (server
'154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often):
02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time
published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings!
I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data.
Could someone shine some light on this?
Thanks, Austin
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUZeM8AAoJEIN/pSyBJlsRGeEH/2ElP4+Z7uD2PQkYk25tq7ji VVTUwxa5qweD4/YBWwoohhMmii+yY4ZoLnmoevNh2Y3PxTwC49N5nyQH7CQL59OU gIL8GCfmoJD6mjv+cCENn+g/iPUpb5eIhuKnLnh0dm49pj5t0Wb8H3R6HUR+BGnA Me3SOwfWT3XR6Ktd93Ev/yY03vRRFFhSQShGCeSwKIIT6CvKWgTSXCi4SZsslY5B mvRJMx99dYbEFuL32hNkPtcx5mr7JkUQamWJzuzPEY4HDFaYIW0zU0SBcFBbXVjT MClytBVcS1YznSMC/l9eusnijDO4LCM7We6EsjRmWWgPKOg+SsoMbCtZzmh+Y0k= =piNO -----END PGP SIGNATURE----- _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi all,
I'm brand new to this, so I'll apologize in advance if this is a silly question.
I've just recently set up a Tor box on Debian, all looks well, logs show it's happy. I've got it setup for 100 Meg bandwidth, 200M burst.
My confusion is because when I look it up on Globe or Atlas, it shows "Observed" bandwidth as 64.5k, yet it shows "Bandwidth Values" as 100 and 200 Meg, as I have them specified in torrc.
My connection is an unloaded Gig-Eth fiber into a data center directly, I'm the ISP in this case; no filtering anywhere.
Thanks in advance.
Rk
On Fri, Nov 14, 2014 at 6:24 PM, Rick Kunze rkunze@colusanet.com wrote:
Hi all,
I'm brand new to this, so I'll apologize in advance if this is a silly question.
I've just recently set up a Tor box on Debian, all looks well, logs show it's happy. I've got it setup for 100 Meg bandwidth, 200M burst.
My confusion is because when I look it up on Globe or Atlas, it shows "Observed" bandwidth as 64.5k, yet it shows "Bandwidth Values" as 100 and 200 Meg, as I have them specified in torrc.
My connection is an unloaded Gig-Eth fiber into a data center directly, I'm the ISP in this case; no filtering anywhere.
What you are observing is normal, expect the observed bandwidth to increase gradually over time as more traffic passes through your relay. For details, please have a look at [1].
— Bert
[1] https://blog.torproject.org/blog/lifecycle-of-a-new-relay
tor-relays@lists.torproject.org
-
Austin Bentley -
Bert Massop -
Christian Gagneraud -
Elrippo -
eric gisse -
Rick Kunze -
s7r