Re: [PATCH 1/2] Add CanWakeUp property to NMDevice
On Wed, 2011-10-12 at 13:22 +0200, Jean Parpaillon wrote:
> From: Jean Parpaillon
So what's the overall architecture here? This is the implementation,
clearly, but what goes into the device's virtual functions like
can_wake_up() and prepare_wake_up()?
Also would be good to pull Matthew Garrett in here; we've had
discussions about WOL/WOWLAN before.
Dan
> ---
> introspection/nm-device.xml |5
> libnm-glib/nm-device.c | 48
> +++
> libnm-glib/nm-device.h |2 +
> src/nm-device-interface.c |7 ++
> src/nm-device-interface.h |2 +
> src/nm-device.c | 23
> src/nm-device.h |4 +++
> 7 files changed, 91 insertions(+), 0 deletions(-)
>
> diff --git a/introspection/nm-device.xml b/introspection/nm-device.xml
> index 5fdda96..2e29bb4 100644
> --- a/introspection/nm-device.xml
> +++ b/introspection/nm-device.xml
> @@ -97,6 +97,11 @@
> The general type of the network device; ie Ethernet, WiFi, etc.
>
>
> +
> +
> +If TRUE, the device can wake up the host when sleeping.
> +
> +
>
>
> value="impl_device_disconnect"/>
> diff --git a/libnm-glib/nm-device.c b/libnm-glib/nm-device.c
> index f06c1e4..9b832d3 100644
> --- a/libnm-glib/nm-device.c
> +++ b/libnm-glib/nm-device.c
> @@ -55,6 +55,7 @@ typedef struct {
> NMDeviceCapabilities capabilities;
> gboolean managed;
> gboolean firmware_missing;
> + gboolean can_wake_up;
> NMIP4Config *ip4_config;
> gboolean got_ip4_config;
> NMDHCP4Config *dhcp4_config;
> @@ -81,6 +82,7 @@ enum {
> PROP_CAPABILITIES,
> PROP_MANAGED,
> PROP_FIRMWARE_MISSING,
> + PROP_CAN_WAKE_UP,
> PROP_IP4_CONFIG,
> PROP_DHCP4_CONFIG,
> PROP_IP6_CONFIG,
> @@ -304,6 +306,7 @@ register_for_property_changed (NMDevice *device)
> { NM_DEVICE_CAPABILITIES, _nm_object_demarshal_generic,
> &priv->capabilities },
> { NM_DEVICE_MANAGED, _nm_object_demarshal_generic,
> &priv->managed },
> { NM_DEVICE_FIRMWARE_MISSING, _nm_object_demarshal_generic,
> &priv->firmware_missing },
> + { NM_DEVICE_CAN_WAKE_UP, _nm_object_demarshal_generic,
> &priv->can_wake_up },
> { NM_DEVICE_IP4_CONFIG, demarshal_ip4_config,
> &priv->ip4_config },
> { NM_DEVICE_DHCP4_CONFIG, demarshal_dhcp4_config,
> &priv->dhcp4_config },
> { NM_DEVICE_IP6_CONFIG, demarshal_ip6_config,
> &priv->ip6_config },
> @@ -452,6 +455,9 @@ get_property (GObject *object,
> case PROP_FIRMWARE_MISSING:
> g_value_set_boolean (value, nm_device_get_firmware_missing
> (device));
> break;
> + case PROP_CAN_WAKE_UP:
> + g_value_set_boolean (value, nm_device_get_can_wake_up (device));
> + break;
> case PROP_IP4_CONFIG:
> g_value_set_object (value, nm_device_get_ip4_config (device));
> break;
> @@ -496,6 +502,9 @@ set_property (GObject *object,
> /* Construct only */
> priv->device_type = g_value_get_uint (value);
> break;
> + case PROP_CAN_WAKE_UP:
> + priv->can_wake_up = g_value_get_boolean (value);
> + break;
> default:
> G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
> break;
> @@ -629,6 +638,19 @@ nm_device_class_init (NMDeviceClass *device_class)
> G_PARAM_READABLE));
>
> /**
> + * NMDevice:can-wake-up:
> + *
> + * When %TRUE indicates the device can be used to wake up the machine.
> + **/
> + g_object_class_install_property
> + (object_class, PROP_CAN_WAKE_UP,
> + g_param_spec_boolean (NM_DEVICE_CAN_WAKE_UP,
> +"CanWakeUp",
> +"Device can WakeUp",
> +FALSE,
> +G_PARAM_READWRITE));
> +
> + /**
>* NMDevice:ip4-config:
>*
>* The #NMIP4Config of the device.
> @@ -1036,6 +1058,32 @@ nm_device_get_firmware_missing (NMDevice *device)
> }
>
> /**
> + * nm_device_get_can_wake_up:
> + * @device: a #NMDevice
> + *
> + * Indicates that the device can be used to wake up the machine
> + *
> + * Returns: %TRUE if the device can be used to wake up the machine.
> + **/
> +gboolean
> +nm_device_get_can_wake_up (NMDevice *device)
> +{
> + NMDevicePrivate *priv;
> +
> + g_return_val_if_fail (NM_IS_DEVICE (device), 0);
> +
> + priv = NM_DEVICE_GET_PRIVATE (device);
> + if (!priv->can_wake_up) {
> + priv->can_wake_up = _nm_object_get_boolean_property (NM_OBJEC
Autoconnect for mobile broadband (was: Re: nm_setting_gsm_get_pin() retuns null)
My pleasure - if only getting rid of bugs was this easy in all software...
Speaking of bugs, I have another open issue in Bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=659228
I've been told that autoconnect is not supported for mobile broadband
yet:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/848164/comments/3
Are there any plans to rectify this?
Thanks,
Anders Feder
On 13-10-2011 01:49, Dan Williams wrote:
On Wed, 2011-10-12 at 05:24 +0200, Anders Feder wrote:
Yes, that did the trick.
I've added the keyring functionality and now have the attached diff.
I've tested it and it works (yay).
How can I get it included in the main source tree?
It's applied, thanks! I did a few cleanups and converted the keyring
calls to by asynchronous, and pushed it to the 0.8 and git master (0.9)
branches. Thanks for fixing this long-standing feature request.
Dan
Thanks,
Anders Feder
On 10-10-2011 23:30, Dan Williams wrote:
On Sun, 2011-10-09 at 17:28 +0200, Anders Feder wrote:
I now have the attached diff. Any chance you can help me understand why
it segfaults when I try running it? Thanks,
Missing trailing G_TYPE_INVALID in gsm_device_added() on the GetAll call
will make dbus-glib overrun the end of the argument list. That's a
marker for the varargs list that tells dbus-glib it can stop processing
arguments. Not sure if that's it but should be fixed.
Any idea where it's crashing? can you get a backtrace when running the
applet in gdb?
Dan
Anders Feder
On 05-10-2011 23:35, Dan Williams wrote:
On Wed, 2011-10-05 at 23:21 +0200, Anders Feder wrote:
Alternatively, can I simply request "SimIdentifier" from unlock_reply()
instead of gsm_device_added()? That way sim_id_reply() won't be invoked
unless unlock_reply() has already completed.
You could chain them together that way, yes, if you moved the stuff from
gsm_device_added() up into unlock_reply() where you get a successful
reply for DeviceIdentifier.
Dan
Anders Feder
On 05-10-2011 22:45, Dan Williams wrote:
On Wed, 2011-10-05 at 22:12 +0200, Anders Feder wrote:
Thanks for that thorough explanation. However, I wonder if there isn't a
race condition in that implementation: if we request all three
properties in gsm_device_added(), can we be certain that we have all of
them once we are in sim_id_reply()? Isn't there a risk that
sim_id_reply() might be called back before unlock_reply()?
Yes, a small risk. This can be alleviated by doing some logic in both
functions and tracking in the 'info' struct whether we've gotten replies
for both the initial modem properties and the initial card properties,
and then only doing the unlock dialog when both of those are true AND
the other stuff I wrote was true, and doing that check from both places.
It just means more variables.
Dan
Anders Feder
On 03-10-2011 23:18, Dan Williams wrote:
On Mon, 2011-10-03 at 14:20 +0200, Anders Feder wrote:
Where would you propose the new code be added?
In the first iteration, I imagine it would work something like this:
If (UnlockRequired)
Get SimIdentifier
If (SimIdentifier is found)
Get PIN for SimIdentifier from keyring
If (PIN is found for SimIdentifier)
Try unlock using saved PIN
While (unlock failed)
Prompt user for new PIN
Try unlock using new PIN
If (unlock succeeded)
Save new PIN for SimIdentifier to keyring
If this works, a similar procedure could be applied for
DeviceIdentifier, if SimIdentifier is not found.
Is this the best approach?
Yeah, that's basically it. So UnlockRequired and DeviceIdentifier are
both properties of the org.freedesktop.ModemManager.Modem interface, and
thus you can retrieve them both in the same D-Bus properties call using
GetAll(). For that, in src/applet-device-gsm.c's gsm_device_added()
function, where it calls the Get() method with UnlockRequired, what you
want to do is call "GetAll" instead and kill the "UnlockRequired"
argument. Then in the unlock_reply() for the dbus_g_proxy_end_call()
you'll do something like:
GHashTable *props = NULL;
if (dbus_g_proxy_end_call (proxy, call,&error,
DBUS_TYPE_G_MAP_OF_VARIANT,&props,
G_TYPE_INVALID)) {
GHashTableIter iter;
const char *prop_name;
GValue *value;
g_hash_table_iter_init (&iter, props);
while (g_hash_table_iter_next (&iter, (gpointer)&prop_name,
(gpointer)&value)) {
if ((strcmp (prop_name, "UnlockRequired") == 0)&&
G_VALUE_HOLDS_STRING (value)) {
g_free (info->unlock_required);
info->unlock_required = parse_unlock_required (value);
}
if ((strcmp (prop_name, "DeviceIdentifier") == 0)&&
G_VALUE_HOLDS_STRING (value)) {
g_free (info->devid);
info->dev
Re: Missing SIM PIN dialog after nm update
On Tue, 2011-10-11 at 09:38 +0200, Arne Caspari wrote: > Am Mon, 10 Oct 2011 16:31:06 +0100 > schrieb Sérgio Basto : > > > I do > > killall modem-manager > > > > Sfter some seconds modem was detected and "SIM PIN dialog" was > > appears. > > Unfortunately, this does not work for me. No matter if I unplug/plug > the modem, kill modem-manager or whatever action I do, there never is a > PIN dialog. > > I ran modem-manager and network-manager in debug mode; logs are here: > > modem-manager: http://pastebin.com/BmpU9wnu > network-manager: http://pastebin.com/7uTS8TE8 > > I also tried to send the PIN to the modem via "chat" directly, which > had some effect since the light on the modem went from red to green but > network manager still complains about a missing PIN in the logs and > does not connect. Run this command: dbus-send --system --print-reply --dest=org.freedesktop.ModemManager /org/freedesktop/ModemManager/Modems/0 org.freedesktop.DBus.Properties.GetAll string:"org.freedesktop.ModemManager.Modem" what does the "UnlockRequired" property say? Also, are you running nm-applet? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trouble with ICS (was Re: Ad-hoc network: cannot ping other machine)
On Tue, 2011-10-11 at 15:03 -0500, Patrick McMunn wrote: > As far as I know, dhcpcd has always been capable of working as a > daemon. I guess NM just doesn't like it that way. I had it starting up > at boot and daemonizing per tutorials I had followed, but then again > the tutorials I had followed were aimed at using Gentoo's networking > structure - not tools like NM. > > So I disabled dhcpcd from starting at boot. Now everything works > perfectly. I even have WPA encryption working over ad-hoc, and until > recently I had been led to believe that was impossible. Hmm, this is something I guess we need to look into, since NM would need some adjustment to support this. I guess we'd also need to know if dhcpcd was in this configuration or not, since that affects how NM handles the process exiting. > The only loose end is with ifnet. I had to disable it to get NM to > behave itself properly, so I'll report those issues to ifnet's > upstream. Yeah, the Gentoo people are pretty good about these sorts of things. It might come back to this list eventually though :) Dan > Thank you very much for your help, Dan. > > >> Huh. Looks like dhcpcd has changed and now sends commands to a daemon? > >> That's fine, but the code doesn't expect that; it expects that the DHCP > >> process it starts will continue until NM tells it to quit. Also looks > >> like in this configuration there's no way to get the DHCP options back > >> to NM, actually. So the main problem is that dhcpcd is acting in a way > >> that NM doesn't expect here, which hasn't been the case with dhcpcd > >> before. > >> > >> Dan > ___ > 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_setting_gsm_get_pin() retuns null
On Wed, 2011-10-12 at 05:24 +0200, Anders Feder wrote:
> Yes, that did the trick.
>
> I've added the keyring functionality and now have the attached diff.
> I've tested it and it works (yay).
>
> How can I get it included in the main source tree?
It's applied, thanks! I did a few cleanups and converted the keyring
calls to by asynchronous, and pushed it to the 0.8 and git master (0.9)
branches. Thanks for fixing this long-standing feature request.
Dan
> Thanks,
> Anders Feder
>
> On 10-10-2011 23:30, Dan Williams wrote:
> > On Sun, 2011-10-09 at 17:28 +0200, Anders Feder wrote:
> >> I now have the attached diff. Any chance you can help me understand why
> >> it segfaults when I try running it? Thanks,
> > Missing trailing G_TYPE_INVALID in gsm_device_added() on the GetAll call
> > will make dbus-glib overrun the end of the argument list. That's a
> > marker for the varargs list that tells dbus-glib it can stop processing
> > arguments. Not sure if that's it but should be fixed.
> >
> > Any idea where it's crashing? can you get a backtrace when running the
> > applet in gdb?
> >
> > Dan
> >
> >> Anders Feder
> >>
> >> On 05-10-2011 23:35, Dan Williams wrote:
> >>> On Wed, 2011-10-05 at 23:21 +0200, Anders Feder wrote:
> Alternatively, can I simply request "SimIdentifier" from unlock_reply()
> instead of gsm_device_added()? That way sim_id_reply() won't be invoked
> unless unlock_reply() has already completed.
> >>> You could chain them together that way, yes, if you moved the stuff from
> >>> gsm_device_added() up into unlock_reply() where you get a successful
> >>> reply for DeviceIdentifier.
> >>>
> >>> Dan
> >>>
> Anders Feder
>
> On 05-10-2011 22:45, Dan Williams wrote:
> > On Wed, 2011-10-05 at 22:12 +0200, Anders Feder wrote:
> >> Thanks for that thorough explanation. However, I wonder if there isn't
> >> a
> >> race condition in that implementation: if we request all three
> >> properties in gsm_device_added(), can we be certain that we have all of
> >> them once we are in sim_id_reply()? Isn't there a risk that
> >> sim_id_reply() might be called back before unlock_reply()?
> > Yes, a small risk. This can be alleviated by doing some logic in both
> > functions and tracking in the 'info' struct whether we've gotten replies
> > for both the initial modem properties and the initial card properties,
> > and then only doing the unlock dialog when both of those are true AND
> > the other stuff I wrote was true, and doing that check from both places.
> > It just means more variables.
> >
> > Dan
> >
> >> Anders Feder
> >>
> >> On 03-10-2011 23:18, Dan Williams wrote:
> >>> On Mon, 2011-10-03 at 14:20 +0200, Anders Feder wrote:
> Where would you propose the new code be added?
>
> In the first iteration, I imagine it would work something like this:
>
> If (UnlockRequired)
> Get SimIdentifier
> If (SimIdentifier is found)
> Get PIN for SimIdentifier from keyring
> If (PIN is found for SimIdentifier)
> Try unlock using saved PIN
> While (unlock failed)
> Prompt user for new PIN
> Try unlock using new PIN
> If (unlock succeeded)
> Save new PIN for SimIdentifier to keyring
>
> If this works, a similar procedure could be applied for
> DeviceIdentifier, if SimIdentifier is not found.
>
> Is this the best approach?
> >>> Yeah, that's basically it. So UnlockRequired and DeviceIdentifier are
> >>> both properties of the org.freedesktop.ModemManager.Modem interface,
> >>> and
> >>> thus you can retrieve them both in the same D-Bus properties call
> >>> using
> >>> GetAll(). For that, in src/applet-device-gsm.c's gsm_device_added()
> >>> function, where it calls the Get() method with UnlockRequired, what
> >>> you
> >>> want to do is call "GetAll" instead and kill the "UnlockRequired"
> >>> argument. Then in the unlock_reply() for the dbus_g_proxy_end_call()
> >>> you'll do something like:
> >>>
> >>> GHashTable *props = NULL;
> >>>
> >>> if (dbus_g_proxy_end_call (proxy, call,&error,
> >>>DBUS_TYPE_G_MAP_OF_VARIANT,&props,
> >>>G_TYPE_INVALID)) {
> >>> GHashTableIter iter;
> >>> const char *prop_name;
> >>> GValue *value;
> >>>
> >>> g_hash_table_iter_init (&iter, props);
> >>> while (g_hash_table_iter_next (&iter, (gpointer)&prop_name,
> >>> (gpointer)&value)) {
> >>> if ((strcmp (prop_name, "UnlockRequired") == 0)&&
> >>> G_VAL
Re: [PATCH 8/9] ifcfg: Ignore higher level configs for bonding slaves
On Tue, 2011-10-11 at 23:18 +0200, Thomas Graf wrote: > On Tue, 2011-10-11 at 14:32 -0500, Dan Williams wrote: > > On Tue, 2011-10-11 at 16:23 +0200, Thomas Graf wrote: > > > > I am very much open to a better implementation regarding this and I > > > think your proposal is much cleaner. > > > > > > To make sure I understood you properly: You propose to replace any > > > existing IP config with a "IP disabled"-config before entering stage1 > > > while activating a bonding slave. Right? > > > > Well, I'd assume the bond's IPv4 config is already disabled? Or do we > > allow separate IP configs on the bond slaves in addition to the master? > > I've heard of this for bridging but not necessarily for bonding. > > Nope, that should be disallowed. This is basically what the patch does, > it adds a "disabled" ip config to the settings and skip any ip config > provided. > > > But anyway, there are two choices if the bond has an IPv4 config: either > > that's invalid and we don't let the connection pass validation (in > > libnm-util/nm-setting-ip4-config.c's verify() method), or having this is > > valid and we should deal with it now or in the future. > > I currently chose to ignore ip config to keep the required changes when > adding an interface to a bond and remove it again trivial. I am also OK > with enforcing that no ip configuration is allowed at all. I'd rather enforce connection validity with verify() and warn the user if any IP config was found in the file in the ifcfg plugin. > > Right. If the config is invalid and we don't allow this, then we make > > sure the connection fails validation in verify() in > > nm-setting-ip4-config.c, and then we make sure to document this so that > > the UI knows it's not possible. This is the same thing we do for PPP, > > where 99% of the time as a client you cannot set the IP address, because > > it's provided for you by upstream and it would be pointless to set one > > of your own. Same thing for bonding; the UI should just disable the > > options. > > OK but we still need the dummy ip config. I'd much rather have the > settings specify whether to do IP respectively fall back to DHCP instead > having to add special cases everywhere to add exceptions. I'm not sure why we need a dummy config; we'd only need one check for it, and that's in stage3 when we start IP config, right? In that case we simply skip the IPv4 config like happens when the config is disabled. In the end I don't have strong feelings on this; but we should certainly warn in ifcfg-rh if an IPv4 config is present in the ifcfg file. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] remove AP always on device disconnect
On Wed, 2011-10-12 at 10:11 +0200, Ludwig Nussel wrote: > Dan Williams wrote: > > On Tue, 2011-10-11 at 16:51 +0200, Ludwig Nussel wrote: > >> Dan Williams wrote: > >>> On Fri, 2011-10-07 at 15:21 +0200, Ludwig Nussel wrote: > This avoids immediate reconnect after link timeout to an AP that may no > longer exist (down/out of range). This also avoids needless prompting > for a password for the no longer existing AP. > >>> > >>> This could work, but I think we need to restrict the AP removal to cases > >>> where the supplicant times out after we've already been successfully > >>> connected, which is basically the case you're talking about. For > >>> example, in the case of an explicit disconnect (via the menu item or > >>> D-Bus call) we'd remove a perfectly good AP and might not find it again > >>> until the next scan happened a few minutes after the disconnect. > >> > >> Yes. Is there a way to find out whether the request was triggered by > >> an event from wpa_supplicant or by the user? > >> > >>> Maybe instead of doing it during deactivate, remove the AP in > >>> supplicant_connection_timeout_cb() right before moving to the > >>> DISCONNECTED state? > >> > >> Doesn't that callback trigger too late? Ie after NM has already > >> prompted for a new password? > > > > That function *should* be the place where disconnects after successful > > connection are handled. But yeah, the code is wrong in > > supplicant_iface_state_cb() (probably from a6f7dfff233de118) so that > > case doesn't get hit correctly. I'll fix that, but in the end, here's > > what should happen: > > I think it's been that way before and intentionally so. To handle the > first case you listed below. > > > 1) disconnect during connection process: if we can tell that the > > password is wrong (need help from wpa_supplicant here) ask for new > > secrets; otherwise if we've connected to this SSID before (ie, timestamp > >> 0) then don't ask for secrets, fail with an error code that the > > secrets might be wrong. If we haven't connected successfully before, > > then possibly ask for secrets. > > Sounds good. That's where supplicant_iface_state_cb() is involved I think. > > > 2) disconnect after successful connect: start a timer and wait for the > > supplicant to reassociate; it that doesn't happen, then when the timer > > fires, deactivate the device and mark the connection as "invalid" for a > > short period of time (at least until new scan results come in) > > Yes. That's what I wanted to achieve, ie prevent reconnect to a no longer > existing AP. From my limited experiments I think this case happens when > the AP gets switched off, goes out of range or kicks the client out. > That's where link_timeout_cb() fires. > > Besides the AP vanishing from the list on explicit user disconnect do you > see any other bad side effect of my patch? The deadline for openSUSE > 12.1 is near. So even if the patch is not acceptable for upstream I'd > like to add it to our package anyways and accept that minor drawback to > avoid users whining about the PK popups. The problem I had was that it unconditionally removes the AP from the list on deactivate, which can happen for any number of reasons, only one of which is loss of sync with the AP. Any of the 802.11 Reason codes (802.11-2007 section 7.3.1.7) are reasons why this could happen; so do we really want to remove the AP from the internal list and wait for the next scan when the disconnect happened due to inactivity, invalid PSK, etc. Removing the AP from link_timeout_cb() is one way to restrict the cases where the AP would be removed. Even better would be to get better status codes from the supplicant (or kernel via nl80211!) and only remove the AP from the list when the driver reported generic disconnect, or reason codes 3 or 8, for example. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for direct connection without cross cable / Run Avahi Zeroconfig Services
Hi Sven, On 10/11/2011 07:26 PM, Sven Nielsen wrote: I am not actually sure where the problem is here? My NM can do this without any problems (0.8.1 on Ubuntu Maverick), and I use it all the time. In the nm applet just go to the tab for wired connections, edit your eth0 (or whatever connection), ipv4 settings, and choose "shared with other machines" (my ui is german, so cannot state the exact name of that option). Thanks for this clue, I was wondering about that option, but thought it was for internet connection sharing, so I didn't tried it. Now that I tried it (It's called "Shared to other computers" in the method option), it's working. Yay! :) All the best. -arief ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for direct connection without cross cable / Run Avahi Zeroconfig Services
Hi Daniel, On 10/11/2011 03:35 PM, Daniel Yek wrote: > +ACs-AD4 I noticed that windows can setup networking > +ACs-AD4 to a direct-connected ... device > +ACs-AD4 (tested ... with network-drives, such as WD MyBook World) > +ACs-AD4 with ... straight ... ethernet cable. > > Hi, > > Could you make sure that you installed and ran Avahi? > > I think Avahi could enable this same easy, direct, connection > with your WD MyBook World. > > I don't have a way to test it now, but > I am interested to find out if you have luck with Avahi. I have Avahi installed and it's not working with it, but I didn't do any configuration (it should not need any, right?) +AKA- > WD MyBook World and Windows implemented > zeroconfig networking (with address range: 169.254.x.x/255.255.0.0), > which make the direct connection works. Yep, on Windows I can confirm they always setup with 169.254.+ACo- addresses. > Without Avahi, it is possible that a Linux command such as this: > +ACs-ACM ifconfig address 169.254.1.23 eth0 > > could enable HTTP connection to WD MyBook World. What I just did is setting up a Wired connection with Method: Shared to other computers in NM, and it's working. Thanks for the reply and the clues, appreciated. All the best. -arief ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for direct connection without cross cable
On 10/11/2011 04:52 AM, Dan Williams wrote: Most network cards have supported direct vs. crossover detection for a while, so that shouldn't be a problem. Ok, just tested this again with Method: Shared to other computers. And it's working :) Thanks for the reply, Dan. All the best. -arief ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/2] Add CanWakeUp property to NMDevice
From: Jean Parpaillon
---
introspection/nm-device.xml |5
libnm-glib/nm-device.c | 48 +++
libnm-glib/nm-device.h |2 +
src/nm-device-interface.c |7 ++
src/nm-device-interface.h |2 +
src/nm-device.c | 23
src/nm-device.h |4 +++
7 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/introspection/nm-device.xml b/introspection/nm-device.xml
index 5fdda96..2e29bb4 100644
--- a/introspection/nm-device.xml
+++ b/introspection/nm-device.xml
@@ -97,6 +97,11 @@
The general type of the network device; ie Ethernet, WiFi, etc.
+
+
+If TRUE, the device can wake up the host when sleeping.
+
+
diff --git a/libnm-glib/nm-device.c b/libnm-glib/nm-device.c
index f06c1e4..9b832d3 100644
--- a/libnm-glib/nm-device.c
+++ b/libnm-glib/nm-device.c
@@ -55,6 +55,7 @@ typedef struct {
NMDeviceCapabilities capabilities;
gboolean managed;
gboolean firmware_missing;
+ gboolean can_wake_up;
NMIP4Config *ip4_config;
gboolean got_ip4_config;
NMDHCP4Config *dhcp4_config;
@@ -81,6 +82,7 @@ enum {
PROP_CAPABILITIES,
PROP_MANAGED,
PROP_FIRMWARE_MISSING,
+ PROP_CAN_WAKE_UP,
PROP_IP4_CONFIG,
PROP_DHCP4_CONFIG,
PROP_IP6_CONFIG,
@@ -304,6 +306,7 @@ register_for_property_changed (NMDevice *device)
{ NM_DEVICE_CAPABILITIES, _nm_object_demarshal_generic,
&priv->capabilities },
{ NM_DEVICE_MANAGED, _nm_object_demarshal_generic,
&priv->managed },
{ NM_DEVICE_FIRMWARE_MISSING, _nm_object_demarshal_generic,
&priv->firmware_missing },
+ { NM_DEVICE_CAN_WAKE_UP, _nm_object_demarshal_generic,
&priv->can_wake_up },
{ NM_DEVICE_IP4_CONFIG, demarshal_ip4_config,
&priv->ip4_config },
{ NM_DEVICE_DHCP4_CONFIG, demarshal_dhcp4_config,
&priv->dhcp4_config },
{ NM_DEVICE_IP6_CONFIG, demarshal_ip6_config,
&priv->ip6_config },
@@ -452,6 +455,9 @@ get_property (GObject *object,
case PROP_FIRMWARE_MISSING:
g_value_set_boolean (value, nm_device_get_firmware_missing
(device));
break;
+ case PROP_CAN_WAKE_UP:
+ g_value_set_boolean (value, nm_device_get_can_wake_up (device));
+ break;
case PROP_IP4_CONFIG:
g_value_set_object (value, nm_device_get_ip4_config (device));
break;
@@ -496,6 +502,9 @@ set_property (GObject *object,
/* Construct only */
priv->device_type = g_value_get_uint (value);
break;
+ case PROP_CAN_WAKE_UP:
+ priv->can_wake_up = g_value_get_boolean (value);
+ break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
@@ -629,6 +638,19 @@ nm_device_class_init (NMDeviceClass *device_class)
G_PARAM_READABLE));
/**
+* NMDevice:can-wake-up:
+*
+* When %TRUE indicates the device can be used to wake up the machine.
+**/
+ g_object_class_install_property
+ (object_class, PROP_CAN_WAKE_UP,
+g_param_spec_boolean (NM_DEVICE_CAN_WAKE_UP,
+ "CanWakeUp",
+ "Device can WakeUp",
+ FALSE,
+ G_PARAM_READWRITE));
+
+ /**
* NMDevice:ip4-config:
*
* The #NMIP4Config of the device.
@@ -1036,6 +1058,32 @@ nm_device_get_firmware_missing (NMDevice *device)
}
/**
+ * nm_device_get_can_wake_up:
+ * @device: a #NMDevice
+ *
+ * Indicates that the device can be used to wake up the machine
+ *
+ * Returns: %TRUE if the device can be used to wake up the machine.
+ **/
+gboolean
+nm_device_get_can_wake_up (NMDevice *device)
+{
+ NMDevicePrivate *priv;
+
+ g_return_val_if_fail (NM_IS_DEVICE (device), 0);
+
+ priv = NM_DEVICE_GET_PRIVATE (device);
+ if (!priv->can_wake_up) {
+ priv->can_wake_up = _nm_object_get_boolean_property (NM_OBJECT
(device),
+
NM_DBUS_INTERFACE_DEVICE,
+
"CanWakeUp",
+
NULL);
+ }
+
+ return priv->can_wake_up;
+}
+
+/**
* nm_device_ge
[PATCH 2/2] Add nm_device_prepare_wake_up function to MNDevice, called when going to sleep and device is marked as 'CanWakeUp'
From: Jean Parpaillon
---
src/nm-device.c | 20 ++--
src/nm-device.h |1 +
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/nm-device.c b/src/nm-device.c
index 31a73c1..fdd5627 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -167,6 +167,8 @@ static gboolean can_assume_connections (NMDeviceInterface
*device);
static void nm_device_activate_schedule_stage5_ip_config_commit (NMDevice
*self, int family);
+static void nm_device_prepare_wake_up (NMDevice *dev);
+
static void nm_device_take_down (NMDevice *dev, gboolean wait,
NMDeviceStateReason reason);
static gboolean nm_device_bring_up (NMDevice *self, gboolean block, gboolean
*no_firmware);
@@ -3296,6 +3298,17 @@ nm_device_bring_up (NMDevice *self, gboolean block,
gboolean *no_firmware)
}
static void
+nm_device_prepare_wake_up (NMDevice *self)
+{
+ g_return_if_fail (NM_IS_DEVICE (self));
+
+ nm_log_info (LOGD_DEVICE, "(%s): preparing for waking up...");
+
+ if (NM_DEVICE_GET_CLASS (self)->prepare_wake_up)
+ NM_DEVICE_GET_CLASS (self)->prepare_wake_up (self);
+}
+
+static void
nm_device_take_down (NMDevice *self, gboolean block, NMDeviceStateReason
reason)
{
g_return_if_fail (NM_IS_DEVICE (self));
@@ -3899,8 +3912,11 @@ nm_device_state_changed (NMDevice *device,
switch (state) {
case NM_DEVICE_STATE_UNMANAGED:
nm_device_set_firmware_missing (device, FALSE);
- if (old_state > NM_DEVICE_STATE_UNMANAGED)
- nm_device_take_down (device, TRUE, reason);
+ if (old_state > NM_DEVICE_STATE_UNMANAGED) {
+ if (priv->can_wake_up)
+ nm_device_prepare_wake_up (device);
+ else
+ nm_device_take_down (device, TRUE, reason);
break;
case NM_DEVICE_STATE_UNAVAILABLE:
if (old_state == NM_DEVICE_STATE_UNMANAGED ||
priv->firmware_missing) {
diff --git a/src/nm-device.h b/src/nm-device.h
index b7273de..fb450bf 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -70,6 +70,7 @@ typedef struct {
gboolean(*is_up) (NMDevice *self);
gboolean(*bring_up) (NMDevice *self);
void(*take_down) (NMDevice *self);
+ void(*prepare_wake_up) (NMDevice *self);
void(* update_hw_address) (NMDevice *self);
void(* update_permanent_hw_address) (NMDevice *self);
--
1.7.6.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9 asks for PK auth without need
Dan Williams wrote: > [...] > But, we *also* can make the change for lock/unlock button in the secrets > dialog so that we don't request PK auth again unless the button gets > pressed. These two things should fix most occurrences of this, right? Yes. > One other thing to think about: creating a new wifi network for > sharing :) Not a common action, but this one actually requires *two* PK > requests: one for checking whether you are allowed to share via wifi, > and the second to create the connection. IIUC PK git head recently gained a feature where one privilege automatically authorizes another. That could be of help here. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] remove AP always on device disconnect
Dan Williams wrote: > On Tue, 2011-10-11 at 16:51 +0200, Ludwig Nussel wrote: >> Dan Williams wrote: >>> On Fri, 2011-10-07 at 15:21 +0200, Ludwig Nussel wrote: This avoids immediate reconnect after link timeout to an AP that may no longer exist (down/out of range). This also avoids needless prompting for a password for the no longer existing AP. >>> >>> This could work, but I think we need to restrict the AP removal to cases >>> where the supplicant times out after we've already been successfully >>> connected, which is basically the case you're talking about. For >>> example, in the case of an explicit disconnect (via the menu item or >>> D-Bus call) we'd remove a perfectly good AP and might not find it again >>> until the next scan happened a few minutes after the disconnect. >> >> Yes. Is there a way to find out whether the request was triggered by >> an event from wpa_supplicant or by the user? >> >>> Maybe instead of doing it during deactivate, remove the AP in >>> supplicant_connection_timeout_cb() right before moving to the >>> DISCONNECTED state? >> >> Doesn't that callback trigger too late? Ie after NM has already >> prompted for a new password? > > That function *should* be the place where disconnects after successful > connection are handled. But yeah, the code is wrong in > supplicant_iface_state_cb() (probably from a6f7dfff233de118) so that > case doesn't get hit correctly. I'll fix that, but in the end, here's > what should happen: I think it's been that way before and intentionally so. To handle the first case you listed below. > 1) disconnect during connection process: if we can tell that the > password is wrong (need help from wpa_supplicant here) ask for new > secrets; otherwise if we've connected to this SSID before (ie, timestamp >> 0) then don't ask for secrets, fail with an error code that the > secrets might be wrong. If we haven't connected successfully before, > then possibly ask for secrets. Sounds good. That's where supplicant_iface_state_cb() is involved I think. > 2) disconnect after successful connect: start a timer and wait for the > supplicant to reassociate; it that doesn't happen, then when the timer > fires, deactivate the device and mark the connection as "invalid" for a > short period of time (at least until new scan results come in) Yes. That's what I wanted to achieve, ie prevent reconnect to a no longer existing AP. From my limited experiments I think this case happens when the AP gets switched off, goes out of range or kicks the client out. That's where link_timeout_cb() fires. Besides the AP vanishing from the list on explicit user disconnect do you see any other bad side effect of my patch? The deadline for openSUSE 12.1 is near. So even if the patch is not acceptable for upstream I'd like to add it to our package anyways and accept that minor drawback to avoid users whining about the PK popups. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
