Quassel IRC

reiterative wrote:

If the host's network connection is temporarily interrupted or altered (e.g. a network change from LAN to WLAN, or if the host goes into sleep mode and then reawakens), then Quassel client should seamlessly restore the connection to the core, or notify the user if the connection cannot be restored.

This does not seem to happen when running Quassel client on my laptop (Lenovo T14S, Debian Bullseye), and my colleagues report the same problem. Quassel client does not report a problem wit the network, but communication with the core appears to be broken, because no messages can be sent or received, until the client is restarted, or the core is manually disconnected and reconnected https://www.mycard-statement.com

Looking at the code (https://github.com/quassel/quassel/blob/3778a12912369eb5add886bb65ca74e9df841744/src/client/coreconnection.cpp#L61), it appears that the client registers for the onlineStateChanged signal, but perhaps it also needs to register for configurationChanged, so that it can verify that a change of network configuration has not broken the connection to the Core.

The observed issue with the Quassel client on laptops, where it fails to reconnect to the core after network changes (LAN to WLAN, sleep/wake), stems from its reliance on the basic onlineStateChanged signal, which isn't granular enough to detect subtle network shifts like IP address changes. This leaves the client with a stale connection, unable to send or receive data without manual intervention. To fix this, the client needs to monitor more specific network signals (e.g., QNetworkConfigurationManager::reachabilityChanged) to proactively detect connection invalidation, gracefully close the old connection, and initiate a new one, potentially with a periodic "heartbeat" check and user notification if reconnection fails after several attempts.