Re: ppp using NM
On Nov 27, 2007 6:40 PM, vikram b [EMAIL PROTECTED] wrote: Hi, I would like use svn trunk's code to setup ppp connection , lets say for dial up (gprs etc). As Dan already said, I have code to drive gsm data cards and we hope to get it to SVN later this week, even if it means there's no way to configure it yet from the UI (the currently missing part). Could anybody give me where to start . i mean i couldn't see things in libnm etc. nm_ppp_manager_start() is a func i could see . Are we planning to support dbus methods to start/manage pppd connections ? (like in nm-vpn-manager.xml: method name=Connect ) any plans for same methods for ppp ? or what is the alternate way to do ppp connection now ? No, the ppp manager is internal to NetworkManager and thus isn't going to be exposed directly over dbus. What exactly do you want to achieve? NetworkManager provides a way to activate/deactivate devices, just starting random programs (like pppd) is a side effect :) Instead, there's a new device type, NMUmtsDevice which can be activated the same way as other device types (NMManager.ActivateDevice ()). One of it's arguments is a NMConnection object which always contains a list of NMSetting subclasses, each device type has it's own required settings. For the NMUmtsDevice, the required settings are NMSettingPPP (to pass ppp options), NMSettingSerial (to configure the serial port) and NMSettingUmts (for gsm specific settings like phone number, APN, username, password, etc). Once the NMUmtsDevice receives the activation request, it opens and configures the serial port, sends the required AT commands and starts pppd. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 28, 2007 7:02 AM, vikram b [EMAIL PROTECTED] wrote: Thanks ! Would wait for his resp. Just a quick question . Are we going to have CAPI plugins for pppd in near future ? which is req. for the isdn dialup etc. I don't know what CAPI is, but the work I've done for gsm card support is done in a way to support all types of serial devices. There's a base class NMSerialDevice which should be a suitable base class for any serial device. Right now, only NMUmtsDevice is derived from it. There's also a ppp-manager which knows nothing about devices or their types. So we should have all the pieces to easily add support for any type of serial devices like cdma, regular land line modems, and isdn cards. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Madwifi connection loss
On Nov 27, 2007 7:47 PM, Darren Albers [EMAIL PROTECTED] wrote: card I show one bar and get disconnected frequently. There was a hack posted by Robert Love almost two years ago that Translated (If that is the right way to describe it) the Madwifi signal reporting into a rough approximation of what most cards use. This helped make the cards more usable but still not enough to compare with other cards. The hack lived in suse packages but users reported the drivers changed and because of that hack, NM always showed 100% signal strength. So apparently the driver is fixed now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
- Tambet Ingo [EMAIL PROTECTED] wrote: As Dan already said, I have code to drive gsm data cards and we hope to get it to SVN later this week, even if it means there's no way to configure it yet from the UI (the currently missing part). Thanks, looking forward to trying it out.. Assuming we can configure a connection manually by putting the right entries into gconf? Regards, Jon ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 28, 2007 2:38 PM, Jon Escombe [EMAIL PROTECTED] wrote: Thanks, looking forward to trying it out.. Assuming we can configure a connection manually by putting the right entries into gconf? Yeah, exactly. That's how I've tested it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Madwifi connection loss
On Wed, 2007-11-28 at 20:08 +1300, Simon Geard wrote: On Tue, 2007-11-27 at 12:47 -0500, Darren Albers wrote: I have been watching Ath5k development and I hope it will resolve these issues since the author's won't be tied into working with a closed HAL. In the meantime I would try and steer clear of Atheros based cards if possible. Speaking of those drivers, do you know what state they're in with regard to joining the mainline kernel? Was reading up on them recently, and noticed that while they were in the 2.6.23 -mm kernels, there's no mention of them in the 2.6.24 -mm patch list. ath5k is in linville's wireless-2.6/everything, which is upstream for wireless drivers. They certainly won't be in 2.6.24 since they aren't in good enough shape yet. They seem on-track to hit 2.6.25 though. ath5k doesn't yet support late-model N-capable chipsets that have recently started appearing though, since the hardware there hasn't been reverse-engineered yet and the register layouts are apparently different. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Wed, 2007-11-28 at 12:38 +, Jon Escombe wrote: - Tambet Ingo [EMAIL PROTECTED] wrote: As Dan already said, I have code to drive gsm data cards and we hope to get it to SVN later this week, even if it means there's no way to configure it yet from the UI (the currently missing part). Thanks, looking forward to trying it out.. Assuming we can configure a connection manually by putting the right entries into gconf? Yes, that'll work; though for secrets you might need to write some C bits to push the PIN or whatever into the keyring. But if you don't have a PIN and since most networks don't care about the username/pass anyway, it may just work. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 28, 2007 5:01 PM, Dan Williams [EMAIL PROTECTED] wrote: Yes, that'll work; though for secrets you might need to write some C bits to push the PIN or whatever into the keyring. But if you don't have a PIN and since most networks don't care about the username/pass anyway, it may just work. Naah, setting PIN is even easier, you just need to add the pin key/value to gconf manually and it'll use it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Madwifi connection loss
Walter, when you say you see no such issues are you using the -Dmadwifi or -Dwext with wpa_supplicant. I have my Network Manager patched so it waits 60 seconds before deciding the link has timed out, however every 15-30 seconds wpa_supplicant scans, this I see using the -Dmadwifi driver. With -Dwext it is rock solid on my home wpa2 network. However at work -Dmadwifi is needed for leap/eap since -Dwext is unreliable for this type of connection. When you connect can you run watch -n1 wpa_cli status and see if it keeps dropping and scanning. I am kind of curious since I would love a solution/workaround for the scanning ...rescanning etc. Walter Neumann wrote: I have no such problem with madwifi-ng-r2594-20070719. On Tue, 27 Nov 2007, Darren Albers wrote: On Tue, 2007-11-27 at 12:18 -0500, Philip A. Culver wrote: Hi, I am using NetworkManager 0.6.5 on Fedora 7 with the madwifi 0.9.3.3 drivers.I am experiencing an issue where NetworkManager thinks that the link has time out and shuts down the connection. It then tries to reconnect, which fails. At this point the device is deactivated. If I restart NetworkManager it usually reconnects immediately. My questions are as follows: * Is this a known issue with madwifi? If so does anyone know of any fixes for this? I have had similar issues with Athero's based cards and MadWifi. This was the sole reason I selected a T61 over a Macbook this year. I /think/ the reason for the disconnect is that Madwifi reports it's signal strength differently than most other cards and therefore reports significantly lower strength than other cards. So in one room of my house if I am using an Intel 2200 B/G MiniPCI card I have 3 bars and a stable connection, if I am using an IBM branded Atheros A/B/G MiniPCI card I show one bar and get disconnected frequently. There was a hack posted by Robert Love almost two years ago that Translated (If that is the right way to describe it) the Madwifi signal reporting into a rough approximation of what most cards use. This helped make the cards more usable but still not enough to compare with other cards. I have been watching Ath5k development and I hope it will resolve these issues since the author's won't be tied into working with a closed HAL. In the meantime I would try and steer clear of Atheros based cards if possible. * Why is the device deactivated? Why wouldnÿÿt the device try to reconnect again after some period of time? Will I have to manually tell NetworkManager to reconnect? * I also experienced a crash in network manager in the same situation. I suspect my problems are perhaps related to madwifi but figured I would start here based on the crash and the fact that if I restart NetworkManager the connection is reestablished. I have included logs for both problems. Thanks, Phil Logs for deactivation and loss of link: Nov 27 11:22:22 localhost NetworkManager: info DHCP daemon state is now 3 (renew) for interface ath0 Nov 27 11:22:22 localhost dhclient: bound to 192.168.2.253 -- renewal in 142 seconds. Nov 27 11:24:44 localhost dhclient: DHCPREQUEST on ath0 to 192.168.2.55 port 67 Nov 27 11:24:44 localhost dhclient: DHCPACK from 192.168.2.55 Nov 27 11:24:44 localhost NetworkManager: info DHCP daemon state is now 3 (renew) for interface ath0 Nov 27 11:24:44 localhost dhclient: bound to 192.168.2.253 -- renewal in 119 seconds. Nov 27 11:26:35 localhost NetworkManager: info nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device ath0 link now 0 Nov 27 11:26:35 localhost NetworkManager: info nm-netlink-monitor.c - nm_netlink_monitor_event_handler (724) netlink reports device ath0 link now 0 Nov 27 11:26:43 localhost dhclient: DHCPREQUEST on ath0 to 192.168.2.55 port 67 Nov 27 11:26:51 localhost last message repeated 2 times Nov 27 11:26:55 localhost NetworkManager: info ath0: link timed out. Nov 27 11:26:55 localhost NetworkManager: info nm-device.c - nm_device_set_active_link (596) device ath0 link state set to 0 Nov 27 11:26:55 localhost NetworkManager: info SWITCH: found better connection 'ath0/GEM_RD_TEST' than current connection 'ath0/GEM_RD_TEST'. same_ssid=1, have_link=0 Nov 27 11:26:55 localhost NetworkManager: info Will activate connection 'ath0/GEM_RD_TEST'. Nov 27 11:26:55 localhost NetworkManager: info Device ath0 activation scheduled... Nov 27 11:26:55 localhost NetworkManager: info Deactivating device ath0. Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address type 801 Nov 27 11:26:55 localhost dhclient: wifi0: unknown hardware address type 801 Nov 27 11:26:55 localhost dhclient: DHCPRELEASE on ath0 to 192.168.2.55 port 67 Nov 27 11:26:56 localhost avahi-daemon[1597]: Withdrawing address record for 192.168.2.253 on ath0. Nov 27 11:26:56 localhost avahi-daemon[1597]: Leaving mDNS multicast group on interface ath0.IPv4 with address
VPNC Connection dropping
There is an issue with recent vpnc releases (in particular, the one in Fedora 8) where connections are dropped fairly regularly by the dead-peer detector. See https://bugzilla.redhat.com/show_bug.cgi?id=345281. The workaround is a parameter in the config file for vpnc to adjust the DPD timeout or turn it off, but there is no way to specify the option for a connection in NM-vpnc. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Static routes support patch for NetworkManager 0.7.0
Hi,
i wrote patch for NetworkManager for support static-routes from DHCP
(033).
With regards
Blondak
diff -bBru NetworkManager-0.7.0/src/dhcp-manager/nm-dhcp-manager.c NetworkManager-0.7.0-blondak/src/dhcp-manager/nm-dhcp-manager.c
--- NetworkManager-0.7.0/src/dhcp-manager/nm-dhcp-manager.c 2007-10-01 22:46:52.0 +0200
+++ NetworkManager-0.7.0-blondak/src/dhcp-manager/nm-dhcp-manager.c 2007-11-28 14:24:29.0 +0100
@@ -839,6 +839,7 @@
char * nameservers = NULL;
char * nis_domain = NULL;
char * nis_servers = NULL;
+ char * static_routes = NULL;
char * ip = NULL; //this is a general string that is used as a temporary place for ip(s)
g_return_val_if_fail (NM_IS_DHCP_MANAGER (manager), NULL);
@@ -909,7 +910,7 @@
domain_names = g_hash_table_lookup (device-options, new_domain_name);
nis_domain = g_hash_table_lookup (device-options, new_nis_domain);
nis_servers = g_hash_table_lookup (device-options, new_nis_servers);
-
+ static_routes = g_hash_table_lookup (device-options, new_static_routes);
if (nameservers) {
char **searches = g_strsplit (nameservers, , 0);
@@ -958,6 +959,22 @@
g_strfreev (searches);
}
+ if (static_routes){
+ char **searches = g_strsplit (static_routes, , 0);
+ char **s;
+ int ip4_address;
+ int ip4_route;
+
+ for (s = searches; *s; s=s+2) {
+ ip4_address = inet_addr (*s);
+ ip4_route = inet_addr (*(s+1));
+ nm_ip4_config_add_static_route (ip4_config, ip4_address, ip4_route);
+ nm_info ( static route %s gw %s, *s, *(s+1));
+ }
+ g_strfreev (searches);
+// nm_info ( hostname '%s', static_routes);
+ }
+
/*
* FIXME:
* Grab the MTU from the backend. If DHCP servers can send recommended
diff -bBru NetworkManager-0.7.0/src/NetworkManagerSystem.c NetworkManager-0.7.0-blondak/src/NetworkManagerSystem.c
--- NetworkManager-0.7.0/src/NetworkManagerSystem.c 2007-09-28 03:37:58.0 +0200
+++ NetworkManager-0.7.0-blondak/src/NetworkManagerSystem.c 2007-11-28 14:49:43.0 +0100
@@ -194,6 +193,8 @@
struct nl_handle * nlh = NULL;
struct rtnl_addr * addr = NULL;
interr;
+ int len,i;
+ guint32 saddr;
g_return_val_if_fail (dev != NULL, FALSE);
@@ -220,6 +221,12 @@
sleep (1);
nm_system_device_set_ip4_route (dev, nm_ip4_config_get_gateway (config), 0, 0, nm_ip4_config_get_mss (config));
+ len = nm_ip4_config_get_num_static_routes (config);
+ for (i = 0; i len; i++){
+ saddr = nm_ip4_config_get_static_route (config, i*2);
+ nm_system_device_set_ip4_route (dev, nm_ip4_config_get_static_route(config,i*2+1), saddr, 0x, nm_ip4_config_get_mss (config));
+ }
+
named_mgr = nm_named_manager_get ();
nm_named_manager_add_ip4_config (named_mgr, config);
g_object_unref (named_mgr);
diff -bBru NetworkManager-0.7.0/src/nm-ip4-config.c NetworkManager-0.7.0-blondak/src/nm-ip4-config.c
--- NetworkManager-0.7.0/src/nm-ip4-config.c 2007-09-12 03:12:13.0 +0200
+++ NetworkManager-0.7.0-blondak/src/nm-ip4-config.c 2007-11-28 14:37:30.0 +0100
@@ -55,6 +55,7 @@
gchar * hostname;
gchar * nis_domain;
GArray *nis_servers;
+ GArray *static_routes;
/* If this is a VPN/etc config that requires
* another device (like Ethernet) to already have
@@ -75,6 +76,7 @@
PROP_DOMAINS,
PROP_NIS_DOMAIN,
PROP_NIS_SERVERS,
+ PROP_STATIC_ROUTES,
LAST_PROP
};
@@ -105,6 +107,7 @@
NMIP4ConfigPrivate *priv;
int i;
int len;
+ guint32 addr;
g_return_val_if_fail (NM_IS_IP4_CONFIG (src_config), NULL);
@@ -131,6 +134,12 @@
for (i = 0; i len; i++)
nm_ip4_config_add_nis_server (dst_config, nm_ip4_config_get_nis_server (src_config, i));
+ len = nm_ip4_config_get_num_static_routes (src_config);
+ for (i = 0; i len; i++){
+ addr = nm_ip4_config_get_static_route (src_config, i*2);
+ nm_ip4_config_add_static_route (dst_config, addr, nm_ip4_config_get_static_route (src_config, i*2+1));
+ }
+
return dst_config;
}
@@ -307,6 +316,28 @@
return NM_IP4_CONFIG_GET_PRIVATE (config)-nis_domain;
}
+void nm_ip4_config_add_static_route (NMIP4Config *config, guint32 host, guint32 router)
+{
+ g_return_if_fail (NM_IS_IP4_CONFIG (config));
+
+g_array_append_val (NM_IP4_CONFIG_GET_PRIVATE (config)-static_routes, host);
+g_array_append_val (NM_IP4_CONFIG_GET_PRIVATE (config)-static_routes, router);
+}
+
+guint32 nm_ip4_config_get_static_route (NMIP4Config *config, guint i)
+{
+ g_return_val_if_fail (NM_IS_IP4_CONFIG (config), 0);
+
+return g_array_index (NM_IP4_CONFIG_GET_PRIVATE (config)-static_routes, guint32, i);
+}
+
+guint32 nm_ip4_config_get_num_static_routes (NMIP4Config *config)
+{
+g_return_val_if_fail (NM_IS_IP4_CONFIG (config), 0);
+
+ return NM_IP4_CONFIG_GET_PRIVATE (config)-static_routes-len / 2;
+}
+
Problems with ipw3945
Hi, on my notebook I'm trying to user NM to access wireless networks. There is a larger problem with setting essids and associating/disassociating to APs. Apparently the card assumes to interpret the essid (empty) to be *any*. Therefore it associates immediately to the next ap. I watched this with iwevent. Nm first sets the essid to to disassociate, later it sets the id, I selected in the menu. But the card is already associated by the setting and NM waits forever for an association event after setting the id. The current lousy workaround is to set an ID blurp manually after NM set . Then the card will generate the events correctly. Would it be difficult to poll the status of the card first, before waiting for the events? Best regards Martin ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with ipw3945
On Wed, 2007-11-28 at 23:07 +0100, Martin Ginkel wrote: Hi, on my notebook I'm trying to user NM to access wireless networks. There is a larger problem with setting essids and associating/disassociating to APs. 0.6.5, right? Apparently the card assumes to interpret the essid (empty) to be *any*. Yeah, that's the standard behavior. Therefore it associates immediately to the next ap. I watched this with iwevent. Nm first sets the essid to to disassociate, later it sets the id, I selected in the menu. But the card is already associated by the setting and NM waits forever for an association event after setting the id. Well, the driver needs to send the association event whenever it gets an association request, even if that association request is for the same AP that it's already associated with. This seems like a driver bug to me. Association requests must always be followed by either a failed association event, or a valid associated AP event. It sounds like the ipw3945 driver isn't doing that. Dan The current lousy workaround is to set an ID blurp manually after NM set . Then the card will generate the events correctly. Would it be difficult to poll the status of the card first, before waiting for the events? Best regards Martin ___ 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: Static routes support patch for NetworkManager 0.7.0
On Wed, 2007-11-28 at 16:32 +0100, Zdeněk Jurka wrote: Hi, i wrote patch for NetworkManager for support static-routes from DHCP (033). With regards Thanks! I've committed this to trunk with a few spacing cleanups, and validation of the DHCP provided addresses (as validated by inet_aton). Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Too much roaming!
Hi, I am having trouble with my ipw2200 roaming all the time in certain places. It doesn't happen everywhere, but here at school, at certain locations, like this classroom, it does this thing: Nov 28 14:42:42 frohro-d600 NetworkManager: debug [1196289762.803838] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8B:10:E0 to 00:0B:86:8B:05:A0 on wireless network 'WIREFREEWWU' Nov 28 14:42:46 frohro-d600 NetworkManager: debug [1196289766.803844] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8A:A7:20 to 00:0B:86:8B:05:A0 on wireless network 'WIREFREEWWU' Nov 28 14:42:56 frohro-d600 NetworkManager: debug [1196289776.803643] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8B:05:A0 to 00:0B:86:8B:10:E0 on wireless network 'WIREFREEWWU' Nov 28 14:43:01 frohro-d600 NetworkManager: debug [1196289780.803701] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8A:A7:20 to 00:0B:86:8B:10:E0 on wireless network 'WIREFREEWWU' Nov 28 14:43:08 frohro-d600 NetworkManager: debug [1196289788.803841] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8B:10:E0 to 00:0B:86:8A:A7:20 on wireless network 'WIREFREEWWU' Nov 28 14:43:10 frohro-d600 NetworkManager: debug [1196289790.803847] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:89:16:A0 to 00:0B:86:8A:A7:20 on wireless network 'WIREFREEWWU' Nov 28 14:43:20 frohro-d600 NetworkManager: debug [1196289800.803815] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8A:A7:20 to 00:0B:86:D3:E8:A0 on wireless network 'WIREFREEWWU' Nov 28 14:43:22 frohro-d600 NetworkManager: debug [1196289802.803625] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8A:AA:A0 to 00:0B:86:8B:12:60 on wireless network 'WIREFREEWWU' Nov 28 14:43:28 frohro-d600 NetworkManager: debug [1196289808.803644] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8A:A7:20 to 00:0B:86:8B:12:60 on wireless network 'WIREFREEWWU' Nov 28 14:43:34 frohro-d600 NetworkManager: debug [1196289814.803848] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8B:12:60 to 00:0B:86:8B:10:E0 on wireless network 'WIREFREEWWU' Nov 28 14:43:36 frohro-d600 NetworkManager: debug [1196289816.803632] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8B:10:E0 to 00:0B:86:89:16:A0 on wireless network 'WIREFREEWWU' Nov 28 14:43:38 frohro-d600 NetworkManager: debug [1196289818.803926] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:89:16:A0 to 00:0B:86:8B:10:E0 on wireless network 'WIREFREEWWU' Nov 28 14:43:44 frohro-d600 NetworkManager: debug [1196289824.803830] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:89:16:A0 to 00:0B:86:8B:10:E0 on wireless network 'WIREFREEWWU' Nov 28 14:43:48 frohro-d600 NetworkManager: debug [1196289828.803865] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8A:A7:20 to 00:0B:86:8B:10:E0 on wireless network 'WIREFREEWWU' Nov 28 14:44:00 frohro-d600 NetworkManager: debug [1196289840.803858] nm_device_802_11_wireless_update_bssid(): Roamed from BSSID 00:0B:86:8B:10:E0 to 00:0B:86:8A:A7:20 on wireless network 'WIREFREEWWU' There appear to be three base stations within the WIREFREEWWU network that it keeps switching between. The signal strengths vary from zero bars to five bars. I just would like it to stay with the five bars. Any ideas? Rob -- Rob Frohne, Ph.D., P.E., Professor E. F. Cross School of Engineering Walla Walla University 100 SW 4th Street College Place, WA 99324 (509) 527-2075 http://www.wallawalla.edu/frohro ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with ipw3945
On Wed, Nov 28, 2007 at 05:16:14PM -0500, Dan Williams wrote: On Wed, 2007-11-28 at 23:07 +0100, Martin Ginkel wrote: Hi, on my notebook I'm trying to user NM to access wireless networks. There is a larger problem with setting essids and associating/disassociating to APs. 0.6.5, right? Apparently the card assumes to interpret the essid (empty) to be *any*. Yeah, that's the standard behavior. Therefore it associates immediately to the next ap. I watched this with iwevent. Nm first sets the essid to to disassociate, later it sets the id, I selected in the menu. But the card is already associated by the setting and NM waits forever for an association event after setting the id. Well, the driver needs to send the association event whenever it gets an association request, even if that association request is for the same AP that it's already associated with. This seems like a driver bug to me. Association requests must always be followed by either a failed association event, or a valid associated AP event. It sounds like the ipw3945 driver isn't doing that. This is a drivers bug. We have a fix for that in ubuntu. You can find it in: https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac the commit of revision 2 is what you want. - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPNC Connection dropping
Matthew Saltzman wrote: There is an issue with recent vpnc releases (in particular, the one in Fedora 8) where connections are dropped fairly regularly by the dead-peer detector. See https://bugzilla.redhat.com/show_bug.cgi?id=345281. The workaround is a parameter in the config file for vpnc to adjust the DPD timeout or turn it off, but there is no way to specify the option for a connection in NM-vpnc. Can you file a bug against NM-vpnc ? I have a patch already that relaxes the options validation step, so that one may add any required non-supported options into gconf. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Wed, 2007-11-28 at 11:49 +0200, Tambet Ingo wrote: On Nov 27, 2007 6:40 PM, vikram b [EMAIL PROTECTED] wrote: Hi, I would like use svn trunk's code to setup ppp connection , lets say for dial up (gprs etc). As Dan already said, I have code to drive gsm data cards and we hope to get it to SVN later this week, even if it means there's no way to configure it yet from the UI (the currently missing part). I'll be more than happy writing the GPRS bits of it. Is there any Bluetooth related code in the code you're writing? I'm thinking specifically of the ppp-manager having a special casing for devices that look like Bluetooth addresses, and having it create rfcomm devices as appropriate (as pppd still doesn't have any native Bluetooth support). Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPNC Connection dropping
On Thu, 2007-11-29 at 00:36 +0100, Denis Leroy wrote: Matthew Saltzman wrote: There is an issue with recent vpnc releases (in particular, the one in Fedora 8) where connections are dropped fairly regularly by the dead-peer detector. See https://bugzilla.redhat.com/show_bug.cgi?id=345281. The workaround is a parameter in the config file for vpnc to adjust the DPD timeout or turn it off, but there is no way to specify the option for a connection in NM-vpnc. Can you file a bug against NM-vpnc ? I have a patch already that relaxes the options validation step, so that one may add any required non-supported options into gconf. https://bugzilla.redhat.com/show_bug.cgi?id=403661 Thanks. BTW, I don't see a setting for keepalive packet interval in gconf, even though I set it while trying to work around this problem. Is that another bug? -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPNC Connection dropping
Matthew Saltzman wrote: BTW, I don't see a setting for keepalive packet interval in gconf, even though I set it while trying to work around this problem. Is that another bug? Hmm odd, I'm seeing it the option added to the vpn-properties gconf dir, but i got a core dump the first time I tried to edit it... ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
if-up hooks not working
Due to wireless issues I've been experiencing since upgrading to Ubuntu Gutsy, I've been switching somewhat frequently between wired and wireless. When I do that, my IP address changes and my router doesn't have enough configurability to force the IP to stay the same. So, I've written a set of scripts that keep my DNS server up-to-date. After poking around the filesystem and NetworkManager's scanty documentation, I determined that I should place my script in /etc/network/if-up.d. However, I've discovered that those scripts get called when switching from wireless to wired, but not the other way around. How can I persuade NetworkManager to run my script *every* time it switches interfaces? -- ===Scott Severance=== Website: http://www.scottseverance.us Blog: http://blog.scottseverance.us Check out the Sermon Illustration Library: http://www.sermonillustrationlibrary.org ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPNC Connection dropping
On Thu, 2007-11-29 at 01:01 +0100, Denis Leroy wrote: Matthew Saltzman wrote: BTW, I don't see a setting for keepalive packet interval in gconf, even though I set it while trying to work around this problem. Is that another bug? Hmm odd, I'm seeing it the option added to the vpn-properties gconf dir, but i got a core dump the first time I tried to edit it... Ah, I'm looking in the wrong place. So it's not missing; don't know about the editing thing--seems OK for me. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: if-up hooks not working
On Nov 28, 2007 7:32 PM, Scott Severance [EMAIL PROTECTED] wrote: Due to wireless issues I've been experiencing since upgrading to Ubuntu Gutsy, I've been switching somewhat frequently between wired and wireless. When I do that, my IP address changes and my router doesn't have enough configurability to force the IP to stay the same. So, I've written a set of scripts that keep my DNS server up-to-date. After poking around the filesystem and NetworkManager's scanty documentation, I determined that I should place my script in /etc/network/if-up.d. However, I've discovered that those scripts get called when switching from wireless to wired, but not the other way around. How can I persuade NetworkManager to run my script *every* time it switches interfaces? -- ===Scott Severance=== Website: http://www.scottseverance.us Blog: http://blog.scottseverance.us Check out the Sermon Illustration Library: http://www.sermonillustrationlibrary.org ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list I take you are are trying to update a DNS servers A record for your PC? What I think you want to use is NetworkManagerDispatcher. These are scripts that are run based on the state of an interface. Some examples are here: http://www.darrenalbers.net/wiki/index.php?title=NetworkManagerScripts In fact someone posted a script to update a dynamic dns server here: http://article.gmane.org/gmane.linux.network.networkmanager.devel/5044 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
How to get NetworkManager connect to known WIFI networks upon BOOT
My Ubuntu 7.10 computer boots up and gets its IP address just fine when it is on a wired network (via DHCP). It can also connect to wireless networks, however, it requires me to be logged on to gnome and enter my password. I want to skip all of that and make NetworkManager connect to several known wifi networks automatically upon boot, even if no one logs on to this laptop. In Fedora, I wrote a custom script calling wpa_supplicant with a .conf file, but I want to integrate NetworkManager better as I like its reconnection abilities. So. How can I make NM connect to password protected wifi networks upon boot, without users logging in? How can I do it? i ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
