Re: Alternative way to set static ip for Ubuntu
On 29 November 2012 13:03, Pavel Simerda psimerda redhat com wrote: >> From: "footkeong Chien" >> I would like to know whether there is any alternative way to set >> static ip for Ubuntu using command lines without affecting the >> etc/network/interfaces. ... > Is this a NetworkManager question? I guess it is. Ubuntu uses NetworkManager and at least I would not try to fiddle with a interface managed by NetworkManager with some basic commands, because you never know what NetworkManager will override (well "you" as in average user, not "you" as those on this list who really know all NM internals) Unfortunately the original poster did not write to what (working?) approach he was looking for an alternative, why he wanted to use the command line, does he want the static IP on eth0 or some other interface, and does he want the assignment to survive a reboot. Earlier this week I had the issue that I wanted to assign a permanent static IP to my eth0 on a Kubuntu Lucid system. Intuitively I would have done that by setting a static address on the "auto eth0" connection in the KDE connections control module. However, that does not work because at least in Kubuntu Lucid "auto eth0" is somehow automagically hidden from the UI. I have the feeling that I might have seen it in Ubuntu systems (using gnome connection manager), but I cannot check at the moment. Yes, I also tried to create a new connection, but that connected only manually on the first attempt and caused a crash (in knetworkmanager I believe) in the second one, so I did not pursue that approach any further. On the net I found the same question many times, but no really good answers, which seems to support the impression that people are struggling with the issue. I found e.g. these instructions http://en.opensuse.org/SDB:Knetworkmanager_static_ip_auto_eth0 too complicated for my purpose. So I just edited /etc/network/interfaces instead and defined eth0 as auto and static. That leads to desired functionality. NetworkManager regards the interface as unmanaged. However the knetworkmanager user experience is non-intuitive in this case. It shows me a disconnected Ethernet cable. Somewhat irritating at least the first week, but I can live with it. Still from the "naive" end user standpoint it is a bit weird that NetworkManager cannot handle such simple use case. (Yes, technically the limit might not be in NetworkManager proper but in KDE connection editor. And static addresses is not the main reason why NetworkManager exists.) But regardless of the reason, there is still a bit to go until Linux Networking is made really easy... Or have things changed completely since then? Lucid is of course 2.5 years old. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Increased RAM usage with nm-applet 0.8.0 to 0.8.1
On 12 December 2011 09:29, Jeff Hoogland wrote: > Attached are the two outputs you requested, digging through them now to see > if I can pinpoint the issue. > Did you find out anything? I converted the outputs to csv, loaded them into an OpenOffice spreadsheet, summed up each category of memory and compared your 2 versions. The differences are really marginal, depending on the memory category sometimes in favor of the old and sometimes in favor of the new version. In terms of resident memory, which should be the most important measure (no swapping has occured) the new version is even 792 KiB (~ 7 %) smaller than the old one. Unless my conversion script really screwed up something and by accident the bug just happened to level out your obvserved 110 MiB difference such difference does not exist. If anybody wants my script and my spreadsheets to double check I can send them by personal mail. I don't want the flood the mailing list with big attachments, which are probably not of big interest for most readers. (There are also other tools to read smaps files on the net, I have never tried them.) Memory consumption in Linux is a tricky thing. There are many different categories to measure (that's why smaps was added some time ago to show them all or at least many of them). There is no single correct number. If the tool you used to compute the 110 MiB delta shows only a single number, are you sure the way the number is calculated has not changed between your old and your new system? I assume you used the same tool in the old and the new system, otherwise it's even more likely that you ended up comparing apples and oranges. 110 MB difference looks huge by any measure. According to to my results the mapped address space of the new version is "only" around 46 MiB. I don't think any reasonable measure can be bigger than the mapped space. (The old one is around 45 MiB, the difference 712 KiB) Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Increased RAM usage with nm-applet 0.8.0 to 0.8.1
On 12 December 2011 06:33, Jeff Hoogland wrote: > but the issue I am having is that this newer version is using nearly > 110megs more RAM than version 0.8.0 does - any ideas why this might > be? Technical progress... Seriously, have you checked where the difference comes from? Can you run the command cat /proc/$(pgrep nm-applet)/smaps on both your old and your new system and post the results here? I'm not an nm-applet hacker, but that's how would I start to look at it. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Nokia 3G USB Modem CS-17 very unreliable
On 17 November 2011 21:08, Dan Williams wrote: > Based on our IRC debugging yesterday, I've gone ahead and pushed a fix > to ModemManager that uses only USB interface 0 for PPP on these devices > since that's what the Windows driver indicates. The driver didn't have > a section for your variant of the CS-17 (0x0623) but I added that USB ID > anyway. Thanks for the fix. I backported the fix to Ubuntu Lucid 10.04 LTS (modem-manager 0.3 + patches) and OpenSUSE 11.4 (modem-manager 0.4 + patches). The patch did not apply cleanly, but I think it was still very straightforward. On Lucid the first test failed, but after that it has been in use ~10 times without problems. On OpenSUSE I have used it maybe 5 times and everything was fine. (Luckily I don't depend on 3G most of the time so I don't come up to big numbers of usage occasions) However, 2 days ago it suddenly stopped working again. I added a g_debug to see what port type is recognized, and they were indeed both MM_PORT_TYPE_UNKNOWN. So did all the successful usage after applying the fix just result from pure luck??? Sounds weird, because before the patch the probability of successful usage was not very high. I have never looked at udev functionality before, but with a bit of guessing and running "/sbin/udevadm info --query=all --name ttyACM0" I came to the conclusion that ttyACM0 is on USB interface 1 and ttyACM1 is on interface 3. (Your patch expects ttyACM0 on interface 0) I know basically nothing about USB. Not sure whether USB interface numbers could possible change randomly (well, depend on some timing or other environment issue)??? So that in the beginning the patch did happen to work, but when the interface number changed of course it could not work anymore??? Anyway, I changed the udev rule now that USB interface 1 has the port of type MM_PORT_TYPE_PRIMARY. Based on my limited testing today I can say that it works. My OpenSUSE patches are at https://build.opensuse.org/package/revisions?package=ModemManager&project=home%3Ageuder%3Abranches%3AopenSUSE%3A11.4%3AUpdate%3ATest (and the rpms can also be downlaoded from there, click on "overview" and "standard" to get to the repo) On Ubuntu Lucid the behaviour was exacatly the same. The patches and Debian packages are not online at the moment, but I could certainly make them available if anybody is interested. Regards, Uwe P.S. Even if the correct port has be selected now reliably there are still a couple of bugs left that make this USB stick somewhat unreliable to use (following observations are from OpenSUSE 11.4 just from today) - sometimes an assertion is hit in modem-manager - NetworkManager has died on SIGSEGV - the network plasmoid of KDE dies and/or gets unresponsive (yes, I know network manager is a GNOME project...) - The kernel has crashed after trying to dereference a null pointer, probably in USB driver when removing the stick This is just FYI. Probably this should first be tested in OpenSUSE 12.1 or even with the newest network manager. Not sure when I will get there. P.P.S. Again FYI: In OpenSUSE 11.4 the packaging of modem-manager is not very good. autotools have been run with some obsolete version (older than what is in 11.4) and the generated files have been included in the source tar. As you see from the version history I patched that also, otherwise the new udev rules get never installed. I have not checked whether this has already been fixed in 12.1 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wrong SIM-Pin not detected by MM?
On 15 November 2011 10:45, Joseph Gunn wrote: > On Tue, 15 Nov 2011 10:19:13 +0200 > Uwe Geuder wrote: > >> Probably the implementers of the N900 reasoned a bit like me: Because >> entering the PIN is not relevant at the AT modem interface of the phone >> at all, they just return ERROR instead of implementing anything real. > Is it possible that the phone/computer link is bluetooth? Depending > on the setup that may require a PIN? No, I absolutely don't think so. Any potential bluetooth PIN is handled at a completely different protocol level inside the bluetooth stack, not with AT commands at modem level. In the first posting there was an ERROR reponse to an AT command. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wrong SIM-Pin not detected by MM?
On 15 November 2011 09:55, Thomas Bechtold wrote: > MM can handle different modems. Not only modems included in phones. eg. > usb-umts-modems aks for the sim pin. > Absolutely. But in your first message you had a example for MM PIN handling from an N900. Because N900 is a phone I did not understand how the example could be relevant. Probably the implementers of the N900 reasoned a bit like me: Because entering the PIN is not relevant at the AT modem interface of the phone at all, they just return ERROR instead of implementing anything real. If you have an issue with PIN handling you would need to demonstrate it with a 3G USB modem, which really requires PIN handling by MM. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Subject: Wrong SIM-Pin not detected by MM?
On 15 November 2011 09:12, Thomas Bechtold wrote: > i just tested with a N900.It's more a general question and not a specific > problem with the N900. > Ok. Then my general remark would be: Aren't all phones used like that, that they are first powered on and registered to the network? So the PIN is entered using the UI of the phone before MM gets involved. I don't understand why a PIN would be used in any way when opening a modem connection on a phone. To my understanding (which is not very detailed) MM asks the PIN state from the modem. In the case of a phone the answer should never be PIN required. At least Nokia phones don't require the PIN to make a modem connection. (I have not tried what happens if the phone is in offline mode) Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Subject: Wrong SIM-Pin not detected by MM?
On 13 November 2011 19:49, Thomas Bechtold wrote: > i tried NM 0.9 (latest from git) with MM 0.5 (from ubuntu 11.10) and > recognized that MM does not detect a wrong SIM-Pin (with a Nokia N900). > i used a wrong Pin (1234) and got the attached NM logs when i tried to > activate the connection with "nmcli con up id simyo". I have used N900 with NM many times before. Only with 0.8.x though and only with the graphical applets (both GNOME and KDE). I don't understand what you (or the software) want to do with the PIN code at all. For a USB modem the device is turned on in the computer (power comes from USB) and there is no UI in the modem. So indeed, MM has to provide the PIN code. However, N900 is a phone. It is powered on and in the network before the USB cable is even connected. The PIN is provided by the user via the phone UI. Once the modem connection is started there is no need to provide the PIN a second time. Everyhting should work fine without it. Or am I missing something here? Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Nokia 3G USB Modem CS-17 very unreliable
Hi! I have a Nokia 3G USB Modem CS-17. Unfortunately it works very unreliable under Linux. If used it with Ubuntu Lucid 10.04 LTS, OpenSUSE 11.3, OpenSUSE 11.4, and Windows XP. Under Linux the failure rate is some 60%-80% and retrying repeatedly does not help. Under XP the failure rate is some 10% and if the first attempt fails retrying helps. If the connection succeeds it is typically very good. I have used it about 1 hour on a running train and I have reached connection speeds up to 5 Mbit/s (not on a running train though...) The attached logs are from Lucid, which uses NetworkManager 0.8-0ubuntu3.2 and modem-manager 0.3-0ubuntu2.2. The typical error case is no responses from LCP (see attached logs). In some rarer occasions the LCP responses are invalid. Not sure how this is related to network manager. But Linux PPP seems to be stable (in the meaning of no changes) for a long time. And it should not be a network issue, with XP I don't experience the same problem. Can you spot anything helpful from the attached logs? Does it make any sense to investigate with nm 0.8? If necessary I can build the newest version. But I vaguely remember from some earlier postings on this list that it's not completely trivial with all the interdependencies of NetworkManager, modem-manager, D-Bus, configuration in /etc, knetworkmanager[1], and what else might needed to be taken into account. So a pointer to instructions would be welcome. Regards, Uwe [1] I typically use KDE. But I have at least tried it once on a GNOME system and the connection problems were the same ones. I cannot imagine that the applet is the culprit. logs1.tbz Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Additional network interfaces in OpenSUSE?
>> However, no it looks in OpenSUSE I cannot even run "ifup br0" >> when network manager is running. Thanks for your answer. On 6 September 2011 06:59, Bin Li wrote: >The best way is to use ifup mode in openSUSE, Yes, I've already managed to use my WLAN connections with ifup. However, I could not find out how to use my USB 3G stick with ifup/netconfig. I tried to configure it as a modem in yast, but there wasn't even a UI to enter the PIN code. Probably I could put extra AT commands to some config file, but I didn't want to back that far. It's year 2011 ;) Is there real support for USB 3G modems in the the traditonal OpenSUSE networking? (sorry, that might be a bit off topic to ask on the network-manager list how not to use nm...) > and if you wanna use the NM, > you could try to use 'unmanaged-devices=mac:;" in NetworkManager. > conf. you can find more with 'man NetworkManager.conf Ahh, good point. I had read that before, but I erroneosly assumed that the plugin in question is not in use in OpenSUSE. But it is. So from network manager part this should be OK. But ifup script does still not work. I've just tested it, and no surprise, the piece of code I copied in my original posting decides that network manager is running so ifup exits immediately. Yes, I could patch the ifup script so it does not exit, but is that really the way to go? Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Additional network interfaces in OpenSUSE?
If I understood it correctly in Debian/Ubuntu network manager will leave additional interfaces defined in /etc/interfaces unmanaged. So you can combine your "main" internet access managed by networkmanager (eth0, wlan0, ppp0 depending on where you are) with "additional" manual network setting you might need insided you machine (e.g. for various virtual machines you might be running) Did I understand that corrcectly? However, in OpenSUSE I cannot see how to achieve anything similar. As soon as network manager is enabled, ifup does not work any longer. >From what I see in the source code this is pretty unconditional: from /usr/src/packages/BUILD/sysconfig-0.74.5/scripts/ifup: (OpenSUSE 11.4) ---clip--- ## # Check if NetworkManager is running, inform the user and exit # if [ "$NETWORKMANAGER" = yes ] && ! netcontrol_running ; then if [ "$SCRIPTNAME" != ifdown -a "$INTERFACE" != lo ] ; then mesg "Network interface is managed by the NetworkManager -> skipping" exit $R_NOTIMPL fi elif nm_running && [ "$INTERFACE" != lo ] ; then mesg "Network interface is managed by the NetworkManager -> skipping" exit $R_NOTIMPL fi --- clip --- Hopefully I'm just missing something here. Often it helps to know what one really wants to achieve, so here it goes: I need a bridge device for Xen. I let network manager take care of the internet access (this is a laptop) The straight forward approach putting the current "internet" interface chosen by network manager on the bridge would require to set the network address & routing to the bridge device instead of eth0/wlan0/ppp0. I don't think network manager can handle that. So my idea was to leave the bridge unmanaged from network manager, give it a static internal IP address and use ipforward together with NAT to connect the bridge with network manager's current "internet" interface. However, no it looks in OpenSUSE I cannot even run "ifup br0" when network manager is running. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to debug 3G USB modem problems?
Thanks Dan for your quick reply. It's too late here for taking more logs so let me just reply quickly on your other questions. > Huh, because they are $120 on eBay which isn't cheap at all :) > Otherwise I'd buy one. This operator http://saunalahti.fi/ gives you one "for free" even you just shop for a cheap fixed-line ADSL. Sounds unlikely that they pay very much for them, because their prices are on the cheaper side compared to the competitors even if you don't count the 3G modem at all. Might not be an option for you though :( Maybe they get cheaper on ebay.fi when many people end up with one without intending to use it. > What does the PPP debugging say when this happens? NM wont' terminate > the connection unless PPP says it's down. I would have included the log if I had it :( I have seen it when using command line, but I did not store it. My point and main question was how to get the logging to work when network-manager runs as a service. Because I can only test occasionally, the real user is not familiar with the command line and she has no root access. Hmm, actually I just find a copy on another machine. (And weird enough the pppd logging I was complaining about *IS* in that syslog) May 4 14:11:39 geuder-u10 pppd[1783]: Using interface ppp0 May 4 14:11:39 geuder-u10 pppd[1783]: Connect: ppp0 <--> /dev/ttyACM1 May 4 14:11:39 geuder-u10 pppd[1783]: sent [LCP ConfReq id=0x1 ] May 4 14:11:59 geuder-u10 pppd[1783]: last message repeated 6 times May 4 14:11:59 geuder-u10 NetworkManager: pppd_timed_out(): Looks like pppd didn't initialize our dbus module May 4 14:11:59 geuder-u10 NetworkManager: (ttyACM1): device state change: 7 -> 9 (reason 14) May 4 14:11:59 geuder-u10 NetworkManager: Marking connection 'Saunalahti Postpaid (contract) 1' invalid. May 4 14:11:59 geuder-u10 pppd[1783]: Terminating on signal 15 May 4 14:11:59 geuder-u10 pppd[1783]: sent [LCP TermReq id=0x2 "User request"] To me it looks that pppd does not get or not recognize any responses (rcvd lines) although it sends its first message uplink 7 times altogether. So NetworkManager decides to kill it after 20 seconds. I'll try to capture full logs including modem-manager later. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
How to debug 3G USB modem problems?
I understand that this a upstream list and most readers are interested in the bleeding edge. However, I have to support some systems for "naive" users and I prefer to use a plain vanilla distribution as long as possible. So please bear with my question regarding versions straight from the museum... On Ubuntu 10.04 (long time support) they have nm version 0.8-0ubuntu3 The USB modem in use is a Nokia CS-17. (I know that if you search for trouble, you select a 3G USB modem. Unfortunately this variant is really by orders of magnitude cheaper in this case than anything more reliable.) The good news is that the CS-17 works even with that old software. The bad news is that it's completely unreliable. Some 30%-50% of the connection attempts just fail. Unfortunately the failures seem to come in waves. If it fails the first time, it will also fail the 2nd, 3rd etc. Removing the modem does not help. But 1 or 2 hours later it might just work again. Alternatively if I want to repeat the problem, I can make 15 connections in a row without any failure. The other problem is that while the connection typically stays open for hours during normal web browsing, it will disconnect with quite high probability when downloading bigger files. Today I needed 4 attempts to download a 20 MB file. I would exclude network-side problems or weak signal, because I use 3G data on the same network nearly all day long on my smartphone without such problems. Additionlly, when the USB modem fails to connect I can use my phone as the modem using the data cable and everything works. So how could I debug this? Is it a Linux-side problem or a firmware problem in the CS-17? (Haven't had a chance to test it with M$ yet) >From searching in the mailing list archives I found 2 debugging hints: 1. starting nm from command line as # NM_SERIAL_DEBUG=1 NM_PPP_DEBUG=1 NetworkManager --no-daemon | tee log.txt That works nicely. When the connection attempt fails I see how PPP negotiation starts, but it doesn't seem to get any reply. sent [LCP ConfReq id=0x1] After 5 repetitions pppd seems to give up and nm complains that the connection failed. (Not sure whether NM_SERIAL_DEBUG has any effect, I don't think I see that variable in the source code of my version) The problem is that using the command line (and root) is OK for me on my test machine, but not for the user in question on the real target machine. So I'd like to configure the "real" service such that logging is always on. I tried to do so by adding the 2 environment variables to /etc/init/network-manager.conf (Ubuntu uses upstart) env NM_PPP_DEBUG=1 env NM_SERIAL_DEBUG=1 exec NetworkManager Unfortunately that seems to have no effect to the pppd logging. The pppd stuff that I can see when running with --no-daemon does just not appear in syslog, neither in successful nor in failing cases. (I have checked from /proc/nnn/environ that the environment variables really end up in the network-manager process) Also the debug parameter appears on the pppd command line as shown in syslog. How can I get pppd logging when running as a daemon? 2. The other hint I found in the mailing archive was a config file entry [logging] level=WARN I changed that to level=DEBUG, but I don't think it made a difference. Could not find such parameter in my source code. Has it possibly been added only in a later version? Yesterday I read in some forum that killing modem-manager after a failed connection attempt helps. Today I had only very few failed attempts in my testing and killing modem-manager helped each time. Not yet sure whether this is really a reliable work-around. If yes, I could of course script it. Does the problem description ring any bells? If you remember specific fixes that solve these issues, I might try to backport them to my version. Or just install a newer version manually. Regards, Uwe P.S. Yes, I am aware of the modeswitching. I left that out from the description above, I'm sure that the modem was always in the right mode. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration?
Hi! > Hm. I'm looking through lots of NetworkManager pages/docs and the GIT > repositories, and I see that there has been something titled "Local > caching nameserver support using dnsmasq" added in 0.8.2. Interesting. I'm using Ubuntu LTS so I'm not at the leading edge with nm, I guess it's 0.8. However, I have been running dnsmasq for a while (mainly to act as DHCP and DNS server for virtual machines I'm hosting on local network interface). On Ubuntu Lucid I solved the dnsmasq - nm integration as follows: - dnsmasq is configured to read upstream DNS servers from /etc/resolv.conf1 - nm is patched to write to /etc/resolv.conf1 instead of /etc/resolv.conf (I'm willing to share the patch if anybody is interested. I haven't done so, because it's not 100% perfect, see below) - /etc/resolve.conf is manually edited to contain 127.0.0.1. It will never be changed (*) (*) actually this is not true: pppd overwrites it every time. But this is an office machine and I use pppd only 1-2 times a year when the network is down, so I have not thought about fixing this. But it means that my solution is not suitable for people using dial-up regularly. On OpenSUSE 11.3 (I guess nm 0.8, too) this approach did not work, because network manager does not write /etc/resolv.conf. I'm not so familiar with OpenSUSE netconfig, but I have dnsmasq working together with nm without any patches. Maybe I needed a one time configuration change or netconfig did it for me, I don't recall. It works very reliably. It's actually a laptop and I use it regularly on very different networks (cable, WiFi and cellular), but dnsmasq - nm has never caused any trouble. In /etc/resolv.conf the first one is 127.0.0.1, i.e. dnsmasq, but dnsmasq knows to ignore that one. Additional ones are put there by nm / netconfig each time a new connection is established and dnsmasq uses them as upstream servers. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Using 2 interfaces with network manager
Hi! I've never understood how network manager works if more than 1 network interface is in use. Is it designed for such usage at all? What I want to do: - use wlan0 to connect to the internet using network manager. Access points might change from time to time, e.g. when travelling. - use eth0 for internet connection sharing (ICS). (using a cross connected Ethernet cable to provide an Internet connection to another device) I don't think network manager can do it, but I'm comfortable to do it manually (interface definition, IP forwarding and NAT) So I configure eth0 in /etc/network/interfaces as auto eth0 iface eth0 inet static address 192.168.77.1 netmask ... ... The other parts are not relevant for the discussion here. Ideally I want to leave this definition there, whether I use the ICS at the moment or not. (I don't think I have the need or even possibility to connect to a wired network) This works without problems in Kubuntu Lucid (nm 0.8.0) with knetworkmanager. However, in Ubuntu Lucid and Xubuntu Lucid (same nm version), which both use nm-applet instead of knetworkmanager there is a nasty problem. It works as long a previously defined WLAN is in range. But whenever no previously defined WLAN is in range, nm-applet is completely invisible. The "not connected" icon is just not there. And without having nm-applet visible I cannot really use any network. Well, I could scan for WLANs from the commandline, start nm-connection-editor from the command line and define the network. But then I have still to log out (or even reboot?) What i currently do is to edit /etc/network/interfaces each time I want to connect to a new WLAN. I remove eth0 from there and reboot (at least I have not found any way without rebooting. Just shutting eth0 down does not help.) After having defined the new WLAN using nm-applet I can revert the changes in /etc/network/interfaces. Needless to say, that's not really pain free networking. Is there any better solution? Is it a bug or feature that nm-applet gets completely invisible? Regards, Uwe P.S. Please bear with me that I have not yet tried nm 0.8.1. I just didn't dare to possibly screw everything up by rpelacing Ubuntu's nm with another version. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
