By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2748 - Tdenetworkmanager shows no wireless networks on TDE14/Debian_Stretch
Summary: Tdenetworkmanager shows no wireless networks on TDE14/Debian_Stretch
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdenetwork (show other bugs)
Version: R14.1.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Slávek Banko
URL:
Depends on:
Blocks: R14.0.5
  Show dependency tree / graph
 
Reported: 2017-02-11 04:04 CST by Q4OS Team
Modified: 2017-06-18 09:23 CDT (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String: 14.1.0 [development]
Application Version: 0.9-12.16.x86_64
Application Name: trinity-tdenetworkmanager-2

Attachments
tdelibs / tdehw : Use TDENetworkDevice in connectionManager (22.21 KB, patch)
2017-06-05 20:06 CDT, Slávek Banko 		Details | Diff
tdenetworkmanager : Use deviceNode instead macAddress (4.92 KB, patch)
2017-06-06 09:58 CDT, Slávek Banko 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Q4OS Team 2017-02-11 04:04:30 CST 
"Tdenetworkmanager" shows no wireless networks, even my wifi setup is correct and commandline network-manager works fine. I have performed testing on several Debian-Stretch/TDE14 machines, all of them suffered from the same problem. So I guess it's a general bug.

Exact steps to reproduce:
- Any laptop/PC with wifi device
- Fresh TDE Preliminary stable (14.0.5) installation on Debian Stretch https://wiki.trinitydesktop.org/Preliminary_Stable_Builds
- Click on the tdenetworkmanager icon in system tray
- Bug: No wireless networks show up

Observations:
If I got around it by selecting edit connections and then manually adding new wireless connection and entering all the information, I can successfully connect to the wifi network. As connected for the first time, tdenetworkmanager began to work fine, showing up and recognized all wireless networks around.

I have performed debbuginga bit and ran tdenetworkmanager from terminal this way:
$ tdenetworkmanager --nofork
I beleive the next message is connected to this issue:
"tdenetworkmanager: WARNING: [void Tray::createDeviceTrayComponent(TQString)] UDI: /sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/wlp1s0/wlp1s0 has unknown devicetype: 11"
Comment 1 Slávek Banko 2017-02-13 20:39:45 CST 
I did upgrade my old test notebook to Stretch and noticing the same problem.
Comment 2 trinitysuse 2017-03-20 15:59:51 CDT 
Opensuse tumbleweed x86-64 4.10.1-1-default #1 SMP PREEMPT Sun Feb 26 12:43:10 UTC 2017 (1ecd5af) x86_64 x86_64 x86_64 GNU/Linux

trinity-tdenetworkmanager-2:0.9-12.16.x86_64
the same problem.
the naming convention is "enp9s0 and wlp12s0"


starting in terminal:

    /usr/bin/iceauth:  creating new authority file /root/.ICEauthority
    [tdebuildsycoca] tdebuildsycoca running...
    [dcopserver] DCOP Cleaning up dead connections.
    Invalid entry (missing '=') at /tmp/tde-root/tdeconf_updateOhA48m.tmp:1
    Invalid entry (missing '=') at /tmp/tde-root/tdeconf_updatemMWbzM.tmp:1
    [FIXME] UNCLASSIFIED DEVICE name: drm_dp_aux0 type: (null) subsystem: drm_dp_aux_dev driver: (null) [Node Path: /dev/drm_dp_aux0] [Syspath: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/drm_dp_aux0] [8086:2a42]
    [FIXME] UNCLASSIFIED DEVICE name: gpiochip451 type: (null) subsystem: gpio driver: gpio_ich [Node Path: (null)] [Syspath: /sys/devices/pci0000:00/0000:00:1f.0/gpio_ich.1.auto/gpio/gpiochip451] [8086:2919]
    [FIXME] UNCLASSIFIED DEVICE name: gpiochip0 type: (null) subsystem: gpio driver: (null) [Node Path: /dev/gpiochip0] [Syspath: /sys/devices/pci0000:00/0000:00:1f.0/gpio_ich.1.auto/gpiochip0] [8086:2919]
    [TDE NM Backend ERROR] [/home/abuild/rpmbuild/BUILD/trinity-tdelibs-14.1.0/tdecore/tdehw/networkbackends/network-manager/network-manager.cpp:1707] Invalid DBUS device string ''
    [TDE NM Backend ERROR] [/home/abuild/rpmbuild/BUILD/trinity-tdelibs-14.1.0/tdecore/tdehw/networkbackends/network-manager/network-manager.cpp:1707] Invalid DBUS device string ''
    [TDE NM Backend ERROR] [/home/abuild/rpmbuild/BUILD/trinity-tdelibs-14.1.0/tdecore/tdehw/networkbackends/network-manager/network-manager.cpp:1707] Invalid DBUS device string ''
    tdenetworkmanager: WARNING: [void Tray::createDeviceTrayComponent(TQString)] UDI: /sys/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/net/wlp12s0/wlp12s0 has unknown devicetype: 11
    [TDE NM Backend ERROR] [/home/abuild/rpmbuild/BUILD/trinity-tdelibs-14.1.0/tdecore/tdehw/networkbackends/network-manager/network-manager.cpp:1823] Attempting to access the network-manager VPN service returned: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager.VPN.Plugin was not provided by any .service files
Comment 3 trinitysuse 2017-03-20 16:17:11 CDT 
"If I got around" part @ " Q4OS Team 2017-02-11 04:04:30 CST " won't work for me
Comment 4 Slávek Banko 2017-04-01 21:25:11 CDT 
Hurray - I finally revealed the cause!

The problem is caused due to randomization MAC addresses of WiFi interfaces. During the identification of network interfaces is compared mac address found from udev (sysfs) and 'PermHwAddress' determined from the NetworkManager. And it differs. In addition, randomization MAC addresses cause the MAC address in the udev is changed after disconnect == information stored in tdehw-lib become outdated.

The patch is not yet available. I'll work on it later.
Comment 5 Slávek Banko 2017-06-05 20:04:07 CDT 
During my past research, I discovered that the problem is caused by MAC address changes because the TDENetworkConnectionManager class uses a MAC address to identify the network interface.

Because the MAC address can be changed easily - or automatically, it is clear that the MAC address is not a good identifier for network interfaces. While the name of the network interface is stable enough.

Therefore, I decided that the correct way of solving the problem will abandon the use of MAC addresses to identify network interfaces, and instead use the name of the network interface, although this will mean changing the API / ABI. It seems that most of the changes are related to internal interfaces, and the only one affected is the TDENetworkManager application (requires patch and rebuild) - which was expected.

Proposed patches will follow...
Comment 6 Slávek Banko 2017-06-05 20:06:17 CDT 
Created attachment 2769 [details]
tdelibs / tdehw : Use TDENetworkDevice in connectionManager
Comment 7 Slávek Banko 2017-06-06 09:58:59 CDT 
Created attachment 2770 [details]
tdenetworkmanager : Use deviceNode instead macAddress
Comment 8 Slávek Banko 2017-06-18 09:23:22 CDT 
tdelibs patch pushed to GIT in commit e0fd34a1 (master) and 234f323f (r14.0.x).

tdenetworkmanager patch pushed to GIT in commit 954f1c91 (master) and f7b0afaf (r14.0.x).

Updated packages are already available in Preliminary Stable Builds repository. Unfortunately, I do not know how often are updated preliminary RPM packages.