NetworkManager on Karmic Koala (0.8~a~git.20090804) doesn't recognise Mobile modem Huawei E1692 (lsusb shows E620)
Hi there! Same old story - worked in Jaunty after usb_modeswitch, doesn't in Karmic. Usb_modeswitch works properly, dmesg shows serial ports gets created, but NM remains silent in it's own debug (--no-daemon and NM_SERIAL_DEBUG used) and I can't connect to mobile broadband profile I created.mBug reported here: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/412362 I just wonder how I could help to get this modem back in the line? What debug shall I do and report for the record? What code I should pull and compile? :) I have some expierence with crunching bugs like this, so give me instructions, I will try to do the rest. Also another interesting feature of this modem in Jaunty is losing it's serial ports when mobile connection goes high-way. Only re-plugging and reswitching helps. Kernel bug? NM problem? Cheers, Peter. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
1 step closer to XO-1 mesh again
NetworkManager git master (to be released as v0.8, for Fedora 12) now includes support for the mesh hardware in the XO-1. so the next step is just to backport 6 patches to NM-0.7 so that they can be included in Fedora while we're waiting for F12, and then to fix up my Sugar patch for sugar-0.86. anyone interested? all details here: http://wiki.laptop.org/go/Network_manager_0.7 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Status of network-manager-netbook?
Hi All, I'm wondering where and how the network-manager-netbook addon to NetworkManager is suppose to happen? Is it supported via this list or somewhere else? The same goes for bug reporting, should it be going to bugzilla.gnome.org? If so can someone add a n-m-n component to the NM product? Or should it all go somewhere else? Cheers, Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Does such list exist?
On Tue, 2009-08-11 at 18:33 -0400, Wei Weng wrote: Hi all. Is there a list that has programs (or important parts of the system) that depend on NetworkManager to give you the online/offline status? Not that I know of. Off the top of my head though, Pidgin, Firefox, and Evolution all ask NM for offline status. That obviously means that if your primary internet connection is not managed by NetworkManager (which is the whole reason NetworkManager exists), then those programs will think you are offline. In that case, the primary internet connection should be managed by NetworkManager, or NetworkManager should be turned off. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-hoc connection extra information
On Tue, 2009-08-11 at 10:46 +0200, Simon Schampijer wrote: Hi, in Sugar I would like to transfer a string with my ad-hoc connection containing the color of the user creating the ad-hoc network. Does anyone know if there is an extra field I can use? Otherwise I could add it to the essid, but this is hacky of course. Yeah, that's hacky, but probably the only way :( About signal strength: The creator of an ad-hoc network, will see a signal strength of 0 in the UI. Maybe this should be set to 100% ? AFAIK, I do not get a signal strength from NM when creating an ad-hoc network. Intentional? I've been trying to push responsibility for the signal strength thing to the drivers, and have them report something sensible in this situation. If that fails, I'm happy to override that in NM I guess. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Status of network-manager-netbook?
On Wed, 2009-08-12 at 16:35 +0100, Peter Robinson wrote: Hi All, I'm wondering where and how the network-manager-netbook addon to NetworkManager is suppose to happen? Is it supported via this list or somewhere else? The same goes for bug reporting, should it be going to bugzilla.gnome.org? If so can someone add a n-m-n component to the NM product? Or should it all go somewhere else? You can probably ask about it on this list, but the work is all Tambet's (and thus Novell's) AFAIK. I'd speak up if I had anything to say, but I've got a lot to do on core NM so havent' played with nmn much yet. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Question regarding the features for the next release
On Mon, 2009-08-10 at 13:52 -0400, Darren Albers wrote: On Mon, Aug 10, 2009 at 1:04 PM, Dan Williamsd...@redhat.com wrote: On Fri, 2009-08-07 at 19:00 -0400, Darren Albers wrote: Dan, I see that PAN support is coming in 8.0 but your blog post mentioned that Bluetooth DUN would be a bit more difficult. Is that going to make the next release or would it be further down the road? I am primarily interested in being able to use Bluetooth to my Blackberry since that device won't show up as a serial device. Blackberry is going to be more problematic, since its serial stuff is quite a bit more special. It requires the use of berry to poke the USB bits into serial mode, requires special commands to send the PIN/unlock code to the device, and doesn't support a lot of the traditional AT commands. But thankfully I think ModemManager with 0.8 can handle that better and even perhaps transparently to NM. I don't have a ton of time to work on DUN at this moment, and I'm thinking it may not hit 0.8.0 unless we get some help on that front. But it's still certainly a priority. Dan If you use DUN over Bluetooth on a Blackberry it doesn't require all that junk thankfully which is why I was hoping to see DUN over Bluetooth support :) Ah right, over Bluetooth :) You're correct. Out of curiousity, any chance you can pull some ATI and AT+GCAP responses out of the device over DUN? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager on Karmic Koala (0.8~a~git.20090804) doesn't recognise Mobile modem Huawei E1692 (lsusb shows E620)
On Wed, 2009-08-12 at 09:38 +0300, Peteris Krisjanis wrote: Hi there! Same old story - worked in Jaunty after usb_modeswitch, doesn't in Karmic. Usb_modeswitch works properly, dmesg shows serial ports gets created, but NM remains silent in it's own debug (--no-daemon and NM_SERIAL_DEBUG used) and I can't connect to mobile broadband profile I created.mBug reported here: https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/412362 I just wonder how I could help to get this modem back in the line? What debug shall I do and report for the record? What code I should pull and compile? :) I have some expierence with crunching bugs like this, so give me instructions, I will try to do the rest. Modems are handled by ModemManager now, which is more flexible and a better architecture for the future. To figure out what's going on now, you'll want to: 1) Stop NetworkManager 2) run /usr/sbin/modem-manager --debug 3) Start NetworkManager 4) Plug in your modem And tell us what log output ModemManager spews out. Also another interesting feature of this modem in Jaunty is losing it's serial ports when mobile connection goes high-way. Only re-plugging and reswitching helps. Kernel bug? NM problem? What do you mean by loosing its serial ports? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Second message, about not being able to activate 'wlan1'
On Tue, 2009-08-11 at 17:03 -0400, John Mahoney wrote: On Tue, Aug 11, 2009 at 4:54 PM, derek starr derekli...@gmail.com wrote: To Rui Tiago Cação Matos, I have been busy with other matters, so I have not had a chance to respond to your answer regarding my problem of not being able to activate 'wlan1' with the GNOME NetworkManager, using the 'Fedora 11' Linux distribution. You said of the files below: 'less /etc/sysconfig/networking/devices': drwxr-xr-x. 2 root root 4096 2009-07-27 08:42 ./ drwxr-xr-x. 4 root root 4096 2009-04-14 07:25 ../ -rw-r--r--. 1 root root 153 2009-07-27 08:47 ifcfg-eth0 -rw-r--r--. 1 root root 198 2009-07-27 08:47 ifcfg-wlan1 -rw---. 1 root root5 2009-07-27 08:47 keys-wlan1 Try to delete (or move away) all those 3 files. Then reboot your system and click the network icon on the gnome-panel (top right screen corner by default). These are Distro configs that NM tries to make sense of. I do not believe they can be deleted through the GUI. Check this recent post for info: They should be able to be deleted, as long as you can authenticate as 'root' via PolicyKit. The ifcfg-rh backend supports deletion of system connections via the GUI. You'll find these in the connection editor (/usr/bin/nm-connection-editor) with names like System eth0 and such. Dan http://www.mail-archive.com/networkmanager-list@gnome.org/msg13444.html I just do not want to delete files being 'root'. I would rather use the NetworkManager applet, or as you said - the network icon on my GNOME panel. I am just not clear what the network icon looks like. The top right screen corner only shows the date and time on my GNOME panel bar. I have an icon on my panel bar that shows two computer terminal screens on top of each other. Is that the network icon? When I click on that icon, it shows the following lines in a small window: Wired Network ( highlited in a gray color ) Auto eth0 ( highlited in a black color, with black dot on the left ) Wireless Networks ( highlited in a gray color ) wireless is disabled ( highlited in a gray color ) VPN connections ( highlited in a black color, with a right arrow on the right ) As I said previously, when I try to activiate 'wlan1' in NetWorkManager, I always get an error message box, saying 'wlan1' cannot be activated. The dialog message box never says why 'wlan1' cannot be activated. Can you, or anybody else, help me? I am just not very good about figuring out how the GNOME NetworkManager works. Derek Starr ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: (missing) pre-up and pre-down
On Sat, 2009-08-08 at 01:50 +0100, Graham Lyon wrote: 2009/8/7 Dan Williams d...@redhat.com On Wed, 2009-08-05 at 11:30 +0100, Marc Herbert wrote: Dan Williams a écrit : There are two reasons I've not yet added pre-up and pre-down. They are: 2) appropriateness Hmmm, the good old just do not do this answer... the best answer to any feature request ever ;-) Especially to people having using this feature for ages and being suddendly deprived of it. Please note I didn't say *all* uses were inappropriate. Just that because we've done something the same way forever, doesn't *necessarily* mean that it should always be done that way until the end of time. b) by the time any pre-down script will run, often the connection has already gone away (the AP is out of range, the cable has been unplugged already, etc) so any operation a pre-down script does *cannot* depend on the interface being up; it must gracefully fail. Common things people wanted to do here were unmount network shares; but since the script must always handle unexpected disconnects (which not all network file systems do well), you might as well just run this from post-down anyway. I think pre-down cleanup scripts could (should?) simply NOT be run on unexpected disconnects (as opposed to explicit disconnection requests). Simply because they are called PRE-down, not AT-down. I did think about this a lot while composing the mail, and couldn't come up with a good reason to not run pre-down scripts on unexpected disconnect. I don't really care either way. Not running them on unexpected disconnects would breed inconsistency and would be confusing for tracking issues/users who aren't aware of this quirk. Running them on unexpected disconnections would be pointless - they are scripts that, by definition, expect the interface to be up. There's no winning. Perhaps when a connection drops unexpectedly the pre-down scripts should be run with an argument of some kind to inform them that the interface has already dropped? That way they can clean up the mess that's created but avoid any action that requires the interface to still be up... That was my thinking too, and probably the right thing to do. Dan Just two my cents -Graham ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager does not find system wide connections
On Sun, 2009-08-09 at 00:51 +0100, Graham Lyon wrote: 2009/8/9 Hadmut Danisch had...@danisch.de Graham Lyon wrote: Then documentation should be fixed, not the method itself. DBus is the best approach to do this, it uniffies IPC in unix, which is a *good* thing. Network configuration is such an essential and basic function, that it should not depend on IPC. IPC means that several processes must exist, and this is error prone by default. IPC may be an addon, but it should work without IPC. I can see what you're saying here and I sympathise. Perhaps the best solution would be one where there is a single NM daemon on the system level that manages the interfaces and deal with the system config and then supplies a (probably the same) DBus API that allows user processes to manage user-configured connections. A merger of NetworkManager and nm-system-settings, basicly. This removes the need for IPC in order to get the core of it working whilst at the same time still supplying the same funcionality. The more that I think about it the more I agree with you on this point that NetworkManager shouldn't be useless without DBus and the nm-settings-daemon running also. NM master (0.8) already has merged NM + nm-system-settings; there is only one core NetworkManager process now. However, to control NM, you still need D-Bus. It is completely pointless to re-implement IPC via a socket just so you don't depend on D-Bus. So then you've got both (a) a standard, well-understood, type-safe D-Bus interface, and (b) a non-standard, hacked up duplicated socket-based control interface. Fail. There is nothing wrong with D-Bus, period. Or maybe people will finally accept D-Bus when it's a kernel module (as Marcel Holtmann has proposed)? Something Hadmut didn't consider was that maybe the distros *should* start D-Bus in single-user mode. That's what I mean by change; the distros aren't stuck in stone in how they are configured and what software they run by default. NM is not interweaved with desktop applications. You're confusing the user settings manager with network manager itself. A plain user will store his network settings under Gnome or KDE and such within the Gnome and KDE configuration methods. This depends on desktop applications. Without a desktop network manager will not find any user specific config. I'm not entirely sure what you meant here, but I suspect you mean that an ordinary user will configure their system using the applets in gnome/kde and so their settings will not be system settings? They only need to tick the make available to all users ticky box. If I completely misread what you're saying, please do correct me. And I did not yet see any command line front end. There is cnetworkmanager, apparently (I've never used it) and there was discussions on this list somewhere about a rewrite of it to make it more functional. Probably not a rewrite, but another tool in C more suitable to size-constrained installs, or people who just don't want to depend on Python. There is certainly room for both and neither would obsolete the other. Martin does good work. It's actually the best way to get the two levels of configuration that I can think of. Storing network configuration in Gnome or KDE in a way that they are not available if someone uses the other Desktop is a bad idea. Network settings are not desktop settings and thus should not be stored in the Gnome or KDE configuration. Fair point, but how often do you switch to using the other desktop environment as the same user login? It's not a particularly common use case... I will admit that the network settings are not part of your desktop settings and the problem here is that there is no unified settings daemon for all user's applications (something like this is really lacking in the world of linux and would be great as it would stop everyone having to roll their own config file reading/writing mechanism. If you want to use user connections in a different DE, you can make them system connections and they will be available to any DE that you use. That's actually the whole point of system connections; it doesn't matter what user or GUI you're using, they are still there. It doesn't need a running desktop to be configured, and lots of system relevent applications require DBus (it's not a desktop program). And that's wrong. DBus is not started in single user mode. So NetworkManager could not be
Re: NetworkManager on Karmic Koala (0.8~a~git.20090804) doesn't recognise Mobile modem Huawei E1692 (lsusb shows E620)
one detail ... On Wed, Aug 12, 2009 at 12:40:20PM -0500, Dan Williams wrote: Modems are handled by ModemManager now, which is more flexible and a better architecture for the future. To figure out what's going on now, you'll want to: 1) Stop NetworkManager 1a) sudo killall modem-manager 2) sudo /usr/sbin/modem-manager --debug 3) Start NetworkManager 4) Plug in your modem - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Status of network-manager-netbook?
Hi Dan, I'm wondering where and how the network-manager-netbook addon to NetworkManager is suppose to happen? Is it supported via this list or somewhere else? The same goes for bug reporting, should it be going to bugzilla.gnome.org? If so can someone add a n-m-n component to the NM product? Or should it all go somewhere else? You can probably ask about it on this list, but the work is all Tambet's (and thus Novell's) AFAIK. I'd speak up if I had anything to say, but I've got a lot to do on core NM so havent' played with nmn much yet. Thanks for the update. Cheers, Peter ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager on Karmic Koala (0.8~a~git.20090804) doesn't recognise Mobile modem Huawei E1692 (lsusb shows E620)
Sorry for trouble, now it works. Karmic packages where set wrong, without modemmanager package, package upload seemingly fixed this only yesterday. Thanks guys for debuging tips, will be useful next time. Cheers, Peteris. 2009/8/12 Alexander Sack a...@ubuntu.com: one detail ... On Wed, Aug 12, 2009 at 12:40:20PM -0500, Dan Williams wrote: Modems are handled by ModemManager now, which is more flexible and a better architecture for the future. To figure out what's going on now, you'll want to: 1) Stop NetworkManager 1a) sudo killall modem-manager 2) sudo /usr/sbin/modem-manager --debug 3) Start NetworkManager 4) Plug in your modem - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Second message, about not being able to activate 'wlan1'
2009/8/12 Dan Williams d...@redhat.com: 'less /etc/sysconfig/networking/devices': [ snip ] They should be able to be deleted, as long as you can authenticate as 'root' via PolicyKit. The ifcfg-rh backend supports deletion of system connections via the GUI. You'll find these in the connection editor (/usr/bin/nm-connection-editor) with names like System eth0 and such. But Dan, the ifcfg-rh backend works with files on /etc/sysconfig/network-scripts right? On my F11 I don't have anything on /etc/sysconfig/networking/devices while I do have NM managed system connections on the network-scripts directory. Rui ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Missing ca_path2 in settings op table for supplicant manager (patch attached)
From 9d583ff6291f7d9423dd6f2e83776658d0cbc880 Mon Sep 17 00:00:00 2001
From: Tyson Whitehead twhiteh...@gmail.com
Date: Wed, 12 Aug 2009 17:05:10 -0400
Subject: [PATCH] Add ca_path2 to op table for verification
---
.../nm-supplicant-settings-verify.c|1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/supplicant-manager/nm-supplicant-settings-verify.c b/src/supplicant-manager/nm-supplicant-settings-verify.c
index 5e30795..2833465 100644
--- a/src/supplicant-manager/nm-supplicant-settings-verify.c
+++ b/src/supplicant-manager/nm-supplicant-settings-verify.c
@@ -109,6 +109,7 @@ static const struct Opt opt_table[] = {
{ phase1, TYPE_KEYWORD, 0, 0, TRUE, phase1_allowed },
{ phase2, TYPE_KEYWORD, 0, 0, TRUE, phase2_allowed },
{ anonymous_identity, TYPE_BYTES, 0, 0, FALSE, NULL },
+ { ca_path2, TYPE_BYTES, 0, 0, FALSE, NULL },
{ ca_cert2, TYPE_BYTES, 0, 65536, FALSE, NULL },
{ client_cert2, TYPE_BYTES, 0, 65536, FALSE, NULL },
{ private_key2, TYPE_BYTES, 0, 65536, FALSE, NULL },
--
1.6.3.3
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
