Re: [NM-openconnect PATCH] Allow 'lasthost' and 'autoconnect' settings.
On Mon, 2009-05-11 at 12:21 -0400, Dan Williams wrote: Sure, but I'd rather not start a precedent of stuffing other random stuff into the connection config that's not actually part of the connection specification. Isn't this basically the difference between /etc and /tmp? Most of this stuff _is_ part of the connection specification -- we're talking about stuff like the username, the list of available VPN servers, which one of those the user selected, etc. I attached a screenshot of the auth-dialog, to make it more obvious what's going on. When it comes up, you choose a host from the combobox at the top. If you check the 'Automatically start connecting next time' box, you can skip that bit in future. It remembers the host you chose. Then you get presented with arbitrary HTML forms from the server, and the responses (except passwords) are remembered too. When you connect successfully, the server gives us an XML configuration file which updates the list of available hosts (which will appear in that combobox next time). I would say that all those _are_ part of the configuration, not just 'other random stuff'. It's just that they're handled _purely_ in the auth-dialog, and don't need to be passed back to the nm-openconnect-service. -- dwmw2 inline: vpn-auth.png___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Moving ppp-manager into ModemManager
On Tuesday 12 May 2009 00:19:01 Dan Williams wrote: Yeah, PPP code is icky. But just like dhclient, it doesn't need rewriting. There are certainly more worthwhile things to spend time on. It's got a responsive upstream who accepts patches, why not fix the specific issues you have and upstream the patches. If that's the case, why do plently of distros have quite invasive patches to dhclient? The latest fedora SRPM has no less than 20 patches and a fully cutomised dhclient-script (ok, the script isn't needed for NM). I also know that Gentoo ships quite a few patches as well. What's more, some distributions have different options on the same command line switch which makes things even more difficult. Now, lets take a look at bloat: $ size /sbin/dhclient /sbin/dhcpcd textdata bss dec hex filename 2719715016 38508 315495 4d067 /sbin/dhclient 70784 7363952 75472 126d0 /sbin/dhcpcd Thats Gentoo/i386 dhclient-3.1.1 and dhcpcd-5.0.3 Why is dhclient so damn big? The last time I checked, dhcpcd also took about 33% less memory when running as well. It can't be features either - dhclient can do two things that dhcpcd cannot (one is deprecated by newer RFC's and the other i don't like from a design perspective) whilst dhcpcd can do at least 10 things I can think of that dhclient can't. Then we have the configuration aspect of it - NM has to write out a special configuration file just to play nice. dhcpcd is fully configurable from the command line as well as a config file. But you're correct - dhclient doesn't need re-writing, it needs replacing :) Thanks Roy ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Question in function nm_device_state_changed()
From my understanding:
nm-client.c
nm_client_deactivate_connection()
then through dbus, call:
impl_manager_deactivate_connection (NMManager *manager,
const char *connection_path,
GError **error)
{
return nm_manager_deactivate_connection (manager,
connection_path,
NM_DEVICE_STATE_REASON_USER_REQUESTED,
error);
}
*The reason is NM_DEVICE_STATE_REASON_USER_REQUESTED in above function
call.*
Then nm_device_state_changed() will be called. From my previous mail, in
nm_device_state_changed(NMDevice *device,
NMDeviceState state,
NMDeviceStateReason reason):
g_signal_emit_by_name (device, state-changed, state, old_state, 0);
but not
g_signal_emit_by_name (device, state-changed, state, old_state, reason);
Then the reason NM_DEVICE_STATE_REASON_USER_REQUESTED can't be received by
related device_state_changed() function.
The reason always is 0(NM_DEVICE_STATE_REASON_NONE).
Think MobileBroad band, it has a Disconnect item in nm-applet menu. When
click it, nm_client_deactivate_connection() will be called, if the
user(programer) want to check the disconnect reason to do something, e.g.
user disconnected, do not auto connect again. They seems can not.
Thanks!
2009/5/12 Dan Williams d...@redhat.com
On Wed, 2009-05-06 at 11:40 +0800, 代尔欣 wrote:
Hi all,
I have a question about the NetworkManager-0.7.1 codes.
In NetworkManager-0.7.1/src/nm-device.c:
void nm_device_state_changed (NMDevice *device,
NMDeviceState state,
NMDeviceStateReason reason)
{
...
// Here the fifth parameter is set to 0. I think it should be set
to reason so that the receiver of the signal state-changed can
do
The question is what event is causing the reason to be 0. Was it a
user-requested disconnection? Was it something else? There may
definitely be some places in NM that don't set the code correctly, but
we need to identify which scenario you've hit here.
// something special base on the state change reason. e.g. When
NM_DEVICE_STATE_DISCONNECTED state signaled, if
// the reason is NM_DEVICE_STATE_REASON_USER_REQUESTED then we
do not schedule auto connect in
// NetworkManagerPolicy.c device_state_changed() or
// set a flag in device-related device_state_changed() and reload
the can_activate() function to check this flag.
g_signal_emit_by_name (device, state-changed, state, old_state,
0);
...
The reason we probably don't schedule autoconnection on disconnect is
precisely because the user chose to manually disconnect. If we did
reschedule the autoconnect, then NM would simply reconnect the
connection the user just disconnected.
Dan
}
If I'm wrong, please point out. Thanks!
___
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: Talking to NM 0.7 with dbus vs. libnm_glib
Dan Williams schrieb:
On Wed, 2009-05-06 at 22:42 +0200, Christian Huff wrote:
Hi,
I am currently working at the libpurple/pidgin NetworkManager
integration code to improve to user experience with roaming with
multiple devices. Currently, libpurple only reacts to the global
StateChange signal, which does not change if one device goes offline or
online and there is another active device. In effect, this often results
in the inability to send or receive messages - the apps stalls until a
timeout occurs.
libpurple gets the current global NM state through Dbus, so, being kinda
new to glib programming, I tried to get NM's devices, connect to device
StateChanged, DeviceAdded and DeviceRemoved signals using
dbus_g_proxy_connect_signal. Doing so, I found I needed to register
custom marshallers as NetworkManager.h didn't provide them (this was
with 0.7.0, I haven't checked 0.7.1 yet). Also, I had to store a proxy
for each device, effectively producing some overly complicated code that
wouldn't make it into libpurple...
libnm-glib makes this easy for you, as it will proxy these signals into
GObject signals. You shouldn't really need to touch dbus-glib at all
here. Using libnm-glib, you could have created a new NMClient object,
then queried that object for the list of devices, or attached to the
'device-added' / 'device-removed' signals or 'state' properties. I can
explain more if you like.
Yes, please! How do you attach to properties? e.g. how do I listen to
the default property of a NMActiveConnection?
But the approach you took was wrong. Not a problem though, given you
hadn't done this before :)
So I read that libnm_glib was rewritten with 0.7, and rewrote my patch
using it. The code turned out much cleaner, yet I found some problems
that I want to share with you. One of the goals I had set myself was to
minimize the number of unnecessary reconnects. A scheme to do so would
be to track the devices that are active at a connect action, and
reconnect only if such a critical device goes down. Another would be
to see if the device currently going down is part of an Active
Connection (NMActiveConnection) that NM reports as being the/a default
connection for DNS and routes.
Yeah, I'd expect that whenever the 'default' property on an active
connection changes, that's when you'd want to see if you should
reconnect.
While the former scheme was not perfect, the latter wasn't reliable,
either. I found nm_active_connection_get_default() to often return true
for multiple active connections, and sometimes the value from before and
sometimes the predicted value from after the device StateChanged event.
That kind of synchronisation problems currently prevent me from
implementing that scheme.
That behavior seems wrong. The NM code should ensure that only one
active connection object has the default property at the same time, but
there may be some latency issues in libnm-glib's proxying of properties.
Or, you may have been checking things at the wrong time. Can you post
some code, or ideally a distilled testcase?
This often occurs when looking at the active connections at the time a
device's state-changed signal is caught by the code, which looks like this:
static NMClient *nm_client = NULL;
static void
device_state_changed_cb(
NMDevice *device,
NMDeviceState new_state,
NMDeviceState old_state,
NMDeviceStateReason reason,
gpointer user_data)
{
const GPtrArray nm_active_connections =
nm_client_get_active_connections(nm_client);
int i = 0;
int default_ac_count = 0;
NMActiveConnection *nm_ac = NULL;
/* entering or leaving the activated state? */
if (new_state != NM_DEVICE_STATE_ACTIVATED
|| old_state != NM_DEVICE_STATE_ACTIVATED)
return;
for (i = 0; i nm_active_connections-len; i++)
{
nm_ac = g_ptr_array_index (nm_active_connections, i);
if (nm_active_connection_get_default (nm_ac))
default_ac_count++;
}
if (default_ac_count != 1)
sprintf(wtf: more or less than one default active connection:
detected %d instead!\n, default_ac_count);
}
static void
init_device (NMDevice *device, gpointer user_data)
{
/*connect state-changed signal*/
g_signal_connect(G_OBJECT(device),
state-changed,
G_CALLBACK(device_state_changed_cb),
NULL);
}
static void
device_added_cb(
NMClient *client,
NMDevice *device,
gpointer user_data)
{
/*new device, initialize it!*/
init_device(device);
}
void
init()
{
nm_client = nm_client_new();
const GPtrArray nm_devices =
nm_client_get_devices(nm_client);
/*get new devices being added to the system*/
Re: Moving ppp-manager into ModemManager
On Tue, 2009-05-12 at 10:11 +0100, Roy Marples wrote: On Tuesday 12 May 2009 00:19:01 Dan Williams wrote: Yeah, PPP code is icky. But just like dhclient, it doesn't need rewriting. There are certainly more worthwhile things to spend time on. It's got a responsive upstream who accepts patches, why not fix the specific issues you have and upstream the patches. If that's the case, why do plently of distros have quite invasive patches to dhclient? The latest fedora SRPM has no less than 20 patches and a fully cutomised dhclient-script (ok, the script isn't needed for NM). I also know that Gentoo ships quite a few patches as well. What's more, some distributions have different options on the same command line switch which makes things even more difficult. I meant pppd upstream is more responsive now. dhcp upstream is not as responsive. But that doesn't necessarily mean that dhclient needs to be rewritten from scratch at this time, if people really dislike dhclient they should use some other client like dhcpcd :) There are enough DHCP clients to go around these days. Dan Now, lets take a look at bloat: $ size /sbin/dhclient /sbin/dhcpcd textdata bss dec hex filename 2719715016 38508 315495 4d067 /sbin/dhclient 70784 7363952 75472 126d0 /sbin/dhcpcd Thats Gentoo/i386 dhclient-3.1.1 and dhcpcd-5.0.3 Why is dhclient so damn big? The last time I checked, dhcpcd also took about 33% less memory when running as well. It can't be features either - dhclient can do two things that dhcpcd cannot (one is deprecated by newer RFC's and the other i don't like from a design perspective) whilst dhcpcd can do at least 10 things I can think of that dhclient can't. Then we have the configuration aspect of it - NM has to write out a special configuration file just to play nice. dhcpcd is fully configurable from the command line as well as a config file. But you're correct - dhclient doesn't need re-writing, it needs replacing :) Thanks Roy ___ 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: [NM-openconnect PATCH] Allow 'lasthost' and 'autoconnect' settings.
On Tue, 2009-05-12 at 08:53 +0100, David Woodhouse wrote: On Mon, 2009-05-11 at 12:21 -0400, Dan Williams wrote: Sure, but I'd rather not start a precedent of stuffing other random stuff into the connection config that's not actually part of the connection specification. Isn't this basically the difference between /etc and /tmp? Most of this stuff _is_ part of the connection specification -- we're talking about stuff like the username, the list of available VPN servers, which one of those the user selected, etc. I attached a screenshot of the auth-dialog, to make it more obvious what's going on. When it comes up, you choose a host from the combobox at the top. If you check the 'Automatically start connecting next time' box, you can skip that bit in future. It remembers the host you chose. Then you get presented with arbitrary HTML forms from the server, and the responses (except passwords) are remembered too. When you connect successfully, the server gives us an XML configuration file which updates the list of available hosts (which will appear in that combobox next time). I would say that all those _are_ part of the configuration, not just 'other random stuff'. It's just that they're handled _purely_ in the auth-dialog, and don't need to be passed back to the nm-openconnect-service. I'd store most of them with the connection details in GConf, then ignore them in the vpn service plugin. What is that socket icon next to the server name? Is that a connect now button? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Question in function nm_device_state_changed()
On Tue, 2009-05-12 at 22:17 +0800, 代尔欣 wrote:
From my understanding:
nm-client.c
nm_client_deactivate_connection()
then through dbus, call:
impl_manager_deactivate_connection (NMManager *manager,
const char *connection_path,
GError **error)
{
return nm_manager_deactivate_connection (manager,
connection_path,
NM_DEVICE_STATE_REASON_USER_REQUESTED,
error);
}
*The reason is NM_DEVICE_STATE_REASON_USER_REQUESTED in above
function call.*
Then nm_device_state_changed() will be called. From my previous mail,
in nm_device_state_changed(NMDevice *device,
NMDeviceState state,
NMDeviceStateReason reason):
g_signal_emit_by_name (device, state-changed, state, old_state, 0);
You are correct. My mistake.
027ef78682baa8f733a7b19d22d78ca551c2bfa3 (master)
851957e272a9829195801eae0136e58d90360561 (0.7.x)
Thanks!
Dan
but not
g_signal_emit_by_name (device, state-changed, state, old_state,
reason);
Then the reason NM_DEVICE_STATE_REASON_USER_REQUESTED can't be
received by
related device_state_changed() function.
The reason always is 0(NM_DEVICE_STATE_REASON_NONE).
Think MobileBroad band, it has a Disconnect item in nm-applet menu.
When click it, nm_client_deactivate_connection() will be called, if
the user(programer) want to check the disconnect reason to do
something, e.g. user disconnected, do not auto connect again. They
seems can not.
Thanks!
2009/5/12 Dan Williams d...@redhat.com
On Wed, 2009-05-06 at 11:40 +0800, 代尔欣 wrote:
Hi all,
I have a question about the NetworkManager-0.7.1 codes.
In NetworkManager-0.7.1/src/nm-device.c:
void nm_device_state_changed (NMDevice *device,
NMDeviceState state,
NMDeviceStateReason reason)
{
...
// Here the fifth parameter is set to 0. I think it
should be set
to reason so that the receiver of the signal
state-changed can
do
The question is what event is causing the reason to be 0. Was
it a
user-requested disconnection? Was it something else? There
may
definitely be some places in NM that don't set the code
correctly, but
we need to identify which scenario you've hit here.
// something special base on the state change reason.
e.g. When
NM_DEVICE_STATE_DISCONNECTED state signaled, if
// the reason is NM_DEVICE_STATE_REASON_USER_REQUESTED
then we
do not schedule auto connect in
// NetworkManagerPolicy.c device_state_changed() or
// set a flag in device-related device_state_changed()
and reload
the can_activate() function to check this flag.
g_signal_emit_by_name (device, state-changed, state,
old_state,
0);
...
The reason we probably don't schedule autoconnection on
disconnect is
precisely because the user chose to manually disconnect. If
we did
reschedule the autoconnect, then NM would simply reconnect the
connection the user just disconnected.
Dan
}
If I'm wrong, please point out. Thanks!
___
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: nm 0.7.1 3g regression
Sipos == Sipos Ferenc ferenc.sipos...@gmail.com writes: Sipos Hi! I'm using arch linux, kernel 2.6.29, option icon 225 3g Sipos modem, I've compiled 0.7.0.99, 0.7.0.100, 0.7.1 from sources , Sipos but with the later, nm can't find the modem, attached is nm Sipos daemon log: Hi, I've the same problem (on Archlinux x86_64) with my Icon 225 - hsoconnect works nicely but since 3g modem is my only internet option at the moment, I'd like to replace it with NM. Any workaround for the above problem? I also cannot make it work with 0.7.0, here is the snippet from the log: [...] May 12 18:15:46 nitai NetworkManager: info ttyHS0: driver is 'hso'. May 12 18:15:46 nitai NetworkManager: debug [1242144946.246867] setup_monitor_device(): No monitoring udi provided May 12 18:15:46 nitai NetworkManager: info Found new Modem device 'ttyHS0'. May 12 18:15:46 nitai NetworkManager: info (ttyHS0): exported as /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_serial_unknown_0 May 12 18:15:46 nitai NetworkManager: info ttyHS1: driver is 'hso'. May 12 18:15:46 nitai NetworkManager: debug [1242144946.456811] setup_monitor_device(): No monitoring udi provided May 12 18:15:46 nitai NetworkManager: info Found new Modem device 'ttyHS1'. May 12 18:15:46 nitai NetworkManager: info (ttyHS1): exported as /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_serial_unknown_1 May 12 18:15:50 nitai NetworkManager: info (ttyHS0): device state change: 1 - 2 May 12 18:15:50 nitai NetworkManager: info (ttyHS0): deactivating device (reason: 2). May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: info (ttyHS0): device state change: 2 - 3 May 12 18:15:50 nitai NetworkManager: info (ttyHS1): device state change: 1 - 2 May 12 18:15:50 nitai NetworkManager: info (ttyHS1): deactivating device (reason: 2). May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: info (ttyHS1): device state change: 2 - 3 [...] Any hint? Sincerely, Gour Sipos Apr 22 22:50:26 leonidas NetworkManager: info (ttyHS0): found Sipos serial port (udev:GSM hal:GSM) Apr 22 22:50:26 leonidas Sipos NetworkManager: WARN new_modem_device(): couldn't find HSO Sipos modem network device. Apr 22 22:50:26 leonidas NetworkManager: Sipos info (ttyHS1): found serial port (udev:GSM hal:GSM) Apr 22 Sipos 22:50:32 leonidas NetworkManager: info (ttyHS2): ignoring due Sipos to lack of mobile broadband capabilties Sipos The hso driver is the same, hal, udev is the same, nothing is Sipos changed except nm, with nm 0.7.0.100 and above the modem is Sipos recognised and connects fine with nm-applet. Sipos Any help appreciated. Sipos Thx Sipos Ferenc ___ Sipos NetworkManager-list mailing list NetworkManager-list@gnome.org Sipos http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgptI7HFjDxGI.pgp Description: PGP signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
strange vpn error
Hi. I am using ii network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2 ii network-manager-gnome 0.7.1~rc4.1-0ubuntu2 ii network-manager-openvpn 0.7.1~rc4.1.20090323+bzr27-0ubunt ii network-manager-pptp 0.7.1~rc4.20090316+bzr23-0ubuntu3 ii network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2 I imported a VPNC profile file that works just fine using windows cisco vpn client software. But I got error that says The vpn connection (x) failed because there were no valid VPN secrets. I googled, but this error so far was only reported that happened on ppptp client, I am using vpnc. Can someone tell me what I am missing here??? Thanks Wei PS: The vpnc version I am using is ii vpnc 0.5.3-1 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm 0.7.1 3g regression
On Tue, 2009-05-12 at 19:07 +0200, Gour wrote: Sipos == Sipos Ferenc ferenc.sipos...@gmail.com writes: Sipos Hi! I'm using arch linux, kernel 2.6.29, option icon 225 3g Sipos modem, I've compiled 0.7.0.99, 0.7.0.100, 0.7.1 from sources , Sipos but with the later, nm can't find the modem, attached is nm Sipos daemon log: Hi, I've the same problem (on Archlinux x86_64) with my Icon 225 - hsoconnect works nicely but since 3g modem is my only internet option at the moment, I'd like to replace it with NM. Any workaround for the above problem? I also cannot make it work with 0.7.0, here is the snippet from the log: You'll probably want to use NM 0.7.1, not 0.7.0. Dan [...] May 12 18:15:46 nitai NetworkManager: info ttyHS0: driver is 'hso'. May 12 18:15:46 nitai NetworkManager: debug [1242144946.246867] setup_monitor_device(): No monitoring udi provided May 12 18:15:46 nitai NetworkManager: info Found new Modem device 'ttyHS0'. May 12 18:15:46 nitai NetworkManager: info (ttyHS0): exported as /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_serial_unknown_0 May 12 18:15:46 nitai NetworkManager: info ttyHS1: driver is 'hso'. May 12 18:15:46 nitai NetworkManager: debug [1242144946.456811] setup_monitor_device(): No monitoring udi provided May 12 18:15:46 nitai NetworkManager: info Found new Modem device 'ttyHS1'. May 12 18:15:46 nitai NetworkManager: info (ttyHS1): exported as /org/freedesktop/Hal/devices/usb_device_af0_6971_Serial_Number_if0_serial_unknown_1 May 12 18:15:50 nitai NetworkManager: info (ttyHS0): device state change: 1 - 2 May 12 18:15:50 nitai NetworkManager: info (ttyHS0): deactivating device (reason: 2). May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: info (ttyHS0): device state change: 2 - 3 May 12 18:15:50 nitai NetworkManager: info (ttyHS1): device state change: 1 - 2 May 12 18:15:50 nitai NetworkManager: info (ttyHS1): deactivating device (reason: 2). May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_routes_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: nm_system_device_flush_ip4_addresses_with_iface: assertion `iface_idx = 0' failed May 12 18:15:50 nitai NetworkManager: info (ttyHS1): device state change: 2 - 3 [...] Any hint? Sincerely, Gour Sipos Apr 22 22:50:26 leonidas NetworkManager: info (ttyHS0): found Sipos serial port (udev:GSM hal:GSM) Apr 22 22:50:26 leonidas Sipos NetworkManager: WARN new_modem_device(): couldn't find HSO Sipos modem network device. Apr 22 22:50:26 leonidas NetworkManager: Sipos info (ttyHS1): found serial port (udev:GSM hal:GSM) Apr 22 Sipos 22:50:32 leonidas NetworkManager: info (ttyHS2): ignoring due Sipos to lack of mobile broadband capabilties Sipos The hso driver is the same, hal, udev is the same, nothing is Sipos changed except nm, with nm 0.7.0.100 and above the modem is Sipos recognised and connects fine with nm-applet. Sipos Any help appreciated. Sipos Thx Sipos Ferenc ___ Sipos NetworkManager-list mailing list NetworkManager-list@gnome.org Sipos 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: nm 0.7.1 3g regression
Dan == Dan Williams d...@redhat.com writes: Dan You'll probably want to use NM 0.7.1, not 0.7.0. I've tried with 0.7.1, but with it I get: May 12 11:13:58 nitai NetworkManager: info (ttyHS2): ignoring due to lack of mobile broadband capabilties May 12 11:13:58 nitai NetworkManager: info (ttyHS1): found serial port (udev:GSM hal:GSM) May 12 11:13:58 nitai NetworkManager: info (ttyHS0): found serial port (udev:GSM hal:GSM) May 12 11:13:58 nitai NetworkManager: WARN new_modem_device(): couldn't find HSO modem network device. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgprFLn7eB3FI.pgp Description: PGP signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm 0.7.1 3g regression
On Tue, 2009-05-12 at 19:46 +0200, Gour wrote: Dan == Dan Williams d...@redhat.com writes: Dan You'll probably want to use NM 0.7.1, not 0.7.0. I've tried with 0.7.1, but with it I get: May 12 11:13:58 nitai NetworkManager: info (ttyHS2): ignoring due to lack of mobile broadband capabilties May 12 11:13:58 nitai NetworkManager: info (ttyHS1): found serial port (udev:GSM hal:GSM) May 12 11:13:58 nitai NetworkManager: info (ttyHS0): found serial port (udev:GSM hal:GSM) May 12 11:13:58 nitai NetworkManager: WARN new_modem_device(): couldn't find HSO modem network device. Are you sure you're using the actual NM 0.7.1 release, or a snapshot of rc4 or something? Are you running VirtualBox? Can you provide the output of 'lshal' when you have this problem? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: strange vpn error
On Tue, 2009-05-12 at 13:31 -0400, Wei Weng wrote: Hi. I am using ii network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2 ii network-manager-gnome 0.7.1~rc4.1-0ubuntu2 ii network-manager-openvpn 0.7.1~rc4.1.20090323+bzr27-0ubunt ii network-manager-pptp 0.7.1~rc4.20090316+bzr23-0ubuntu3 ii network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2 I imported a VPNC profile file that works just fine using windows cisco vpn client software. But I got error that says The vpn connection (x) failed because there were no valid VPN secrets. I googled, but this error so far was only reported that happened on ppptp client, I am using vpnc. Maybe the passwords didn't import correctly? Do you have passwords if you go into the connection editor (nm-connection-editor) and edit the imported VPN? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [NM-openconnect PATCH] Allow 'lasthost' and 'autoconnect' settings.
On Tue, 2009-05-12 at 11:10 -0400, Dan Williams wrote: I'd store most of them with the connection details in GConf, then ignore them in the vpn service plugin. That's what I do. I keep having to add new items to be ignored, and update the vpn service plugin in lock-step with the auth-dialog (which is shipped with openconnect itself). Hence: http://git.gnome.org/cgit/network-manager-openconnect/commit/?id=ba97bd52 http://git.gnome.org/cgit/network-manager-openconnect/commit/?id=09071a81 I'm actually tempted to make the vpn service plugin just ignore _anything_ it doesn't understand. There's no benefit in bailing out, is there? What is that socket icon next to the server name? Is that a connect now button? Yes. It actually connects automatically when you change the selected host in the combobox... but if the one you want is the _default_, and you haven't got automatically start connecting...' set, then you'll end up hitting the connect button. -- dwmw2 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: strange vpn error
On 5/12/2009 2:15 PM, Dan Williams wrote: On Tue, 2009-05-12 at 13:31 -0400, Wei Weng wrote: Hi. I am using ii network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2 ii network-manager-gnome 0.7.1~rc4.1-0ubuntu2 ii network-manager-openvpn 0.7.1~rc4.1.20090323+bzr27-0ubunt ii network-manager-pptp 0.7.1~rc4.20090316+bzr23-0ubuntu3 ii network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2 I imported a VPNC profile file that works just fine using windows cisco vpn client software. But I got error that says The vpn connection (x) failed because there were no valid VPN secrets. I googled, but this error so far was only reported that happened on ppptp client, I am using vpnc. Maybe the passwords didn't import correctly? Do you have passwords if you go into the connection editor (nm-connection-editor) and edit the imported VPN? Dan hmm, strange, I rebooted the computer and it suddenly worked now! Thanks Wei ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: strange vpn error
On 12/05/09 19:15, Dan Williams wrote: On Tue, 2009-05-12 at 13:31 -0400, Wei Weng wrote: Hi. I am using ii network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2 ii network-manager-gnome 0.7.1~rc4.1-0ubuntu2 ii network-manager-openvpn 0.7.1~rc4.1.20090323+bzr27-0ubunt ii network-manager-pptp 0.7.1~rc4.20090316+bzr23-0ubuntu3 ii network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2 I imported a VPNC profile file that works just fine using windows cisco vpn client software. But I got error that says The vpn connection (x) failed because there were no valid VPN secrets. I googled, but this error so far was only reported that happened on ppptp client, I am using vpnc. Maybe the passwords didn't import correctly? Do you have passwords if you go into the connection editor (nm-connection-editor) and edit the imported VPN? Dan Fwiw, I had the same issue with an OpenVPN connection on a clean F11 preview install. I added the NetworkManager-openvpn package and defined the VPN connection, but got the above error until I restarted the NetworkManager service... Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: strange vpn error
On 5/12/2009 6:01 PM, Jon Escombe wrote: On 12/05/09 19:15, Dan Williams wrote: On Tue, 2009-05-12 at 13:31 -0400, Wei Weng wrote: Hi. I am using ii network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2 ii network-manager-gnome 0.7.1~rc4.1-0ubuntu2 ii network-manager-openvpn 0.7.1~rc4.1.20090323+bzr27-0ubunt ii network-manager-pptp 0.7.1~rc4.20090316+bzr23-0ubuntu3 ii network-manager-vpnc 0.7.1~rc4.20090316+bzr21-0ubuntu2 I imported a VPNC profile file that works just fine using windows cisco vpn client software. But I got error that says The vpn connection (x) failed because there were no valid VPN secrets. I googled, but this error so far was only reported that happened on ppptp client, I am using vpnc. Maybe the passwords didn't import correctly? Do you have passwords if you go into the connection editor (nm-connection-editor) and edit the imported VPN? Dan Fwiw, I had the same issue with an OpenVPN connection on a clean F11 preview install. I added the NetworkManager-openvpn package and defined the VPN connection, but got the above error until I restarted the NetworkManager service... Regards, Jon. google openVPN there were no valid VPN secrets. There should be quite a few solutions out there. :) Thanks Wei ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: strange vpn error
On 12/05/09 23:06, Wei Weng wrote: On 5/12/2009 6:01 PM, Jon Escombe wrote: On 12/05/09 19:15, Dan Williams wrote: On Tue, 2009-05-12 at 13:31 -0400, Wei Weng wrote: google openVPN there were no valid VPN secrets. There should be quite a few solutions out there. :) Thanks Wei Indeed, the 'solution' for me was just to restart NM.. But was really just pointing out that the same failure on a new connection seems common to multiple (all?) VPN plugins.. Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Auto Connect through NetworkManager
Hi All, Is there any possibility to Disable Auto Connect through NetworkManager Code. in my Scenario If Auto Connect Is enabled In GSM Profile and User Click on Disconnect button then I wanted to Set Auto Connect flag disabled so networkManager won't retry to Start Connection again. I don't want to change Auto Connect manually through Connection editior because during resume my System has been checking mail and its will start Connection if only Auto Connect is set. Through some pointer on it. sanjeev sharma ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
