(In reply to David Canzi from comment #16) > I will read your last 2 comments shortly, but I'll say some things > briefly. I have packet captures for version 115.11.0 and version > 115.9.0. The results are similar. On startup, Thunderbird downloads > new articles from Eternal September, then nothing else happens > until 35 minutes later. What I see at the first 35m point is TB doesn't know the connection has been closed by ES. It them tries to send a NNTP command to check for new messages and no response is received after several requests are sent. Since the release TB doesn't have a tcptimeout enabled, there is no indication to TB that the connection is down so it gives up and waits for the next 35m "biff" time to occur. By then it somehow knows the connection is gone (not sure how) and at the 70m point it does a reconnect and successfully communicates with ES and brings in any new message. > My computer doesn't receive anything from ES at or near 30 minutes. I think this is a problem (bug?) at the ES server. When connecting to ES with port 119 (no TLS) at the 30m point it sends a tcp FIN to close the connection and everything works as expected. If port 563 (TLS) is used and the route is via my charter isp, ipv4 is used and at the 30m point ES sends an "alert" via the TLS protocol that the connection is going down. TB then sends the FIN to close the connection all is fine. But if I connect via cell phone network (AT&T as isp) it uses ipv6 (may not be significant) but at the 30m point, there is no TLS alert or FIN sent by the ES server; either that or it is block by some other server along the route. This seems like what you are seeing too if wireshark shows nothing coming in from ES at the 30m point. Note: I haven't tried connecting via cell network to ES with port 119. > > I have Thunderbird currently getting articles from two news > servers, one using port 563, the other using port 119 without > encryption. At startup, Thunderbird opens two connections > to ES, port 563, and two to paganini.bofh.team, port 119. If you have more than 1 group subscribed on a server and if you are set up to check for new messages at startup, there will, by default, be two connections per server created at start up. You can adjust this with the TB config editor (advanced) parameter ```mail.server.serverX.max_cached_connections``` where X is the server number. You have to look at items "mail.server.server" to determine the server number X. You can set the parameter to 1 if you want only one connection to occur, or you can set it larger if you have a lot of subscribed groups. (I think I saw on ES site they allow only 2 connections.) > After 35 minutes it closes all of these sockets and opens > one new connection to paganini. After this, I can't get > version 115.9.0 to communicate with ES. I haven't tested > 115.11.0 at this same point. After another 35 minutes, Thunderbird > closes its connection to paganini and opens two new > connections to paganini and none to ES. After this I can't get > version 115.11.0 to communicate with ES. Here's what I see with the release TB version. If I set the time between checks for message to 1 hour (60m biff time) using IPv6 via cell route, TB fails when checking for message at the 60m point, then at the 120m point it tries again and succeeds. It then fails again at the 180m point and succeeds at the 240m point. So effectively the biff time is 120m (2 hours). I have a fix for this so that if TB fails at the scheduled time, before the send I configure the tcptimeout for 25 seconds. Now TB will see the timeout signal (from the mozilla framework) and know the connection is gone, create a new connection and retry the command. The only problem I see with this is it takes 25 seconds for TB to know/assume that the connection is down. So there will be a 25 delay if you manually request a new message after TB has set idle long enough for the server to silently disconnect (which is something I don't think the server should do). The fix: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/MQRsTmncTh2OJ5j9ESd38w/runs/0/artifacts/public/build/target.tar.bz2 Again, this is a patched version of 115.11.1. Here's the full "try" build link: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=c325ab932f620a8ab4b89c563436f240e92a39a7 > > I don't know how to attach packet captures to this comment. If you saved the capture file, you can attach it using the "Attach new file" button above. Or if you prefer, you can just email it to me. I think I have received files OK that are more than 16M is length. But maybe just try the patched version above and see if that has any effect first.
Bug 1901338 Comment 17 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to David Canzi from comment #16) > I will read your last 2 comments shortly, but I'll say some things > briefly. I have packet captures for version 115.11.0 and version > 115.9.0. The results are similar. On startup, Thunderbird downloads > new articles from Eternal September, then nothing else happens > until 35 minutes later. What I see at the first 35m point is TB doesn't know the connection has been closed by ES. It them tries to send a NNTP command to check for new messages and no response is received after several requests are sent. Since the release TB doesn't have a tcptimeout enabled, there is no indication to TB that the connection is down so it gives up and waits for the next 35m "biff" time to occur. By then it somehow knows the connection is gone (not sure how) and at the 70m point it does a reconnect and successfully communicates with ES and brings in any new message. > My computer doesn't receive anything from ES at or near 30 minutes. I think this is a problem (bug?) at the ES server. When connecting to ES with port 119 (no TLS) at the 30m point it sends a tcp FIN to close the connection and everything works as expected. If port 563 (TLS) is used and the route is via my charter isp, ipv4 is used and at the 30m point ES sends an "alert" via the TLS protocol that the connection is going down. TB then sends the FIN to close the connection all is fine. But if I connect via cell phone network (AT&T as isp) it uses ipv6 (may not be significant) but at the 30m point, there is no TLS alert or FIN sent by the ES server; either that or it is block by some other server along the route. This seems like what you are seeing too if wireshark shows nothing coming in from ES at the 30m point. Note: I haven't tried connecting via cell network to ES with port 119. > > I have Thunderbird currently getting articles from two news > servers, one using port 563, the other using port 119 without > encryption. At startup, Thunderbird opens two connections > to ES, port 563, and two to paganini.bofh.team, port 119. If you have more than 1 group subscribed on a server and if you are set up to check for new messages at startup, there will, by default, be two connections per server created at start up. You can adjust this with the TB config editor (advanced) parameter ```mail.server.serverX.max_cached_connections``` where X is the server number. You have to look at items "mail.server.server" to determine the server number X. You can set the parameter to 1 if you want only one connection to occur, or you can set it larger if you have a lot of subscribed groups. (I think I saw on ES site they allow only 2 connections.) > After 35 minutes it closes all of these sockets and opens > one new connection to paganini. After this, I can't get > version 115.9.0 to communicate with ES. I haven't tested > 115.11.0 at this same point. After another 35 minutes, Thunderbird > closes its connection to paganini and opens two new > connections to paganini and none to ES. After this I can't get > version 115.11.0 to communicate with ES. Here's what I see with the release TB version. If I set the time between checks for message to 1 hour (60m biff time) using IPv6 via cell route, TB fails when checking for message at the 60m point, then at the 120m point it tries again and succeeds. It then fails again at the 180m point and succeeds at the 240m point. So effectively the biff time is 120m (2 hours). I have a fix for this so that if TB fails at the scheduled time, before the send I configure the tcptimeout for 25 seconds. Now TB will see the timeout signal (from the mozilla framework) and know the connection is gone, create a new connection and retry the command. The only problem I see with this is it takes 25 seconds for TB to know/assume that the connection is down. So there will be a 25 delay if you manually request a new message after TB has set idle long enough for the server to silently disconnect (which is something I don't think the server should do). ~~The fix: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/MQRsTmncTh2OJ5j9ESd38w/runs/0/artifacts/public/build/target.tar.bz2~~ Edit: Don't use, has a problem. See next comment. Again, this is a patched version of 115.11.1. Here's the full "try" build link: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=c325ab932f620a8ab4b89c563436f240e92a39a7 > > I don't know how to attach packet captures to this comment. If you saved the capture file, you can attach it using the "Attach new file" button above. Or if you prefer, you can just email it to me. I think I have received files OK that are more than 16M is length. But maybe just try the patched version above and see if that has any effect first.
(In reply to David Canzi from comment #16) > I will read your last 2 comments shortly, but I'll say some things > briefly. I have packet captures for version 115.11.0 and version > 115.9.0. The results are similar. On startup, Thunderbird downloads > new articles from Eternal September, then nothing else happens > until 35 minutes later. What I see at the first 35m point is TB doesn't know the connection has been closed by ES. It them tries to send a NNTP command to check for new messages and no response is received after several requests are sent. Since the release TB doesn't have a tcptimeout enabled, there is no indication to TB that the connection is down so it gives up and waits for the next 35m "biff" time to occur. By then it somehow knows the connection is gone (not sure how) and at the 70m point it does a reconnect and successfully communicates with ES and brings in any new message. > My computer doesn't receive anything from ES at or near 30 minutes. I think this is a problem (bug?) at the ES server. When connecting to ES with port 119 (no TLS) at the 30m point it sends a tcp FIN to close the connection and everything works as expected. If port 563 (TLS) is used and the route is via my charter isp, ipv4 is used and at the 30m point ES sends an "alert" via the TLS protocol that the connection is going down. TB then sends the FIN to close the connection all is fine. But if I connect via cell phone network (AT&T as isp) it uses ipv6 (may not be significant) but at the 30m point, there is no TLS alert or FIN sent by the ES server; either that or it is block by some other server along the route. This seems like what you are seeing too if wireshark shows nothing coming in from ES at the 30m point. Note: I haven't tried connecting via cell network to ES with port 119. > > I have Thunderbird currently getting articles from two news > servers, one using port 563, the other using port 119 without > encryption. At startup, Thunderbird opens two connections > to ES, port 563, and two to paganini.bofh.team, port 119. If you have more than 1 group subscribed on a server and if you are set up to check for new messages at startup, there will, by default, be two connections per server created at start up. You can adjust this with the TB config editor (advanced) parameter ```mail.server.serverX.max_cached_connections``` where X is the server number. You have to look at items "mail.server.server" to determine the server number X. You can set the parameter to 1 if you want only one connection to occur, or you can set it larger if you have a lot of subscribed groups. (I think I saw on ES site they allow only 2 connections.) > After 35 minutes it closes all of these sockets and opens > one new connection to paganini. After this, I can't get > version 115.9.0 to communicate with ES. I haven't tested > 115.11.0 at this same point. After another 35 minutes, Thunderbird > closes its connection to paganini and opens two new > connections to paganini and none to ES. After this I can't get > version 115.11.0 to communicate with ES. Here's what I see with the release TB version. If I set the time between checks for message to 1 hour (60m biff time) using IPv6 via cell route, TB fails when checking for message at the 60m point, then at the 120m point it tries again and succeeds. It then fails again at the 180m point and succeeds at the 240m point. So effectively the biff time is 120m (2 hours). I have a fix for this so that if TB fails at the scheduled time, before the send I configure the tcptimeout for 25 seconds. Now TB will see the timeout signal (from the mozilla framework) and know the connection is gone, create a new connection and retry the command. The only problem I see with this is it takes 25 seconds for TB to know/assume that the connection is down. So there will be a 25 delay if you manually request a new message after TB has set idle long enough for the server to silently disconnect (which is something I don't think the server should do). ~~The fix: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/MQRsTmncTh2OJ5j9ESd38w/runs/0/artifacts/public/build/target.tar.bz2~~ Edit: Don't use, has a problem. See next comment. Again, this is a patched version of 115.11.1. Here's the full "try" build link: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=c325ab932f620a8ab4b89c563436f240e92a39a7 > > I don't know how to attach packet captures to this comment. If you saved the capture file, you can attach it using the "Attach new file" button above. Or if you prefer, you can just email it to me. I think I have received files OK that are more than 16M is length. But maybe just try the patched version ~~above~~ below and see if that has any effect first.