System-wide wireless connection bug

[Gökçen Eraslan]

Hello,

I've found another bug in KNM and prepared a patch for that. Problem is: I can
see wired system-wide connections in plasma applet but I can't see wireless
system-wide connections.

Steps to reproduce:
1- Add a system-wide wireless connection (using nm-applet unfortunately)
2- Try to connect it from KNM plasma applet.

Reason is that:

* kded module gets a system-wide wireless connection and calls
NMDBusSettingsConnectionProvider::initialiseAndRegisterRemoteConnection
method, in this method an empty Connection is created:

00096 Knm::Connection * connection = new Knm::Connection(QUuid(),
Knm::Connection::Wired);

At this point, connection type is wired but the setting gathered from NM DBus
interface is for a wireless connection. After that, empty connection gets
filled with ConnectionDbus class:

00097 ConnectionDbus dbusConverter(connection);
00098 dbusConverter.fromDbusMap(connectionIface->GetSettings());

and in fromDbusMap method:

00227 m_connection->setType(type);

is called. type of connection is changed using setType method, but Settings
objects of the connection are still for a wired connection because Connection
is initialized with Knm::Connection::Wired parameter. After that,
ConnectionDbus class tries change the settings :

00228
00229 // all other settings
00230 foreach (Setting * setting, m_connection->settings()) {
00231 if (settings.contains(setting->name())) {
00232 SettingDbus * sd = dbusFor(setting);
00233 sd->fromMap(settings.value(setting->name()));
00234 }
00235 }

but since the settings are all in wired type, this does not work and
connection has the wired settings. And in:
WirelessNetworkInterfaceActivatableProvider::handleAdd method:

00093 Knm::WirelessSetting * wirelessSetting =
dynamic_cast<Knm::WirelessSetting *>(addedConnection-

setting(Knm::Setting::Wireless));

00094
00095 if (wirelessSetting) {

it's checked whether the connection has a setting named 802-11-wireless, but
it doesn't since settings are still in wired type.

setType method of Connection class is wrong and must be changed since it just
changes the type and does not change Settings objects created in init method.

Here is the attached patch to regenerate Settings objects of connection when
setType is called with a second parameter regenerateSettings. An alternative
solution would be making ConnectionDbus and Connection classes friends, so
ConnectionDbus::fromDbusMap method can create new Settings objects itself.

Cheers.

[Lamarque Vieira Souza]

Hi,

What is the status of your work on system connections implementation?
Does it still have the problems you mentioned below? I see you have been
working in a git branch:

http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2Fgokcen%2Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide

with several modifications for networkmanagement besides system
connections. Do you plan to push those changes to master?

Post by Gökçen Eraslan
Hello,
I've found another bug in KNM and prepared a patch for that. Problem is: I
can see wired system-wide connections in plasma applet but I can't see
wireless system-wide connections.
1- Add a system-wide wireless connection (using nm-applet unfortunately)
2- Try to connect it from KNM plasma applet.
* kded module gets a system-wide wireless connection and calls
NMDBusSettingsConnectionProvider::initialiseAndRegisterRemoteConnection
00096 Knm::Connection * connection = new Knm::Connection(QUuid(),
Knm::Connection::Wired);
At this point, connection type is wired but the setting gathered from NM
DBus interface is for a wireless connection. After that, empty connection
00097 ConnectionDbus dbusConverter(connection);
00098 dbusConverter.fromDbusMap(connectionIface->GetSettings());
00227 m_connection->setType(type);
is called. type of connection is changed using setType method, but Settings
objects of the connection are still for a wired connection because
Connection is initialized with Knm::Connection::Wired parameter. After
that,
00228
00229 // all other settings
00230 foreach (Setting * setting, m_connection->settings()) {
00231 if (settings.contains(setting->name())) {
00232 SettingDbus * sd = dbusFor(setting);
00233 sd->fromMap(settings.value(setting->name()));
00234 }
00235 }
but since the settings are all in wired type, this does not work and
00093 Knm::WirelessSetting * wirelessSetting =
dynamic_cast<Knm::WirelessSetting *>(addedConnection-

setting(Knm::Setting::Wireless));

00094
00095 if (wirelessSetting) {
it's checked whether the connection has a setting named 802-11-wireless,
but it doesn't since settings are still in wired type.
setType method of Connection class is wrong and must be changed since it
just changes the type and does not change Settings objects created in init
method.
Here is the attached patch to regenerate Settings objects of connection
when setType is called with a second parameter regenerateSettings. An
alternative solution would be making ConnectionDbus and Connection classes
friends, so ConnectionDbus::fromDbusMap method can create new Settings
objects itself.
Cheers.

[Andrey Borzenkov]

Hi,
What is the status of your work on system connections implementation? Does
it still have the problems you mentioned below? I see you have been working
http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2Fgokcen%2Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
with several modifications for networkmanagement besides system connections.

I was testing this branch and I do not remember any issue with
wireless - I think I could see both wired and wireless system
connections.

Do you plan to push those changes to master?

This branch does not support user settings as of now. What are plans
regarding NM 0.9? It dropped user settings completely; may be it makes
sense to target this branch at NM 0.9 support? This obsoletes user
settings problem completely.

Post by Gökçen Eraslan
Hello,
I've found another bug in KNM and prepared a patch for that. Problem is: I
can see wired system-wide connections in plasma applet but I can't see
wireless system-wide connections.
1- Add a system-wide wireless connection (using nm-applet unfortunately)
2- Try to connect it from KNM plasma applet.
* kded module gets a system-wide wireless connection and calls
NMDBusSettingsConnectionProvider::initialiseAndRegisterRemoteConnection
00096 Knm::Connection * connection = new Knm::Connection(QUuid(),
Knm::Connection::Wired);
At this point, connection type is wired but the setting gathered from NM
DBus interface is for a wireless connection. After that, empty connection
00097 ConnectionDbus dbusConverter(connection);
00098 dbusConverter.fromDbusMap(connectionIface->GetSettings());
00227 m_connection->setType(type);
is called. type of connection is changed using setType method, but Settings
objects of the connection are still for a wired connection because
Connection is initialized with Knm::Connection::Wired parameter. After
that,
00228
00229 // all other settings
00230 foreach (Setting * setting, m_connection->settings()) {
00231 if (settings.contains(setting->name())) {
00232 SettingDbus * sd = dbusFor(setting);
00233 sd->fromMap(settings.value(setting->name()));
00234 }
00235 }
but since the settings are all in wired type, this does not work and
00093 Knm::WirelessSetting * wirelessSetting =
dynamic_cast<Knm::WirelessSetting *>(addedConnection-

setting(Knm::Setting::Wireless));

00094
00095 if (wirelessSetting) {
it's checked whether the connection has a setting named 802-11-wireless,
but it doesn't since settings are still in wired type.
setType method of Connection class is wrong and must be changed since it
just changes the type and does not change Settings objects created in init
method.
Here is the attached patch to regenerate Settings objects of connection
when setType is called with a second parameter regenerateSettings. An
alternative solution would be making ConnectionDbus and Connection classes
friends, so ConnectionDbus::fromDbusMap method can create new Settings
objects itself.
Cheers.

--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://www.kde-mg.org
_______________________________________________
kde-networkmanager mailing list
kde-networkmanager at kde.org
https://mail.kde.org/mailman/listinfo/kde-networkmanager

[Andrey Borzenkov]

On Wed, Mar 9, 2011 at 9:56 PM, Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Hi,
What is the status of your work on system connections implementation?
Does it still have the problems you mentioned below? I see you have been
http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2Fgokcen%2
Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
with several modifications for networkmanagement besides system
connections.

I was testing this branch and I do not remember any issue with
wireless - I think I could see both wired and wireless system
connections.

Good to know that.

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Do you plan to push those changes to master?

This branch does not support user settings as of now. What are plans
regarding NM 0.9? It dropped user settings completely; may be it makes
sense to target this branch at NM 0.9 support? This obsoletes user
settings problem completely.

We still need user settings support for those who are not going to upgrade
to NM 0.9 soon. Have you tested that branch against a NM 0.9 snapshot?

No. It is very unlikely to work due to D-Bus API changes, secrets
handling changes, ...

I do not know if it possible at all to have support for both NM 0.8
and NM 0.9 in a single program. For a start, all NM lib major were
increased so it is not clear how to even compile such binary.

I thought more about current KNM 0.9 support NM 0.8 and move forward
to 0.10 (or whatever) with NM 0.9 support.

I
still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM 0.9
specification. Maybe it is a good idea to create a new networkmanager-0.9
backend in kde://kde-workspace/solid/

Does it help?

http://projects.gnome.org/NetworkManager/developers/migrating-to-09/

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza

Post by Gökçen Eraslan
Hello,
I've found another bug in KNM and prepared a patch for that. Problem
I
can see wired system-wide connections in plasma applet but I can't see
wireless system-wide connections.
1- Add a system-wide wireless connection (using nm-applet
unfortunately)
2- Try to connect it from KNM plasma applet.
* kded module gets a system-wide wireless connection and calls
NMDBusSettingsConnectionProvider::initialiseAndRegisterRemoteConnection
00096 Knm::Connection * connection = new Knm::Connection(QUuid(),
Knm::Connection::Wired);
At this point, connection type is wired but the setting gathered from NM
DBus interface is for a wireless connection. After that, empty
connection
00097 ConnectionDbus dbusConverter(connection);
00098 dbusConverter.fromDbusMap(connectionIface->GetSettings());
00227 m_connection->setType(type);
is called. type of connection is changed using setType method, but
Settings
objects of the connection are still for a wired connection because
Connection is initialized with Knm::Connection::Wired parameter. After
that,
00228
00229 // all other settings
00230 foreach (Setting * setting, m_connection->settings()) {
00231 if (settings.contains(setting->name())) {
00232 SettingDbus * sd = dbusFor(setting);
00233 sd->fromMap(settings.value(setting->name()));
00234 }
00235 }
but since the settings are all in wired type, this does not work and
00093 Knm::WirelessSetting * wirelessSetting =
dynamic_cast<Knm::WirelessSetting *>(addedConnection-

setting(Knm::Setting::Wireless));

00094
00095 if (wirelessSetting) {
it's checked whether the connection has a setting named
802-11-wireless,
but it doesn't since settings are still in wired type.
setType method of Connection class is wrong and must be changed since it
just changes the type and does not change Settings objects created in
init
method.
Here is the attached patch to regenerate Settings objects of connection
when setType is called with a second parameter regenerateSettings. An
alternative solution would be making ConnectionDbus and Connection
classes
friends, so ConnectionDbus::fromDbusMap method can create new Settings
objects itself.
Cheers.

--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://www.kde-mg.org
_______________________________________________
kde-networkmanager mailing list
kde-networkmanager at kde.org
https://mail.kde.org/mailman/listinfo/kde-networkmanager

--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://www.kde-mg.org

[Jirka Klimes]

Post by Andrey Borzenkov
On Wed, Mar 9, 2011 at 9:56 PM, Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Hi,
What is the status of your work on system connections implementation?
Does it still have the problems you mentioned below? I see you have been
http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2Fgokce
n%2
Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
with several modifications for networkmanagement besides system
connections.

I was testing this branch and I do not remember any issue with
wireless - I think I could see both wired and wireless system
connections.

Good to know that.

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Do you plan to push those changes to master?

This branch does not support user settings as of now. What are plans
regarding NM 0.9? It dropped user settings completely; may be it makes
sense to target this branch at NM 0.9 support? This obsoletes user
settings problem completely.

We still need user settings support for those who are not going to
upgrade to NM 0.9 soon. Have you tested that branch against a NM 0.9
snapshot?

No. It is very unlikely to work due to D-Bus API changes, secrets
handling changes, ...
I do not know if it possible at all to have support for both NM 0.8
and NM 0.9 in a single program. For a start, all NM lib major were
increased so it is not clear how to even compile such binary.
I thought more about current KNM 0.9 support NM 0.8 and move forward
to 0.10 (or whatever) with NM 0.9 support.

I
still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM 0.9
specification. Maybe it is a good idea to create a new networkmanager-0.9
backend in kde://kde-workspace/solid/

Does it help?
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/

Hi guys,

yeah, NM 0.9 changes the API a bit, so it is not compatible with 0.8.
Basicaly the API is simplified and applets can save a ton of code, because they
don't have to deal with user connections.

Moreover, Dan would like to release NM 0.9 very soon (16th of March):
http://blogs.gnome.org/dcbw/2011/02/24/networkmanager-0-8-4-beta1-gets-all-up-
in-there/

And it will be in Fedora 15 too. Most of the stuff that depends on the new NM
is already changed. But the KDE'a applet is not ready. And we don't what to
let KDE users down. I think it's better to do the work right in upstream than
just make patches for Fedora.
I would suggest to create a new branch in the main repo for that to be able to
have separate applets for NM 0.8 and NM 0.9.

Since NM 0.9 uses just system-wide connections it is crucial that knm supports
them. Is the cloned repo with the systemwide branch working? Could it be
merged to the new branch for NM 0.9 created on main repo?

Yeah, the API changes are here:
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/
I am ready to help with the migration to NM 0.9.

BTW, is the Solid code dependent on NM version or is it sufficient to just adapt
networkmanagement applet?

Cheers,
Jirka

[Andrey Borzenkov]

Post by Jirka Klimes

Post by Andrey Borzenkov
On Wed, Mar 9, 2011 at 9:56 PM, Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Hi,
What is the status of your work on system connections implementation?
Does it still have the problems you mentioned below? I see you have been
http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2Fgokce
n%2
Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
with several modifications for networkmanagement besides system
connections.

I was testing this branch and I do not remember any issue with
wireless - I think I could see both wired and wireless system
connections.

Good to know that.

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Do you plan to push those changes to master?

This branch does not support user settings as of now. What are plans
regarding NM 0.9? It dropped user settings completely; may be it makes
sense to target this branch at NM 0.9 support? This obsoletes user
settings problem completely.

We still need user settings support for those who are not going to
upgrade to NM 0.9 soon. Have you tested that branch against a NM 0.9
snapshot?

No. It is very unlikely to work due to D-Bus API changes, secrets
handling changes, ...
I do not know if it possible at all to have support for both NM 0.8
and NM 0.9 in a single program. For a start, all NM lib major were
increased so it is not clear how to even compile such binary.
I thought more about current KNM 0.9 support NM 0.8 and move forward
to 0.10 (or whatever) with NM 0.9 support.

I
still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM 0.9
specification. Maybe it is a good idea to create a new networkmanager-0.9
backend in kde://kde-workspace/solid/

Does it help?
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/

Hi guys,
yeah, NM 0.9 changes the API a bit, so it is not compatible with 0.8.
Basicaly the API is simplified and applets can save a ton of code, because they
don't have to deal with user connections.
http://blogs.gnome.org/dcbw/2011/02/24/networkmanager-0-8-4-beta1-gets-all-up-
in-there/
And it will be in Fedora 15 too. Most of the stuff that depends on the new NM
is already changed. But the KDE'a applet is not ready. And we don't what to
let KDE users down. I think it's better to do the work right in upstream than
just make patches for Fedora.
I would suggest to create a new branch in the main repo for that to be able to
have separate applets for NM 0.8 and NM 0.9.
Since NM 0.9 uses just system-wide connections it is crucial that knm supports
them. Is the cloned repo with the systemwide branch working? Could it be
merged to the new branch for NM 0.9 created on main repo?
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/
I am ready to help with the migration to NM 0.9.
BTW, is the Solid code dependent on NM version or is it sufficient to just adapt
networkmanagement applet?

Well ... except for missing new properties and lack of IPv6 support,
the main difference is WWAN; those methods no more exist:

org.freedesktop.NetworkManager.Device.Cdma,
org.freedesktop.NetworkManager.Device.Gsm,
org.freedesktop.NetworkManager.Device.Serial

Wired/wireless should actually work I guess to fetch those properties
that are supported by Solid.

So yes, some adaptation of Solid is required for mobile to work.

[Lamarque Vieira Souza]

Post by Andrey Borzenkov

Post by Jirka Klimes

Post by Andrey Borzenkov
On Wed, Mar 9, 2011 at 9:56 PM, Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Hi,
What is the status of your work on system connections
implementation?
Does it still have the problems you mentioned below? I see you have been
http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2Fgo
kce n%2
Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
with several modifications for networkmanagement besides system
connections.

I was testing this branch and I do not remember any issue with
wireless - I think I could see both wired and wireless system
connections.

Good to know that.

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Do you plan to push those changes to master?

This branch does not support user settings as of now. What are plans
regarding NM 0.9? It dropped user settings completely; may be it makes
sense to target this branch at NM 0.9 support? This obsoletes user
settings problem completely.

We still need user settings support for those who are not going to
upgrade to NM 0.9 soon. Have you tested that branch against a NM 0.9
snapshot?

No. It is very unlikely to work due to D-Bus API changes, secrets
handling changes, ...
I do not know if it possible at all to have support for both NM 0.8
and NM 0.9 in a single program. For a start, all NM lib major were
increased so it is not clear how to even compile such binary.
I thought more about current KNM 0.9 support NM 0.8 and move forward
to 0.10 (or whatever) with NM 0.9 support.

I
still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM 0.9
specification. Maybe it is a good idea to create a new
networkmanager-0.9 backend in kde://kde-workspace/solid/

Does it help?
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/

Hi guys,
yeah, NM 0.9 changes the API a bit, so it is not compatible with 0.8.
Basicaly the API is simplified and applets can save a ton of code,
because they don't have to deal with user connections.
http://blogs.gnome.org/dcbw/2011/02/24/networkmanager-0-8-4-beta1-gets-al
l-up- in-there/

That is too soon for KDE :-/

Post by Andrey Borzenkov

Post by Jirka Klimes
And it will be in Fedora 15 too. Most of the stuff that depends on the
new NM is already changed. But the KDE'a applet is not ready. And we
don't what to let KDE users down. I think it's better to do the work
right in upstream than just make patches for Fedora.

I agree about working with upstream, that really helps.

Post by Andrey Borzenkov

Post by Jirka Klimes
I would suggest to create a new branch in the main repo for that to be
able to have separate applets for NM 0.8 and NM 0.9.

Sebastian K?gler <sebas at kde.org> and Will Stephenson
<wstephenson at kde.org> have to approve that in my oppinion, specially because
Will is officially the Plasma NM maintainer. Sebas, Will, what do you think?

Post by Andrey Borzenkov

Post by Jirka Klimes
Since NM 0.9 uses just system-wide connections it is crucial that knm
supports them. Is the cloned repo with the systemwide branch working?
Could it be merged to the new branch for NM 0.9 created on main repo?

It seems to be working according to Andrey Borzenkov, but the repo's ower
(G?kcen Eraslan) has not appeared here in list for few months. I would like
him to answer that question and if he has tested the code against a NM-0.9
snapshot. The repository also contains changes not related to system
connections implementation.

Post by Andrey Borzenkov

Post by Jirka Klimes
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/
I am ready to help with the migration to NM 0.9.
BTW, is the Solid code dependent on NM version or is it sufficient to
just adapt networkmanagement applet?

Well ... except for missing new properties and lack of IPv6 support,

You mean those DBus' interfaces.

Post by Andrey Borzenkov
org.freedesktop.NetworkManager.Device.Cdma,
org.freedesktop.NetworkManager.Device.Gsm,
org.freedesktop.NetworkManager.Device.Serial
Wired/wireless should actually work I guess to fetch those properties
that are supported by Solid.
So yes, some adaptation of Solid is required for mobile to work.

I think it is better add a new Solid NM-0.9 backend
(git://anongit.kde.org/kde-workspace/solid/networkmanagement-0.9) to deal with
that changes in Solid. Anway, those changes are going to be available only in
KDE SC 4.7, which is scheduled to be released late July, unless we get
approval to change KDE SC's API before that. Releasing those changes before
KDE SC 4.7 is another thing that should be discussed with Sebas and Will.

[Lamarque Vieira Souza]

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Jirka Klimes

Post by Andrey Borzenkov
On Wed, Mar 9, 2011 at 9:56 PM, Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Hi,
What is the status of your work on system connections implementation?
Does it still have the problems you mentioned below? I see you
have been
http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2F
go kce n%2
Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
with several modifications for networkmanagement besides system
connections.

I was testing this branch and I do not remember any issue with
wireless - I think I could see both wired and wireless system
connections.

Good to know that.

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Do you plan to push those changes to master?

This branch does not support user settings as of now. What are plans
regarding NM 0.9? It dropped user settings completely; may be it makes
sense to target this branch at NM 0.9 support? This obsoletes user
settings problem completely.

We still need user settings support for those who are not going to
upgrade to NM 0.9 soon. Have you tested that branch against a NM 0.9
snapshot?

No. It is very unlikely to work due to D-Bus API changes, secrets
handling changes, ...
I do not know if it possible at all to have support for both NM 0.8
and NM 0.9 in a single program. For a start, all NM lib major were
increased so it is not clear how to even compile such binary.
I thought more about current KNM 0.9 support NM 0.8 and move forward
to 0.10 (or whatever) with NM 0.9 support.

I
still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM
0.9 specification. Maybe it is a good idea to create a new
networkmanager-0.9 backend in kde://kde-workspace/solid/

Does it help?
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/

Hi guys,
yeah, NM 0.9 changes the API a bit, so it is not compatible with 0.8.
Basicaly the API is simplified and applets can save a ton of code,
because they don't have to deal with user connections.
http://blogs.gnome.org/dcbw/2011/02/24/networkmanager-0-8-4-beta1-gets-
al l-up- in-there/

That is too soon for KDE :-/

Post by Andrey Borzenkov

Post by Jirka Klimes
And it will be in Fedora 15 too. Most of the stuff that depends on the
new NM is already changed. But the KDE'a applet is not ready. And we
don't what to let KDE users down. I think it's better to do the work
right in upstream than just make patches for Fedora.

I agree about working with upstream, that really helps.

Post by Andrey Borzenkov

Post by Jirka Klimes
I would suggest to create a new branch in the main repo for that to be
able to have separate applets for NM 0.8 and NM 0.9.

Sebastian K?gler <sebas at kde.org> and Will Stephenson
<wstephenson at kde.org> have to approve that in my oppinion, specially
because Will is officially the Plasma NM maintainer. Sebas, Will, what do
you think?

Post by Andrey Borzenkov

Post by Jirka Klimes
Since NM 0.9 uses just system-wide connections it is crucial that knm
supports them. Is the cloned repo with the systemwide branch working?
Could it be merged to the new branch for NM 0.9 created on main repo?

It seems to be working according to Andrey Borzenkov, but the repo's ower
(G?kcen Eraslan) has not appeared here in list for few months. I would like
him to answer that question and if he has tested the code against a NM-0.9
snapshot. The repository also contains changes not related to system
connections implementation.

Post by Andrey Borzenkov

Post by Jirka Klimes
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/
I am ready to help with the migration to NM 0.9.
BTW, is the Solid code dependent on NM version or is it sufficient to
just adapt networkmanagement applet?

Well ... except for missing new properties and lack of IPv6 support,

You mean those DBus' interfaces.

Post by Andrey Borzenkov
org.freedesktop.NetworkManager.Device.Cdma,
org.freedesktop.NetworkManager.Device.Gsm,
org.freedesktop.NetworkManager.Device.Serial
Wired/wireless should actually work I guess to fetch those properties
that are supported by Solid.
So yes, some adaptation of Solid is required for mobile to work.

I think it is better add a new Solid NM-0.9 backend
(git://anongit.kde.org/kde-workspace/solid/networkmanagement-0.9) to deal
with that changes in Solid. Anway, those changes are going to be available
only in KDE SC 4.7, which is scheduled to be released late July, unless we
get approval to change KDE SC's API before that. Releasing those changes
before KDE SC 4.7 is another thing that should be discussed with Sebas and
Will.

Include
Kevin Ottens <ervin at kde.org> in that list too. He's the Solid's maintainer.

[Andrey Borzenkov]

On Thu, Mar 10, 2011 at 11:45 PM, Lamarque Vieira Souza

Post by Lamarque Vieira Souza

Post by Jirka Klimes
Since NM 0.9 uses just system-wide connections it is crucial that knm
supports them. Is the cloned repo with the systemwide branch working?
Could it be merged to the new branch for NM 0.9 created on main repo?

It seems to be working according to Andrey Borzenkov,

I asked Pardus guy and he replied

==
Though I couldn't understand who said what from the thread, We didn't
test the current system-wide branch against 0.9, but we're using it with
latest 0.8 for months.
==

He mentioned some problems with VPN stuff, I did not test it myself.

[Sebastian Kügler]

[Adding G?kcen to CC:]

Post by Andrey Borzenkov
On Thu, Mar 10, 2011 at 11:45 PM, Lamarque Vieira Souza

Post by Lamarque Vieira Souza

Post by Jirka Klimes
Since NM 0.9 uses just system-wide connections it is crucial that knm
supports them. Is the cloned repo with the systemwide branch working?
Could it be merged to the new branch for NM 0.9 created on main repo?

It seems to be working according to Andrey Borzenkov,

I asked Pardus guy and he replied
==
Though I couldn't understand who said what from the thread, We didn't
test the current system-wide branch against 0.9, but we're using it with
latest 0.8 for months.
==

Would be nice if we could merge this branch, users are waiting for this...

[Sebastian Kügler]

Hey guys,

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Jirka Klimes

Post by Andrey Borzenkov

We still need user settings support for those who are not going to
upgrade to NM 0.9 soon. Have you tested that branch against a NM 0.9
snapshot?

No. It is very unlikely to work due to D-Bus API changes, secrets
handling changes, ...
I do not know if it possible at all to have support for both NM 0.8
and NM 0.9 in a single program. For a start, all NM lib major were
increased so it is not clear how to even compile such binary.
I thought more about current KNM 0.9 support NM 0.8 and move forward
to 0.10 (or whatever) with NM 0.9 support.

I
still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM
0.9 specification. Maybe it is a good idea to create a new
networkmanager-0.9 backend in kde://kde-workspace/solid/

Does it help?
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/

Hi guys,
yeah, NM 0.9 changes the API a bit, so it is not compatible with 0.8.
Basicaly the API is simplified and applets can save a ton of code,
because they don't have to deal with user connections.
http://blogs.gnome.org/dcbw/2011/02/24/networkmanager-0-8-4-beta1-gets-
al l-up- in-there/

That is too soon for KDE :-/

Well, we won't have it supported at release time, but having NM 0.9 out if
important for us so we can start the transition.

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov

Post by Jirka Klimes
And it will be in Fedora 15 too. Most of the stuff that depends on the
new NM is already changed. But the KDE'a applet is not ready. And we
don't what to let KDE users down. I think it's better to do the work
right in upstream than just make patches for Fedora.

I agree about working with upstream, that really helps.

Post by Andrey Borzenkov

Post by Jirka Klimes
I would suggest to create a new branch in the main repo for that to be
able to have separate applets for NM 0.8 and NM 0.9.

Sebastian K?gler <sebas at kde.org> and Will Stephenson
<wstephenson at kde.org> have to approve that in my oppinion, specially
because Will is officially the Plasma NM maintainer. Sebas, Will, what do
you think?

Yes, that's what branches are for. :)

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov
Wired/wireless should actually work I guess to fetch those properties
that are supported by Solid.
So yes, some adaptation of Solid is required for mobile to work.

I think it is better add a new Solid NM-0.9 backend
(git://anongit.kde.org/kde-workspace/solid/networkmanagement-0.9) to deal
with that changes in Solid. Anway, those changes are going to be available
only in KDE SC 4.7, which is scheduled to be released late July, unless we
get approval to change KDE SC's API before that. Releasing those changes
before KDE SC 4.7 is another thing that should be discussed with Sebas and
Will.

No strong preference from my side, what do others think? It would surely be
nice if we had as little duplicated code as possible, but retain support for
"older" versions of NM.

Cheers,

[Andrey Borzenkov]

Post by Sebastian Kügler
Hey guys,

Post by Jirka Klimes

Post by Andrey Borzenkov

We still need user settings support for those who are not going to
upgrade to NM 0.9 soon. Have you tested that branch against a NM 0.9
snapshot?

No. It is very unlikely to work due to D-Bus API changes, secrets
handling changes, ...
I do not know if it possible at all to have support for both NM 0.8
and NM 0.9 in a single program. For a start, all NM lib major were
increased so it is not clear how to even compile such binary.
I thought more about current KNM 0.9 support NM 0.8 and move forward
to 0.10 (or whatever) with NM 0.9 support.

I
still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM
0.9 specification. Maybe it is a good idea to create a new
networkmanager-0.9 backend in kde://kde-workspace/solid/

Does it help?
http://projects.gnome.org/NetworkManager/developers/migrating-to-09/

Hi guys,
yeah, NM 0.9 changes the API a bit, so it is not compatible with 0.8.
Basicaly the API is simplified and applets can save a ton of code,
because they don't have to deal with user connections.
http://blogs.gnome.org/dcbw/2011/02/24/networkmanager-0-8-4-beta1-gets-
al l-up- in-there/

? ? ? That is too soon for KDE :-/

Well, we won't have it supported at release time, but having NM 0.9 out if
important for us so we can start the transition.

I think, the most smooth transition can be achieved by factoring out
current local connection handling code in separate (kded?) module and
making applet talk to it via D-Bus. Then minimal changes would be
necessary in applet to transition to NM 0.9, because it will handle
connection only via D-Bus anyway; and connection module could be
transitioned to secrets agent for NM 0.9. Depending on amount of
changes, it may even be possible to conditionally use NM 0.8/0.9 code
in the same binary.

Comments?

Any pointers or short introduction to sources structure to achieve
this split (besides readme in KNM tree)?

[Lamarque Vieira Souza]

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Hi,
What is the status of your work on system connections implementation?
Does it still have the problems you mentioned below? I see you have been
http://quickgit.kde.org/index.php?p=clones%2Fnetworkmanagement%2Fgokcen%2
Fnetworkmanagement.git&a=shortlog&h=refs/heads/systemwide
with several modifications for networkmanagement besides system connections.

I was testing this branch and I do not remember any issue with
wireless - I think I could see both wired and wireless system
connections.

Good to know that.

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza
Do you plan to push those changes to master?

This branch does not support user settings as of now. What are plans
regarding NM 0.9? It dropped user settings completely; may be it makes
sense to target this branch at NM 0.9 support? This obsoletes user
settings problem completely.

We still need user settings support for those who are not going to
upgrade to NM 0.9 soon. Have you tested that branch against a NM 0.9 snapshot?
I still need to figure out what kind of changes we will need to do in
Solid::Control::NetworkManager (or its successor) to accomodate NM 0.9
specification. Maybe it is a good idea to create a new networkmanager-0.9
backend in kde://kde-workspace/solid/

Post by Andrey Borzenkov

Post by Lamarque Vieira Souza

Post by Gökçen Eraslan
Hello,
I've found another bug in KNM and prepared a patch for that. Problem is: I
can see wired system-wide connections in plasma applet but I can't see
wireless system-wide connections.
1- Add a system-wide wireless connection (using nm-applet unfortunately)
2- Try to connect it from KNM plasma applet.
* kded module gets a system-wide wireless connection and calls
NMDBusSettingsConnectionProvider::initialiseAndRegisterRemoteConnection
00096 Knm::Connection * connection = new Knm::Connection(QUuid(),
Knm::Connection::Wired);
At this point, connection type is wired but the setting gathered from NM
DBus interface is for a wireless connection. After that, empty connection
00097 ConnectionDbus dbusConverter(connection);
00098 dbusConverter.fromDbusMap(connectionIface->GetSettings());
00227 m_connection->setType(type);
is called. type of connection is changed using setType method, but Settings
objects of the connection are still for a wired connection because
Connection is initialized with Knm::Connection::Wired parameter. After
that,
00228
00229 // all other settings
00230 foreach (Setting * setting, m_connection->settings()) {
00231 if (settings.contains(setting->name())) {
00232 SettingDbus * sd = dbusFor(setting);
00233 sd->fromMap(settings.value(setting->name()));
00234 }
00235 }
but since the settings are all in wired type, this does not work and
00093 Knm::WirelessSetting * wirelessSetting =
dynamic_cast<Knm::WirelessSetting *>(addedConnection-

setting(Knm::Setting::Wireless));

00094
00095 if (wirelessSetting) {
it's checked whether the connection has a setting named 802-11-wireless,
but it doesn't since settings are still in wired type.
setType method of Connection class is wrong and must be changed since it
just changes the type and does not change Settings objects created in init
method.
Here is the attached patch to regenerate Settings objects of connection
when setType is called with a second parameter regenerateSettings. An
alternative solution would be making ConnectionDbus and Connection classes
friends, so ConnectionDbus::fromDbusMap method can create new Settings
objects itself.
Cheers.

--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
http://www.kde-mg.org
_______________________________________________
kde-networkmanager mailing list
kde-networkmanager at kde.org
https://mail.kde.org/mailman/listinfo/kde-networkmanager