[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