| Summary: | knetworkmanager needs rewrite for network-manager API 0.9 and higher | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Timothy Pearson <kb9vqf> |
| Component: | non-core programs | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | bugwatch, darrella, krisgamrat |
| Priority: | P5 | ||
| Version: | 3.5.13 [Trinity] | ||
| Hardware: | All | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 160, 495, 1105, 435 | ||
|
Description
Timothy Pearson
2011-10-19 02:00:26 CDT
This should be handled as part of the new TDE hardware library, such that all TDE applications can view network status, receive network events, and request connection changes. The new knetworkmanager application should then use the network functionality in the TDE hardware library to perform its tasks. (In reply to comment #1) > This should be handled as part of the new TDE hardware library, such that all > TDE applications can view network status, receive network events, and request > connection changes. The new knetworkmanager application should then use the > network functionality in the TDE hardware library to perform its tasks. Based on the description for your proposed library, it should not be dependent on any one specific network management daemon, but instead should be capable of working with other network management daemons such as wicd, wpa_supplicant, ifconfig/iwconfig/dhclient/dhcpcd, etc. in addition to the most recent NetworkManager 0.9.x. Not all distros will use NetworkManager, and even on distros that do, many people will switch to a different daemon for network management. (In reply to comment #2) > Based on the description for your proposed library, it should not be dependent > on any one specific network management daemon, but instead should be capable of > working with other network management daemons such as wicd, wpa_supplicant, > ifconfig/iwconfig/dhclient/dhcpcd, etc. in addition to the most recent > NetworkManager 0.9.x. Correct. It may actually be easier to work with those other programs, as NetworkManager now insists on storing all of its configuration data internally, with no way for an external program to request a one-off connection. Not all distros will use NetworkManager, and even on > distros that do, many people will switch to a different daemon for network > management. I have about had my fill of NetworkManager as well. ;-) Tim (In reply to comment #3) > (In reply to comment #2) <snip> > > Not all distros will use NetworkManager, and even on > > distros that do, many people will switch to a different daemon for network > > management. > > I have about had my fill of NetworkManager as well. ;-) > > Tim Here's an idea: after doing the general compatibility with the other network daemons (which IMO should take priority over this idea), rewrite KNetworkManager (or write a new TDE-specific app from scratch) so it is either entirely it's own utility, or try to rework it to be more agnostic toward the various daemons that are out there. If those would take too much effort, it should be possible at the very least to rework KNetworkManager (TNetworkManager?) to use wpa_supplicant and dhclient/dhcpcd; those should be around for another long while, and considering that 'update_config=1' is set in wpa_supplicant.conf, updating it when the user adds/removes/modifies a connection shouldn't be a big issue. The only problem with this approach is figuring out a way around the super user permissions needed by wpa_supplicant and dhclient/dhcpcd. |