Disable automatic connection switch

Jan Grulich jgrulich at redhat.com
Thu Jul 27 11:47:23 UTC 2017


Hi,

On středa 19. července 2017 10:03:55 CEST Federico Buti wrote:
> Hi list.
> 
> I've been tasked from my boss to write a little wrapper for
> NetworkManagerQt to provide specific operations suited from the devices of
> my company.
> 
> Currently the devices have wifi, umts modem and ethernet interfaces. The
> latter should not be used to communicate with our server thus I've added
> "never-default = true" to the eth. configuration we create. In most of
> other connections we heavily rely on "autoConnect" set to true so that once
> a connection with higher priority is available the NM just switches to that
> (e.g. umts modem to wifi).
> 

That should work, using "never-default" means that the connection won't  be 
the default one used for regular network traffic.

> So far, so good. Among the requirements of the API I should provide there
> must be a function do disable the automatic switch of connections. In
> certain cases we want that the current primary connection remains the
> primary one even if a connection with higher priority is available.
> 
> I thought about using again "never-default". Once my API to disable
> connections switch is called I simply set "never-default" to true on all
> the available connections expect the primary one. That is the most obvious
> approach I could come up with by reading NM API documentation.
> 

I think this would work only in case you set "never-default" before the new 
connection gets activated, if you use "autoconnect" then you won't have a 
chance to do so and you will have to re-connect the new connection again to 
take the new configuration. 

> Now, questions time:
> 
>    - Is my interpretation of the NM API correct?
>    - Is it the "right" approach?
>    - Is there a more smart/easy approach?
> 

I think the best would be to ask NM devs what could be the best approach for 
this and whatever solution they come up with, then you should be able to use 
NMQT for that as well.

Regards,
Jan



More information about the Kde-frameworks-devel mailing list