Re: NM ath0 trouble
On Wed, 2006-01-04 at 21:23 -0500, Sven Rinke wrote: Dan, thanks for your prompt reply. my kernel version is 2.6.14-1.1636 with swusp2 patches, and i'm using the binary-HAL from www.madwifi.org , a recent version with a fix for some trouble with NM: www.madwifi.org/changeset/1380 Haha, I hadn't realized they didn't have SET_NETDEV_DEV... I could swear the driver had that correct at least 6 months ago or so, I have used an Atheros b/g card quite extensively before with 2.6.12 and 2.6.13 kernels. Weird. Well, I'll give it a shot and see what happens in the next couple days here. Dan Sven On Wed, 2006-01-04 at 21:11 -0500, Dan Williams wrote: So we've finally got an a/b/g Atheros card (Netgear) at work now for testing. What exact version of the driver are you using? Are you using the reverse-engineered HAL or the normal binary-HAL? What kernel version? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM ath0 trouble
Dan Williams wrote: On Wed, 2006-01-04 at 21:23 -0500, Sven Rinke wrote: Haha, I hadn't realized they didn't have SET_NETDEV_DEV... I could swear the driver had that correct at least 6 months ago or so, I have used an Atheros b/g card quite extensively before with 2.6.12 and 2.6.13 kernels. Weird. Well, I'll give it a shot and see what happens in the next couple days here. Note that the mentioned website is about the new madwifi-ng driver, which uses the new HAL from Atheros. The old madwifi driver can be checked out as madwifi-old branch (http://www.madwifi.org/browser/branches/madwifi-old) from svn and works just fine. Tim -- Tim Niemueller [EMAIL PROTECTED] www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM ath0 trouble
On Thu, 2006-01-05 at 14:28 +0100, Tim Niemueller wrote: Note that the mentioned website is about the new madwifi-ng driver, which uses the new HAL from Atheros. The old madwifi driver can be checked out as madwifi-old branch (http://www.madwifi.org/browser/branches/madwifi-old) from svn and works just fine. Indeed. But work is continuing on madwifi-ng and that will be the solution going forward, so we should get working on that. It fixes a lot of other madwifi issues nicely, too. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
dialup oddity on debian (ubuntu)
Hi all,
am trying to get nm to start a dialup connection.
I have my mobile phone connected in such a way that doing the following
will do what I want:
sudo ifup ppp0
Now, from looking at the code and the daemon.log it seems that nm does
just that. I even created a wrapper script to call ifup and see what
it's doing like this:
[EMAIL PROTECTED]:~$ more /sbin/ifup
#!/bin/bash
echo ifup: [EMAIL PROTECTED] /tmp/ifup.out
echo EUID: ${EUID} /tmp/ifup.out
/ifup [EMAIL PROTECTED]
echo result: ${?} /tmp/ifup.out
this yields:
ifup: ppp0
EUID: 0
result: 0
ifup: ppp0
EUID: 0
result: 0
ifup: ppp0
EUID: 0
result: 0
And I can see no difference between me doing it on the command line and
nm doing it, not in /var/log/messages, ...daemon.log, or syslog either.
Any ideas what else to look at?
TIA,
Karl.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA status 2006-01-03
On Thu, 2006-01-05 at 10:24 -0500, Robert Love wrote: On Tue, 2006-01-03 at 17:19 -0500, Dan Williams wrote: What's left to be done? --- 'Connect to Other Network' and 'Create New Network' do not work. Is this known or ... ? The latter prints a warning: tried to manually connect to network 'foo' without providing security information!' And then, in both cases, basically nothing happens. Hmm, bug :) Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM ath0 trouble
On Thu, 2006-01-05 at 09:28 -0500, Robert Love wrote: On Thu, 2006-01-05 at 14:28 +0100, Tim Niemueller wrote: Note that the mentioned website is about the new madwifi-ng driver, which uses the new HAL from Atheros. The old madwifi driver can be checked out as madwifi-old branch (http://www.madwifi.org/browser/branches/madwifi-old) from svn and works just fine. Indeed. But work is continuing on madwifi-ng and that will be the solution going forward, so we should get working on that. It fixes a lot of other madwifi issues nicely, too. So in the 3rd Edition of your book, Robert, can you pleasepleaseplease add a chapter for Making your driver play nice with others, including HAL that has a section on what to do to get the correct sysfs entries, ie stuff like SET_NETDEV_DEV and ensuring the sysfs 'driver' link is correct by passing the correct driver structure to the device init routines (which I believe is SET_MODULE_OWNER)? It seems there's complete lack of documentation on how to make drivers interact with sysfs. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM ath0 trouble
On Thu, 2006-01-05 at 11:01 -0500, Dan Williams wrote: So in the 3rd Edition of your book, Robert, can you pleasepleaseplease add a chapter for Making your driver play nice with others, including HAL that has a section on what to do to get the correct sysfs entries, ie stuff like SET_NETDEV_DEV and ensuring the sysfs 'driver' link is correct by passing the correct driver structure to the device init routines (which I believe is SET_MODULE_OWNER)? It seems there's complete lack of documentation on how to make drivers interact with sysfs. God, yes. Linux drivers are absolutely horrid and networking is the worst subsystem and wireless the worst grouping therein. Just terrible. But the problem really lies on three issues (a) No documentation. Driver writers do not know what to do or how to do it. (b) Incomplete implementation in current kernels, so driver writers roll their own solution. Nice in the short-term, awful in the longer term. (c) Other kernel hackers and some users just don't care. Until things like HAL, g-v-m, and NM, the need for a unified API just was not there. And there is one other concern, broader in scope: People simply do not treat sysfs as API--immutable and important--in the same way they treat system calls or even, for that matter, device nodes. I added a brief sysfs section to the 2ed, but it was largely a sysfs internals -- how to hack the sysfs code, not work with sysfs in your own driver. A 3ed will surely do better. Also, I think Linux Device Drivers 3ed has a decent treatment of this material. But probably not enough. We really need to outline MANDATORY behavior and MANDATORY sysfs entries that all drivers need support. It is a lot of work to document all of that. But, damn, we need it. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM ath0 trouble
Message: 6 From: Tim Niemueller [EMAIL PROTECTED] Subject: Re: NM ath0 trouble Message-ID: [EMAIL PROTECTED] Note that the mentioned website is about the new madwifi-ng driver, which uses the new HAL from Atheros. The old madwifi driver can be checked out as madwifi-old branch (http://www.madwifi.org/browser/branches/madwifi-old) from svn and works just fine. Tim my October post was about NM and the old madwifi driver - it didn't work for me as described there. and going back to an old madwifi driver now ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) wlan: 0.8.6.0 (EXPERIMENTAL) ath_rate_sample: 1.2 ath_pci: 0.9.6.0 (EXPERIMENTAL) ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11 ACPI: PCI Interrupt :02:0a.0[A] - Link [LNKH] - GSI 11 (level, low) - IRQ 11 Build date: Oct 27 2005 still does not work: NetworkManager: information ath0: Device is fully-supported using driver 'ath_pci'. NetworkManager: information nm_device_new(): waiting for device's worker thread to start NetworkManager: information nm_device_new(): device's worker thread started, continuing. NetworkManager: information Now managing wireless device 'ath0'. NetworkManager: information Deactivating device ath0. NetworkManager: information Updating allowed wireless network lists. NetworkManager: information FORCE: device '/org/freedesktop/NetworkManager/Devices/ath0', network 'default' NetworkManager: information Deactivating device ath0. NetworkManager: debug info[1136481046.955453] (): Forcing AP 'default' NetworkManager: information Device ath0 activation scheduled... NetworkManager: information Activation (ath0) started... NetworkManager: information Activation (ath0) Stage 1 (Device Prepare) scheduled... NetworkManager: information Activation (ath0) Stage 1 (Device Prepare) started... NetworkManager: information Activation (ath0) Stage 2 (Device Configure) scheduled... NetworkManager: information Activation (ath0) Stage 1 (Device Prepare) complete. NetworkManager: information Activation (ath0) Stage 2 (Device Configure) starting... NetworkManager: information Activation (ath0/wireless) Stage 2 (Device Configure) will connect to access point 'default'. NetworkManager: information Activation (ath0/wireless): access point 'default' is unencrypted, no key needed. NetworkManager: information Activation (ath0/wireless): using essid 'default', with no authentication. NetworkManager: debug info[1136481055.331714] (): Activation (ath0/wireless): no hardware link to 'default' in non-encrypted mode. NetworkManager: information Activation (ath0) failure scheduled... NetworkManager: information Activation (ath0) failure scheduled... NetworkManager: information Activation (ath0) Stage 2 (Device Configure) complete. NetworkManager: information Activation (ath0) failed for access point (default) NetworkManager: information Deactivating device ath0. NetworkManager: information Activation (ath0) failed for access point (default) NetworkManager: information Deactivating device ath0. i don't understand why it should not work for me if it works for others. any debugging suggestions? Sven ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA status 2006-01-03
On Thu, 2006-01-05 at 12:21 -0500, Dan Williams wrote: They should be hooked up, I got it all working before Christmas and before I started the NMDevice refactor. Hrm. Also - are we converting old-style gconf/keyring data? Yes, since around the 23 Dec 2005 or so. Can you try running the applet with --sm-disable and see if it prints anything out when you try Other wireless network ? Sure thing. It does not print anything. The daemon prints: NetworkManager: debug info[1136482380.660630] (): Forcing AP 'wolf' NetworkManager: WARNING (): nm_device_802_11_wireless_get_activation_ap: tried to manually connect to network 'wolf' without providing security information! NetworkManager: information User Switch: /org/freedesktop/NetworkManager/Devices/ath0 / wolf NetworkManager: information Deactivating device ath0. NetworkManager: nm_act_request_new: assertion `ap != NULL' failed NetworkManager: nm_policy_schedule_device_activation: assertion `req != NULL' failed Meanwhile, doing Create New Network, shows no response in the daemon, but the applet prints: ** Message: information Creating network 'molly' on device '/org/freedesktop/NetworkManager/Devices/ath0'. In either case, nothing actually happens. The applet looks the same and the daemon initiates no change. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA status 2006-01-03
On Thu, 2006-01-05 at 12:32 -0500, Robert Love wrote: In either case, nothing actually happens. The applet looks the same and the daemon initiates no change. The problem is nm-dbus-nm.c :: line 260, where we call nm_device_802_11_wireless_get_activation_ap(). security is NULL, but the function wants a non-NULL security in the case of a non-scanned network. It looks like nm_dbus_nm_set_active_device() should be creating a security context? But ... if I try to connect to an AP with encryption via Connect to Other, I get: NetworkManager: nm_ap_security_new_deserialize: assertion `dbus_message_iter_get_arg_type (iter) == DBUS_TYPE_INT32' failed NetworkManager: WARNING (): nm-dbus-nm.c:254 (nm_dbus_nm_set_active_device): Invalid argument (wireless security info). Does that point to something obvious? You aren't seeing the same behavior? Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: kernel headers ethtool.h and mii.h
On Wed, 04 Jan 2006 11:12:16 -0500 Robert Love [EMAIL PROTECTED] wrote: On Wed, 2006-01-04 at 10:57 -0500, Dan Williams wrote: Yes, it appears that we do. Alright. I'll look into patching our glibc, too. In the meantime, the previous patch works. We have to do this for wpa.c too since somebody decided it was cool to use kernel types in wpa_supplicant. Whatever. Ugh. On a similar vein -- I am seeing a problem (reported weeks ago by someone else) with more recent wireless-tools. It seems some things use net/if.h and others linux/if.h. Unfortunately, they define much the same stuff (ifmap, ifreq, and ifconf structures being the troublemakers) and thus break compilation. Not sure an easy solution for that, although a quick-hack would be to patch iwlib.h to always use linux/if.h instead of net/if.h. [ The problem in NM's case is that we include iwlib.h and kernel headers, such as mii.h that use linux/if.h, in the same file. ] Robert Love Is there something that needs to be exported in net/if.h or is it just application stupidity? -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: kde support
Terry wrote: I am guessing this is a known issue. Should I be seeing the NM icon in my KDE tray when the service is running? Are you running nm-applet? Tim -- Tim Niemueller [EMAIL PROTECTED] www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: kde support
I am now. Thanks! moron On 1/5/06, Tim Niemueller [EMAIL PROTECTED] wrote: Terry wrote: I am guessing this is a known issue. Should I be seeing the NM icon in my KDE tray when the service is running? Are you running nm-applet? Tim -- Tim Niemueller [EMAIL PROTECTED] www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ 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: kernel headers ethtool.h and mii.h
On Thu, 2006-01-05 at 10:19 -0800, Stephen Hemminger wrote: Is there something that needs to be exported in net/if.h or is it just application stupidity? Nah, I think they both export the right stuff. But I would not say the problem is application stupidity -- we have two official headers that both define the same stuff. While we may expect an individual application to be smart enough to not include both, what do we expect if an application uses various other libraries and headers, that include the two files, plus does networking of its own? This is what we see in NM: NM wants to get at this data, but so does iwlib and mii. We can have NM use whatever header we want, but iwlib uses net/if.h and mii uses linux/if.h. For SUSE, at least, I patched wireless-tools to use linux/if.h. It does not fix the underlying problem, but at least we can build. Robert Love ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
patch update 1.1, was: Re: draw applet without theme
Hi all,
on a hint from Predatory Kangaroo (nice name btw.) I've mananged to make
the left-click menu with my patch behave a little more like it does in
the original version.
In other words:
The patch now looks at the position of the applet. If it's in the upper
half of the screen, it will position the menu below the applet. If it's
in the lower half, it will try to position the menu above the applet. In
both cases will it try to align the menu's left edge with the applet's.
Of course this may all not work because there may not be enough space
for the menu in the determined position. In this case the menu will be
moved to fit on screen automatically by GTK as required ... that can
probably be regarded as standard behaviour and as desirable.
The other thing is that positioning relies on getting the menu height
with gtk_widget_size_requisition. This seems to work decently for me
here (though it causes segfaults for P.K.). However, I also remember
having encountered problems elsewhere because gtk_widget_size_request
returns the widget's DESIRED dimensions. Now, the dimensions actually
allocated may be quite different. Don't think this is problematic
because it will worst case make the positioning above the applet a
little inaccurate. I'm just elaborating in case somebody has an idea for
determining the menu's size accurately and deterministically before
actually showing it.
If you also experience segfaults with this version, go back to the
previous one and leave positioning to GTK. On my ubuntu breezy machine
it works alright.
Karl.
--- gnome/applet/applet.c 2005-10-18 16:51:22.0 +0200
+++ gnome/applet/applet.c.khb 2006-01-05 21:06:21.0 +0100
@@ -1948,7 +1948,34 @@
* Pop up the wireless networks menu
*
*/
-static void nmwa_dropdown_menu_show_cb (GtkWidget *menu, NMWirelessApplet
*applet)
+void position_popup_menu (GtkMenu *menu, gint *x, gint *y, gboolean *push_in,
gpointer user_data)
+{
+ GtkWidget *applet;
+
+ applet = GTK_WIDGET(user_data);
+ g_assert (applet);
+ g_assert (x);
+ g_assert (y);
+
+ *x = *y = 0;
+ gdk_window_get_origin (GDK_WINDOW (applet-window), x, y);
+
+ if ( *y + applet-allocation.height / 2
+ gdk_screen_get_height( gtk_widget_get_screen(
GTK_WIDGET( menu ))) / 2 ) {
+
+ GtkRequisition size;
+
+ // the following will not necessarily give the correct size of
the menu as it has
+ // not been rendered yet, but it's prolly the best we can get
+ gtk_widget_size_request( GTK_WIDGET( menu ), size );
+ *y -= size.height;
+ } else {
+ *y += applet-allocation.height;
+ }
+ *push_in = TRUE;
+}
+
+static void nmwa_dropdown_menu_show_cb (GtkWidget *menu, NMWirelessApplet
*applet, GdkEventButton *event)
{
g_return_if_fail (menu != NULL);
g_return_if_fail (applet != NULL);
@@ -1961,7 +1988,9 @@
{
nmwa_dropdown_menu_clear (applet-dropdown_menu);
nmwa_dropdown_menu_populate (applet-dropdown_menu, applet);
- gtk_widget_show_all (applet-dropdown_menu);
+
+ gtk_menu_popup (GTK_MENU (applet-dropdown_menu), NULL, NULL,
position_popup_menu, applet,
+event-button, event-time);
}
nmi_dbus_signal_user_interface_activated (applet-connection);
@@ -1973,7 +2002,7 @@
* Create the applet's dropdown menu
*
*/
-static GtkWidget *nmwa_dropdown_menu_create (GtkMenuItem *parent,
NMWirelessApplet *applet)
+static GtkWidget *nmwa_dropdown_menu_create (GtkWidget *parent,
NMWirelessApplet *applet)
{
GtkWidget *menu;
@@ -1982,8 +2011,6 @@
menu = gtk_menu_new ();
gtk_container_set_border_width (GTK_CONTAINER (menu), 0);
- gtk_menu_item_set_submenu (GTK_MENU_ITEM (parent), menu);
- g_signal_connect (menu, show, G_CALLBACK
(nmwa_dropdown_menu_show_cb), applet);
return menu;
}
@@ -2101,7 +2128,7 @@
if (applet-top_menu_item)
{
gtk_menu_item_remove_submenu (GTK_MENU_ITEM
(applet-top_menu_item));
- applet-dropdown_menu = nmwa_dropdown_menu_create
(GTK_MENU_ITEM (applet-top_menu_item), applet);
+ applet-dropdown_menu = nmwa_dropdown_menu_create (GTK_WIDGET
(applet-top_menu_item), applet);
}
}
@@ -2117,9 +2144,14 @@
g_return_val_if_fail (applet != NULL, FALSE);
- if (event-button != 1)
g_signal_stop_emission_by_name (widget, button_press_event);
+ if (event-button == 1)
+ {
+ nmwa_dropdown_menu_show_cb(applet-dropdown_menu, applet, event
);
+ return (TRUE);
+ }
+
if (event-button == 3)
{
nmwa_context_menu_update (applet);
@@ -2140,31 +2172,19 @@
*/
static void nmwa_setup_widgets (NMWirelessApplet *applet)
{
-
