Bugzilla

Ok, I looked at your 119 file again and, I saw it wrong yesterday. It looks just like what I see. I.e., the server sends the disconnect (FIN) at about 30m and TB acks it. Then at about 31m biff kicks in and does a connection.

For the 563 file, the "Application data" right after the keepalives I assume must actually be the ```Alert (Level: Warning, Description: Close Notify)``` being sent by the server at the 30m point and TB responds with the same thing. So I suppose your version of tshark or wireshark, whichever you are using, is decoding the "alert" message as "Application Data" since the sequence and timing pretty much match what I see, just the descriptive text differs.

My understanding of the keepalive is that it doesn't affect the 30m timeout of the server. If no application (NNTP) data is sent for 30m, the server disconnects (sends FIN or TLS alert to TB) regardless of keepalive period.  All the keepalive is doing is telling the intermediate routers/NATs that the connection is still needed and please do drop the connection. Then if the connection stays up for the 30m server timeout, the FIN or TLS alert sent back to TB is still seen and an orderly TB reconection can occur without locking up.

However, I don't think there is a guarantee that the routers/NATs will respect the keepalives and they may just ignore them. So my original fix is still needed along with adding the keepalives.

Ok, I looked at your 119 file again and, I saw it wrong yesterday. It looks just like what I see. I.e., the server sends the disconnect (FIN) at about 30m and TB acks it. Then at about 31m biff kicks in and does a connection.

For the 563 file, the "Application data" right after the keepalives I assume must actually be the ```Alert (Level: Warning, Description: Close Notify)``` being sent by the server at the 30m point and TB responds with the same thing. So I suppose your version of tshark or wireshark, whichever you are using, is decoding the "alert" message as "Application Data" since the sequence and timing pretty much match what I see, just the descriptive text differs.

My understanding of the keepalive is that it doesn't affect the 30m timeout of the server. If no application (NNTP) data is sent for 30m, the server disconnects (sends FIN or TLS alert to TB) regardless of keepalive period.  All the keepalive is doing is telling the intermediate routers/NATs that the connection is still needed and please do not drop the connection. Then if the connection stays up for the 30m server timeout, the FIN or TLS alert sent back to TB is still seen and an orderly TB reconection can occur without locking up.

However, I don't think there is a guarantee that the routers/NATs will respect the keepalives and they may just ignore them. So my original fix is still needed along with adding the keepalives.

Ok, I looked at your 119 file again and, I saw it wrong yesterday. It looks just like what I see. I.e., the server sends the disconnect (FIN) at about 30m and TB acks it. Then at about 31m biff kicks in and does a connection.

For the 563 file, the "Application data" right after the keepalives I assume must actually be the ```Alert (Level: Warning, Description: Close Notify)``` being sent by the server at the 30m point and TB responds with the same thing. So I suppose your version of tshark or wireshark, whichever you are using, is decoding the "alert" message as "Application Data" since the sequence and timing pretty much match what I see, just the descriptive text differs. 
Edit: Also the packet length for your "application data" match the length for what I see as alerts.

My understanding of the keepalive is that it doesn't affect the 30m timeout of the server. If no application (NNTP) data is sent for 30m, the server disconnects (sends FIN or TLS alert to TB) regardless of keepalive period.  All the keepalive is doing is telling the intermediate routers/NATs that the connection is still needed and please do not drop the connection. Then if the connection stays up for the 30m server timeout, the FIN or TLS alert sent back to TB is still seen and an orderly TB reconection can occur without locking up.

However, I don't think there is a guarantee that the routers/NATs will respect the keepalives and they may just ignore them. So my original fix is still needed along with adding the keepalives.