Re: Executing commands at home and elsewhere

[Darren Albers]

On 6/25/07, Kjetil Kjernsmo <[EMAIL PROTECTED]> wrote:
> Hi and thanks for the quick reply!
>
> I was meaning to start working on it, but the Real World came in and
> interferred, anyway, here we go. :-)
>
> On Tuesday 19 June 2007, Darren Albers wrote:
> > On 6/19/07, Dan Williams <[EMAIL PROTECTED]> wrote:
>
> > > There's a tool called NetworkManagerDispatcher that calls scripts
> > > in /etc/NetworkManager/dispatcher.d when connections go up and down
> > > that most people use for this sort of thing, actually.
>
> > Here is one list (Though it is somewhat short since I haven't seen
> > any posted lately):
> > http://www.darrenalbers.net/wiki/index.php?title=NetworkManagerScript
> >s
> >
> > I think what you want is to use something whereami in conjunction
> > with NetworkManagerDispatcher.
>
> Great stuff, this is what I'm looking for, for sure.
>
> whereami seems to have everything I have looked for in terms of
> determining where I am. So, what remains is just executing scripts
> depending on the location.
>
> NetworkManagerDispatcher will only execute the scripts in the first
> level /etc/NetworkManager/dispatcher.d directory, right, not descend
> into subdirs?
>
> So, I was thinking about a setup similar to the Apache 2 setup on my
> box, i.e. create /etc/NetworkManager/dispatcher.d/scripts-available
> and /etc/NetworkManager/dispatcher.d/scripts-enabled and in the latter
> again subdirs for each of the locations, given the same names as in the
> whereami config, which would symlink to the actual scripts to be
> launched at each location
> in /etc/NetworkManager/dispatcher.d/scripts-available
>
> This would allow for relatively straightforward setups in the supposedly
> common case that there are several actions that would be in common for
> different locations, but not all.
>
> Does that sound like a reasonable approach?
>
> Kjetil
> --
> Kjetil Kjernsmo
> Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer
> [EMAIL PROTECTED]
> Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
> ___


I vaguely remember that Dispatcher.d doesn't support symlinks, but it
does support calling other scripts from the script itself so something
like:
if [ $2 == "up" ]; then
/etc/init.d/whereami restart
fi


All you are doing is telling whereami to run when the interface comes
up and letting it handle the rest.  It has been a LONG time since I
have used whereami so any specifics of it are long forgotten but I
remember using it to handle my NFS mounts based on the location I was
visiting.  I am trying to remember how it knew that the network had
changed but whereami may have handled that for me automatically
If I get some time when I get home I will take a look at whereami's
man pages.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Executing commands at home and elsewhere

[Kjetil Kjernsmo]

Hi and thanks for the quick reply!

I was meaning to start working on it, but the Real World came in and 
interferred, anyway, here we go. :-)

On Tuesday 19 June 2007, Darren Albers wrote:
> On 6/19/07, Dan Williams <[EMAIL PROTECTED]> wrote:

> > There's a tool called NetworkManagerDispatcher that calls scripts
> > in /etc/NetworkManager/dispatcher.d when connections go up and down
> > that most people use for this sort of thing, actually. 

> Here is one list (Though it is somewhat short since I haven't seen
> any posted lately):
> http://www.darrenalbers.net/wiki/index.php?title=NetworkManagerScript
>s
>
> I think what you want is to use something whereami in conjunction
> with NetworkManagerDispatcher.

Great stuff, this is what I'm looking for, for sure. 

whereami seems to have everything I have looked for in terms of 
determining where I am. So, what remains is just executing scripts 
depending on the location. 

NetworkManagerDispatcher will only execute the scripts in the first 
level /etc/NetworkManager/dispatcher.d directory, right, not descend 
into subdirs?

So, I was thinking about a setup similar to the Apache 2 setup on my 
box, i.e. create /etc/NetworkManager/dispatcher.d/scripts-available
and /etc/NetworkManager/dispatcher.d/scripts-enabled and in the latter 
again subdirs for each of the locations, given the same names as in the 
whereami config, which would symlink to the actual scripts to be 
launched at each location 
in /etc/NetworkManager/dispatcher.d/scripts-available

This would allow for relatively straightforward setups in the supposedly 
common case that there are several actions that would be in common for 
different locations, but not all. 

Does that sound like a reasonable approach?

Kjetil
-- 
Kjetil Kjernsmo
Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer
[EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, dragoran <[EMAIL PROTECTED]> wrote:




On 6/25/07, dragoran <[EMAIL PROTECTED]> wrote:
>
> here again with some cleanups.
> btw the new fdi file seems not to work:
> there is no ipw_killswitch under computer for me...
> any idea why?
>
> new one the same but fixed 2 memory leaks. (should be leakfree now)

forgot one to free hal_ctx ...
#include 
#include 
#include 
#include 

static LibHalContext *hal_ctx;

int main(int argc,char** argv) {

	DBusError error;

	char *iface;
	int i,j,k;
	int found=0;
	char kill_status;
	char **udis;
	char **ifaces;
	int num_udis,num_ifaces;
	FILE *fd;
	char *path;
	char ipw[3][8]={"ipw2100","ipw2200","ipw3945"};
	int ret=-1;

	if(argc==1 || argc > 3) {
		fprintf (stderr, "Usage: ipwWirelessCtl [getrfkill] [setrfkill [1|0]]\n");
		return -1;	
	}

	dbus_error_init (&error);

	if ((hal_ctx = libhal_ctx_new ()) == NULL) {
		fprintf (stderr, "error: libhal_ctx_new\n");
		return -1;
	}

	if (!libhal_ctx_set_dbus_connection (hal_ctx, dbus_bus_get (DBUS_BUS_SYSTEM, &error))) {
		fprintf (stderr, "error: libhal_ctx_set_dbus_connection: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}

	if (!libhal_ctx_init (hal_ctx, &error)) {
		fprintf (stderr, "error: libhal_ctx_init: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}


	if(argc==2 && strcmp("getrfkill",argv[1])==0) {
		
		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (ifaces);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"r"))==NULL) return -1;
	kill_status=fgetc(fd);
	fclose(fd);
	g_free(path);

	switch(kill_status) {
		case '1':
		case '2':
		case '3':
			ret=1;
		break;
	}

	libhal_free_string(iface);
}

libhal_free_string_array (ifaces);

			}
			
			libhal_free_string_array (udis);			
			
		}
		
		if(found && ret!=1) ret=0;
	
	}

	if(argc==3 && strcmp("setrfkill",argv[1])==0 && (atoi(argv[2])==0 || atoi(argv[2])==1)) {

		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (ifaces);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"w"))==NULL) return -1;
	fputc(argv[2][0],fd);
	fclose(fd);
	g_free(path);

	libhal_free_string(iface);
}

libhal_free_string_array (ifaces);

			}
			
			libhal_free_string_array (udis);

		}
		
		if(found) ret=0;
	
	}

	libhal_ctx_free (hal_ctx);

	if (dbus_error_is_set (&error)) {
		fprintf (stderr, "error: %s: %s\n", error.name, error.message);
		dbus_error_free (&error);
		return -1;
	}

	return ret;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, dragoran <[EMAIL PROTECTED]> wrote:


here again with some cleanups.
btw the new fdi file seems not to work:
there is no ipw_killswitch under computer for me...
any idea why?

new one the same but fixed 2 memory leaks. (should be leakfree now)
#include 
#include 
#include 
#include 

static LibHalContext *hal_ctx;

int main(int argc,char** argv) {

	DBusError error;

	char *iface;
	int i,j,k;
	int found=0;
	char kill_status;
	char **udis;
	char **ifaces;
	int num_udis,num_ifaces;
	FILE *fd;
	char *path;
	char ipw[3][8]={"ipw2100","ipw2200","ipw3945"};
	int ret=-1;

	if(argc==1 || argc > 3) {
		fprintf (stderr, "Usage: ipwWirelessCtl [getrfkill] [setrfkill [1|0]]\n");
		return -1;	
	}

	dbus_error_init (&error);

	if ((hal_ctx = libhal_ctx_new ()) == NULL) {
		fprintf (stderr, "error: libhal_ctx_new\n");
		return -1;
	}

	if (!libhal_ctx_set_dbus_connection (hal_ctx, dbus_bus_get (DBUS_BUS_SYSTEM, &error))) {
		fprintf (stderr, "error: libhal_ctx_set_dbus_connection: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}

	if (!libhal_ctx_init (hal_ctx, &error)) {
		fprintf (stderr, "error: libhal_ctx_init: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}


	if(argc==2 && strcmp("getrfkill",argv[1])==0) {
		
		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (ifaces);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"r"))==NULL) return -1;
	kill_status=fgetc(fd);
	fclose(fd);
	g_free(path);

	switch(kill_status) {
		case '1':
		case '2':
		case '3':
			ret=1;
		break;
	}

	libhal_free_string(iface);
}

libhal_free_string_array (ifaces);

			}
			
			libhal_free_string_array (udis);			
			
		}
		
		if(found && ret!=1) ret=0;
	
	}

	if(argc==3 && strcmp("setrfkill",argv[1])==0 && (atoi(argv[2])==0 || atoi(argv[2])==1)) {

		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (ifaces);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"w"))==NULL) return -1;
	fputc(argv[2][0],fd);
	fclose(fd);
	g_free(path);

	libhal_free_string(iface);
}

libhal_free_string_array (ifaces);

			}
			
			libhal_free_string_array (udis);

		}
		
		if(found) ret=0;
	
	}

	if (dbus_error_is_set (&error)) {
		fprintf (stderr, "error: %s: %s\n", error.name, error.message);
		dbus_error_free (&error);
		return -1;
	}

	return ret;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[Larry Finger]

dragoran wrote:
> 
> 
> On 6/25/07, *yelo_3* <[EMAIL PROTECTED] > wrote:
> 
> 
> ok
> 
> anyway sorry but why did they implement a hardware kill that cannot
> be "revoked" using software? I don't find the use case of this
> 
> 
> dunno but thats how the cards where designed...

My notebook has a slide switch for rfkill/radio disable. No software can move 
that switch with the 
hardware available.

Larry
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

thank you!

- Messaggio originale -
Da: Larry Finger <[EMAIL PROTECTED]>
A: dragoran <[EMAIL PROTECTED]>
Cc: yelo_3 <[EMAIL PROTECTED]>; network manager 
; Bastien Nocera <[EMAIL PROTECTED]>
Inviato: Lunedì 25 giugno 2007, 21:15:37
Oggetto: Re: ipw srcipts for hal

dragoran wrote:
> 
> 
> On 6/25/07, *yelo_3* <[EMAIL PROTECTED] > wrote:
> 
> 
> ok
> 
> anyway sorry but why did they implement a hardware kill that cannot
> be "revoked" using software? I don't find the use case of this
> 
> 
> dunno but thats how the cards where designed...

My notebook has a slide switch for rfkill/radio disable. No software can move 
that switch with the 
hardware available.

Larry





  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, Larry Finger <[EMAIL PROTECTED]> wrote:


dragoran wrote:
>
>
> On 6/25/07, *yelo_3* <[EMAIL PROTECTED] > wrote:
>
>
> ok
>
> anyway sorry but why did they implement a hardware kill that cannot
> be "revoked" using software? I don't find the use case of this
>
>
> dunno but thats how the cards where designed...

My notebook has a slide switch for rfkill/radio disable. No software can
move that switch with the
hardware available.



same here but that is  the hardware design ;)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, yelo_3 <[EMAIL PROTECTED]> wrote:


> that not what I meant...
> this is not a "real file" the values that you write to it must not be
the same when you read them again.
> try this:
> echo 1 to the file while the card is killed by the hw kill switch
> it will contain 3 not 1.
> we have to check for this cases too.

In fact I've written the two cases of failure:
1) if you write 0 and the content is not 0
2) if you write 1 and the content is 0



ok sorry I missread this ...

Anyway the errors should be propaged to network-manager so the user is

informed of the type of error:
- hardware kill is on and you can't edit the state visa software
- other type of error occurred



ok

anyway sorry but why did they implement a hardware kill that cannot be

"revoked" using software? I don't find the use case of this



dunno but thats how the cards where designed...
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

> that not what I meant... 

> this is not a "real file" the values that you write to it must not be the 
> same when you read them again.
> try this:
> echo 1 to the file while the card is killed by the hw kill switch
> it will contain 3 not 1.

> we have to check for this cases too.

In fact I've written the two cases of failure:
1) if you write 0 and the content is not 0
2) if you write 1 and the content is 0


Anyway the errors should be propaged to network-manager so the user is informed 
of the type of error:
- hardware kill is on and you can't edit the state visa software
- other type of error occurred


anyway sorry but why did they implement a hardware kill that cannot be 
"revoked" using software? I don't find the use case of this








___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, yelo_3 <[EMAIL PROTECTED]> wrote:


> already added in the cleaned up version I sended in my second mail.
sorry, I sent the email before receiving the new version



ok, np


this check wouldn't work. when you write a value to the file it can be
0,1,2 or 3 depending on the hwkillswitch and if it worked at all.
this check is important because:
you can only write 0 or 1 to that file
if you have hardware killed your card, you cannot enable it using
software, as documented in README
sometimes the write could fail for other reasons

So if we need a more complex check we should do it:
if you wrote 0 and the file content is different than 0 the method failed
if you wrote 1 and the file content is 0 the mehod failed



that not what I meant...
this is not a "real file" the values that you write to it must not be the
same when you read them again.
try this:
echo 1 to the file while the card is killed by the hw kill switch
it will contain 3 not 1.
we have to check for this cases too.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

> already added in the cleaned up version I sended in my second mail. 
sorry, I sent the email before receiving the new version

> this check wouldn't work. when you write a value to the file it can be 0,1,2 
> or 3 depending on the hwkillswitch and if it worked at all.
this check is important because:

you can only write 0 or 1 to that file
if you have hardware killed your card, you cannot enable it using software, as 
documented in README
sometimes the write could fail for other reasons

So if we need a more complex check we should do it:
if you wrote 0 and the file content is different than 0 the method failed
if you wrote 1 and the file content is 0 the mehod failed


> yes but what should  apps like nm do if we fail to disable all cards? 
> wouldn't it be better to reneable the successful disabled ones to not confuse 
> nm?

> Dan what do you think?
yes you are right, it is not simple to choose...










  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, yelo_3 <[EMAIL PROTECTED]> wrote:


ok but please add these:
1) an error message if the user didn't invoke the file correctly



already added in the cleaned up version I sended in my second mail.

2) a check to see if the setrfkill have not failed

if((fd=fopen(path,"rw"))==NULL) return -1;
fputc(argv[2][0],fd);
kill_status=fgetc(fd);
if (argv[2][0]!=kill_status) return -1;
fclose(fd);
g_free(path);



this check wouldn't work. when you write a value to the file it can be
0,1,2 or 3 depending on the hwkillswitch and if it worked at all.

wouldn't it be better if instead of returning immediately error, we first

try to set the values to all cards? this if the first card fails, but the
second is ok, we don't prevent the second setting to be applied!
This could be done adding a flag error_occurred...



yes but what should  apps like nm do if we fail to disable all cards?
wouldn't it be better to reneable the successful disabled ones to not
confuse nm?
Dan what do you think?
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

ok but please add these:
1) an error message if the user didn't invoke the file correctly
2) a check to see if the setrfkill have not failed
if((fd=fopen(path,"rw"))==NULL) return -1;
fputc(argv[2][0],fd);
kill_status=fgetc(fd);
if (argv[2][0]!=kill_status) return -1;
fclose(fd);
g_free(path);

wouldn't it be better if instead of returning immediately error, we first try 
to set the values to all cards? this if the first card fails, but the second is 
ok, we don't prevent the second setting to be applied!
This could be done adding a flag error_occurred...


- Messaggio originale -
Da: dragoran <[EMAIL PROTECTED]>
A: yelo_3 <[EMAIL PROTECTED]>
Cc: Dan Williams <[EMAIL PROTECTED]>; network manager 
; David Zeuthen <[EMAIL PROTECTED]>; Bastien 
Nocera <[EMAIL PROTECTED]>
Inviato: Lunedì 25 giugno 2007, 19:14:24
Oggetto: Re: ipw srcipts for hal



On 6/25/07, yelo_3 <[EMAIL PROTECTED]> wrote:
I've removed some code duplication...
And in my opinion the script should return On if it founds at least one card 
on, and not as dan said, off if it finds at least one card off..
It is just an opinion...
Because one card on is enough to say that you have wireless on

What do you think?
this won't work with the new .fdi file (the ipw card is no longer a parent of 
the killswitch).
and you also don't check for cards but for interfaces on one card. 












  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, dragoran <[EMAIL PROTECTED]> wrote:


here again with some cleanups.
btw the new fdi file seems not to work:
there is no ipw_killswitch under computer for me...
any idea why?



ok seems that the dell check does not work.
Bastien/David any idea how this could be done?
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

here again with some cleanups.
btw the new fdi file seems not to work:
there is no ipw_killswitch under computer for me...
any idea why?
#include 
#include 
#include 
#include 

static LibHalContext *hal_ctx;

int main(int argc,char** argv) {

	DBusError error;

	char *iface;
	int i,j,k;
	int found=0;
	char kill_status;
	char **udis;
	char **ifaces;
	int num_udis,num_ifaces;
	FILE *fd;
	char *path;
	char ipw[3][8]={"ipw2100","ipw2200","ipw3945"};
	int ret=-1;

	if(argc==1 || argc > 3) {
		fprintf (stderr, "Usage: ipwWirelessCtl [getrfkill] [setrfkill [1|0]]\n");
		return -1;	
	}

	dbus_error_init (&error);

	if ((hal_ctx = libhal_ctx_new ()) == NULL) {
		fprintf (stderr, "error: libhal_ctx_new\n");
		return -1;
	}

	if (!libhal_ctx_set_dbus_connection (hal_ctx, dbus_bus_get (DBUS_BUS_SYSTEM, &error))) {
		fprintf (stderr, "error: libhal_ctx_set_dbus_connection: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}

	if (!libhal_ctx_init (hal_ctx, &error)) {
		fprintf (stderr, "error: libhal_ctx_init: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}


	if(argc==2 && strcmp("getrfkill",argv[1])==0) {
		
		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (udis);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"r"))==NULL) return -1;
	kill_status=fgetc(fd);
	fclose(fd);
	g_free(path);

	switch(kill_status) {
		case '1':
		case '2':
		case '3':
			ret=1;
		break;
	}

	libhal_free_string(iface);
}

			}
		}
		
		if(found && ret!=1) ret=0;
	
	}

	if(argc==3 && strcmp("setrfkill",argv[1])==0 && (atoi(argv[2])==0 || atoi(argv[2])==1)) {

		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (udis);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"w"))==NULL) return -1;
	fputc(argv[2][0],fd);
	fclose(fd);
	g_free(path);

	libhal_free_string(iface);
}

			}
		}
		
		if(found) ret=0;
	
	}

	if (dbus_error_is_set (&error)) {
		fprintf (stderr, "error: %s: %s\n", error.name, error.message);
		dbus_error_free (&error);
		return -1;
	}

	return ret;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, yelo_3 <[EMAIL PROTECTED]> wrote:


I've removed some code duplication...
And in my opinion the script should return On if it founds at least one
card on, and not as dan said, off if it finds at least one card off..
It is just an opinion...
Because one card on is enough to say that you have wireless on
What do you think?



this won't work with the new .fdi file (the ipw card is no longer a parent
of the killswitch).
and you also don't check for cards but for interfaces on one card.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

ok here are the new ipwWirelessCtl.c and the .fdi file


10-ipw-rfkill-switch.fdi
Description: Binary data
#include 
#include 
#include 
#include 

static LibHalContext *hal_ctx;

int main(int argc,char** argv) {

	DBusError error;

	char *iface;
	int i,j,k;
	int found;
	char kill_status;
	char **udis;
	char **ifaces;
	int num_udis,num_ifaces;
	FILE *fd;
	char *path;
	char ipw[3][8]={"ipw2100","ipw2200","ipw3945"};
	int ret=-1;

	if(argc==1) return -1;	

	dbus_error_init (&error);

	if ((hal_ctx = libhal_ctx_new ()) == NULL) {
		fprintf (stderr, "error: libhal_ctx_new\n");
		return -1;
	}

	if (!libhal_ctx_set_dbus_connection (hal_ctx, dbus_bus_get (DBUS_BUS_SYSTEM, &error))) {
		fprintf (stderr, "error: libhal_ctx_set_dbus_connection: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}

	if (!libhal_ctx_init (hal_ctx, &error)) {
		fprintf (stderr, "error: libhal_ctx_init: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}


	if(argc==2 && strcmp("getrfkill",argv[1])==0) {
		
		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (udis);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"r"))==NULL) return -1;
	kill_status=fgetc(fd);
	fclose(fd);
	g_free(path);

	switch(kill_status) {
		case '1':
		case '2':
		case '3':
			ret=1;
		break;
	}

	libhal_free_string(iface);
}

			}
		}
		
		if(found && ret!=1) ret=0;
	
	}

	if(argc==3 && strcmp("setrfkill",argv[1])==0 && (atoi(argv[2])==0 || atoi(argv[2])==1)) {

		for(i = 0; i < 3 ; i++) {

			udis = libhal_manager_find_device_string_match (hal_ctx, "info.linux.driver", ipw[i], &num_udis, &error);

			if(num_udis==0) {
libhal_free_string_array (udis);
continue;
			}

			for(j = 0;j < num_udis; j++) {

ifaces = libhal_manager_find_device_string_match (hal_ctx, "info.parent", udis[j], &num_ifaces, &error);

if(num_ifaces==0) {
	libhal_free_string_array (udis);
	continue;
}
else {
	found++;
}

for (k = 0; k < num_ifaces; k++) {

	iface = libhal_device_get_property_string (hal_ctx, ifaces[k], "net.interface", &error);
	path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);

	if((fd=fopen(path,"w"))==NULL) return -1;
	fputc(argv[2][0],fd);
	fclose(fd);
	g_free(path);

	libhal_free_string(iface);
}

			}
		}
		
		if(found && ret!=1) ret=0;
	
	}

	if (dbus_error_is_set (&error)) {
		fprintf (stderr, "error: %s: %s\n", error.name, error.message);
		dbus_error_free (&error);
		return -1;
	}

	return ret;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

I've removed some code duplication...
And in my opinion the script should return On if it founds at least one card 
on, and not as dan said, off if it finds at least one card off..
It is just an opinion...
Because one card on is enough to say that you have wireless on
What do you think?

- Messaggio originale -
Da: Dan Williams <[EMAIL PROTECTED]>
A: dragoran <[EMAIL PROTECTED]>
Cc: yelo_3 <[EMAIL PROTECTED]>; network manager 
; David Zeuthen <[EMAIL PROTECTED]>; Bastien 
Nocera <[EMAIL PROTECTED]>
Inviato: Lunedì 25 giugno 2007, 18:36:25
Oggetto: Re: ipw srcipts for hal

On Mon, 2007-06-25 at 18:20 +0200, dragoran wrote:
> 
> 
> On 6/25/07, Dan Williams <[EMAIL PROTECTED]> 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...  
> 
> 
> no it should be correct
> /usr/bin/ipwWirelessCtl =1
> getrfkill = 2
> in case of setrfkill we have:
> /usr/bin/ipwWirelessCtl =1
> getrfkill = 2
> value ( 0 or 1) = 3

Oh right, sorry, I'm doing too many things at once right now.  You're
entirely correct

Dan

>  
> 
> 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.
> 
> ok will update it 
> 
> 
> I've attached an updated .fdi file for ipw devices that
> excludes Dells,
> and makes only _one_ killswitch device.
> 
> ok you removed the ipw3945 I will readd it and attach a new
> script/program.
> 
> 
> Dan
> 
> 
> 






  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html#include 
#include 
#include 
#include 
#include 

static LibHalContext *hal_ctx;

int main(int argc,char** argv) {

	DBusError error;

	char *udi="/org/freedesktop/Hal/devices/ipw_wlan_switch";
	char *parent;
	char *iface;
	int i;
	char kill_status;
	char **udis;
	int num_udis;
	FILE *fd;
	char *path;
	int found_card_on=0;
	int error_occurred=0;

	if ( !(
		(argc==2 && strcmp("getrfkill", argv[1])==0) ||
		(argc==3 && strcmp("setrfkill", argv[1])==0 && (strcmp(argv[2], "0")==0 || strcmp(argv[2], "1"))) )
	{
		printf("usage:\n,%s getrfkill\n%s setrfkill 0\n%s setrfkill 1\n",argv[0],argv[0],argv[0]);
		return -1;
	}

	dbus_error_init (&error);

	if ((hal_ctx = libhal_ctx_new ()) == NULL) {
		fprintf (stderr, "error: libhal_ctx_new\n");
		return -1;
	}

	if (!libhal_ctx_set_dbus_connection (hal_ctx, dbus_bus_get (DBUS_BUS_SYSTEM, &error))) {
		fprintf (stderr, "error: libhal_ctx_set_dbus_connection: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR

Re: forcing 802.11a association

[Derek Atkins]

Dan Williams <[EMAIL PROTECTED]> writes:

>> Like I said, "the BSSID is the same on both (a) and (b/g)", so, yes,
>> my AP (a D-Link) has the same BSSID/MAC on both bands.  I do not
>> believe there is any way for me to change this.  In fact, it uses
>> the same BSSID/MAC on ALL three "interfaces" (802.3, 802.11a, and 802.11b/g)
>
> Whee.  So drivers internally now have to differentiate a specific access
> point based on the (band, BSSID, SSID) tuple, which I'm pretty sure not
> many do.

Um, all the drivers have ALWAYS done this.  The iwl3945 is the first
driver NOT to differentiate them!  The madwifi and the ipw3945 drivers
certain work "correctly" in my situation.

> Dan

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: forcing 802.11a association

[Dan Williams]

On Mon, 2007-06-25 at 12:23 -0400, Derek Atkins wrote:
> Dan Williams <[EMAIL PROTECTED]> writes:
> 
> >> > It will see the channels, but if you have the same SSID on both bands,
> >> > it's completely up to wpa_supplicant and the driver itself what band it
> >> > decides to use for the association, since NM doesn't pass the channel.
> >> > I'd guess that the card just reports scan results for the b/g band
> >> > first, and therefore that's the BSSID that wpa_supplicant picks.
> >> >
> >> > Dan
> >> 
> >> I've noticed that the iwl3945 driver doesn't even report the (a) band
> >> results when the BSSID is the same on both (a) and (b/g).
> >
> > That seems quite wrong from a driver point of view; it shouldn't be
> > coalescing the networks that aggressively internally.  Unless, of
> > course, the A band radio and the B/G band radio of a specific AP have
> > the same BSSID/MAC address... do they for you?
> 
> Like I said, "the BSSID is the same on both (a) and (b/g)", so, yes,
> my AP (a D-Link) has the same BSSID/MAC on both bands.  I do not
> believe there is any way for me to change this.  In fact, it uses
> the same BSSID/MAC on ALL three "interfaces" (802.3, 802.11a, and 802.11b/g)

Whee.  So drivers internally now have to differentiate a specific access
point based on the (band, BSSID, SSID) tuple, which I'm pretty sure not
many do.

Dan



___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[Dan Williams]

On Mon, 2007-06-25 at 18:20 +0200, dragoran wrote:
> 
> 
> On 6/25/07, Dan Williams <[EMAIL PROTECTED]> 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...  
> 
> 
> no it should be correct
> /usr/bin/ipwWirelessCtl =1
> getrfkill = 2
> in case of setrfkill we have:
> /usr/bin/ipwWirelessCtl =1
> getrfkill = 2
> value ( 0 or 1) = 3

Oh right, sorry, I'm doing too many things at once right now.  You're
entirely correct

Dan

>  
> 
> 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.
> 
> ok will update it 
> 
> 
> I've attached an updated .fdi file for ipw devices that
> excludes Dells,
> and makes only _one_ killswitch device.
> 
> ok you removed the ipw3945 I will readd it and attach a new
> script/program.
> 
> 
> Dan
> 
> 
> 

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: forcing 802.11a association

[Derek Atkins]

Dan Williams <[EMAIL PROTECTED]> writes:

>> > It will see the channels, but if you have the same SSID on both bands,
>> > it's completely up to wpa_supplicant and the driver itself what band it
>> > decides to use for the association, since NM doesn't pass the channel.
>> > I'd guess that the card just reports scan results for the b/g band
>> > first, and therefore that's the BSSID that wpa_supplicant picks.
>> >
>> > Dan
>> 
>> I've noticed that the iwl3945 driver doesn't even report the (a) band
>> results when the BSSID is the same on both (a) and (b/g).
>
> That seems quite wrong from a driver point of view; it shouldn't be
> coalescing the networks that aggressively internally.  Unless, of
> course, the A band radio and the B/G band radio of a specific AP have
> the same BSSID/MAC address... do they for you?

Like I said, "the BSSID is the same on both (a) and (b/g)", so, yes,
my AP (a D-Link) has the same BSSID/MAC on both bands.  I do not
believe there is any way for me to change this.  In fact, it uses
the same BSSID/MAC on ALL three "interfaces" (802.3, 802.11a, and 802.11b/g)

> Dan

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

On 6/25/07, Dan Williams <[EMAIL PROTECTED]> 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...




no it should be correct
/usr/bin/ipwWirelessCtl =1
getrfkill = 2
in case of setrfkill we have:
/usr/bin/ipwWirelessCtl =1
getrfkill = 2
value ( 0 or 1) = 3


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.



ok will update it

I've attached an updated .fdi file for ipw devices that excludes Dells,

and makes only _one_ killswitch device.



ok you removed the ipw3945 I will readd it and attach a new script/program.

Dan




___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: forcing 802.11a association

[Dan Williams]

On Mon, 2007-06-25 at 11:15 -0400, Derek Atkins wrote:
> Dan Williams <[EMAIL PROTECTED]> writes:
> 
> > On Sun, 2007-06-24 at 18:21 +0200, Mathieu GELI wrote:
> >> Hi list,
> >> 
> >> I'm wondering wheter it is possible to force association on the 5Ghz band
> >> when a hostpot provides both 2.4 & 5 even if on 2.4 the driver reports
> >> a quality a little bit bigger.
> >
> > Not with 0.6.x, unfortunately.  0.7 will allow you to specify a
> > particular band for a specific Connection.
> >
> >> I doubt NM does even see the 5Ghz channels.
> >> The card is an Intel PRO Wireless 3945ABG
> >
> > It will see the channels, but if you have the same SSID on both bands,
> > it's completely up to wpa_supplicant and the driver itself what band it
> > decides to use for the association, since NM doesn't pass the channel.
> > I'd guess that the card just reports scan results for the b/g band
> > first, and therefore that's the BSSID that wpa_supplicant picks.
> >
> > Dan
> 
> I've noticed that the iwl3945 driver doesn't even report the (a) band
> results when the BSSID is the same on both (a) and (b/g).

That seems quite wrong from a driver point of view; it shouldn't be
coalescing the networks that aggressively internally.  Unless, of
course, the A band radio and the B/G band radio of a specific AP have
the same BSSID/MAC address... do they for you?

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[Dan Williams]

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.

Dan



10-ipw-rfkill-switch.fdi
Description: application/xml
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: forcing 802.11a association

[Derek Atkins]

Dan Williams <[EMAIL PROTECTED]> writes:

> On Sun, 2007-06-24 at 18:21 +0200, Mathieu GELI wrote:
>> Hi list,
>> 
>> I'm wondering wheter it is possible to force association on the 5Ghz band
>> when a hostpot provides both 2.4 & 5 even if on 2.4 the driver reports
>> a quality a little bit bigger.
>
> Not with 0.6.x, unfortunately.  0.7 will allow you to specify a
> particular band for a specific Connection.
>
>> I doubt NM does even see the 5Ghz channels.
>> The card is an Intel PRO Wireless 3945ABG
>
> It will see the channels, but if you have the same SSID on both bands,
> it's completely up to wpa_supplicant and the driver itself what band it
> decides to use for the association, since NM doesn't pass the channel.
> I'd guess that the card just reports scan results for the b/g band
> first, and therefore that's the BSSID that wpa_supplicant picks.
>
> Dan

I've noticed that the iwl3945 driver doesn't even report the (a) band
results when the BSSID is the same on both (a) and (b/g).

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

Thank you! I will have a look at it soon.

- Messaggio originale -
Da: dragoran <[EMAIL PROTECTED]>
A: yelo_3 <[EMAIL PROTECTED]>
Cc: Dan Williams <[EMAIL PROTECTED]>; network manager 

Inviato: Lunedì 25 giugno 2007, 16:09:30
Oggetto: Re: ipw srcipts for hal



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.












  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

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.
#include 
#include 
#include 
#include 
#include 

static LibHalContext *hal_ctx;

int main(int argc,char** argv) {

	DBusError error;

	char *udi="/org/freedesktop/Hal/devices/ipw_wlan_switch";
	char *parent;
	char *iface;
	int i;
	char kill_status;
	char **udis;
	int num_udis;
	FILE *fd;
	char *path;
	int ret=-1;

	if(argc==1) return -1;	

	dbus_error_init (&error);

	if ((hal_ctx = libhal_ctx_new ()) == NULL) {
		fprintf (stderr, "error: libhal_ctx_new\n");
		return -1;
	}

	if (!libhal_ctx_set_dbus_connection (hal_ctx, dbus_bus_get (DBUS_BUS_SYSTEM, &error))) {
		fprintf (stderr, "error: libhal_ctx_set_dbus_connection: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}

	if (!libhal_ctx_init (hal_ctx, &error)) {
		fprintf (stderr, "error: libhal_ctx_init: %s: %s\n", error.name, error.message);
		LIBHAL_FREE_DBUS_ERROR (&error);
		return -1;
	}


	parent = libhal_device_get_property_string (hal_ctx, udi, "info.parent", &error);
	udis = libhal_manager_find_device_string_match (hal_ctx, "info.parent", parent, &num_udis, &error);
	libhal_free_string(parent);
	
	if(argc==2 && strcmp("getrfkill",argv[1])==0) {

		for (i = 0; i < num_udis; i++) {
			if(strcmp(udis[i],udi)==0) continue;
			iface = libhal_device_get_property_string (hal_ctx, udis[i], "net.interface", &error);
			path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);
			if((fd=fopen(path,"r"))==NULL) return -1;
			kill_status=fgetc(fd);
			fclose(fd);
			g_free(path);
			switch(kill_status) {
case '0':
	ret=1;
break;
case '1':
case '2':
case '3':
	ret=0;
break;
			}
			libhal_free_string(iface);
		}
	
		libhal_free_string_array (udis);
	}

	if(argc==3 && strcmp("setrfkill",argv[1])==0 && (atoi(argv[2])==0 || atoi(argv[2])==1)) {
		for (i = 0; i < num_udis; i++) {
			if(strcmp(udis[i],udi)==0) continue;
			iface = libhal_device_get_property_string (hal_ctx, udis[i], "net.interface", &error);
			path=g_strdup_printf("/sys/class/net/%s/device/rf_kill",iface);
			if((fd=fopen(path,"w"))==NULL) return -1;
			fputc(argv[2][0],fd);
			fclose(fd);
			g_free(path);
			libhal_free_string(iface);
		}
	
		libhal_free_string_array (udis);	

		ret=0;
	}
	
	if (dbus_error_is_set (&error)) {
		fprintf (stderr, "error: %s: %s\n", error.name, error.message);
		dbus_error_free (&error);
		return -1;
	}

	return ret;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

unable to 'create new wireless network'

[Fanen Ahua]

on debian sid, nm can't create new ad-hoc wireless networks unless there
are other visible wireless access points available.

i'm just hoping to get a second opinion before i file a bug report...
and i'm not sure where to file it, (debian or nm)
-- 
fanen
http://traversingmind.blogspot.com

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

> 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.


again corrected another error in hal-system-killswitch, reattaching
a question:how to invoke in hal getrfkill and setrfkill from the shell? to 
check if they return correct values!

another question: should we add laptop-leds stuff in this 
hal-system-killswitch, since it is really related to it, or do we really need a 
new hal entry?



  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html--- hal-system-killswitch-get-power-linux.ORIG	2007-06-22 22:33:24.0 -0400
+++ hal-system-killswitch-get-power-linux	2007-06-22 23:13:39.0 -0400
@@ -47,6 +47,17 @@
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "dellWirelessCtl returned $value" >&2
 	fi
+   elif [ "$HAL_PROP_KILLSWITCH_ACCESS_METHOD" = "ipw" ] && [ -x /usr/bin/ipwWirelessCtl ]; then
+		/usr/bin/ipwWirelessCtl getrfkill
+		value=$?
+		if [ "$value" = "0" ]; then
+		exit 1
+		elif [ "$value" = "1" ]; then
+		exit 0
+		else
+		echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
+		echo "ipwWirelessCtl returned $value" >&2
+		fi
else
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "Access type not supported" >&2
 	
--- hal-system-killswitch-set-power-linux.ORIG	2007-06-22 22:33:24.0 -0400
+++ hal-system-killswitch-set-power-linux	2007-06-22 23:13:39.0 -0400
@@ -47,6 +47,17 @@
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "dellWirelessCtl returned $value" >&2
 	fi
+	elif [ "$HAL_PROP_KILLSWITCH_ACCESS_METHOD" = "ipw" ] && [ -x /usr/bin/ipwWirelessCtl ]; then
+		if [ "$value" = "true" ]; then
+			rf_value=0
+		elif [ "$value" = "false" ]; then
+			rf_value=1
+		fi
+
+		/usr/bin/ipwWirelessCtl setrfkill $rf_value
+		ret=$?
+		if [ "$ret" != "0" ]; then 
+			echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
+			echo "ipwWirelessCtl returned $value" >&2
+		fi
else
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "Access type not supported" >&2
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

yelo_3 wrote:
> instead of using sprintf you should use
> #include 
> char* path = g_strconcat("/sys/class/net/", iface, "/device/rf_kill", 
> NULL);
> [...]
> g_free(path);
didn't want to make hal depend on glib but it seems that it does this 
anyway so I will use this or g_strdup_printf()
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

instead of using sprintf you should use 
#include 
char* path = g_strconcat("/sys/class/net/", iface, "/device/rf_kill", NULL);
[...]
g_free(path);

- Messaggio originale -
Da: dragoran <[EMAIL PROTECTED]>
A: yelo_3 <[EMAIL PROTECTED]>
Cc: network manager ; [EMAIL PROTECTED]; Dan 
Williams <[EMAIL PROTECTED]>
Inviato: Domenica 24 giugno 2007, 22:15:30
Oggetto: Re: ipw srcipts for hal

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?

programm is attached... any comments?







  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

yelo_3 wrote:
> This is how in bash we could find the interface by the udi
>
>   
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.

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

This is how in bash we could find the interface by the udi






  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

find-interface-by-udi.sh
Description: application/shellscript
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

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
>
>   
we just have to pass something unique to ipwWirelessCtl
>> What other tools like NetworkManager do is another question; right now
>> NM will kill _all_ radios when it detects one that's killed.  I don't
>> see any reason to change that right now.  If the laptop actually has a
>> physical killswitch, it certainly doesn't have more than one for wifi
>> specifically, so I'm not sure we care about support multiple independent
>> wifi killswitches in NM right now.
>>
>> Dan
>> 
>
> This is, in my opinion, good for now.
>
>
>
> I might have done an error in the setrkfill code portion in 
> hal-system-killswitch-set-power-linux:
> I think that the variable "$value" is passed by someone to the script, since 
> it is used in the first lines, but I don't know if value=1 means rfkill=1 or 
> rfkill=0...
>
>
>   
my program just returns 1 for on and 0 for off

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

> 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

> What other tools like NetworkManager do is another question; right now
> NM will kill _all_ radios when it detects one that's killed.  I don't
> see any reason to change that right now.  If the laptop actually has a
> physical killswitch, it certainly doesn't have more than one for wifi
> specifically, so I'm not sure we care about support multiple independent
> wifi killswitches in NM right now.
> 
> Dan

This is, in my opinion, good for now.



I might have done an error in the setrkfill code portion in 
hal-system-killswitch-set-power-linux:
I think that the variable "$value" is passed by someone to the script, since it 
is used in the first lines, but I don't know if value=1 means rfkill=1 or 
rfkill=0...








___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html--- hal-system-killswitch-get-power-linux.ORIG	2007-06-22 22:33:24.0 -0400
+++ hal-system-killswitch-get-power-linux	2007-06-22 23:13:39.0 -0400
@@ -47,6 +47,17 @@
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "dellWirelessCtl returned $value" >&2
 	fi
+   elif [ "$HAL_PROP_KILLSWITCH_ACCESS_METHOD" = "ipw" ] && [ -x /usr/bin/ipwWirelessCtl ]; then
+		/usr/bin/ipwWirelessCtl getrfkill
+		value=$?
+		if [ "$value" = "0" ]; then
+		exit 1
+		elif [ "$value" = "1" ] || [ "$value" = "2" ] || [ "$value" = "3" ]; then
+		exit 0
+		else
+		echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
+		echo "ipwWirelessCtl returned $value" >&2
+		fi
else
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "Access type not supported" >&2
 	
--- hal-system-killswitch-set-power-linux.ORIG	2007-06-22 22:33:24.0 -0400
+++ hal-system-killswitch-set-power-linux	2007-06-22 23:13:39.0 -0400
@@ -47,6 +47,17 @@
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "dellWirelessCtl returned $value" >&2
 	fi
+	elif [ "$HAL_PROP_KILLSWITCH_ACCESS_METHOD" = "ipw" ] && [ -x /usr/bin/ipwWirelessCtl ]; then
+		if [ "$value" = "true" ]; then
+			rf_value=1
+		elif [ "$value" = "false" ]; then
+			rf_value=0
+		fi
+
+		/usr/bin/ipwWirelessCtl setrfkill $rf_value
+		ret=$?
+		if [ "$ret" != "0" ]; then 
+			echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
+			echo "ipwWirelessCtl returned $value" >&2
+		fi
else
 	echo "org.freedesktop.Hal.Device.KillSwitch.NotSupported" >&2
 	echo "Access type not supported" >&2
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

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  

> What other tools like NetworkManager do is another question; right now
> NM will kill _all_ radios when it detects one that's killed.  I don't
> see any reason to change that right now.  If the laptop actually has a
> physical killswitch, it certainly doesn't have more than one for wifi
> specifically, so I'm not sure we care about support multiple independent
> wifi killswitches in NM right now.
>
>   
I never saw a laptop with 2 killswitches so this seems the right thing 
to do now.


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager on Fedora 7

[Dan Williams]

On Sun, 2007-06-10 at 00:58 +0100, John Lagrue wrote:
> It seems that there's a problem with NM on F7 when using WPA.
> 
> My wireless network uses WPA2-Personal, with AES encryption. However
> when I try to connect to it on F7 using NM I don't get those options
> to choose from; it only offers WPA Personal and type of Automatic or
> AES-CCMP (whatever that might be)

Can you post the results of '/sbin/iwlist ethX scan' just for your
access point?  (replace ethX with your device, and scrub your MAC
address).  That will tell whether it really is WPA or WPA2.

Dan

> Is the problem with my driver? Or with NM? Or with Fedora? Any
> pointers of where to start looking would be greatly appreciated.
> 
> Currently I'm without wireless until I can find a solution.
> 
> JDL
> ___
> 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: how to have rfkill supported by hal?

[dragoran]

Dan Williams wrote:
> On Sat, 2007-06-23 at 14:23 +0100, Bastien Nocera wrote:
>   
>> On Fri, 2007-06-22 at 23:21 -0400, Dan Williams wrote:
>> 
>>> On Fri, 2007-06-22 at 18:34 +, yelo_3 wrote:
>>>   
> HAL should be fixed to work with ACPI-based laptops.  For now, I'd
> suggest a small daemon that monitors ACPI events (or, have acpid callout
> scripts write the status to a file somewhere), and then add a section to
> the HAL rfkill script to read that file for rfkill status.
>
> Dan
>   
 I have acpid installed. 
 I have a script that manually changes /sys/class/net/eth1/device/rf_kill
 what else should I add to the script, to talk to hal rfkill?
 
>>> I whipped something together in about 30 minutes for ipw2200 and ipw2100
>>> users.  You don't need to add anything to that acpi-triggered script;
>>> you need to do the following using the attachments I've provided
>>> (locations assume Fedora):
>>>
>>> cp 10-ipw-rfkill-switch.fdi /usr/share/hal/fdi/information/10freedesktop/
>>> cp hal-system-ipw /usr/libexec/hal-system-ipw
>>> chmod 755 /usr/libexec/hal-system-ipw
>>> cd /usr/lib/hal/scripts/linux
>>> patch -p0 < /path/to/hal-system-killswitch-get-power-linux.diff
>>>
>>> Restart HAL, and you're good to go.
>>>
>>> davidz/bastien: comments?  the shellscript could possibly be better of
>>> course.
>>>   
>> If only it was that easy ;)
>>
>> You need to disable your script for Dell laptops, in the fdi, otherwise
>> you end up with 2 levels of rfkill, one at the card level, one at .
>> 
>
> Yeah; can we do ! in .fdi files as yelo_3 asked?
>
>   
that was me who asked ;) I couldn't find anything about it in the spec...

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Feature Request - Alphabetization

[Dan Williams]

On Fri, 2007-06-15 at 10:44 -0500, Greg Oliver wrote:
> I would REALLY love to have the vpn connections in alphabetical order.

Hmm, I checked that this weekend, and the code does clearly sort the
connections alphabetically in the applet menu.  That doesn't rule out a
bug somewhere though.

Do you mean the VPN connection setup dialog, or the applet menu?

Dan

> We do remote installs for my company as well as support (all of our
> clients have 100% cisco gear and firewalls/VPN concentrators), so I use
> vpnc heavily, and on the few occasions it does not work, I use the cisco
> client.  I have well over 200 vpn connections, but it is hard to find
> them since they are not in any particular order.
> 
> Thanks,
> 
> Greg
> 
> ___
> 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: Sharing connection

[Dan Williams]

On Sun, 2007-06-24 at 11:27 +0200, Dawid Wróbel wrote:
> On Sat, 23 Jun 2007 14:35:56 +0200 "Antonio Bulgheroni"
> <[EMAIL PROTECTED]> wrote:
> 
> > Great! I will wait for that
> It would be even better if it was possible to set up a simple AP
> on the wifi card to share the internet. It shouldn't
> introduce a lot of code, most of the things (bridging) will
> be/are done anyway as a part of connection sharing feature. 
> There would only be a need to change the mode of the card into master.
> (like we do it now with iwconfig). Unfortunately not all the drivers
> support mode changing this way, although let's hope it will
> change in the future as the drivers will be ported to the unified
> mac80211 stack.

NM probably won't set master (AP) mode at all, for a number of reasons:

1) most drivers right now don't support master mode, or have a lot of
hoops to jump through to get to master mode (different firmware, restart
card, reload modules, etc).  Many of the drivers that do (ie, based on
mac80211) just aren't usable enough yet.

2) Master mode is less tested on many drivers, if they support it

3) wpa_supplicant doesn't support master mode, nor should it

4) You have to start and manage a lot more daemons, like dhcpd

Both Windows (usually) and OS X (always) set the card to adhoc mode, set
a self-assigned IPv4 address, and then NAT the connection.  That's the
route we're likely to take with NetworkManager, because it's the
simplest way to get there, and it works reasonably well.  If people
_really_ want a dedicated AP, that's what hostapd is for.  We can
revisit AP-mode in the future, but I believe adhoc is the immediate
solution.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: forcing 802.11a association

[Dan Williams]

On Sun, 2007-06-24 at 18:21 +0200, Mathieu GELI wrote:
> Hi list,
> 
> I'm wondering wheter it is possible to force association on the 5Ghz band
> when a hostpot provides both 2.4 & 5 even if on 2.4 the driver reports
> a quality a little bit bigger.

Not with 0.6.x, unfortunately.  0.7 will allow you to specify a
particular band for a specific Connection.

> I doubt NM does even see the 5Ghz channels.
> The card is an Intel PRO Wireless 3945ABG

It will see the channels, but if you have the same SSID on both bands,
it's completely up to wpa_supplicant and the driver itself what band it
decides to use for the association, since NM doesn't pass the channel.
I'd guess that the card just reports scan results for the b/g band
first, and therefore that's the BSSID that wpa_supplicant picks.

Dan

> The UI doesn't show A/B difference when selecting the essid, and iwconfig 
> always
> report an association on 2.4Ghz.
> 
> Cheers
> 

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager uses usb0 as my default network interface, how do I stop it?

[Dan Williams]

On Sun, 2007-06-24 at 17:25 -0700, Toby Latin-Stoermer wrote:
> NetworkManager uses usb0 as my default network interface, but I don't
> have a network connection on usb0. I would like to either remove it as
> an option or at least not make it not the default connection. I'm
> running Ubuntu Fiesty, on a nearly clean install. What should I do? 

Configure it in your /etc/interfaces file or something, since Ubuntu has
some patches that make NM ignore any device you've manually configured.
BTW, what type of connection is usb0?  Is it a Zaurus or Moto ROKR E2 or
something like that?

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[Dan Williams]

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.

What other tools like NetworkManager do is another question; right now
NM will kill _all_ radios when it detects one that's killed.  I don't
see any reason to change that right now.  If the laptop actually has a
physical killswitch, it certainly doesn't have more than one for wifi
specifically, so I'm not sure we care about support multiple independent
wifi killswitches in NM right now.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: how to have rfkill supported by hal?

[Dan Williams]

On Sat, 2007-06-23 at 14:23 +0100, Bastien Nocera wrote:
> On Fri, 2007-06-22 at 23:21 -0400, Dan Williams wrote:
> > On Fri, 2007-06-22 at 18:34 +, yelo_3 wrote:
> > > >HAL should be fixed to work with ACPI-based laptops.  For now, I'd
> > > >suggest a small daemon that monitors ACPI events (or, have acpid callout
> > > >scripts write the status to a file somewhere), and then add a section to
> > > >the HAL rfkill script to read that file for rfkill status.
> > > >
> > > >Dan
> > > 
> > > I have acpid installed. 
> > > I have a script that manually changes /sys/class/net/eth1/device/rf_kill
> > > what else should I add to the script, to talk to hal rfkill?
> > 
> > I whipped something together in about 30 minutes for ipw2200 and ipw2100
> > users.  You don't need to add anything to that acpi-triggered script;
> > you need to do the following using the attachments I've provided
> > (locations assume Fedora):
> > 
> > cp 10-ipw-rfkill-switch.fdi /usr/share/hal/fdi/information/10freedesktop/
> > cp hal-system-ipw /usr/libexec/hal-system-ipw
> > chmod 755 /usr/libexec/hal-system-ipw
> > cd /usr/lib/hal/scripts/linux
> > patch -p0 < /path/to/hal-system-killswitch-get-power-linux.diff
> > 
> > Restart HAL, and you're good to go.
> > 
> > davidz/bastien: comments?  the shellscript could possibly be better of
> > course.
> 
> If only it was that easy ;)
> 
> You need to disable your script for Dell laptops, in the fdi, otherwise
> you end up with 2 levels of rfkill, one at the card level, one at .

Yeah; can we do ! in .fdi files as yelo_3 asked?

Dan

> The shell script should be in C, and probably use the UDI passed to it,
> instead of looking for the device by hand.
> 
> Finally, You don't handle values 2 and 3 in the Get. From the ipw2200
> README:
>  rf_kill
>   read - 
>   0 = RF kill not enabled (radio on)
>   1 = SW based RF kill active (radio off)
>   2 = HW based RF kill active (radio off)
>   3 = Both HW and SW RF kill active (radio off)
>   write -
>   0 = If SW based RF kill active, turn the radio back on
>   1 = If radio is on, activate SW based RF kill
> 
>   NOTE: If you enable the SW based RF kill and then toggle the HW
>   based RF kill from ON -> OFF -> ON, the radio will NOT come back on
> 
> You can also support the ipw3945 driver with the same settings. I
> believe that the iwlwifi drivers are also supportable with the same
> script.
> 
> Cheers
> 

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[dragoran]

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.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ipw srcipts for hal

[yelo_3]

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

- Messaggio originale -
Da: dragoran <[EMAIL PROTECTED]>
A: yelo_3 <[EMAIL PROTECTED]>
Cc: network manager ; [EMAIL PROTECTED]; Dan 
Williams <[EMAIL PROTECTED]>
Inviato: Domenica 24 giugno 2007, 22:15:30
Oggetto: Re: ipw srcipts for hal

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?

programm is attached... any comments?










___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list