[tor-bugs] #12023 [Tor]: Should we update timestamp_last_added_nonpadding when we send a destroy cell?

[Tor Bug Tracker & Wiki]

#12023: Should we update timestamp_last_added_nonpadding when we send a destroy
cell?
------------------------+------------------------------------
 Reporter:  nickm       |          Owner:
     Type:  defect      |         Status:  new
 Priority:  normal      |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor         |        Version:
 Keywords:  tor-client  |  Actual Points:
Parent ID:              |         Points:
------------------------+------------------------------------
 As near as I can tell based on my work on #6799, our fix for #7912
 introduces a "fun" property: DESTROY cells no longer count as "non-
 padding" cells for the purpose of killing an idle connection.  Here's a
 debug log (with the #6799 fixes in place):

 {{{
 May 15 22:54:07.000 [debug] circuit_expire_old_circuits_clientside():
 Closing ci
 rcuit that has been unused for 3626990 msec.
 May 15 22:54:07.000 [debug] circuit_get_by_circid_channel_impl():
 circuit_get_by
 _circid_channel_impl() returning circuit 0x7f0846e25ff0 for circ_id
 2927002286,
 channel ID 19 (0x7f0846e65b20)
 May 15 22:54:07.000 [debug] circuit_get_by_circid_channel_impl():
 circuit_get_by
 _circid_channel_impl() returning circuit 0x7f0846e25ff0 for circ_id
 2927002286,
 channel ID 19 (0x7f0846e65b20)
 May 15 22:54:07.000 [debug] circuitmux_append_destroy_cell(): Cmux at
 0x7f0846e4
 b2b0 queued a destroy for circ 2927002286, cmux counter is now 1, global
 counter
  is now 1
 May 15 22:54:07.000 [debug] circuitmux_append_destroy_cell(): Primed a
 buffer.
 May 15 22:54:07.000 [debug] channel_write_packed_cell(): Writing
 packed_cell_t 0
 x7f0846e65d38 to channel 0x7f0846e65b20 with global ID 19
 May 15 22:54:07.000 [debug] circuit_get_by_circid_channel_impl():
 circuit_get_by
 _circid_channel_impl() returning circuit 0x7f0846e25ff0 for circ_id
 2927002286,
 channel ID 19 (0x7f0846e65b20)
 May 15 22:54:07.000 [debug] circuitmux_notify_xmit_destroy(): Cmux at
 0x7f0846e4b2b0 sent a destroy, cmux counter is now 0, global counter is
 now 0
 May 15 22:54:07.000 [debug] channel_send_destroy(): Sending destroy
 (circID 2927002286) on channel 0x7f0846e65b20 (global ID 19)
 May 15 22:54:07.000 [notice] Expiring non-used OR connection
 0x7f0846e28060 to fd 5 (127.0.0.1:5004) [idle 3627, timeout 1274,
 canonical=1].
 }}}

 Note that the channel counts as having been "idle for an hour", even
 though the DESTROY cell was just sent immediately before.

 Do we care about this?  Is it actually wrong?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12023>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online