Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#9798 closed defect (fixed)

Directory authorities on master are causing clock skew warns on every reachability test

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth
Cc: mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

A growing number of relay operators started complaining tonight of lines like

Sep 21 05:22:01.021 [Warning] Received NETINFO cell
with skewed time from server at 76.73.17.194:9090. It seems that our
clock is ahead by 15969 days, 3 hours, 22 minutes, or that theirs is behind.
Tor requires an accurate clock to work: please check your time and date
settings.

That's 1970. Mike maintains his clock is correct. And also he upgraded to git master recently.

In parallel, git commit 1d0ba9 does

-  /* Timestamp. */
-  set_uint32(cell.payload, htonl((uint32_t)now));
+  /* Timestamp, if we're a relay. */
+  if (! conn->handshake_state->started_here)
+    set_uint32(cell.payload, htonl((uint32_t)now));

That means every outgoing connection from a directory authority puts a time of 0 in the netinfo cell during its handshake. And relays are programmed to log_warn if they get told a time from an authority that disagrees with their opinion about what time it is.

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by arma

#4852 and #9767 look related. As does proposal 222.

comment:2 Changed 4 years ago by arma

Cc: mikeperry added
Summary: Tor authorities on master are causing clock skew warns on every reachability testDirectory authorities on master are causing clock skew warns on every reachability test

Ok, I pushed a quick hack to basically revert #4852. I thought about making my quick hack try to do the new behavior correctly, but there are too many anxious relay operators right now for that to be a wise move.

Mike, now would be a fine time to upgrade turtles again. Or downgrade I guess.

comment:3 Changed 4 years ago by arma

Ok! Now that things are a bit calmer. One option is

-  /* Timestamp. */
-  set_uint32(cell.payload, htonl((uint32_t)now));
+  /* Timestamp, if we're a relay. */
+  if (public_server_mode(get_options()) || !conn->handshake_state->started_here)
+    set_uint32(cell.payload, htonl((uint32_t)now));

Then bridges set the timestamp when somebody connects to them, but they act like a client they connect to somebody.

I see a bit lower in connection_or_send_netinfo() that we have another very similar-looking check, where we look at

  if ((public_server_mode(get_options()) || !conn->is_outgoing) && [...]

Maybe we should use !conn->is_outgoing in both cases, for uniformity? Unless they ever differ from each other?

Last edited 4 years ago by arma (previous) (diff)

comment:4 Changed 4 years ago by nickm

I think that

  if ((public_server_mode(get_options()) || !conn->is_outgoing) && [...]

would be fine.

comment:5 Changed 4 years ago by nickm

Resolution: fixed
Status: newclosed

Applied in d1dbaf247396f.

comment:6 Changed 4 years ago by Jesse V.

I've been seeing this quite frequently. The last I saw it was about an hour ago.

comment:7 Changed 4 years ago by Jesse V.

I haven't seen this for five hours now. Given the frequency of the warnings before and the gap between now and when last I saw them, it looks fixed to me.

Note: See TracTickets for help on using tickets.