On Mon, 2016-06-27 at 12:17 +0000, Avichal Agarwal wrote: > From d05b55b745eb8c8a01c798f9e649983b9f6da0a1 Mon Sep 17 00:00:00 > 2001 > From: Avichal Agarwal <avichal.a@xxxxxxxxxxx> > Date: Mon, 27 Jun 2016 17:16:31 +0530 > Subject: [PATCH] disconnected notification to dbus on intreface up > > This patch will send (disconnected) state changed signal to dbus on > disable and enable the interface.Before this patch the interface > state > received by dbus was inactive , which should be disconnected. > commands:ifconfig (interface ) down/up It seems we had a long discussion about this back in 2011: "dbus: Do Not Coalesce State Changed Signals" That thread didn't come to any specific conclusion, except that clients already have to handle arbitrary state changes. Since clients should not depend on any specific signal ordering from the supplicant since that's not guaranteed in the supplicant API that I''m aware of, there's not much of a point to flushing the state change immediately. Maybe it's time to restart that discussion though; I can't recall any hard technical reason to not flush the State property except for the one above. Dan > Signed-off-by: Avichal Agarwal <avichal.a@xxxxxxxxxxx> > --- > wpa_supplicant/dbus/dbus_new.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/wpa_supplicant/dbus/dbus_new.c > b/wpa_supplicant/dbus/dbus_new.c > index 0263b2c..e3a9fd8 100644 > --- a/wpa_supplicant/dbus/dbus_new.c > +++ b/wpa_supplicant/dbus/dbus_new.c > @@ -1982,6 +1982,7 @@ void wpas_dbus_signal_prop_changed(struct > wpa_supplicant *wpa_s, > break; > case WPAS_DBUS_PROP_STATE: > prop = "State"; > + flush = TRUE; > break; > case WPAS_DBUS_PROP_CURRENT_BSS: > prop = "CurrentBSS"; _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
