Bugzilla

(In reply to gene smith from comment #17)
> > TB shall not try to reconnect unless the network is ready and functional, and should do so as soon as it happens.
> 
> Right now that doesn't happen. An attempt is made to connect and it fails and there is no real retry other than try again at the next biff time. Also, don't think there is a signal that there is no network available at TB startup or after an OS wake-up. Or if there is a signal (network up or down), it is not currently hooked onto in imap code (but I could be wrong :)).

It should down to the automatic triggering of **Get Message** button command **upon network up event**. This action do re-connect (I believe) to the IMAP server as part as the process and check for new emails.

> > The alternative use case could also be a switch of network for example after a VPN connection that may completely change IP range (connection via local IP rather than external IP).
> 
> I don't have a VPN but I do have a cell phone wifi "hot spot" that I use sometimes when electrical power is off (storms, etc). I think when I use it I can switch between it and normal wifi and TB still keeps going OK. This changes the route but not the end IP address  of the server so maybe not the same issues as VPN?

I am more referring to the case where the end IP address of the server change in the process of change of network. E.g local IP vs remote IP for example. Which may be likely to happen if you connect to a corporate VPN for example, especially if set to route all traffic via VPN.

Upon network status change, Thunderbird shall not only Get Message when network up event, but clear existing connection and re-connect with a new one to take into consideration network changes. That include clearing connection cache such as socket, DNS, etc... 

Recent version of windows clear the Windows DNS cache upon network changes (before it was not) but because Thunderbird use its own cache (rather than the system one) its DNS cache is not cleared. Still trying to use old cached end IP address, instead of looking up again to get the new one and re-connect with it to the server.

The mechanism may already be available in Thunderbird, they may just not be properly triggered upon network up event.

That said, for the change of IP issue, there may need some adjustments as putting TB offline and back online does not seems to clear cached connection and reset it. Which I would expect should happen in that case as well.

Does it make more sense now?

(In reply to gene smith from comment #17)
> > TB shall not try to reconnect unless the network is ready and functional, and should do so as soon as it happens.
> 
> Right now that doesn't happen. An attempt is made to connect and it fails and there is no real retry other than try again at the next biff time. Also, don't think there is a signal that there is no network available at TB startup or after an OS wake-up. Or if there is a signal (network up or down), it is not currently hooked onto in imap code (but I could be wrong :)).

It should be down to the automatic triggering of **Get Message** button command **upon network up event**. This action do re-connect (I believe) to the IMAP server as part as the process and check for new emails.

> > The alternative use case could also be a switch of network for example after a VPN connection that may completely change IP range (connection via local IP rather than external IP).
> 
> I don't have a VPN but I do have a cell phone wifi "hot spot" that I use sometimes when electrical power is off (storms, etc). I think when I use it I can switch between it and normal wifi and TB still keeps going OK. This changes the route but not the end IP address  of the server so maybe not the same issues as VPN?

I am more referring to the case where the end IP address of the server change in the process of change of network. E.g local IP vs remote IP for example. Which may be likely to happen if you connect to a corporate VPN for example, especially if set to route all traffic via VPN.

Upon network status change, Thunderbird shall not only Get Message when network up event, but clear existing connection and re-connect with a new one to take into consideration network changes. That include clearing connection cache such as socket, DNS, etc... 

Recent version of windows clear the Windows DNS cache upon network changes (before it was not) but because Thunderbird use its own cache (rather than the system one) its DNS cache is not cleared. Still trying to use old cached end IP address, instead of looking up again to get the new one and re-connect with it to the server.

The mechanism may already be available in Thunderbird, they may just not be properly triggered upon network up event.

That said, for the change of IP issue, there may need some adjustments as putting TB offline and back online does not seems to clear cached connection and reset it. Which I would expect should happen in that case as well.

Does it make more sense now?