Bug 272135 - Irrelevant entry highlighted in "Connections" section
Summary: Irrelevant entry highlighted in "Connections" section
Status: RESOLVED FIXED
Alias: None
Product: Network Management
Classification: Miscellaneous
Component: Plasma Widget (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Kügler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-01 12:51 UTC by Nikos Platis
Modified: 2011-05-08 20:58 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot displaying the bug (17.70 KB, image/jpeg)
2011-05-02 08:59 UTC, Nikos Platis
Details
Tentative fix (878 bytes, patch)
2011-05-02 13:36 UTC, Lamarque V. Souza
Details
Screenshot of icon with text over it (2.22 KB, image/jpeg)
2011-05-02 20:43 UTC, Nikos Platis
Details
Another tentative (8.61 KB, patch)
2011-05-03 02:39 UTC, Lamarque V. Souza
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos Platis 2011-05-01 12:51:17 UTC
Version:           unspecified (using KDE 4.6.2) 
OS:                Linux

My PC has two network interfaces, eth0 and eth1. Normally eth1 is connected.

If I hover over the "eth1" entry in the "Interfaces" section, then an arbitrary entry in the "Connections" section is highlighted, usually not the one that is active.

Actually I don't really know which entry should be highlighted, but I would expect that if one is highlighted, then this should be the active one.

If I hover over the "eth0" entry (which has no cable plugged), then no entry in the "Connections" gets highlighted.

This behavior is the same with several versions of plasma-networkmanagement: latest stable, latest git, latest git nm09 branch.

Sometimes, if I fiddle for some time with the connections (switch between the default and a static one that I have created for eth1) then the correct one gets highlighted.

Reproducible: Always
Comment 1 Lamarque V. Souza 2011-05-02 01:48:33 UTC
If you hover an interface Plasma NM will hover the connection associated to that interface independently if the connection is activated or not. If you have two instances of the same interface type it may happen the same connection is duplicated for each interface and you would not know which one activates which interface.

In my case my 3G modem and my cell phone are both Gsm type interface and there would be one connection for both with the same name, without the hover hightlight I could activate the wrong interface.

Your eth0 does not hover any connection because when there is no cable plugged all wired connections are removed from connection list to make it cleaner. When you have several interfaces (I have four plus one VPN) the connection list can get crowded.

If this explanation is satisfatory I will close this bug.
Comment 2 Nikos Platis 2011-05-02 08:59:49 UTC
Created attachment 59526 [details]
Screenshot displaying the bug

Attached a screenshot.

"Wired connection 1" and "Wired connection 2" are the (DHCP) connections automatically created by NM for eth0 and eth1 respectively. I haven't changed any of their settings apart from setting "Wired connection 2" to NOT connect automatically. "Static eth1" is a connection I have created with static IP for eth1 and set to connect automatically. The settings work OK, eth1 indeed has the static IP assigned.

So, about the hovering effect: should both "Wired connection 2" and "Static eth1" be highlighted? If so, there should probably be a way to show which of them is active.
Comment 3 Lamarque V. Souza 2011-05-02 09:12:41 UTC
Ok, I got it now. I will fix it in a few minutes, I am in the middle of fixing a commit conflict now.
Comment 4 Lamarque V. Souza 2011-05-02 09:29:42 UTC
Git commit ca71e9e8cc0ec808407c6f75cbb59ac342339d46 by Lamarque V. Souza.
Committed on 02/05/2011 at 09:39.
Pushed by lvsouza into branch 'nm09'.

Hover all connections associated to a network interface instead of just
the first one found.

BUG: 272135
(cherry picked from commit 2333c91f864e4fdbc6f2239b323b6d5d1743b0ac)

M  +0    -2    applet/activatablelistwidget.cpp     

http://commits.kde.org/networkmanagement/ca71e9e8cc0ec808407c6f75cbb59ac342339d46
Comment 5 Lamarque V. Souza 2011-05-02 09:30:08 UTC
Git commit 2333c91f864e4fdbc6f2239b323b6d5d1743b0ac by Lamarque V. Souza.
Committed on 02/05/2011 at 09:39.
Pushed by lvsouza into branch 'master'.

Hover all connections associated to a network interface instead of just
the first one found.

BUG: 272135

M  +0    -2    applet/activatablelistwidget.cpp     

http://commits.kde.org/networkmanagement/2333c91f864e4fdbc6f2239b323b6d5d1743b0ac
Comment 6 Nikos Platis 2011-05-02 09:44:42 UTC
Thanks for the quick response.

However, I think that more sophistication would be better: now when I hover over eth1 *all three* connections get highlighted, even "Wired connection 1" which is restricted to eth0 (probably because the check is only based on the interface type?)
Comment 7 Lamarque V. Souza 2011-05-02 09:50:32 UTC
Yes, the check is for interface type. The connection name the interface is connected to should appear above the interface name but it is not in your screenshot. I am trying to figure out why, but as far as I can tell Plasma NM is just not able to find the connection and returning a empty connection name. It works here for me for my wireless connection and the code is the same for both wifi and ethernet.
Comment 8 Nikos Platis 2011-05-02 10:25:40 UTC
If it is of any help, I am on Arch Linux using their latest package for NM:
http://www.archlinux.org/packages/extra/x86_64/networkmanager/
and this PKGBUILD file for my Plasma-NM to use the nm09 branch:
http://pastebin.com/wgQyTzd9
(but my earlier test were made using their latest Plasma-NM package:
http://www.archlinux.org/packages/extra/x86_64/kdeplasma-applets-networkmanagement/ )
Comment 9 Lamarque V. Souza 2011-05-02 11:10:43 UTC
Does the connection name problem happen with nm09 branch or master or both?
Comment 10 Nikos Platis 2011-05-02 12:23:57 UTC
I think you mean that, in my case, the eth1 connection should say "Connected to Static eth1" and overlay the blue globe icon?

This does not happen with any branch, I see exactly the same thing, only "Connected".

As far as I remember I have only seen this icon and text very seldom, with the older version of NM and Plasma-NM and only after fiddling for some time with connections (connecting/disconnecting).
Comment 11 Lamarque V. Souza 2011-05-02 13:36:59 UTC
Created attachment 59533 [details]
Tentative fix

Yes, it should appear "Connected to Static eth1" there and the blue globe indicates which interface has the default route to the Internet. I looked at the source code and to both that happen Plasma NM should be able to find the connection associated to the interface, so both are symptoms of the same problem.

It may be a race condition, when the interface state change Plasma NM tries to find the connection associated to the Internet, but it may happen that information has not been updated yet, and Plasma NM thinks there is no connection. Can you try the attached patch and see if it fix the problem?
Comment 12 Nikos Platis 2011-05-02 20:25:50 UTC
I managed to re-install NM 0.8.3 and (I think) to correctly patch and install plasma-nm from master.

Now plasma-nm works better, but not perfectly:
The tooltip mentions "Connected to Static eth1", the same text appears under the eth1 connection, and the globe icons appear correctly
BUT
The work "Interfaces" appears above the icon on the taskbar (!)
Comment 13 Nikos Platis 2011-05-02 20:43:56 UTC
Created attachment 59551 [details]
Screenshot of icon with text over it
Comment 14 Nikos Platis 2011-05-02 21:00:45 UTC
With the patched version, I also notice some issues regarding refreshing of the info displayed.

I do the following:
1. Being connected with "Static" I click to "DHCP" (I will use this as a shortcut for my automatically created connection with DHCP settings) - everything works OK
2. I click back to "Static" - Then sometimes the text beneath "eth1" remains "Preparing to connect" even when the connection has been established correctly. This does not happen always, sometimes the text is set correctly to "Connected to Static eth1".

Also a similar thing happens when I have clicked on the "eth1" entry and see the details of the connection:
- Switching from Static to DHCP all info gets updated correctly.
- Switching from DHCP to Static the intermediate messages on the "Connection state" field are displayed quickly but the final text reads "Not connected" even after the connection is established (and the IP address is displayed correctly). This happens all the time, and only when switching from DHCP to Static. If I later click on the icon and display the page again, the "state" field will be updated correctly.

Since the change DHCP -> Static gets completed very quickly, it seems to be some other form of race condition.

I will check this with the unpatched plasma-nm and report back.
Comment 15 Nikos Platis 2011-05-02 21:22:03 UTC
Using the unpatched plasma-nm, the behavior is quite different:
a) If I switch back and forth between Static and DHCP, the icon (and the text "connected to...") start to appear, and from then on get updated correctly at each change.
b) On the main page of plasma-nm, the text seems to be updated correctly to "Connected to Static eth1" in all my tests -- so the patch seems to cause some trouble here.
c) On the detail page, however, when I switch from DHCP to Static, all details disappear and do not appear again (until I refresh this page either by going back to the main page or by hiding the plasma-nm and showing it again). When switching from Static to DHCP the details disappear momentarily and are displayed again.

So again, on the detail page, there seem to be some sort of race condition since the change to Static is very quick.
Comment 16 Lamarque V. Souza 2011-05-03 01:49:17 UTC
The "Interface" name in task bar is really odd.

processEvents is not a good idea, it changes the order in which Plasma NM processes interface's status changes ("Connected to Static eth1" status being processed before the "Preparing to connect"). It may solve the connection not being found problem but the side effects are not acceptable.
Comment 17 Lamarque V. Souza 2011-05-03 02:39:08 UTC
Created attachment 59560 [details]
Another tentative

Please try this new patch. It is not final, I am going to improve it if it really works.
Comment 18 Lamarque V. Souza 2011-05-08 20:58:34 UTC
Let's move the discussion of the "eth unplugged" problem to http://bugs.kde.org/256400 since the problem in the title of this bug was fixed.