Bugzilla

> If you define filters for a newsgroup, they are written into the newsgroup's .dat file.

Of course, I should know that. But I haven't dealt much with filtering during by TB "career". :)

> I saw the following sequence of events in a packet capture:
    Thunderbird sends GROUP alt.atheism
    My computer receives an RST packet
    Thunderbird opens a new connection
    Thunderbird sends GROUP alt.free.newsservers

I assume this is right after a 50m (or whatever time) biff interval. I see similar changes with unpatched code except I never see a RST from my location. So from here, sending the first GROUP in you sequence never gets a response at all. With the patch in place that you are testing now, a TIMEOUT error will be generated after 25s with no response to a command. Also, a RST response when attempting to "reuse" a connection will also be treated like a TIMEOUT. So if a TIMEOUT or RST occur when a connection is attempting to be reused, a new connection will be opened to retry the command and the old timed-out or reset connection will be closed locally and tcp FIN is sent to ensure the remote host sees that it is closed.

If you are still have network problems with the latest patch to 115.12.2, another tshark capture file would be most helpful to see what's going on, since, unfortunately, I don't see the same things here, i.e., you see RST, I see no response and a timeout.
Thanks!

> If you define filters for a newsgroup, they are written into the newsgroup's .dat file.

Of course, I should know that. But I haven't dealt much with filtering during by TB "career". :)

> I saw the following sequence of events in a packet capture:
    Thunderbird sends GROUP alt.atheism
    My computer receives an RST packet
    Thunderbird opens a new connection
    Thunderbird sends GROUP alt.free.newsservers

I assume this is right after a 50m (or whatever time) biff interval. I see a similar sequence with unpatched code except I never see a RST from my location. So from here, sending the first GROUP in you sequence never gets a response at all. With the patch in place that you are testing now, a TIMEOUT error will be generated after 25s with no response to a command. Also, a RST response when attempting to "reuse" a connection will also be treated like a TIMEOUT. So if a TIMEOUT or RST occur when a connection is attempting to be reused, a new connection will be opened to retry the command and the old timed-out or reset connection will be closed locally and tcp FIN will be sent to ensure the remote host sees that it is closed.

If you are still having network problems with the latest patch to 115.12.2, another tshark capture file would be most helpful to see what's going on, since, unfortunately, I don't see the same things here, i.e., you see RST, I see no response and a timeout.
Thanks!