Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#9798 closed defect (fixed)

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

Reported by: arma Owned by:
Priority: normal Milestone: Tor: 0.2.4.x-final
Component: Tor Version:
Keywords: tor-auth Cc: mikeperry
Actual Points: Parent ID:
Points:

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 7 months ago by arma

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

comment:2 Changed 7 months ago by arma

  • Cc mikeperry added
  • Summary changed from Tor authorities on master are causing clock skew warns on every reachability test to Directory 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 7 months 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 7 months ago by arma (previous) (diff)

comment:4 Changed 7 months ago by nickm

I think that

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

would be fine.

comment:5 Changed 7 months ago by nickm

  • Resolution set to fixed
  • Status changed from new to closed

Applied in d1dbaf247396f.

comment:6 Changed 7 months ago by Jesse V.

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

comment:7 Changed 7 months 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.