Re: Latest Fedora 7 NM can't disable wireless
On Wed, 2007-06-27 at 19:08 +0200, dragoran wrote: > > > On 6/27/07, Dan Williams <[EMAIL PROTECTED]> wrote: > On Wed, 2007-06-27 at 09:09 -0400, Dan Williams wrote: > > On Tue, 2007-06-26 at 22:08 +, Matthew Saltzman wrote: > > > On Tue, 2007-06-26 at 23:42 +0200, dragoran wrote: > > > > sorry attached the wrong patch. > > > > this is the working one (also set the variable to true > in this case) > > > > > > Seems to work here (Dan's original one didn't). > > > > Ah, right. Ok, will apply and push the update, thanks. > > Can you guys try the RPMs here? > > http://koji.fedoraproject.org/packages/NetworkManager/0.6.5/7.fc7/ > > It's got a slightly modified fix from what dragoran posted. > > works fine thx. Seems OK here, too. > > > > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wake on LAN support. NetworkManager?
On Wed 27. Jun - 11:57:28, Steev Klimaszewski wrote: > Holger Macht wrote: > > Hi, > > I'm currently looking for a place to integrate Wake On LAN > > capabilities/enablement. As a logical result, NetworkManager came to my > > mind. > > When talking about Wake On LAN, I'm talking about the functionality > > ethtool provides, and about the network drivers which implement ethtool > > support. I've already created a proof-of-concept patch. The current work > > is based on NetworkManager-0.6.5, just because it's the most recent stable > > release. > > I've added three new D-Bus methods: > > getWakeOnLanEnabled > > getWakeOnLanSupported > > setWakeOnLanEnabled > > So this mail is not a "please commit", but rather a question if it makes > > sense to integrate into NetworkManager at all. The other possibility would > > be to add to HAL if it doesn't fit into the NetworkManager concept. > > Comments? > > - Holger > > I won't comment on the patch itself (I haven't looked it over yet here) but > I am wondering exactly what you mean - assuming the laptop is asleep/off NM > won't be running/active to catch the WOL signal - or is this supposed to > send it to another machine? I admit I am not familiar with the ethtool and > what it does wrt WOL (and only have 1 machine that support WOL afaik) but I > would think this is something that would be more suited for hal, or a > persons bios (in fact, as far as I knew, it has to be enabled in bios - but > I know I am not the most knowledgeable person, and I am always willing to > learn!) > Wake On LAN has to be enabled in the BIOS for all this to work anyway, right. But you still have to enable it from software, because it is disabled by default with most cards AFAIC. The actual handling of the WOL signal, and the waking up is still handled by the hardware itself. What the methods do are actually just frontending ethtool. They just enabling WOL on the network card. Another system has to send the so called MagicPacket to wake up the system afterwards. getWakeOnLanEnabled --> ethtool eth0 | grep "Wake-on" getWakeOnLanSupported --> ethtool eth0 | grep "Supports Wake-on" setWakeOnLanEnabled --> ethtool -s eth0 wol umbg Right, this doesn't entirely has something to do with "managing networks", it's just something that has to be done with each network interface the system has. Hopes this makes things more clear. - Holger ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Latest Fedora 7 NM can't disable wireless
On 6/27/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Wed, 2007-06-27 at 09:09 -0400, Dan Williams wrote: > On Tue, 2007-06-26 at 22:08 +, Matthew Saltzman wrote: > > On Tue, 2007-06-26 at 23:42 +0200, dragoran wrote: > > > sorry attached the wrong patch. > > > this is the working one (also set the variable to true in this case) > > > > Seems to work here (Dan's original one didn't). > > Ah, right. Ok, will apply and push the update, thanks. Can you guys try the RPMs here? http://koji.fedoraproject.org/packages/NetworkManager/0.6.5/7.fc7/ It's got a slightly modified fix from what dragoran posted. works fine thx. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Latest Fedora 7 NM can't disable wireless
On Wed, 2007-06-27 at 09:09 -0400, Dan Williams wrote: > On Tue, 2007-06-26 at 22:08 +, Matthew Saltzman wrote: > > On Tue, 2007-06-26 at 23:42 +0200, dragoran wrote: > > > sorry attached the wrong patch. > > > this is the working one (also set the variable to true in this case) > > > > Seems to work here (Dan's original one didn't). > > Ah, right. Ok, will apply and push the update, thanks. Can you guys try the RPMs here? http://koji.fedoraproject.org/packages/NetworkManager/0.6.5/7.fc7/ It's got a slightly modified fix from what dragoran posted. Thanks, Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wake on LAN support. NetworkManager?
Holger Macht wrote: > Hi, > > I'm currently looking for a place to integrate Wake On LAN > capabilities/enablement. As a logical result, NetworkManager came to my > mind. > > When talking about Wake On LAN, I'm talking about the functionality > ethtool provides, and about the network drivers which implement ethtool > support. I've already created a proof-of-concept patch. The current work > is based on NetworkManager-0.6.5, just because it's the most recent stable > release. > > I've added three new D-Bus methods: > > getWakeOnLanEnabled > getWakeOnLanSupported > setWakeOnLanEnabled > > So this mail is not a "please commit", but rather a question if it makes > sense to integrate into NetworkManager at all. The other possibility would > be to add to HAL if it doesn't fit into the NetworkManager concept. > > Comments? > > - Holger I won't comment on the patch itself (I haven't looked it over yet here) but I am wondering exactly what you mean - assuming the laptop is asleep/off NM won't be running/active to catch the WOL signal - or is this supposed to send it to another machine? I admit I am not familiar with the ethtool and what it does wrt WOL (and only have 1 machine that support WOL afaik) but I would think this is something that would be more suited for hal, or a persons bios (in fact, as far as I knew, it has to be enabled in bios - but I know I am not the most knowledgeable person, and I am always willing to learn!) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trunk make dist broken missing file?
On 6/26/07, Dan Williams <[EMAIL PROTECTED]> wrote: > On Tue, 2007-06-26 at 14:29 -0500, Steev Klimaszewski wrote: > > There is no nm-object.h in subversion as far as i can tell, did this > > file fail to get committed, or is it left out to keep people from > > testing right now? > > It might have been, Tambet? Sorry folks, I take the blame. Fixed now, thanks. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Wed, 2007-06-27 at 15:46 +0200, dragoran wrote: > Bastien Nocera wrote: > ok will fix the program to use the env var and open a thread on the hal > list. is it subscribers only list or can I post directly to it? No idea, I believe it's subscribers only though. -- Bastien Nocera <[EMAIL PROTECTED]> ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Wed, 2007-06-27 at 14:15 +0100, Bastien Nocera wrote:
> On Mon, 2007-06-25 at 12:13 -0400, Dan Williams wrote:
> > On Mon, 2007-06-25 at 16:09 +0200, dragoran wrote:
> > >
> > >
> > > On 6/25/07, yelo_3 <[EMAIL PROTECTED]> wrote:
> > > > ok, but this does not solve the problem of multiple
> > > killswitches (will
> > > > show up with multiple cards) because both will have
> > > > /org/freedesktop/Hal/devices/ipw_wlan_switch as uid.
> > > Yes the previous shell script didn't solve the problem...
> > > sorry. This might mean that the UDI should contain the
> > > interface name as you were saying
> > > The C code misses the setrfkill section, and a !=null check
> > > when you fopen the file.
> > >
> > > ok here is a new version.
> > > it implements setrfkill too and uses g_strdup_printf instead of
> > > sprintf.
> >
> > I don't think argc == 3 is valid for the setrfkill check, since the
> > number of args will still be 2... I'd just put a check before the
> > libhal_ctx_init() that does:
> >
> > if (argc != 2) {
> > fprintf (stderr, "Usage: ipwWirelessCtl [getrfkill] [setrfkill
> > [1|0]]\n");
> > return -1;
> > }
> >
> > or something like that, and get rid of the argc checks for getrfkill and
> > setrfkill.
> >
> > I think we should actually just reparent the device to be a child of
> > Computer. I also think the script should just rfkill _everything_, and
> > that it should return '1' if _any_ ipw radios are off. This script is
> > really only a stopgap until the _real_ kernel rfkill interfaces are
> > complete, and then most these problems go away. So instead of trying to
> > overengineer the whole thing, I think it should work like this:
> >
> > a) .fdi file adds _one_ rfkill device if any ipw cards are found
> > b) 'ipwWirelessCtl getrfkill' checks all ipw devices for rfkill status,
> > and if one of them is killed, it returns 1
> > c) 'ipwWirelessCtl setrfkill 1' kills _all_ ipw devices, while
> > 'ipwWirelessCtl 0' re-enables _all_ ipw devices
> >
> > Sound OK? That way we also don't have to figure out how to unique-ify
> > the device name, which the future kernel patches will handle for us.
> >
> > I've attached an updated .fdi file for ipw devices that excludes Dells,
> > and makes only _one_ killswitch device.
>
> Please attach the killswitch to the device itself, not the computer.
I changed it to be on the computer object, because this is all really
just a hack until the kernel rfkill patches land and we get _signals_,
which is what I really really want.
I don't really care either way.
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
Bastien Nocera wrote: > On Wed, 2007-06-27 at 15:38 +0200, dragoran wrote: > >> Bastien Nocera wrote: >> >>> On Sun, 2007-06-24 at 22:15 +0200, dragoran wrote: >>> >>> here is a C implementation of the ipwWirelessCtl the udi is hardcoded and I only implemented get for now (will add the rest tomorrow). It also uses all values from the README. yelo_3 you have a typo in your patch (you used getrfkill instead of set ;) ) Bastien: the UDI that will get passed to the script would be that of the killswitch corret? >>> Yes, and it will be passed as a envvar, as in the other scripts. >>> >>> >>> >> ok HAL_PROP_UDI ? >> > > HAL_PROP_INFO_UDI I believe. > ok programm is attached... any comments? >>> As this will live in HAL, it should have a better name (Dan was only >>> mimicking the name of the Dell rfkill-helper). >>> >>> >>> >> ok that shouldn't be the problem. >> >> any idea how to exclude dell laptops in the .fdi? >> > > No idea, but I'm no fdi file guru. Probably a good idea to move this > discussion to the HAL list, so you can get comments directly from the > horse's mouth. > > ok will fix the program to use the env var and open a thread on the hal list. is it subscribers only list or can I post directly to it? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Wed, 2007-06-27 at 15:38 +0200, dragoran wrote: > Bastien Nocera wrote: > > On Sun, 2007-06-24 at 22:15 +0200, dragoran wrote: > > > >> here is a C implementation of the ipwWirelessCtl > >> the udi is hardcoded and I only implemented get for now (will add the > >> rest tomorrow). It also uses all values from the README. > >> yelo_3 you have a typo in your patch (you used getrfkill instead of > >> set ;) ) > >> > >> Bastien: the UDI that will get passed to the script would be that of > >> the killswitch corret? > >> > > > > Yes, and it will be passed as a envvar, as in the other scripts. > > > > > ok HAL_PROP_UDI ? HAL_PROP_INFO_UDI I believe. > >> programm is attached... any comments? > >> > > > > As this will live in HAL, it should have a better name (Dan was only > > mimicking the name of the Dell rfkill-helper). > > > > > ok that shouldn't be the problem. > > any idea how to exclude dell laptops in the .fdi? No idea, but I'm no fdi file guru. Probably a good idea to move this discussion to the HAL list, so you can get comments directly from the horse's mouth. -- Bastien Nocera <[EMAIL PROTECTED]> ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
Bastien Nocera wrote: > On Sun, 2007-06-24 at 22:15 +0200, dragoran wrote: > >> here is a C implementation of the ipwWirelessCtl >> the udi is hardcoded and I only implemented get for now (will add the >> rest tomorrow). It also uses all values from the README. >> yelo_3 you have a typo in your patch (you used getrfkill instead of >> set ;) ) >> >> Bastien: the UDI that will get passed to the script would be that of >> the killswitch corret? >> > > Yes, and it will be passed as a envvar, as in the other scripts. > > ok HAL_PROP_UDI ? >> programm is attached... any comments? >> > > As this will live in HAL, it should have a better name (Dan was only > mimicking the name of the Dell rfkill-helper). > > ok that shouldn't be the problem. any idea how to exclude dell laptops in the .fdi? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Mon, 2007-06-25 at 12:13 -0400, Dan Williams wrote:
> On Mon, 2007-06-25 at 16:09 +0200, dragoran wrote:
> >
> >
> > On 6/25/07, yelo_3 <[EMAIL PROTECTED]> wrote:
> > > ok, but this does not solve the problem of multiple
> > killswitches (will
> > > show up with multiple cards) because both will have
> > > /org/freedesktop/Hal/devices/ipw_wlan_switch as uid.
> > Yes the previous shell script didn't solve the problem...
> > sorry. This might mean that the UDI should contain the
> > interface name as you were saying
> > The C code misses the setrfkill section, and a !=null check
> > when you fopen the file.
> >
> > ok here is a new version.
> > it implements setrfkill too and uses g_strdup_printf instead of
> > sprintf.
>
> I don't think argc == 3 is valid for the setrfkill check, since the
> number of args will still be 2... I'd just put a check before the
> libhal_ctx_init() that does:
>
> if (argc != 2) {
> fprintf (stderr, "Usage: ipwWirelessCtl [getrfkill] [setrfkill [1|0]]\n");
> return -1;
> }
>
> or something like that, and get rid of the argc checks for getrfkill and
> setrfkill.
>
> I think we should actually just reparent the device to be a child of
> Computer. I also think the script should just rfkill _everything_, and
> that it should return '1' if _any_ ipw radios are off. This script is
> really only a stopgap until the _real_ kernel rfkill interfaces are
> complete, and then most these problems go away. So instead of trying to
> overengineer the whole thing, I think it should work like this:
>
> a) .fdi file adds _one_ rfkill device if any ipw cards are found
> b) 'ipwWirelessCtl getrfkill' checks all ipw devices for rfkill status,
> and if one of them is killed, it returns 1
> c) 'ipwWirelessCtl setrfkill 1' kills _all_ ipw devices, while
> 'ipwWirelessCtl 0' re-enables _all_ ipw devices
>
> Sound OK? That way we also don't have to figure out how to unique-ify
> the device name, which the future kernel patches will handle for us.
>
> I've attached an updated .fdi file for ipw devices that excludes Dells,
> and makes only _one_ killswitch device.
Please attach the killswitch to the device itself, not the computer.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Mon, 2007-06-25 at 12:28 +, yelo_3 wrote: > > I think the scripts will provide multiple killswitches, one for each ipw > > device found. And once ipwWirelessCtl uses the UDI that's passed to it, > > it should work fine with multiple killswitches. > > So the work with the UDI might be done in the shell script > hal-system-killswitch-?et-power, so that ipwWirelessCtl is invoked > with the device name to shut down! > this could be done through info.parent as in the C code by dragoran, > but in bash No, please don't put any logic in this bash script, except selecting the right binary to run. Do it in C, in the worker program. -- Bastien Nocera <[EMAIL PROTECTED]> ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Mon, 2007-06-25 at 14:01 +0200, dragoran wrote: > Dan Williams wrote: > > On Mon, 2007-06-25 at 13:33 +0200, dragoran wrote: > > > >> yelo_3 wrote: > >> > >>> I've had a look at your implementation. I have a question: > >>> Think if someone has 2 ipw cards (I don't know if it is possible, but > >>> think it is, since it is an example) > >>> will he have 2 killswitches in hal, or just one? > >>> If it has two, the script is executed two times, so it would be better > >>> to pass to the script the interface to kill, instead of doing a for > >>> among all interfaces which have a killswitch > >>> > >> thats a good question... but It should be possible (pccard? , but dunno > >> if intel offers that) but than both would have the same killswitch > >> anyway, but hal would show two. > >> > > > > I think the scripts will provide multiple killswitches, one for each ipw > > device found. And once ipwWirelessCtl uses the UDI that's passed to it, > > it should work fine with multiple killswitches. > > > > > yes but we use > > /org/freedesktop/Hal/devices/ipw_wlan_switch > > as uid which would be the same for multiple killswitches we need something > more unique The killswitch should be attached to the wireless card object, not the computer (for Bluetooth, you need to attach to the computer, as the device disappears when killed, for Dell laptops, the device isn't attached to a specific device). -- Bastien Nocera <[EMAIL PROTECTED]> ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ipw srcipts for hal
On Sun, 2007-06-24 at 22:15 +0200, dragoran wrote: > here is a C implementation of the ipwWirelessCtl > the udi is hardcoded and I only implemented get for now (will add the > rest tomorrow). It also uses all values from the README. > yelo_3 you have a typo in your patch (you used getrfkill instead of > set ;) ) > > Bastien: the UDI that will get passed to the script would be that of > the killswitch corret? Yes, and it will be passed as a envvar, as in the other scripts. > programm is attached... any comments? As this will live in HAL, it should have a better name (Dan was only mimicking the name of the Dell rfkill-helper). -- Bastien Nocera <[EMAIL PROTECTED]> ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Latest Fedora 7 NM can't disable wireless
On Tue, 2007-06-26 at 22:08 +, Matthew Saltzman wrote: > On Tue, 2007-06-26 at 23:42 +0200, dragoran wrote: > > sorry attached the wrong patch. > > this is the working one (also set the variable to true in this case) > > Seems to work here (Dan's original one didn't). Ah, right. Ok, will apply and push the update, thanks. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Gnome+PPPOE
hey, i have one idea, why gnome don't have tab for configuration pppoe conection? only linux console!! thx!___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Wake on LAN support. NetworkManager?
Hi,
I'm currently looking for a place to integrate Wake On LAN
capabilities/enablement. As a logical result, NetworkManager came to my
mind.
When talking about Wake On LAN, I'm talking about the functionality
ethtool provides, and about the network drivers which implement ethtool
support. I've already created a proof-of-concept patch. The current work
is based on NetworkManager-0.6.5, just because it's the most recent stable
release.
I've added three new D-Bus methods:
getWakeOnLanEnabled
getWakeOnLanSupported
setWakeOnLanEnabled
So this mail is not a "please commit", but rather a question if it makes
sense to integrate into NetworkManager at all. The other possibility would
be to add to HAL if it doesn't fit into the NetworkManager concept.
Comments?
- Holger
Index: include/NetworkManager.h
===
--- include/NetworkManager.h (revision 2617)
+++ include/NetworkManager.h (working copy)
@@ -89,6 +89,7 @@
#define NM_DEVICE_CAP_NM_SUPPORTED 0x0001
#define NM_DEVICE_CAP_CARRIER_DETECT 0x0002
#define NM_DEVICE_CAP_WIRELESS_SCAN 0x0004
+#define NM_DEVICE_CAP_WAKE_ON_LAN 0x0008
/* 802.11 wireless-specific device capability bits */
Index: src/nm-dbus-nm.c
===
--- src/nm-dbus-nm.c (revision 2617)
+++ src/nm-dbus-nm.c (working copy)
@@ -37,6 +37,7 @@
#include "nm-ap-security.h"
#include "nm-device-802-3-ethernet.h"
#include "nm-device-802-11-wireless.h"
+#include "nm-ethtool-wol.h"
/*
@@ -533,6 +534,109 @@
return reply;
}
+static DBusMessage *nm_dbus_nm_set_wol_enabled (DBusConnection *connection, DBusMessage *message, NMDbusCBData *data)
+{
+ DBusMessage *reply = NULL;
+ DBusError err;
+ char *dev_path;
+ int enable;
+ NMDevice *dev;
+
+ g_return_val_if_fail (data && data->data && connection && message, NULL);
+
+ dbus_error_init (&err);
+
+ if (!dbus_message_get_args (message, NULL, DBUS_TYPE_STRING, &dev_path,
+DBUS_TYPE_BOOLEAN, &enable, DBUS_TYPE_INVALID))
+ {
+ reply = nm_dbus_create_error_message (message, NM_DBUS_INTERFACE, "InvalidArguments",
+ "NetworkManager::setWakeOnLanEnabled called with invalid arguments.");
+ goto out;
+ }
+
+ if ((dev = nm_dbus_get_device_from_escaped_object_path (data->data, dev_path)))
+ {
+ int ret;
+
+ if (enable == 1)
+ ret = nm_ethtool_wol_enable(nm_device_get_iface (dev))
+ else
+ ret = nm_ethtool_wol_disable(nm_device_get_iface (dev));
+ if (ret < 0)
+ reply = nm_dbus_create_error_message (message, NM_DBUS_INTERFACE, "RequestFailed",
+ "Could not enable wake on LAN.");
+ }
+ else
+ {
+ reply = nm_dbus_create_error_message (message, NM_DBUS_INTERFACE, "DeviceNotFound",
+ "The requested network device does not exist.");
+ }
+
+out:
+ if (dbus_error_is_set (&err))
+ dbus_error_free (&err);
+
+ return (reply);
+}
+
+static DBusMessage *nm_dbus_nm_get_wol_status (DBusConnection *connection, DBusMessage *message, NMDbusCBData *data,
+ int supported)
+{
+ DBusMessage *reply = NULL;
+ DBusError err;
+ char *dev_path;
+
+ g_return_val_if_fail (data && data->data && connection && message, NULL);
+
+ dbus_error_init (&err);
+ if (dbus_message_get_args (message, &err, DBUS_TYPE_STRING, &dev_path, DBUS_TYPE_INVALID))
+ {
+ NMDevice *dev;
+
+ if ((dev = nm_dbus_get_device_from_escaped_object_path (data->data, dev_path)))
+ {
+ int value;
+
+ if (supported) {
+value = nm_ethtool_wol_supported (nm_device_get_iface (dev));
+ } else
+value = nm_ethtool_wol_enabled (nm_device_get_iface (dev));
+
+ if (value < 0)
+reply = nm_dbus_create_error_message (message, NM_DBUS_INTERFACE, "NoWakeOnLan",
+ "Could not get wake on LAN capability.");
+ else
+if ((reply = dbus_message_new_method_return (message)))
+ dbus_message_append_args (reply, DBUS_TYPE_BOOLEAN, &value, DBUS_TYPE_INVALID);
+ }
+ else
+ {
+ reply = nm_dbus_create_error_message (message, NM_DBUS_INTERFACE, "DeviceNotFound",
+ "The requested network device does not exist.");
+ }
+ }
+ else
+ {
+ reply = nm_dbus_create_error_message (message, NM_DBUS_INTERFACE, "DeviceBad",
+ "The device ID was bad.");
+ }
+
+ if (dbus_error_is_set (&err))
+ dbus_error_free (&err);
+
+ return (reply);
+}
+
+static DBusMessage *nm_dbus_nm_get_wol_enabled (DBusConnection *connection, DBusMessage *message, NMDbusCBData *data)
+{
+ return nm_dbus_nm_get_wol_status (connection, message, data, 0);
+}
+
+static DBusMessage *nm_dbus_nm_get_wol_supported (DBusConnection *connection, DBusMessage *message, NMDbusCBData *data)
+{
+ return nm_dbus_nm_get_wol_status (connection, message, data, 1);
+}
+
static DBusMessage *nm_dbus_nm_sleep (DBusConnection *connection, DBusMessage *message, NMDbusCBData *data)
{
NMData *app_data;
@@ -676,6 +780,9 @@
nm_dbus_method_list_add_method (list, "createWirelessNetwork", nm_dbus_nm_create_wireless_n
Re: Sharing connection
Is NAT with two or more wired connections also planned? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Sharing connection
On Mon, 25 Jun 2007 08:01:04 -0400 Dan Williams <[EMAIL PROTECTED]> wrote: > NM probably won't set master (AP) mode at all, for a number of > reasons: Well, it sounds reasonable to set up the ad-hoc mode only. It will do the job anyway. Nice to hear something like this is planned at all! -- Regards, Dawid Wróbel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
