Re: A comment on NetworkManager
Hello, Peter Roediger wrote: ... 2.) The configuration issue. In my view NetworkManager is one of the most intransparent linux applications out there. There's no Documentation (correct me if I'm wrong), there is no configuration file easily accessible and there are weird things going on with resolv.conf. How is it configured? How can I change the DNS server without violating # generated by NetworkManager, do not edit!? Do I have to use a special program to set this up? If so, then just write it down at some place. I've been using Linux for 5 years now and having problems to set up basic things with an application that is supposed to be a snap to use. ... Having thrown a penny into an empty well a few days ago, I'd like to echo this frustration. NM is slick and cool and I also want to echo the praise. I went cold turkey with Linux (fc2 - from MacOS 8.1!) mid-2004 and then found I was the first person in my University (Auckland) to set up wpa_supplicant on it's wireless network... - there's some amusing reading on the wpa_supplicant mail list back then. I got there, with a little help from my friends. When I went to fc4 I gave up trying to configure it for the Uni network, though it was a delight on my home wep network. I consoled myself with my home network and looking forward to fc5. Now I'm with fc5 I know NM is configurable with my Uni network - but, how? Just a little info might go a long way (but, I make no promise:) NM is way cool, please keep up the good work. Best regards, Morgan. -- Morgan Read NEW ZEALAND mailto:mstuffATreadDOTorgDOTnz get a life; GET FIREFOX! www.getfirefox.com WHY ME? Read on: http://www.theregister.co.uk/2004/06/28/cert_ditch_explorer/ http://www.theregister.co.uk/2004/09/13/german_ie_jitters/ signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On Thu, 11 May 2006, Russell Harrison wrote: must remember to hit reply to all :-) While we're accreting wish lists, let me add mine: 1) NM should to be able to manage keys and protocols (including WPA and WPA-2, given that WEP is pretty much useless no matter how many bits it has:-) without having to unlock the keyring. I know the key-unlocking problem will soon be solved outside of NM per se, but hey, the WEP key for myssid is preserved in e.g. .gconf/system/networking/wireless/networks/myssid, with the WEP key written (of course) in plaintext. For most non-paranoid people in most default account configurations this whole tree is by default 644/755 top to bottom so anybody on the system can read it. Which makes me REALLY wonder why NM bothers using the keyring -- the data isn't encrypted or otherwise effectively hidden in the first place. 2) NM needs to be able to have NM remember networks with no broadcast SSID once they are entered so that one doesn't have to go through the custom network interface every time. The WEP key is already stored on the system where anybody can read it, but when I select connect to other wireless networks the first time after logging in I seem to have to enter it before the connect button becomes active. It would also be nice to have a GUI list of other wireless networks ssids pop up at this point to click on instead of requiring typewriter entry of the ssid, and make the create new wireless network action a menu choice on this interface. 3) indeed, what NM needs is a full featured SSID table manager interface (a manage SSIDs menu entry to replace both the connect and create entries that are there now) that permits the user to fully manage and customize the table of SSIDs. In addition to WEP/WPA information any given SSID needs to be markeable at LEAST as: - whitelist (always connect to strongest signal available in order of a user-defined priority that overrides signal strength). - blacklist (always ignore, never connect, do not even SHOW ever again except in the SSID table manager interface once they are marked out in the working table). This can easily/consistently be done with a single file in .gconf/.../wireless/network, e.g.: blacklist essidessid1/essid essidessid2/essid ... /blacklist - greylist controls, e.g. show/don't show greylist connections as available in the left-click applet popup (they'll always be in the table manager interface), connect/don't connect to greylist connections without a deliberate user action (like answering ok in a popup). Basically, 98% or more of my wireless connections are to one of three SSIDs, one of which is not broadcast. 70% of the time I'm connecting to my home network, the one with the non-broadcast SSID. I want to be able to tell my system to ALWAYS ignore the six or seven broadcast SSIDs it ALWAYS sees at boot time at home and to ALWAYS look for the network with the hidden non-broadcast SSID and connect to it FIRST if it is there, to NEVER ask for a password or make me manually manipulate keys after the primary key entry to (re)connect, and yet to be able to transparently re-connect to a greylist broadcast SSID open interface if I should close my laptop and go to a wi-fi cafe somewhere for a cup of coffee, with or without a message asking if it should connect as I choose to configure. Automatic means not manual. The applet/popup GUI on NM is nice and permits one to perform many actions without having to type in low level commands but NM itself is not terribly automatic even for things that have to be done over and over again exactly the same way -- where it IS automatic it nearly always does the wrong thing, at least for me, so I end up having to manipulate it to get correctly connected nearly every time I connect. NM is clearly CAPABLE of doing what it needs to do for all categories of interface -- all it lacks is a higher-level interface where repetitive tasks can be categorized and response sequences predefined so that they can be avoided in the future. Basically, manipulation should only be necessary ONE TIME per network one sees -- blacklist and then DONE (for those essids, never ever see them again in a toplevel interface), greylist (configure?) and DONE, whitelist (configure) and DONE -- where no essid or NM itself is ever touched again in that connection context unless/until one wants to do something unusual or a key changes. rgb -- Forwarded message -- From: Russell Harrison [EMAIL PROTECTED] Date: May 10, 2006 11:20 PM Subject: Re: A comment on NetworkManager To: Peter Roediger [EMAIL PROTECTED] Very well written. I'd like to second everything you've said. NetworkManager is very frustrating to work with. I only use it because I feel like its got some real potential and somebody needs to find the bugs. I am continually in a love hate relationship with the simplicity of the interface. Right now its so simple I don't see how any layperson could
Re: A comment on NetworkManager
On Thu, 2006-05-11 at 02:48 +0200, Peter Roediger wrote: Hi everyone, I thought I should write a little -personal- comment on what I think about the current implementation of NetworkManager and, more importantly, its design goals. First of all, I'm very pleased to see that there is some effort going on to make a linux desktop more user-friendly in terms of network usage and managing more than one network device in more than one (wireless) network. So far, NetworkManager looks to me like a very good approach to it, though it has some, in my view, major shortcomings which I'd like to address in this mail. 1.) Wireless networks list. There is no Search for wireless networks or Refresh wireless networks list button/option in the applet. While this seems to be convenient in the first place it turns out to be not in some cases. Consider this: Many laptops nowadays feature an LED that shows the status of the wireless connection ( e.g. flashing when it's not connected, etc.). Thus people will naturally switch the wireless network off when it's not needed. Then, they might disconnect their wired LAN at one point and go to some place that is supplied by a wireless network. Now, they turn on their wireless network card by a hardware switch and...they have to wait. They have to wait until NM will update the list. Which will take some time. The average user will not understand this behavior. But the average user would understand an option mentioned above. It's easy. Easier than a WEP key. Or something else: You walk around in a foreign city in order to find a hotspot to logon to. There is a desperate need to update the list immediately. It's simply crucial. I must be pretty confused. I use my wireless at home and at work and nm-applet shows me immediately the wireless access points that are available. 2.) The configuration issue. In my view NetworkManager is one of the most intransparent linux applications out there. There's no Documentation (correct me if I'm wrong), there is no configuration file easily accessible and there are weird things going on with resolv.conf. How is it configured? How can I change the DNS server without violating # generated by NetworkManager, do not edit!? Do I have to use a special program. In answer to part of point two, it is the DHCP server that supplies the addresses of the DNS servers not NM ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
p.roediger wrote: Aaron Konstam schrieb: On Thu, 2006-05-11 at 02:48 +0200, Peter Roediger wrote: Hi everyone, I thought I should write a little -personal- comment on what I think about the current implementation of NetworkManager and, more importantly, its design goals. First of all, I'm very pleased to see that there is some effort going on to make a linux desktop more user-friendly in terms of network usage and managing more than one network device in more than one (wireless) network. So far, NetworkManager looks to me like a very good approach to it, though it has some, in my view, major shortcomings which I'd like to address in this mail. 1.) Wireless networks list. There is no Search for wireless networks or Refresh wireless networks list button/option in the applet. While this seems to be convenient in the first place it turns out to be not in some cases. Consider this: Many laptops nowadays feature an LED that shows the status of the wireless connection ( e.g. flashing when it's not connected, etc.). Thus people will naturally switch the wireless network off when it's not needed. Then, they might disconnect their wired LAN at one point and go to some place that is supplied by a wireless network. Now, they turn on their wireless network card by a hardware switch and...they have to wait. They have to wait until NM will update the list. Which will take some time. The average user will not understand this behavior. But the average user would understand an option mentioned above. It's easy. Easier than a WEP key. Or something else: You walk around in a foreign city in order to find a hotspot to logon to. There is a desperate need to update the list immediately. It's simply crucial. I must be pretty confused. I use my wireless at home and at work and nm-applet shows me immediately the wireless access points that are available. Only if your network card is running right from the system boot. But as i pointed out, this does not have to be the case. It only works well, when you never turn off your wlan card and you never change places. 2.) The configuration issue. In my view NetworkManager is one of the most intransparent linux applications out there. There's no Documentation (correct me if I'm wrong), there is no configuration file easily accessible and there are weird things going on with resolv.conf. How is it configured? How can I change the DNS server without violating # generated by NetworkManager, do not edit!? Do I have to use a special program. In answer to part of point two, it is the DHCP server that supplies the addresses of the DNS servers not NM Only if you have a DHCP service running on your network (which does not apply always, in fact, it does not apply in most cases), dns servers will be assigned. Otherwise you have to specify them in /etc/resolv.conf ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list I wonder why it is that negative comments I make about NetworkManager seem to always go into a black hole, never coming back from the list. It appears to me that there might be a small snowballs chance in hell of its working if two conditions are met: 1. Must be running gnome or it appears all the tools aren't available 2. Must NOT be using ndiswrapper. This assumes that the now 4 month old tome from redhat, written by Rosanna Yuen has been printed, salted peppered and comsumed in hopes it might enlighten the potential user. For this user, it does not. And its all gnome-centric, totally ignoreing kde users. Does this mean that kde users will be forever locked out of using this tool? So when is it going to be made compatible with kde, AND ndiswrapper so all of us using broadcom radios can share in the apparent glee here. My experience with NM has been uniformly negative, with every attempt to run it destroying all networking and requireing a full powerdown reset to restore it. I do not consider that to be either impressive, or useful. Nor do I see mention of newer versions being available, but I don't see them in yumex, nor do I see any great importance given to the exact version in the messages to this list so that I might check to see if indeed I do have the latest installed. -- Cheers, Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On Thu, 11 May 2006, Aaron Konstam wrote: On Thu, 2006-05-11 at 09:51 -0400, Robert G. Brown wrote: On Thu, 11 May 2006, Russell Harrison wrote: must remember to hit reply to all :-) While we're accreting wish lists, let me add mine: 1) NM should to be able to manage keys and protocols (including WPA and WPA-2, given that WEP is pretty much useless no matter how many bits it has:-) without having to unlock the keyring. I know the key-unlocking problem will soon be solved outside of NM per se, but hey, the WEP key for myssid is preserved in e.g. P key .gconf/system/networking/wireless/networks/myssid This is interesting, since the WEP key requested is for 13 characters but the WEP key recoorded is only 10 characters. What is going on? However, my directories are 700 so only I can read it. This is a (smart) user choice, of course, but many users or new account programs might create the tree 755 or whatever. And besides, as long as it is stored even 700 in cleartext, using a decryption step via the keyring is just silly. Either store it encrypted (only) or don't bother encrypting it. I'm inclined toward having the choice -- a userspace 700 DEFAULT security level on this part of the .gconf tree or at least all files containing keys OR not storing the keys there at all and using strict encryption. This isn't an obvious choice to make -- most users would probably be just fine with the 700 option, especially for WEP keys. 64-bit WEP takes anywhere from five minutes to an hour of passive monitoring to break in the worst cases and WEP in general should never take anyone longer than ten to twenty hours to break, regardless of key length (the weakness is in the 24 bit initialization vector used in BOTH 64 and 128 bit WEP, transmitted in cleartext, which lets people statistically analyze traffic on easily discoverable broadcast SSID networks and deduce the static shared key). Additional problems include its vulnerability to man-in-the-middle attacks because of its lack of host authentication, because most access points broadcast their ESSID, because tools like NM can reconnect your network without warning so that you think you're entering something into a secured encrypted channel not realizing that you've reconnected to a new WAP and the remote password you are typing is going out in cleartext (something that has happened to me already more than once, or would have if I didn't use additional layers e.g. ssh) and so on. I think of 64-bit WEP (metaphorically) as like locking a door to your house on a public street with one of the non-deadbolt type locks. It keeps the riff-raff out, but any real burglar will use a credit card or aluminum ruler to open the door almost as fast as you can open it with the key. Which is fine -- that keeps out 99.99% of potential intruders, as most of them are people who live in your neighborhood who just happen to pick up your broadcasting SSID and could connect without even MEANING to without WEP (as happens all the time to me at home as one of my neighbors has nothing so my wireless connects there while I'm trying to do all the mouse clicks and keyboarding required to get it to connect to my non-broadcasting 64-bit WEP access point at home). I don't care if it is crackable, as all of my systems use e.g. ssh or ssl to encrypt most of my network traffic, although NFS is probably (sigh) vulnerable to somebody determined and knowledgeable. 128-bit WEP is a tiny bit stronger -- like using cheap deadbolts, perhaps -- but your windows are still smashable, a lockpick can still open it pretty easily. Not broadcasting your ESSID in either case stronger still although still pretty weak -- first they have to FIND your house which is no longer on ANY street in plain sight -- you have to know how to reach it through the woods or how to follow somebody who is going there. However, if you are doing e.g. something with medical records (EMRs) then HIPAA requires, I think, something a bit stronger than WEP, period, with or without broadcast ESSIDs. WPA isn't bad -- it solves most of the obvious problems with WEP but perhaps isn't NSA-grade security as it has weak or static authentication. WPA-2 is probably DOE/NSA grade secure -- active authentication layers as well as a pretty solid encryption scheme. So ultimately for linux laptops or other wireless tools to be useable in an EMR or DOE or corporate secure setting where money or privacy or lives are really on the line, they (and NM) will need to completely support them. I still don't know much about MIMO and whether it is yet another extension in security-land or more about bandwidth on top of e.g. WPA-2, but that's coming as well. The point being that NM is currently treating security in a very internally contradictory manner -- supporting WEP (a good thing, don't get me wrong) when WEP is basically why bother false-sense-of-security aside from doing the exclusion what white/black/greylists would do much better,
Re: A comment on NetworkManager
It appears to me that there might be a small snowballs chance in hell ofits working if two conditions are met: 1. Must be running gnome or it appears all the tools aren't available2. Must NOT be using ndiswrapper.This assumes that the now 4 month old tome from redhat, written byRosanna Yuen has been printed, salted peppered and comsumed in hopes it might enlighten the potential user.For this user, it does not.Andits all gnome-centric, totally ignoreing kde users.Does this mean thatkde users will be forever locked out of using this tool? Ubuntu and SUSE are both shipping with KNetworkManager so NM for KDE is available now. I think it is hosted in the KDE.org SVN. So when is it going to be made compatible with kde, AND ndiswrapper soall of us using broadcom radios can share in the apparent glee here.Myexperience with NM has been uniformly negative, with every attempt to run it destroying all networking and requireing a full powerdown resetto restore it.The problem is not N-M it is NDISWrapper supporting a full set of Wireless Extensions, I think that the latest (Or maybe it is the version in CVS) fully support the latest version of WEXT and work with N-M. So if you have a new version of NDISWrapper and run KNetworkManager you should be good to go. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On 5/11/06, Darren Albers [EMAIL PROTECTED] wrote: So when is it going to be made compatible with kde, AND ndiswrapper so all of us using broadcom radios can share in the apparent glee here.My experience with NM has been uniformly negative, with every attempt to run it destroying all networking and requireing a full powerdown resetto restore it.The problem is not N-M it is NDISWrapper supporting a full set of Wireless Extensions, I think that the latest (Or maybe it is the version in CVS) fully support the latest version of WEXT and work with N-M. So if you have a new version of NDISWrapper and run KNetworkManager you should be good to go.I think I should expand on this a bit, awhile back Robert Love posted a large patch with a set of workarounds for many of the drivers that do not support the latest WEXT. I think these were Madwifi, NDISWrapper, and one other (Orinco?). Dan has taken the position that N-M itself should strictly support WEXT only to avoid supporting the 25 different cards and their unique implementations (I think his reasoning is valid), but he has no issues with individual distributions patching N-M for direct support to increase the usability for their users. This is why some distro's (Ubuntu Dapper and I think SUSE) have an install of Network Manager that works with NDISWrapper, MadWifi and many other cards that N-M itself does not support. While many may disagree with Dan's stance it has already had a positive result for NDISWrapper and MadWifi, users of N-M who had to use either of those two drivers put together patches for those drivers and submitted them. Both were accepted and committed, to me this is a perfect example of why the Open-Source model works so well. So if you want a working setup with KDE and NDISWrapper you have a couple of options:1) Use a distro that has support for both like Ubuntu Dapper or SUSE.2) Build Network Manager by hand and apply Robert's patch to it and use KNetworkManager 3) Upgrade the version of NDISWrapper you are using and use KNetworkManager.I hope this helps! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On 5/11/06, Robert G. Brown [EMAIL PROTECTED] wrote: Must admit I'm puzzled by these posts.. I've checked the %gconf.xml files for all the WEP networks I've connected to, and there's no key in any of them. Could you have left-overs from an old version? [EMAIL PROTECTED]|B:1045dirDUKE/ hpsetup/ LinkSys_CifTAN/NETGEAR/sposton/Freedomlink/Latimore/mpp/ PASSYM/ [EMAIL PROTECTED]@wireless/%gconf.xmllinksys/ NCM_Guest/ myessid/ [EMAIL PROTECTED]|B:1046cat myessid/%gconf.xml?xml version=1.0?gconf entry name=addresses mtime=1127738223 type=listltype=string li type=string stringvalue0:c:41:7b:42:88/stringvalue /li /entry entry name=auth_method mtime=1147352804 type=int value=2 /entry entry name=key_type mtime=1147352804 type=int value=2 /entry entry name=key mtime=1127738218 type=string stringvalue(IT WAS HERE)/stringvalue /entry entry name=essid mtime=1147352804 type=string stringvaluemyessid/stringvalue /entry entry name=timestamp mtime=1147352804 type=intvalue=1147352804 /entry/gconf[EMAIL PROTECTED] |B:1047rpm -qv NetworkManagerNetworkManager-0.5.1-1.FC4.4I am running 0.6.2 and my %gconf.xml does not contain the key, my key is only in Gnome-Keyring. This is for WPA, I do not have an access point using WEP to test with. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
My comments inline.On 5/10/06, Peter Roediger [EMAIL PROTECTED] wrote: 1.) Wireless networks list.There is no Search for wireless networks or Refresh wireless networks list button/option in the applet. While this seems to be convenient in the first place it turns out to be not in some cases. Consider this: Many laptops nowadays feature an LED that shows the status of the wireless connection ( e.g. flashing when it's not connected, etc.). Thus people will naturally switch the wireless network off when it's not needed. Then, they might disconnect their wired LAN at one point and go to some place that is supplied by a wireless network. Now, they turn on their wireless network card by a hardware switch and...they have to wait. They have to wait until NM will update the list. Which will take some time. The average user will not understand this behavior. But the average user would understand an option mentioned above. It's easy. Easier than a WEP key. Or something else: You walk around in a foreign city in order to find a hotspot to logon to. There is a desperate need to update the list immediately. It's simply crucial.I can see the use of this but I use N-M a lot while traveling through airports and hotels and have never had a problem yet (Though I do have a problem with ad-hoc networks but that is a seperate issue). It has reliably detected networks for me everytime without a lot of waiting. The advantage of the way NM does it now is that if I see a Network in NM I know it is not some phantom network just out of my range. 2.) The configuration issue.In my view NetworkManager is one of the most intransparent linux applications out there. There's no Documentation (correct me if I'm wrong), there is no configuration file easily accessible and there are weird things going on with resolv.conf. How is it configured? How can I change the DNS server without violating # generated by NetworkManager, do not edit!? Do I have to use a special program to set this up? If so, then just write it down at some place. I've been using Linux for 5 years now and having problems to set up basic things with an application that is supposed to be a snap to use. I think Dan has said that this is something they plan for .7 3.) Profiles.I know, you don't like them. You think, they are an inconvenient user experience. Well, while I understand your pursuit of simplicity i don't really get what is so bad about profiles. You could present the user with some sort of a default profile. No further setting up is required. It just uses the settings specified in /etc/network/interfaces as usual. On the other hand, there are A LOT of people who use their laptop at home and at work or at the uni or wherever. And in those places there is no dhcp available in many cases. So what is so evil about letting the user create profiles so he can easily switch to the appropriate one? That is something so many criticize about Windows: They always have to change their network settings. Every day. That is not even close to user-friendly. And again: With a bit of explaining the average user will indeed be able to set up profiles. If he is capable of changing the network settings every day, he'll be capable of creating profiles. For sure. And it's just so useful.I think something like this is in the pipeline for .7 but I am just an interested party who reads this list so Dan would have to comment on this directly. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
A little trouble starting the applet...
Hello everyone: I'm wondering if could you give me a clue what's happening with my Network Manager (actually it's a great soft :D). My distro: -Ubuntu Dapper 6.06 My packages and versions: -gnome-common 2.12.0-1 -2.6.15-22-386 -wireless-tools 27+28pre13-1ubuntu2 x -network-manager 0.6.2-0ubuntu6 -network-manager-gnome 0.6.2-0ubuntu6 My problem: -I got No network devices have been found -I've been searching on Google and I found something about changing the policy in /etc/dbus-1/system.d/nm-applet.conf. My nm-applet-conf: -I changed user=root to user=gohan. !DOCTYPE busconfig PUBLIC -//freedesktop//DTD D-BUS Bus Configuration 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd; busconfig policy user=gohan allow own=org.freedesktop.NetworkManagerInfo/ allow send_destination=org.freedesktop.NetworkManagerInfo/ allow send_interface=org.freedesktop.NetworkManagerInfo/ /policy policy at_console=true allow own=org.freedesktop.NetworkManagerInfo/ allow send_destination=org.freedesktop.NetworkManagerInfo/ allow send_interface=org.freedesktop.NetworkManagerInfo/ /policy policy context=default deny own=org.freedesktop.NetworkManagerInfo/ deny send_destination=org.freedesktop.NetworkManagerInfo/ deny send_interface=org.freedesktop.NetworkManagerInfo/ /policy /busconfig - Running NetworkManager I have something like this: [EMAIL PROTECTED]:/etc/dbus-1/system.d# NetworkManager --no-daemon NetworkManager: information starting... NetworkManager: WARNINGmain (): nm_data_new: Setting up dbus filter NetworkManager: information Updating allowed wireless network lists. NetworkManager: WARNINGnm_dbus_get_networks_cb (): nm-dbus-nmi.c:522 (nm_dbus_get_networks_cb): error received: org.freedesktop.DBus.Error.AccessDenied - A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface org.freedesktop.NetworkManagerInfo member getNetworks error name (unset) destination org.freedesktop.NetworkManagerInfo). I have no idea was coming on... :S Sorry if my English is pretty bad, I'm Spanish speaker. Thank you for your help!!! Omar Alva. Mexico. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Another Network Manager Stupidity: Swapping eth0 and eth1
I have just found what may be another Network Manager (NM) stupidity. I have two NICs on my laptop (http://www.charlescurley.com/Lenovo.R51.html) running Fedora Core 5. One is a wired Ethernet interface, the other a wireless Ethernet interface. In system-config-network, I have anchored eth0 and eth1 to specific MAC addresses. I recently switched from using the usual configuration tools to NM. I just found out is that NM seems to be ignoring that MAC address anchoring. It has swapped eth0 and eth1. As a result of this the firewall defined by firestarter does not work, and as a result of that my system is wide open and has been for several days. This came to my attention because I started to think I may have a root kit on my laptop, and started to track things down. Pain-Free Networking, huh? -- Charles Curley /\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpvtxggyBS1S.pgp Description: PGP signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Another Network Manager Stupidity: Swapping eth0 and eth1
I don't think this is Network Manager, it does not touch that as far as I am aware of. I have seen this problem in Ubuntu and I think it was a bug in hotplug that caused it to swap. The bug was filed in Launchpad.net so maybe if you can find it there you will find more information and a possible fix for Fedora?On 5/9/06, Charles Curley [EMAIL PROTECTED] wrote:I have just found what may be another Network Manager (NM) stupidity. I have two NICs on my laptop(http://www.charlescurley.com/Lenovo.R51.html) running Fedora Core5. One is a wired Ethernet interface, the other a wireless Ethernet interface. In system-config-network, I have anchored eth0 and eth1 tospecific MAC addresses.I recently switched from using the usual configuration tools to NM. Ijust found out is that NM seems to be ignoring that MAC address anchoring. It has swapped eth0 and eth1. As a result of this thefirewall defined by firestarter does not work, and as a result of thatmy system is wide open and has been for several days. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A little trouble starting the applet...
With Ubuntu NM is customized to not manage any devices in /etc/interfaces. Try commenting out your wireless card there and see if it works.**Resending this to list, I forgot to hit reply to all, GMail hates mailing lists**On 5/11/06, Omar Alva [EMAIL PROTECTED] wrote:Hello everyone:I'm wondering if could you give me a clue what's happening with my Network Manager (actually it's a great soft :D).My distro:-Ubuntu Dapper 6.06My packages and versions:-gnome-common 2.12.0-1-2.6.15-22-386-wireless-tools 27+28pre13-1ubuntu2 x -network-manager 0.6.2-0ubuntu6-network-manager-gnome 0.6.2-0ubuntu6My problem:-I got No network devices have been found-I've been searching on Google and I found something about changing the policy in /etc/dbus-1/system.d/nm-applet.conf.My nm-applet-conf:-I changed user=root to user=gohan. !DOCTYPE busconfig PUBLIC-//freedesktop//DTD D-BUS Bus Configuration 1.0//ENhttp://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd busconfigpolicy user=gohanallow own=org.freedesktop.NetworkManagerInfo/allowsend_destination= org.freedesktop.NetworkManagerInfo/allowsend_interface=org.freedesktop.NetworkManagerInfo//policypolicy at_console=true allow own=org.freedesktop.NetworkManagerInfo/allowsend_destination=org.freedesktop.NetworkManagerInfo/allow send_interface=org.freedesktop.NetworkManagerInfo//policypolicy context=defaultdeny own=org.freedesktop.NetworkManagerInfo/ denysend_destination=org.freedesktop.NetworkManagerInfo/denysend_interface=org.freedesktop.NetworkManagerInfo//policy /busconfig-Running NetworkManager I have something like this:[EMAIL PROTECTED]:/etc/dbus-1/system.d# NetworkManager --no-daemonNetworkManager: information starting... NetworkManager: WARNINGmain (): nm_data_new: Setting up dbusfilterNetworkManager: information Updating allowed wireless network lists.NetworkManager: WARNINGnm_dbus_get_networks_cb (): nm-dbus-nmi.c:522 (nm_dbus_get_networks_cb): error received:org.freedesktop.DBus.Error.AccessDenied - A security policy in placeprevents this sender from sending this message to this recipient, seemessage bus configuration file (rejected message had interface org.freedesktop.NetworkManagerInfo member getNetworks error name(unset) destination org.freedesktop.NetworkManagerInfo).I have no idea was coming on... :S Sorry if my English is pretty bad, I'm Spanish speaker.Thank you for your help!!!Omar Alva.Mexico.___NetworkManager-list mailing list NetworkManager-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[patch] my latest wireless drivers workaround patch.
Here it is. A bunch of crap we sadly should never need but
unfortunately do.
Robert Love
Index: src/nm-device-802-11-wireless.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-device-802-11-wireless.c,v
retrieving revision 1.60.2.5
diff -u -r1.60.2.5 nm-device-802-11-wireless.c
--- src/nm-device-802-11-wireless.c 27 Mar 2006 16:11:53 - 1.60.2.5
+++ src/nm-device-802-11-wireless.c 20 Apr 2006 16:06:48 -
@@ -214,22 +214,13 @@
if ((data_len = minlen) range-we_version_compiled = 18)
{
- if (range-enc_capa IW_ENC_CAPA_WPA)
- {
caps |= (NM_802_11_CAP_PROTO_WPA
| NM_802_11_CAP_KEY_MGMT_PSK
| NM_802_11_CAP_KEY_MGMT_802_1X);
- }
- if (range-enc_capa IW_ENC_CAPA_WPA2)
- {
caps |= (NM_802_11_CAP_PROTO_WPA2
| NM_802_11_CAP_KEY_MGMT_PSK
| NM_802_11_CAP_KEY_MGMT_802_1X);
- }
-
- if (range-enc_capa IW_ENC_CAPA_CIPHER_TKIP)
caps |= NM_802_11_CAP_CIPHER_TKIP;
- if (range-enc_capa IW_ENC_CAPA_CIPHER_CCMP)
caps |= NM_802_11_CAP_CIPHER_CCMP;
}
@@ -1829,23 +1820,21 @@
int orig_rate = 0;
struct iwreq wrq;
+ /* Must be in infrastructure mode during scan, otherwise we don't get a full
+ * list of scan results. Scanning doesn't work well in Ad-Hoc mode :(
+ *
+ * We only set the mode and unlock the frequency if the card is in adhoc mode,
+ * in case doing so is a costly operation for the driver or the driver prefers
+ * IW_MODE_AUTO.
+ */
orig_mode = nm_device_802_11_wireless_get_mode (self);
if (orig_mode == IW_MODE_ADHOC)
{
orig_freq = nm_device_802_11_wireless_get_frequency (self);
orig_rate = nm_device_802_11_wireless_get_bitrate (self);
- }
-
- /* Must be in infrastructure mode during scan, otherwise we don't get a full
- * list of scan results. Scanning doesn't work well in Ad-Hoc mode :(
- */
- nm_device_802_11_wireless_set_mode (self, IW_MODE_INFRA);
-
- /* We only unlock the frequency if the card is in adhoc mode, in case it is
- * a costly operation for the driver.
- */
- if (orig_mode == IW_MODE_ADHOC)
+nm_device_802_11_wireless_set_mode (self, IW_MODE_INFRA);
nm_device_802_11_wireless_set_frequency (self, 0);
+ }
wrq.u.data.pointer = NULL;
wrq.u.data.flags = 0;
@@ -2253,13 +2242,11 @@
}
-#define NM_SUPPLICANT_TIMEOUT 20 /* how long we wait for wpa_supplicant to associate (in seconds) */
+#define NM_SUPPLICANT_TIMEOUT 60 /* how long we wait for wpa_supplicant to associate (in seconds) */
static unsigned int
get_supplicant_timeout (NMDevice80211Wireless *self)
{
- if (self-priv-num_freqs 14)
- return NM_SUPPLICANT_TIMEOUT * 2;
return NM_SUPPLICANT_TIMEOUT;
}
@@ -2425,13 +2412,28 @@
const char * iface = nm_device_get_iface (NM_DEVICE (self));
gboolean success = FALSE;
inttries = 0;
+ const char * wpa_driver;
+ const char * kernel_driver;
if (!(ctrl = wpa_ctrl_open (WPA_SUPPLICANT_GLOBAL_SOCKET, NM_RUN_DIR)))
goto exit;
+ kernel_driver = nm_device_get_driver (NM_DEVICE (self));
+
+ /*
+ * We want to work with the generic wext wpa_supplicant driver, but some kernel drivers
+ * are just utter junk. For those losers, we use a specific wpa_supplicant driver.
+ */
+ if (!strcmp (kernel_driver, ath_pci))
+ wpa_driver = madwifi;
+ else if (!strcmp (kernel_driver, prism54))
+ wpa_driver = prism54;
+ else
+ wpa_driver = wext;
+
/* wpa_cli -g/var/run/wpa_supplicant-global interface_add eth1 wext /var/run/wpa_supplicant */
if (!nm_utils_supplicant_request_with_check (ctrl, OK, __func__, NULL,
- INTERFACE_ADD %s\t\twext\t WPA_SUPPLICANT_CONTROL_SOCKET \t, iface))
+ INTERFACE_ADD %s\t\t%s\t WPA_SUPPLICANT_CONTROL_SOCKET \t, iface, wpa_driver))
goto exit;
wpa_ctrl_close (ctrl);
@@ -2468,6 +2470,7 @@
gboolean user_created;
const char * hex_essid;
const char * ap_scan = AP_SCAN 1;
+ const char * kernel_driver;
guint32 caps;
gboolean supports_wpa;
@@ -2489,12 +2492,39 @@
|| (caps NM_802_11_CAP_PROTO_WPA2);
/* Use AP_SCAN 2 if:
- * - The wireless network is non-broadcast or user created
- * - The wireless driver does not support WPA
+ * - The wireless driver does not support AP_SCAN 1
+ *(orinoco, prism54, airo, and ndiswrapper)
+ * - The wireless network is hidden and the driver
+ *does not support AP_SCAN 1 with hidden SSIDs (ipw2100)
+ * - The wireless network is user created
+ * - The wireless driver does not support WPA
+ * Otherwise, we prefer AP_SCAN 1.
*/
user_created = nm_ap_get_user_created (ap);
- if (!nm_ap_get_broadcast (ap) || user_created || !supports_wpa)
+ kernel_driver = nm_device_get_driver (NM_DEVICE (self));
+ if (!strcmp (kernel_driver, orinoco_cs))
+ ap_scan = AP_SCAN 2;
+ else if (!strcmp (kernel_driver, prism54))
ap_scan = AP_SCAN 2;
+ else if (!strncmp (kernel_driver, airo, 4))
+ ap_scan = AP_SCAN 2;
+ else if (!strcmp (kernel_driver,
Re: Another Network Manager Stupidity: Swapping eth0 and eth1
Yeah, it's actually udev that's swapping the device names (happens to me too), depending on the order they get initialised. Guess the 'usual' network scripts may already have had some magic to deal with this... I've not tried it myself, but you can create new udev rules to lock the mac address to a specific interface name. There's a good example here - http://www.debianhelp.co.uk/udev.htm HTH, Jon. Darren Albers wrote: I don't think this is Network Manager, it does not touch that as far as I am aware of. I have seen this problem in Ubuntu and I think it was a bug in hotplug that caused it to swap. The bug was filed in Launchpad.net http://Launchpad.net so maybe if you can find it there you will find more information and a possible fix for Fedora? On 5/9/06, *Charles Curley* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have just found what may be another Network Manager (NM) stupidity. I have two NICs on my laptop (http://www.charlescurley.com/Lenovo.R51.html) running Fedora Core 5. One is a wired Ethernet interface, the other a wireless Ethernet interface. In system-config-network, I have anchored eth0 and eth1 to specific MAC addresses. I recently switched from using the usual configuration tools to NM. I just found out is that NM seems to be ignoring that MAC address anchoring. It has swapped eth0 and eth1. As a result of this the firewall defined by firestarter does not work, and as a result of that my system is wide open and has been for several days. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-Hoc networks again
On Thu, 2006-05-11 at 14:44 -0400, Darren Albers wrote: I know this has come up in the past but I can't remember if anything was ever decided on it, but I have been traveling a lot lately and while in airports I have mistakenly tried to connect to misconfigured laptops running in ad-hoc mode that has carried over the SSID from somewhere else (This happens to windows users who have their system configured to connect to any available AP). Was anything ever decided on if Ad-hoc networks were going to be marked or hidden in the UI? It is not a big deal, just a minor annoyance since I can use iwlist or kismet to see which ones are real access points. Other than this Network-Manager has been rock solid for me! I (and I suspect Mr Williams, as well) would be totally happy to get a patch that somehow distinguished Ad-Hoc networks in the UI. It just needs to be stetic. We probably need new icons. It can be handled in the same way we do secure networks now, with a different icon. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Robert Love wrote: On Thu, 2006-05-11 at 18:24 +0100, Jon Escombe wrote: That said, my private key password (for a WPA2 network) is stored in the xml file rather than the keyring ;), but doubtless it'll be stored somewhere better in due course.. I just fixed this in CVS, a few days ago. ;-) Upgrade to HEAD. You'll need to manually remove the key from gconf -- NM won't do it automatically -- but the private certificate file passphrase for WPA Enterprise networks is now in gnome-keyring. Robert Love Good stuff! Thanks... ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-Hoc networks again
That would mean that I need to actually use my 10 year old Comp Sci degree which has been sitting unused since the day I completed it! lol I might take a look at this and see if I can puzzle out a patch for this, it would be a good way to get some rust off with what is hopefully a relatively simple project. On 5/11/06, Robert Love [EMAIL PROTECTED] wrote: On Thu, 2006-05-11 at 14:44 -0400, Darren Albers wrote: I know this has come up in the past but I can't remember if anything was ever decided on it, but I have been traveling a lot lately and while in airports I have mistakenly tried to connect to misconfigured laptops running in ad-hoc mode that has carried over the SSID from somewhere else (This happens to windows users who have their system configured to connect to any available AP).Was anything ever decided on if Ad-hoc networks were going to be marked or hidden in the UI? It is not a big deal, just a minor annoyance since I can use iwlist or kismet to see which ones are real access points. Other than this Network-Manager has been rock solid for me!I (and I suspect Mr Williams, as well) would be totally happy to get apatch that somehow distinguished Ad-Hoc networks in the UI. It just needs to be stetic.We probably need new icons.It can be handled in the same way we do secure networks now, with adifferent icon.Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
John Lagrue wrote: On 11/05/06, Gene Heskett [EMAIL PROTECTED] wrote: I wonder why it is that negative comments I make about NetworkManager seem to always go into a black hole, never coming back from the list. It appears to me that there might be a small snowballs chance in hell of its working if two conditions are met: 1. Must be running gnome or it appears all the tools aren't available 2. Must NOT be using ndiswrapper. I agree about gnome - which to my mind is a large disadvantage. It means I have to be running a GUI before it will do anything. But it works a treat with ndiswrapper on my Fedora 5, as it did on FC 4 and FC 3 before that. JDL And I repeat, here, running kde, all it does is tear down the network and hang. You can stop it, kill it, do anything you want, but the only way to restore network function through ANY port, ethernet or wireless, is a full, powerdown reset. A normal reboot will not do it. Tested many times. Rosanna's docs leave way too much to the users imagination, showing only what she did that made it work, and absolutely no discussion of why it worked or of what might be wrong it it doesn't. Here it doesn't, and ATM I'm firmly of the belief that its at least 75% because I'm a KDE fan. OTOH, the default gnome install is still here, and I believe that a 'switchdesk gnome' and an X restart would recover it. However, I had such a hell of a time getting it truely into the kde camp that I'm not inclined to want to try the backswitch test it. IMO, a place like NM is a hell of a platform to conduct the gnome vs kde wars from. This is after all, linux, and something like NM should be independent of the users gui choice. It should be able to work from before an init 3 login even. A further squawk John, I'm on many mailing lists, but why am I getting private replies that really should be going back to the mailing list for everyones use? I just added the list back onto this message. Generally, I can click on reply rather than reply all, and get the mailing list, but on this list, a simple reply goes to the poster only. That really should be addressed so that it takes a reply all to included double bombing the posters inbox. Of course this is thunderbird, and its flakey enough it could be a t-bird problem. -- Cheers, Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Hello. On Thu, 2006-05-11 at 15:21, Gene Heskett wrote: Generally, I can click on reply rather than reply all, and get the mailing list, but on this list, a simple reply goes to the poster only. That really should be addressed so that it takes a reply all to included double bombing the posters inbox. No. Set reply-to to the ml is Reply-To munging. Gnome does it right. http://www.unicom.com/pw/reply-to-harmful.html Everey good email client supports reply to ml. regards Stefan Schmidt signature.asc Description: Digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Darren Albers wrote: It appears to me that there might be a small snowballs chance in hell of its working if two conditions are met: 1. Must be running gnome or it appears all the tools aren't available 2. Must NOT be using ndiswrapper. This assumes that the now 4 month old tome from redhat, written by Rosanna Yuen has been printed, salted peppered and comsumed in hopes it might enlighten the potential user. For this user, it does not. And its all gnome-centric, totally ignoreing kde users. Does this mean that kde users will be forever locked out of using this tool? Ubuntu and SUSE are both shipping with KNetworkManager so NM for KDE is available now. I think it is hosted in the KDE.org SVN. So when is it going to be made compatible with kde, AND ndiswrapper so all of us using broadcom radios can share in the apparent glee here. My experience with NM has been uniformly negative, with every attempt to run it destroying all networking and requireing a full powerdown reset to restore it. The problem is not N-M it is NDISWrapper supporting a full set of Wireless Extensions, I think that the latest (Or maybe it is the version in CVS) fully support the latest version of WEXT and work with N-M. So if you have a new version of NDISWrapper and run KNetworkManager you should be good to go. Currently running: ndiswrapper-1.13-1.lvn5 But I've not seen a KNetworkManager yet. I do have kwiwfimanager, but it seems to be only a guified version of iwlist /device/ scan. It use to unghost the switch network button, but has never done that here in the motel. And, where iwlist wlan0 scan shows both AP nodes here, Kwifimanager only sees one. Both carry the same ESSID of course, but different MAC addresses. so its basicly a snooper program as yet. If, as everyone seems to be claiming, its been working since FC3, then it seems to me it should be nigh onto bulletproof by FC5. Instead, its the bullet that kills everything it touches here. -- Cheers, Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Hello. On Thu, 2006-05-11 at 15:30, Gene Heskett wrote: But I've not seen a KNetworkManager yet. http://websvn.kde.org/trunk/kdereview/knetworkmanager/ You can even search this ml for information about it. regards Stefan Schmidt PS: Please strip down your answers to the necessary bits. signature.asc Description: Digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On Thu, 11 May 2006, Aaron Konstam wrote: Your post is extremely interesting but leaves me with a question and a statement. Question: I thought I was using 13 character WEP passwd but the file in the .gconf records only a 10 character passwd. Why is this? It sounds like it could be a legacy of earlier versions. Your 13 character key is probably in the keyring. Now about locking. You choose a lock consistent with the security you want to have. I am satisfied to have a lock and deadbolt on my house but it is not completely secure. Someone would have to be crazy to spend 10 to 24 hours to crack mt WEP passwd. If I was a bank it would be different. I am not convinced yet that for the vast majority of users a 13 bit WEP passwd is not secure enough. I also agree removing the ESSID makes it harder to figure out what access point you are connected to. No, for the vast majority of users WEP is enough. The point is that gnome-keyring is overkill for those users as well. 700 protection of the key in your home directory is probably enough as that is locked against everybody but root, and nothing is really locked against root. The weakness in the house metaphor is that the house has a universal master key in the hands of a hopefully benevolent but fairly easily subverted individual (who could be you). At any time they can unlock your house even if you otherwise bury it in ten feet of steel reinforced concrete, and THEY live in a house which has proven annoyingly vulnerable countless times in the past, allowing their master privileges to be stolen by the good and the wicked alike. rgb -- Robert G. Brownhttp://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Stefan Schmidt wrote: Hello. On Thu, 2006-05-11 at 15:21, Gene Heskett wrote: Generally, I can click on reply rather than reply all, and get the mailing list, but on this list, a simple reply goes to the poster only. That really should be addressed so that it takes a reply all to included double bombing the posters inbox. No. Set reply-to to the ml is Reply-To munging. Gnome does it right. Ok, so where do I set that in t-bird? http://www.unicom.com/pw/reply-to-harmful.html Everey good email client supports reply to ml. regards Stefan Schmidt ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Cheers, Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Darren Albers wrote: I am 99.9% certain that outside of the Network Manager Front-end (nm-applet) it is platform independent, for Gnome there is NM-Applet, for KDE there is KNetworkManager (I think it is available from kde.org SVN). The network-manager tarball comes with nm-applet but it should not be hard to build it without nm-applet. I can help work that out if you need help. On 5/11/06, Gene Heskett [EMAIL PROTECTED] wrote: IMO, a place like NM is a hell of a platform to conduct the gnome vs kde wars from. This is after all, linux, and something like NM should be independent of the users gui choice. It should be able to work from before an init 3 login even. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list From memory, and following Rosanna's instructions, in the middle of page 3: NetworkNanagerInfo I don't believe its even found to run. At risk of needing to reboot before I can send this, I'll dbl check, yes: [EMAIL PROTECTED] GNOME]# NetworkManagerInfo [1] 3901 bash: NetworkManagerInfo: command not found [EMAIL PROTECTED] GNOME]# And there is no such seperate package available according to yumex. Following on down the page, the next item: as far as I know, there is no kde equ to gnome-session-save, so I didn't do that at all. Also, NM itself seemed to have crashed as I've yet to see the network selection menu on the screen of this machine. It wouldn't respond to a service NetworkManager stop, and I wound up hitting the power button, and then having kyum install htop so I had a reliable way of killing stuff that needed killed. But, I'll repeat again, it tears down the network I have so badly only a full power down reset will restore it. Thats as far as I've ever gotten with it. No docs, no manpages or real help has been offered, usually the reply is that 'it works for me'. Here its well and trueky busted so why should I take a chance of its trashing my hd or whatever else it might want to do next? As far as sticking with WEXT, whatever that means as I've not seen that acronym till now, it seems to me that efforts to do workarounds should be in stuff like ndiswrapper/bcml5 yadda yadda, so I agree that there should be a standard interface IF that interface well and truely covers all options. I'm not convinced this interface does yet. And darned little of this is ever going to get tested as long as its hidden in an svn repo someplace I don't have the address of. Throw in that I haven't put in checkinstall and configured it for rpms yet, and I am determined to stay with an rpm based install this time and you can see a bit of my problem. You want testing and reports?, package it make it available on a well know repo even if its alpha rated stuff. Then it will get tested. -- Cheers, Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] more support for openvpn
Robert Love wrote: On Thu, 2006-05-11 at 00:45 +0200, Groug wrote: This patch adds support for openvpn --tls-auth and --cipher options. Looks good, committed to STABLE and HEAD. I've actually had people request tls-auth support so this is a welcome addition. Btw, are there plans to release new tarballs for the VPN plugins? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Gene Heskett wrote: Ok, so where do I set that in t-bird? Reply to all. --Pat ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On 5/11/06, Gene Heskett [EMAIL PROTECTED] wrote: And I repeat, here, running kde, all it does is tear down the network and hang. You can stop it, kill it, do anything you want, but the only way to restore network function through ANY port, ethernet or wireless, is a full, powerdown reset. A normal reboot will not do it. Tested many times. That seems odd, it might be an issue between NDISWrapper and NM but I doubt it.If you remove Network Manager does the problem go away? Is this a Broadcom chipset card? Thats as far as I've ever gotten with it. No docs, no manpages or real help has been offered, usually the reply is that 'it works for me'. Here its well and trueky busted so why should I take a chance of its trashing my hd or whatever else it might want to do next? If that is the way you feel then continue using whatever tools you prefer to manager your wireless networks and wait until NM is more stable. Network Manager is not required you can use whatever the tools kde provides. However I am willing to help you try KNetworkManager if you want to experiment. Before you read the below let me make this clear: I have never used an RPM based Distro like Fedora or SUSE so what I tell you could be completely wrong. I think you are running into a Distro issue and not a Network Manager issue, I did a quick google search and I don't see any Fedora RPM's for KNetworkManager (I found some for SUSE). I suspect the reason for this is that KNetworkManager was not ready for FC5's release and not any deliberate snub on the part of the Fedora team. However since you are not running Gnome nm-applet should not even be starting so you should be able to just install KNetworkManager and be good to go. Stefan posted a link to KNetworkManager this list earlier so you can use svn to checkout the latest snapshot. Assuming you have svn installed you can grab it with: svn co svn://anonsvn.kde.org/trunk/kdereview/knetworkmanager Assuming you have all the required libraries you then do the standard ./configure make make install all options. I'm not convinced this interface does yet. And darned little of this is ever going to get tested as long as its hidden in an svn repo someplace I don't have the address of. This is not an issue of the Network Manager Dev's this is an issue with your distro maintainers. Maybe someone here who runs Fedora can point you towards a testing repository that has it? If you look at Ubuntu you will find a large number of Kubuntu users happily using Network Manager under KDE with no large issues so I feel confident saying that KDE and NetworkManager can work great together. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] special iconf or ad-hoc networks.
This is great! Thank you so much! On 5/11/06, Robert Love [EMAIL PROTECTED] wrote: I grabbed my own gauntlet. Attached patch gives Ad-Hoc networks a special icon. I just used some gtk stock icon of a computer. We can -- we must -- do better. Also, a TODO item: putting both the encrypted and an ad-hoc network icon would be ugly and take up too much room. So we should have a comingling of the two icons that says encrypted and ad-hoc. Right now I ignore that case and show all encrypted networks with the current encrypted icon, Ad-hoc or not. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On 5/11/06, Gene Heskett [EMAIL PROTECTED] wrote: Assuming you have svn installed you can grab it with: svn co svn://anonsvn.kde.org/trunk/kdereview/knetworkmanager (wd now: /usr/src) [EMAIL PROTECTED] src]# [EMAIL PROTECTED] src]# svn co svn://anonsvn.kde.org/trunk/kdereview/knetworkmanager svn: No repository found in 'svn://anonsvn.kde.org/trunk/kdereview/knetworkmanager' Oops, try svn co svn://anonsvn.kde.org/home/kde/trunk/kdereview/knetworkmanager And that starts the long road to an unmaintainable system like I have at home, where it took me a year to actually get everything I needed working right. So the system works great, but not even yum in that early version will touch it, too many broken dependencies. I'd druther not start down that road just yet with this new lappy. Understandable so NM may not be something for you until someone builds a KNetworkManager RPM. Though I can't imagine that KNetworkManager would cause this problem since it does not require any special libraries and if you use Checkinstall it can be removed cleanly. This is not an issue of the Network Manager Dev's this is an issue with your distro maintainers. Maybe someone here who runs Fedora can point you towards a testing repository that has it? This is the standard mantra on this list, its *never* NM fault. That gets old. I think you might be speaking out of anger here and not looking at this objectively. I have lurked/posted here for awhile and have found everyone to be very responsive but a certain level of initiative is expected and willingness to experiment since this is a pre-1.0 release. If you read the list archives you will see A LOT of discussion and help between the devs and others posted on this list. A number of suggestions have been provided but you have dismissed them. I think the problems for you are the following: 1) Your Distro does not have the KDE Front-end yet - Not NM's fault 2) Your Distro decided not to include the patches for direct NDISWrapper support or is running an old version of NDISWrapper - Not NM's fault You may not like the answer but it is the truth, it has been proven repeatedly that NM works for ALOT of people and if you are not willing to experiment then nobody can help you. If you are not comfortable building a package yourself and working out the problems then your only choice is to switch to a distro with support or wait until FC5 supports it so these issues are cleared up for you. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
Darren Albers wrote: On 5/11/06, Gene Heskett [EMAIL PROTECTED] wrote: I did install the latest ndiswrapper thats available: [EMAIL PROTECTED] src]# ndiswrapper -v utils version: 1.8 driver version:1.13 vermagic: 2.6.16-1.2111_FC5 686 REGPARM 4KSTACKS gcc-4.1 The previous version didn't work at all, wouldn't even modprobe. Mmm I think that should work with NM but until you get a front-end working we won't know for sure. Here is the WEXT compliance ticket for NDISWrapper, version 1.11 seems to have full WEXT compliance so you should be good. Ok, I got the svn, but its its missing the configure and make stuffs. Here is an ls on the top level dir: [EMAIL PROTECTED] knetworkmanager]# ls AUTHORS ChangeLogCOPYING INSTALL knetworkmanager.kdevelop NEWS README TODO autom4te.cache configure.in.in Doxyfile knetworkmanager.conf Makefile.am pics src I think the autom4ke.cache was made by my attempt to run autoconf, I don't recall seeing it before. Not knowing all that much about autoconf, I tried that using configure.in.in as its argument, but that bails very quickly: [EMAIL PROTECTED] knetworkmanager]# autoconf configure.in.in configure.in.in:3: error: m4_defn: undefined macro: _m4_divert_diversion autoconf/c.m4:1011: AC_C_BIGENDIAN is expanded from... configure.in.in:3: the top level autom4te: /usr/bin/m4 failed with exit status: 1 So the svn suck is not complete with enough stuff to build it, or I need more tutorials. The only other time I used svn, it worked very well indeed. But here I quit while I was ahead... -- Cheers, Gene ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: A comment on NetworkManager
On 5/11/06, Casey Harkins [EMAIL PROTECTED] wrote: Russell Harrison wrote: simplicity of the interface.Right now its so simple I don't see how any layperson could understand it, there just isn't any feed back orI don't understand this at all. I have a few laptop users who are not very computer literate (not even on Windows), but have no problems usingNetworkManager, without any instruction.Try giving it to a novice and asking them to get on the network when a network doesn't automatically show in their list. Networks that don't broadcast their ESSID, are the prime example here. Or why does NM disconnect from a network I'm already connected to when I click on it. Profiles are a big thing for me since I want to be able to deploy laptops on our network and configure them by installing an rpm.Its so much cleaner than creating a bunch of documentation, to tell them how to set it up themselves.That's confusing, they don't need to know what authentication mechanism we use, or even care what the network is named.They just want to be on it.Unless each user has multiple configurations, I don't see the need forprofiles here. Who doesn't have multiple configurations? Besides many companies have slightly different configs for the various campuses. As for setting their defaults up for them from an rpm,just create an rpm that runs gconftool-2 (in %post) to set theappropriate NetworkManager settings. You make these defaults, or evenmandatory settings (so they can't change them). 1.) Wireless networks list. There is no Search for wireless networks or Refresh wireless networksIdeally, NetworkManager should update the wireless networks listautomatically without these options. If that can't be done (do most hardware wireless switches expose their state through their kerneldrivers?), then maybe a refresh option would be necessary.This is probably one of the biggest questions I get about NM. Why don't I see my network when I know I'm in range. I don't doubt it is a driver issue but a Search for Networks or something would be helpful. Especially with cards that don't have the best driver support. 2.) The configuration issue. In my view NetworkManager is one of the most intransparent linux applications out there. There's no Documentation (correct me if I'm ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
