Is that the exact number for the release? Because I think I had to go back even further than that… to something that ended in -13.
Maybe I can upgrade!!!
The same problem here for the some days now: ethernet working, wireless not. On a HP 6720s/11.1 64bit. I searched the bugs and on this forum as well, I found possible solutions but none worked in my case. I’ll keep trying though my room is messier with all these cables again like 5-6 yrs ago 
.
rpm -qa "*NetworkManager*"|sort
NetworkManager-0.7.0.r4359-15.1.1
NetworkManager-glib-0.7.0.r4359-15.1.1
NetworkManager-kde-0.7r848570-35.1
NetworkManager-kde4-0.7.svn924744-60.23
NetworkManager-kde4-lang-0.7.svn924744-60.23
NetworkManager-openvpn-0.7.0.r4274-1.18
NetworkManager-openvpn-kde-0.7r848570-35.1
NetworkManager-openvpn-kde4-0.7.svn924744-60.23
NetworkManager-vpnc-0.7.0.r4274-1.19
NetworkManager-vpnc-kde-0.7r848570-35.1
NetworkManager-vpnc-kde4-0.7.svn924744-60.23
cat /etc/SuSE-release
openSUSE 11.1 (x86_64)
VERSION = 11.1
Works for me™
Akoellh wrote:
>
>
> Works for me™
This bug has what appears to be a rather random nature. In the Bugzilla entry
“[Bug 486267] Latest update of NetworkManager breaks wireless networking”, one
user reports that he has two nearly identical x86 systems. One works and the
other broke when NM was updated.
The difficulty arose when a security hole in the Dbus permissions was plugged in
NM. The commit message is “Add fix_dbus_conf.patch (bnc#479563, CVE-2009-0578”.
I can make my system work by changing the permissions for
send_interface=“org.freedesktop.NetworkManagerSettings.Connection.Secrets”, but
that restores the security problem. I have not found a change that will enable
root to get the secrets while denying access by a general user.
I’m running 32 bit and those files didn’t work for me. I had to roll back the Network Manager and glib files to the version that ended in .13-1. I also had to run kwallet to take care of the encryption.
Well, I was hit by the problem (rather hard), but I could solve it:
openSUSE Forums - View Single Post - Latest NetworkManager Broken
Akoellh wrote:
>
> Well, I was hit by the problem (rather hard), but I could solve it:
>
> ‘openSUSE Forums - View Single Post - Latest NetworkManager Broken’
> (http://forums.opensuse.org/1960586-post13.html)
As I reported, reloading the latest version of every NM, HAL, and Dbus-related
package didn’t work for me.
I was waxed pretty solidly by this bug set. If I roll back HAL, DBUS, and NetworkManager to the versions from the 11.1 DVD, all works fine. As soon as I apply the updates (and yes, I apply them all together) trash city. Wireless doesn’t work, UM175 no longer appears in list for new connections. The only thing which works is a hard cable.
I have blown 4 full days trying to fix that notebook (Toshiba Satellite A215-S5848). I guess I have to hope I don’t get another contract before there is an update available. I was getting the notebook ready to go because I travel when consulting and that is my workhorse then. All real work at home office happens via workstation which is hard linked into my HughesNet service. I did like my Verizon service. It’s fast and allows me to download bigger chunks at once, but for now, it looks like I’m paying $60/mo for nothing since I cannot use it.
Hopefully they’ve raised the priority on this since a lot of people have the Verizon service.
I had different issues with Gnome (gnome hang at second login, hplip not starting, Packagekit not working) and they were all related to the same problem described here (I didn’t noted problems with NM however). I had to rollback hal, dbus-1, network-manager and packagekit to get a functionning system again.
Problem is seen with :
dbus-1 1.2.10-5.3.1
hal 0.5.12-10.13.1
packagekit 0.3.11-1.13.1
networkmanager 0.7.0.r4359-15.1.1
Prexy wrote:
> I’m running 32 bit and those files didn’t work for me. I had to roll
> back the Network Manager and glib files to the version that ended in
> .13-1. I also had to run kwallet to take care of the encryption.
It appears that the problem with the latest updates for NetworkManager and
friends is due to the presence of a directory that should not be there. If you
are having trouble, check to see is the directory
/var/run/dbus/at_console/root
exists. If it does, then try the command
sudo rm -rf /var/run/dbus/at_console/root
Does this allow NM to work correctly?
Larry
I don’t even have at_console directory.
What’s the latest with this? I rerverted all dbus , hal, networkmanager and powersave packages (those are all I have installed) to the original repository versions, but still no WiFi. Re-installed the latest versions all in one go and the NetowrkManager crashed during the install.
Are we all waiting for the networkmanager team to re-write their package, and then release it to an unsuspecting linux community to test? I waited years for a decent ATI driver, but it came good in the end. Hope I don’t have wait years to get WiFi back on opensuse.
Anyone have any workarounds using the command line?
Switch to the “traditional method with ifup”.
If you have a laptop and need to use WiFi in different environments, have a look at SCPM (profile manager).
If you only use one wireless network (desktop machine) NetworkManager isn’t needed at all.
thanks -works like a charm. Who needs networkmanager anyway?
I have a desktop which uses a wired connection. That directory is present. But, since this is a wired connection, it appears to have no effect. Should I remove it anyway?
On the laptop that has been giving me the wireless trouble, that directory is not present. I have rolled back to 0.7.0r4323-1.13-i586 and locked the network manager files so they will not update. I don’t like doing this since, in general, I would prefer to have zypper (or yast) manage updates properly. Eventually, I will have to let these update because they will be far behind. I am afraid to update because, if the new updates fail, I may not be able to get these old versions back.
Also, I have a real hodge-podge of versions. NetworkManager and NetworkManger-glib have the version listed above.
NetworkManager-kde is 0.7r848570-23.1-i586
NetworkManager-kde4 and NetworkManger -kde4-lang are both 0.7svn924744-60.22-i586
In yast, all of these are blue. I am using the NM plasmoid to manage the connections, since that was my only working option.
Prexy wrote:
> I have a desktop which uses a wired connection. That directory is
> present. But, since this is a wired connection, it appears to have no
> effect. Should I remove it anyway?
It shouldn’t matter.
> On the laptop that has been giving me the wireless trouble, that
> directory is not present. I have rolled back to 0.7.0r4323-1.13-i586 and
> locked the network manager files so they will not update. I don’t like
> doing this since, in general, I would prefer to have zypper (or yast)
> manage updates properly. Eventually, I will have to let these update
> because they will be far behind. I am afraid to update because, if the
> new updates fail, I may not be able to get these old versions back.
>
> Also, I have a real hodge-podge of versions. NetworkManager and
> NetworkManger-glib have the version listed above.
> NetworkManager-kde is 0.7r848570-23.1-i586
> NetworkManager-kde4 and NetworkManger -kde4-lang are both
> 0.7svn924744-60.22-i586
>
> In yast, all of these are blue. I am using the NM plasmoid to manage
> the connections, since that was my only working option.
You can always switch to ifup to control your wireless connection. None of these
NM problems break that method.
Could someone post the command line instruction sequence to establish a connection using ifup. I’ve never used it before and haven’t a clue. I can cut and paste commands to the terminal pretty well though. I would like it to work like a charm for me too.
I found the following set of command line instructions for using ifup to set up a wireless connection:
sudo /sbin/ifconfig wlan0 down
sudo /sbin/dhclient -r wlan0
sudo /sbin/ifconfig wlan0 up
sudo /usr/sbin/iwconfig wlan0 essid “Green_Acres”
sudo /usr/sbin/iwconfig wlan0 mode Managed
sudo /sbin/dhclient wlan0
However, when issuing the final command of this sequence the result is:
wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:90:4b:43:ca:67
Sending on LPF/wlan0/00:90:4b:43:ca:67
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
The router is setup to issue DHCP addresses. So, why aren’t any offered?
And how do you handle a proxy with ifup?
Here’s the “alternate” solution:
Wicd
it has no dumb “automated” one-clicks but the capabilities to work with profiles and scripts for your connections. May be this could suit your needs, may be not. If you’re happy with NM - don’t bother to checkout “wicd”.
regards.
Deleting the directory had absolutely no impact on the problem. This is busted bad