With declared tcp_persistent_flag in registrar module we expect TCP connection lifetime to be set equal to "expires" parameter in contact on REGISTER message, provided setflag() is called in the routing script before save().
Alas, lifetime value is taken into account only once during the calculation in set_tcp_timeout() (after a connection child is released), then it gets instantly overridden with zero due to a bug in the same function. During each read cycle it will be reassigned with its former value which was once stored in static c_tcp_con_lifetime (in tcp_read.c) as long as static c_tcp_con_id is equal to its connection id. When the next TCP/TLS connection is opened and flagged as persistent, it rewrites both c_tcp_con_lifetime and c_tcp_con_id, so lifetime values of all the previous connections will be zeroed on each cycle. Apparently, we must not share single static variable for all the connections.
This is why the server bluntly cuts sane TCP/TLS connections after inactivity that exceeds tcp_con_lifetime value but still below "expires" threshold! The issue becomes apparent with tcp_con_lifetime set to zero and multiple TCP/TLS connections being flagged with tcp_persistent_flag.
Proposed patch fixes the issue.
Log in to post a comment.