[Interest] Bearer management on Linux with NetworkManager and switching between different connection profiles

Jan Kundr√°t jkt at flaska.net
Thu Dec 26 13:00:30 CET 2013


Hi,
my application uses QSslSockets for communicating with an IMAP server. On 
Linux with NetworkManager, the network connectivity stops working after 
switching between the wired Ethernet and WiFi connections; I have to 
manually disconnect and reconnect from within the application.

I've tried to follow the steps at [1], but the QNetworkSession instance I 
create using the default configuration does not ever emit the 
preferredConfigurationChanged signal. Indeed, the networkmanager bearer 
plugin does not appear to contain any reference to that signal. This is 
expected, I guess, because the manager's capabilities() returns 
CanStartAndStopInterfaces | ForcedRoaming. The problem I'm facing is that 
there is no clear signal to connect to telling me "hey, please reconnect 
now", though.

When I start the application, both eth0 and wlan0 are available. The 
QNetworkConfigurationManager::defaultConfiguration returns "eth0", which is 
correct. I therefore create a QNetworkSession based on this default 
configuration, and get back the opened() signal. So far, so good.

Upon unplugging the Ethernet cable, the QNetworkSession emits closed() and 
stateChanged(NotAvailable). At that point, the configuration manager emits 
configurationChanged() for the wired, "eth0" configuration. If I ask for 
manager's default configuration from within the slot connected to 
configurationChanged, I now get "wlan0". It seems that the only thing I can 
do at that point is to close the old QNetworkSession, replace it with the 
new one and reconnect. There is no documentation about that, AFAIK.

I find this API rather strange to work with. What I would appreciate is a 
signal telling me "hey, the platform decided that you have to reconnect, do 
it now". A simple pair of 
QNetworkConfigurationManager::onlineStateChanged() flapping between false 
and true would be enough. There is also no way of announcing that the 
default configuration has changed; the only workaround I was able to come 
up with involves comparing the old and new QNetworkConfiguration instances 
within a slot connected to the manager's configurationChanged, which looks 
ugly, IMHO.

Am I on a right track? What is the clean way of triggering the reconnects?

Cheers,
Jan

[1] http://qt-project.org/doc/qt-4.8/qnetworksession.html#details

-- 
Trojit√°, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/



More information about the Interest mailing list