Re: [DNG] netman GIT project

[Edward Bartolo]

I don't think it is necessary to daemonise the backend as connection
to and disconnecting from a network is not something that is done
continuously. Therefore, in my humble opinion, running the backend on
request seems to be the best approach. This also avoids additional
complexity of requiring a dedicated init script. An SUID belonging to
root is enough for the backend to be allowed privileges automatically
whenever it is invoked. This means, the post installation script will
only need to "chmod u+s backend" and create a launcher on user
request.

I will now test an installation to /usr/bin of both backend and
frontend using an SUID for the backend. If everthing goes well, it
would mean, the time for an ALPHA release of a .deb package for
netman, is possible now.

I included more functionality in the frontend to recognise the
existence of an /etc/network/interfaces displaying and option to
connect to eth0 if that is found. I also included a compiler
conditional directive to compile the frontend so as to bypass the
requirement of sudo.

When I am ready, and I think the project can be package, I will upload
to git.devuan.org


Edward

On 26/08/2015, Isaac Dunham  wrote:
> On Wed, Aug 26, 2015 at 02:27:57PM +0200, tilt! wrote:
>> On 08/26/2015 01:36 PM, Irrwahn wrote:
>> >[...]
>> >Or, even better, you could easily pass the IF name as an additional
>> >parameter to the backend (and possily even use it as additional component
>> >to construct the interface file names).
>>
>> An easy way to obtain a list of interface names on Linux is:
>>
>> awk 'NR>2{gsub(/:/,"");print $1}' /proc/net/dev
>
> Or "ls /sys/class/net".
> For listing non-loopback devices only, use
> ls -d /sys/class/net/*/device | cut -d/ -f5
>
> For wireless, check for the files "phy80211" or "wireless".
>
> The equivalent can be done trivially in C with readdir(); ask if you'd like
> an example.
>
> HTH,
> Isaac Dunham
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] wpa_supplicant/ifup integration documentation

[Didier Kryn]

Le 25/08/2015 03:40, Isaac Dunham a écrit :

For your perusal, here's an overview of how they work together; it's a 100+
line summary.
If anyone wants more details, here are some sources:
Manual pages:
interfaces(5), wpa_supplicant.conf(5), wpa_supplicant(8), wpa_cli(8),
wpa_action(8).
Scripts:
/sbin/wpa_action
/etc/network/if-*.d/wpasupplicant
/etc/wpa_supplicant/*.sh
(/etc/wpa_supplicant/functions.sh is going to be needed if you want a
low-level understanding of what's going on; the script authors have an
exceptional capacity for indirection.)

You will need to read the scripts for a practical understanding of how
it works, but the interfaces, wpa_cli, and wpa_action manpages are rather
helpful for understanding the glue.


Thanks, Isaac, I had made my best to RTFM :-) but what I couldn't 
find is how the line wpa_roam ... is passed to the script.


Here is the idea I got from looking at the scripts. Any line 
following the iface line is interpreted by ifup in the following way 
before invoking all the scripts:


The first token in the line is capitallized and prefixed with 
"IF_", then, an environment variable with this name is created and its  
value is the rest of the line. Each line following the iface line is 
treated like this and all the scripts can then check the enviroment 
variables. This is not the whole story though, since I remember it is 
also possible to put command lines -- I did it a few years ago to 
configure bonding interfaces.


Therefore, asserting all this is still on my todo list, and maybe 
the only way is to look at the source of ifup, althoug I would have 
preferred a more authoritative description. For now, my feeling is still 
that it makes little sense to set up a parallel framework when what is 
missing is only a tinier version of wpa_gui, and maybe first a curses 
version.


Thanks.
Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] replacing kernel 3.16.0-4

[aitor_czr]

Replacing the kernel is very easy. The problem is in debian-installer. 
We need to add all the modules in it, and it is a titanic work 
(exaggerating :-).


But it is possible.

Mmmmh..., there must be a consensus about this issue in VUA's for 
official images.


Aitor.

On 26/08/15 17:55, Haines Brown  wrote:

I've already tried your patience with a query about why xrandr tells me
my display uses VGA 1024x768 when it shows my video card supports DVI
1920x1080. I hope you will bear with me if I pursue the matter.

I am told that because selection of optimal resolution is today done by
the kernel, my 3.16.0-4 kernel therefore has a bug. I find significant
that kernel.org skips this kernel for possible downloading. Is anyone
else experiencing this problem?

I'm loading fluxbox on devuan-jessie without a desktop environment. When
I edit the linux line in the GRUB menu by appending video=VGA-1:d, the
display comes up with the proper DVI 1920x1080 resolution. Does this not
show that the kernel is sick?

So I'd like to use a different kernel, but there are no alternatives in
the devuan repository. How then should I install an alternative kernel?

Some time ago I tried to install devuan testing and it failed right away
for reasons I forget. Is the testing installation option actually
working?

Haines Brown


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Edward Bartolo]

I am trying to write a C function to start the wired network
interfaces eth0, eth1 up to eth2. This is how I wrote it, but I would
like your opinion about it especially where I should declare err.

The attachment is best viewed with medit with a tab space of 2.


On 27/08/2015, Edward Bartolo  wrote:
> I don't think it is necessary to daemonise the backend as connection
> to and disconnecting from a network is not something that is done
> continuously. Therefore, in my humble opinion, running the backend on
> request seems to be the best approach. This also avoids additional
> complexity of requiring a dedicated init script. An SUID belonging to
> root is enough for the backend to be allowed privileges automatically
> whenever it is invoked. This means, the post installation script will
> only need to "chmod u+s backend" and create a launcher on user
> request.
>
> I will now test an installation to /usr/bin of both backend and
> frontend using an SUID for the backend. If everthing goes well, it
> would mean, the time for an ALPHA release of a .deb package for
> netman, is possible now.
>
> I included more functionality in the frontend to recognise the
> existence of an /etc/network/interfaces displaying and option to
> connect to eth0 if that is found. I also included a compiler
> conditional directive to compile the frontend so as to bypass the
> requirement of sudo.
>
> When I am ready, and I think the project can be package, I will upload
> to git.devuan.org
>
>
> Edward
>
> On 26/08/2015, Isaac Dunham  wrote:
>> On Wed, Aug 26, 2015 at 02:27:57PM +0200, tilt! wrote:
>>> On 08/26/2015 01:36 PM, Irrwahn wrote:
>>> >[...]
>>> >Or, even better, you could easily pass the IF name as an additional
>>> >parameter to the backend (and possily even use it as additional
>>> > component
>>> >to construct the interface file names).
>>>
>>> An easy way to obtain a list of interface names on Linux is:
>>>
>>> awk 'NR>2{gsub(/:/,"");print $1}' /proc/net/dev
>>
>> Or "ls /sys/class/net".
>> For listing non-loopback devices only, use
>> ls -d /sys/class/net/*/device | cut -d/ -f5
>>
>> For wireless, check for the files "phy80211" or "wireless".
>>
>> The equivalent can be done trivially in C with readdir(); ask if you'd
>> like
>> an example.
>>
>> HTH,
>> Isaac Dunham
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Edward Bartolo]

Oooops, forgot the attachment!  Here it is.

On 27/08/2015, Edward Bartolo  wrote:
> I am trying to write a C function to start the wired network
> interfaces eth0, eth1 up to eth2. This is how I wrote it, but I would
> like your opinion about it especially where I should declare err.
>
> The attachment is best viewed with medit with a tab space of 2.
>
>
> On 27/08/2015, Edward Bartolo  wrote:
>> I don't think it is necessary to daemonise the backend as connection
>> to and disconnecting from a network is not something that is done
>> continuously. Therefore, in my humble opinion, running the backend on
>> request seems to be the best approach. This also avoids additional
>> complexity of requiring a dedicated init script. An SUID belonging to
>> root is enough for the backend to be allowed privileges automatically
>> whenever it is invoked. This means, the post installation script will
>> only need to "chmod u+s backend" and create a launcher on user
>> request.
>>
>> I will now test an installation to /usr/bin of both backend and
>> frontend using an SUID for the backend. If everthing goes well, it
>> would mean, the time for an ALPHA release of a .deb package for
>> netman, is possible now.
>>
>> I included more functionality in the frontend to recognise the
>> existence of an /etc/network/interfaces displaying and option to
>> connect to eth0 if that is found. I also included a compiler
>> conditional directive to compile the frontend so as to bypass the
>> requirement of sudo.
>>
>> When I am ready, and I think the project can be package, I will upload
>> to git.devuan.org
>>
>>
>> Edward
>>
>> On 26/08/2015, Isaac Dunham  wrote:
>>> On Wed, Aug 26, 2015 at 02:27:57PM +0200, tilt! wrote:
 On 08/26/2015 01:36 PM, Irrwahn wrote:
 >[...]
 >Or, even better, you could easily pass the IF name as an additional
 >parameter to the backend (and possily even use it as additional
 > component
 >to construct the interface file names).

 An easy way to obtain a list of interface names on Linux is:

 awk 'NR>2{gsub(/:/,"");print $1}' /proc/net/dev
>>>
>>> Or "ls /sys/class/net".
>>> For listing non-loopback devices only, use
>>> ls -d /sys/class/net/*/device | cut -d/ -f5
>>>
>>> For wireless, check for the files "phy80211" or "wireless".
>>>
>>> The equivalent can be done trivially in C with readdir(); ask if you'd
>>> like
>>> an example.
>>>
>>> HTH,
>>> Isaac Dunham
>>> ___
>>> Dng mailing list
>>> Dng@lists.dyne.org
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>>
>>
>
int connectWired(
	const char * ethx
) {
	int err;
	int valid_eth = 0;
	if (strcmp("eth0", ethx) == 0 || strcmp("eth1", ethx) == 0 || strcmp("eth2", ethx) == 0)
		valid_eth = 1;
		
	if (!valid_eth) {
		fprintf(stderr, "ERROR: only eth0, eth1 and eth2 are allowed; err=%d\n", err);

		return err;
	}
		
	err = execl("/sbin/ifup ", ethx, "-i", "/etc/network/interfaces", char * NULL)
	
	fprintf(
		stderr, 
		"ERROR: connectWired(): "
		"\"/sbin/ifup %s -i /etc/network.interfaces\" failed; err=%d\n",
		ethx, err
	);
			
	return err;
}___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Edward Bartolo]

Nevermind, I spotted the idiocy I was doing, trying to use a system
error type for a custom error! The solution is to declare an error
constant and display a error description.

Edward

On 27/08/2015, Edward Bartolo  wrote:
> Oooops, forgot the attachment!  Here it is.
>
> On 27/08/2015, Edward Bartolo  wrote:
>> I am trying to write a C function to start the wired network
>> interfaces eth0, eth1 up to eth2. This is how I wrote it, but I would
>> like your opinion about it especially where I should declare err.
>>
>> The attachment is best viewed with medit with a tab space of 2.
>>
>>
>> On 27/08/2015, Edward Bartolo  wrote:
>>> I don't think it is necessary to daemonise the backend as connection
>>> to and disconnecting from a network is not something that is done
>>> continuously. Therefore, in my humble opinion, running the backend on
>>> request seems to be the best approach. This also avoids additional
>>> complexity of requiring a dedicated init script. An SUID belonging to
>>> root is enough for the backend to be allowed privileges automatically
>>> whenever it is invoked. This means, the post installation script will
>>> only need to "chmod u+s backend" and create a launcher on user
>>> request.
>>>
>>> I will now test an installation to /usr/bin of both backend and
>>> frontend using an SUID for the backend. If everthing goes well, it
>>> would mean, the time for an ALPHA release of a .deb package for
>>> netman, is possible now.
>>>
>>> I included more functionality in the frontend to recognise the
>>> existence of an /etc/network/interfaces displaying and option to
>>> connect to eth0 if that is found. I also included a compiler
>>> conditional directive to compile the frontend so as to bypass the
>>> requirement of sudo.
>>>
>>> When I am ready, and I think the project can be package, I will upload
>>> to git.devuan.org
>>>
>>>
>>> Edward
>>>
>>> On 26/08/2015, Isaac Dunham  wrote:
 On Wed, Aug 26, 2015 at 02:27:57PM +0200, tilt! wrote:
> On 08/26/2015 01:36 PM, Irrwahn wrote:
> >[...]
> >Or, even better, you could easily pass the IF name as an additional
> >parameter to the backend (and possily even use it as additional
> > component
> >to construct the interface file names).
>
> An easy way to obtain a list of interface names on Linux is:
>
> awk 'NR>2{gsub(/:/,"");print $1}' /proc/net/dev

 Or "ls /sys/class/net".
 For listing non-loopback devices only, use
 ls -d /sys/class/net/*/device | cut -d/ -f5

 For wireless, check for the files "phy80211" or "wireless".

 The equivalent can be done trivially in C with readdir(); ask if you'd
 like
 an example.

 HTH,
 Isaac Dunham
 ___
 Dng mailing list
 Dng@lists.dyne.org
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

>>>
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Steve Litt]

On Thu, 27 Aug 2015 08:14:39 +0100
Edward Bartolo  wrote:

> I don't think it is necessary to daemonise the backend as connection
> to and disconnecting from a network is not something that is done
> continuously. 

Unless you're walking down the street in the business district, with
wifi stations fading in and out.

> Therefore, in my humble opinion, running the backend on
> request seems to be the best approach. This also avoids additional
> complexity of requiring a dedicated init script. 

I keep forgetting that not everybody runs daemontools or its
descendents, where "init scripts" are about 6 lines long and there's no
need for the author of the daemon to make his program go into the
background.

In other words, I keep forgetting that in sysvinit, systemd, OpenRC and
the like, daemons have a substantial cost.

Anyway, let me ask you this question: If I were to run the back end on
a terminal somewhere, would the front end cooperate with it and leave
it running between front end actions?

I think I'll order a wifi dongle so I can start testing your program.

Thanks,

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Edward Bartolo]

There are no infinite loops in the backend, therefore it will do what
it is requested and terminate. The backend is run every time the
frontend needs the former's services. On every call, the backend
terminates, otherwise we would need some form of messaging between
applications, and probably, fall into traps like requiring the
services of dbus and the like, and we want to avoid that.

Now, in the case of frequently changing wifi hotspots, the frontend
need to be made to detect that a different wifi hotspot is required.
This can be achieved with TTimer calling a subroutine regularly in
which a connection is tested, and in case the active wifi is
unreachable, other wifi's are tried starting with the strongest
signal. In case, no essid file is found, the user is prompted to enter
password and essid. However, this can become a nuisance, so we have to
decide where to stop regarding automating wifi connections.

On 27/08/2015, Steve Litt  wrote:
> On Thu, 27 Aug 2015 08:14:39 +0100
> Edward Bartolo  wrote:
>
>> I don't think it is necessary to daemonise the backend as connection
>> to and disconnecting from a network is not something that is done
>> continuously.
>
> Unless you're walking down the street in the business district, with
> wifi stations fading in and out.
>
>> Therefore, in my humble opinion, running the backend on
>> request seems to be the best approach. This also avoids additional
>> complexity of requiring a dedicated init script.
>
> I keep forgetting that not everybody runs daemontools or its
> descendents, where "init scripts" are about 6 lines long and there's no
> need for the author of the daemon to make his program go into the
> background.
>
> In other words, I keep forgetting that in sysvinit, systemd, OpenRC and
> the like, daemons have a substantial cost.
>
> Anyway, let me ask you this question: If I were to run the back end on
> a terminal somewhere, would the front end cooperate with it and leave
> it running between front end actions?
>
> I think I'll order a wifi dongle so I can start testing your program.
>
> Thanks,
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Mirroring Devuan

[Hendrik Boom]

On Tue, Aug 25, 2015 at 10:34:42PM +0200, k...@aspodata.se wrote:
> Jaromil:
> > we haven't yet worked on the mirroring mechanism, but we will
> > 
> > once done, there will be a script and it will be easy
> > I guess it will be a sort of amprolla satellite process
> > so that the mirror redirection will be handled by nextime's software
> ...
> 
> I would be good if one could have a local mirror with just file:// 
> entries i sources.list.
> 
> It would be a great overhead if I needed apache at.al. when accessing
> files on the local disk.
> 
> ///
> 
> According to amprolla/nginx/rewrites.conf:
> 
> rewrite /merged/pool/DEVUAN/(.*) http://packages.devuan.org/devuan/pool/$1;
> rewrite /merged/pool/DEBIAN/(.*) http://http.debian.net/debian/pool/$1;
> rewrite /merged/pool/MARILLAT/(.*) http://www.deb-multimedia.org/pool/$1;
> rewrite /merged/dists/(.*)/main/(installer-.*)/(.*) 
> /devuan/dists/$1/main/$2/$3;
> 
> I guess that this means that if the file is in devouan, use it,
> else use the debian one etc. That could be handled by using the
> right order in sources.list something in preferences.
>  So if I have a copy of http://packages.devuan.org/devuan/ and
> a debian mirror, all I need is to prioritize them, am I right ?

If you carefully order the sources.list entries,
might there wtill be a problem if the debian package is slightly more 
up-to-date than the devuan one?

-- hendrik

> 
> Regards,
> /Karl Hammar
> 
> ---
> Aspö Data
> Lilla Aspö 148
> S-742 94 Östhammar
> Sweden
> +46 173 140 57
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Where to find the latest Devuan that runs under Qemu?

[Steve Litt]

Hi all,

I know this was asked and answered once before, but 1/2 hour of
searching my archives couldn't find it.

Where can I find and download the latest Devuan capable of being run on
Qemu (I assume this means an ISO, unless someone knows another way to
do it).

Thanks,

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] What's /dev/bus/usb?

[Steve Litt]

Hi all,

What's /dev/bus/usb? On Wheezy, this is where you must aim your
inotifywait command to detect insertion and removal of flash drives.

Is /dev/bus/usb used on Devuan?

Is /dev/bus/usb a udev thang, and if so, does vdev continue the
tradition?

Thanks,

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] automount Was: Re: A better default windows manager

[Steve Litt]

On Wed, 26 Aug 2015 12:58:14 +0200
Svante Signell  wrote:

> On Tue, 2015-08-25 at 17:29 +0200, Joerg Reisenweber wrote:
> > On Sun 26 July 2015 23:18:58 Steve Litt wrote:
> > > You can roll your own automount with one day's work using
> > > inotify-wait, dmesg, sudo, lsblk, and the mount command. Works
> > > without X or window manager. Heck, I'll do it myself if more than
> > > 20 people want it.
> > 
> > +1
> > /j
> 
> Steve, what is the current development status of your promised tool?

I just did a little work on it, and then realized there's a package
that might do this for us, in a better way than I'd anticipated.

Please try the pmount package, and see if that fulfills your automount
needs.

Thanks,

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] automount Was: Re: A better default windows manager

[David Hare]

On 27/08/15 15:09, Steve Litt wrote:

On Wed, 26 Aug 2015 12:58:14 +0200
Svante Signell  wrote:


On Tue, 2015-08-25 at 17:29 +0200, Joerg Reisenweber wrote:

On Sun 26 July 2015 23:18:58 Steve Litt wrote:

You can roll your own automount with one day's work using
inotify-wait, dmesg, sudo, lsblk, and the mount command. Works
without X or window manager. Heck, I'll do it myself if more than
20 people want it.


+1
/j


Steve, what is the current development status of your promised tool?


I just did a little work on it, and then realized there's a package
that might do this for us, in a better way than I'd anticipated.

Please try the pmount package, and see if that fulfills your automount
needs.

Thanks,

SteveT

Steve Litt


There is also udevil (nothing to do with udev)

David
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] automount Was: Re: A better default windows manager

[fsmithred]

On 08/26/2015 01:08 PM, Go Linux wrote:
> On Wed, 8/26/15, Steve Litt  wrote:
> 
>  Subject: Re: [DNG] automount Was: Re:  A better default windows manager
>  To: dng@lists.dyne.org
>  Date: Wednesday, August 26, 2015, 11:31 AM
>  
>  On Wed, 26 Aug 2015
>  12:58:14 +0200
>  Svante Signell 
>  wrote:
>  
>  > On Tue,
>  2015-08-25 at 17:29 +0200, Joerg Reisenweber wrote:
>>> On Sun 26 July 2015 23:18:58 Steve Litt wrote:
 You can roll your own automount with one day's work using
 inotify-wait, dmesg, sudo, lsblk, and the mount command. Works
 without X or window manager. Heck, I'll do it myself if more than
 20 people want it.
>>>
>>> +1
>>> /j
>>
>> Steve, what is the current development status of your promised tool?
> 
> I haven't started it yet. Only about 4 people have said they wanted it.
> 
> SteveT
> 
> 
> 
> Excuses, excuses . . .  ;)  OK.  Add me to the list.  I wanna see you do 
> this!!
> 
> golinux
> 
> ___


[[ SIX = "me too" ]]


Steve,

Think like a politician - every letter someone sends is worth 10 voters
(local), 100 voters (state), or 1000 voters (federal).

Or think of us as cockroaches - for every one you see, there are 10 behind
the wall.

fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Edward Bartolo]

I added another function to core_functions.c. It attempts to connect
to eth0 but for some weird reason, probably a bug not from our part,
it is failing.

The function is:  int connectWired(const char ethx)

And the error is: (passed command to execl is "ifup eth0")
"This command should be called as ifup, ifdown, or ifquery"

Any pointers as to what is the cause are appreciated.

Edward

On 27/08/2015, Steve Litt  wrote:
> On Thu, 27 Aug 2015 14:18:02 +0100
> Edward Bartolo  wrote:
>
>>
>> Now, in the case of frequently changing wifi hotspots, the frontend
>> need to be made to detect that a different wifi hotspot is required.
>> This can be achieved with TTimer calling a subroutine regularly in
>> which a connection is tested, and in case the active wifi is
>> unreachable, other wifi's are tried starting with the strongest
>> signal. In case, no essid file is found, the user is prompted to enter
>> password and essid. However, this can become a nuisance, so we have to
>> decide where to stop regarding automating wifi connections.
>
> You're right.
>
> Probably something in the network software sends a message (besides the
> one sent to dbus) indicating that the current active wifi just
> disconnected, and if that can be redirected to your software, that
> pretty much does the job.
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
>
/*
netman - A Network Connection Manager
Copyright (C) 2015  Edward Bartolo

"netman" is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

"netman" is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with "netman".  If not, see .
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include "core_functions.h"
#include "essid_encoder.h"
#include "paths.h"

#define SIMPLE_SCAN_OPT ""
//#define POWER_SCAN_OPT "-B 4"

int connectWired(
	const char * ethx
) {
	int err;
	int valid_eth = 0;
	
	if (ethx == NULL) 
		return 107; // ethx is NULL
	
	char ethN[10];
	strcpy(ethN, "eth");
	
	valid_eth = (strncmp(ethN, ethx, 3) == 0);
	if (valid_eth && (strlen(ethx) > 3 && strlen(ethx) < 6)) {
		if (strlen(ethx) == 4) {
			valid_eth = isdigit(ethx[3]);
		} else {
			valid_eth = ethx[3] != '0' && isdigit(ethx[3]) && isdigit(ethx[4]);
		}		
	}
	
		
	if (!valid_eth) {
		fprintf(stderr, "ERROR: ethX not recognized.\n");

		return 106;  //ethx not recognized
	}
		
	err = execl("/sbin/ifup", ethx, (char *) NULL);
		
	fprintf(
		stderr, 
		"ERROR: connectWired(): "
		"\"/sbin/ifup %s\" failed; err=%d\n",
		ethx, err
	);
			
	return err;
}

int connectionConnect(
	const char * essid
) {
	char filename[1024];
	char * encoded_essid;
	int err;

	err = encode_essid_alloc(essid, &encoded_essid);

	if(err!=0) {
		fprintf(stderr, "ERROR: essid_encode_alloc(essid=%s) failed; err=%d\n", essid, err);

		return err;
	}

	err = encode_essid(essid, &encoded_essid);

	if(err!=0) {
		fprintf(stderr, "ERROR: essid_encode(essid=%s) failed; err=%d\n", essid, err);
		
		return err;
	}

	err = snprintf(filename, 1024, "%s/%s", IFACES_PATH, encoded_essid);

	if(err<0) {
		fprintf(stderr, "ERROR: snprintf(filename) failed; err=%d\n", err);
		
		return err;
	}

	fprintf(stderr, "DEBUG: now executing: /sbin/ifup wlan0 -i %s\n", filename); // DEBUG

	err = execl("/sbin/ifup", "ifup", "wlan0", "-i", filename, (char *) NULL);

	fprintf(
		stderr, 
		"ERROR: connectionConnect(): "
		"\"/sbin/ifup wlan0 -i %s\" failed; err=%d\n",
		filename, err
	);

	return err;
}

int disconnectActiveConnection()
{
	int err = execl("/sbin/ifdown", "ifdown", "wlan0", (char *) NULL);

	fprintf(
		stderr, 
		"ERROR: disconnectActiveConnection(): "
		"\"/sbin/ifdown wlan0\" failed; err=%d\n",
		err
	);

	return err;
} 

int power_scan(scan_type scan)
{
	const char *command_up = "/sbin/ifconfig wlan0 up";
	int status;
	FILE * shell_reader;
	char * scan_buffer;
	int err;

	scan_buffer = calloc(1024, 1);

	if(!scan_buffer) {
		fprintf(
			stderr, 
			"ERROR: power_scan(): "
			"could not allocate 104 bytes for scan_buffer (Error: %s)\n", 
			strerror(errno)
		);

		return -1;
	}

	status = system(command_up);

	if(status==-1 || !WIFEXITED(status)) {
		fprintf(
			stderr, 
			"ERROR: power_scan(): "
			"\"%s\" did not exit regularly (status=%d).\n", 
			command_up, status
		);

		return status;
	}
	else if (0 != WEXITSTATUS(status)) {
		fprintf(
			stderr, "ERROR: power_scan(): "
			"\"%s\" did not exit successfully (status=%d).\n", 
			command_up, WEX

Re: [DNG] What's /dev/bus/usb?

[Jude Nelson]

/dev/bus/usb/* are USB devices, organized by the kernel-assigned USB bus
number and USB device number (i.e.
/dev/bus/usb/$USB_BUS_ID/$USB_DEVICE_ID).  This includes not only USB
devices like mice and Web cameras, but also USB hubs and controllers.

Vdev creates the /dev/bus/usb/* device files as well.

-Jude

On Thu, Aug 27, 2015 at 9:43 AM, Steve Litt 
wrote:

> Hi all,
>
> What's /dev/bus/usb? On Wheezy, this is where you must aim your
> inotifywait command to detect insertion and removal of flash drives.
>
> Is /dev/bus/usb used on Devuan?
>
> Is /dev/bus/usb a udev thang, and if so, does vdev continue the
> tradition?
>
> Thanks,
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What's /dev/bus/usb?

[tilt!]

Hi Steve,

On 08/27/2015 03:43 PM, Steve Litt wrote:

Hi all,

What's /dev/bus/usb? On Wheezy, this is where you must aim your
inotifywait command to detect insertion and removal of flash drives.


As I understand it, it is a concatenation from the dev directory
root (which is /dev) and a "syspath", provided by the kernel
(that is bus/usb). The concatenation is performed by udev and
applied as result of a builtin rule (i.e. this is not in
/lib/udev/rules.d or whatever).


Is /dev/bus/usb used on Devuan?


Apparently so.

 lsb_release -id && ls -ld /dev/bus/usb/001/001
 Distributor ID:Devuan
 Description:   Devuan GNU/Linux 2.0 (ascii)
 crw-rw-r-- 1 root root 189, 0 Aug 19 04:55 /dev/bus/usb/001/001

It is a drop-in replacement for the previous usbfs which was mounted
at /proc/bus/usb. As I understand it, it has the same layout and
implements a subset of the former's features.


Is /dev/bus/usb a udev thang, and if so, does vdev continue the
tradition?


I could not yet identify the exact code that accomplishes this
syspath and/or device path naming either in kernel or in udev.

On the vdev end, it's much easier, the code that implements is:

https://github.com/jcnelson/vdev/blob/master/vdevd/helpers/LINUX/usb-name.sh

So the answer to the second part of your question is yes.

Kind regards,
T.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] What's /dev/bus/usb?

[tilt!]

Hi Jude,

next time before I hit "send" I check for new mails first! :)

Best regards,
T.

On 08/27/2015 04:52 PM, Jude Nelson wrote:> /dev/bus/usb/* are USB 
devices, organized by the kernel-assigned USB bus

> number and USB device number (i.e.
> /dev/bus/usb/$USB_BUS_ID/$USB_DEVICE_ID).  This includes not only USB
> devices like mice and Web cameras, but also USB hubs and controllers.
>
> Vdev creates the /dev/bus/usb/* device files as well.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[tilt!]

Usage:

execl(full_pathname, runas, arg1, arg2, ..., NULL)

in this case:

full_pathname = /bin/ifup
runas = ifup
arg1 = eth0

Regards,
T.

Am 27. August 2015 16:40:49 MESZ, schrieb Edward Bartolo :
>I added another function to core_functions.c. It attempts to connect
>to eth0 but for some weird reason, probably a bug not from our part,
>it is failing.
>
>The function is:  int connectWired(const char ethx)
>
>And the error is: (passed command to execl is "ifup eth0")
>"This command should be called as ifup, ifdown, or ifquery"
>
>Any pointers as to what is the cause are appreciated.
>
>Edward
>
> [...]

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Steve Litt]

On Thu, 27 Aug 2015 15:40:49 +0100
Edward Bartolo  wrote:

> I added another function to core_functions.c. It attempts to connect
> to eth0 but for some weird reason, probably a bug not from our part,
> it is failing.
> 
> The function is:  int connectWired(const char ethx)
> 
> And the error is: (passed command to execl is "ifup eth0")
> "This command should be called as ifup, ifdown, or ifquery"
> 
> Any pointers as to what is the cause are appreciated.

You might get lucky by sending execl the full path to ifup, perhaps
it's /sbin/ifup and execl didn't send the environment.



SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Edward Bartolo]

It worked.

Now, I must find a way to determine whether we can communicate with a
router. Found that also.

"ip a | grep wlan0"
With wifi switched on and connection active: state UP

With wifi turned off and connection still active: state DOWN

That is what I need.


Edward

On 27/08/2015, Steve Litt  wrote:
> On Thu, 27 Aug 2015 15:40:49 +0100
> Edward Bartolo  wrote:
>
>> I added another function to core_functions.c. It attempts to connect
>> to eth0 but for some weird reason, probably a bug not from our part,
>> it is failing.
>>
>> The function is:  int connectWired(const char ethx)
>>
>> And the error is: (passed command to execl is "ifup eth0")
>> "This command should be called as ifup, ifdown, or ifquery"
>>
>> Any pointers as to what is the cause are appreciated.
>
> You might get lucky by sending execl the full path to ifup, perhaps
> it's /sbin/ifup and execl didn't send the environment.
>
>
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] netman GIT project

[Edward Bartolo]

Also successfully detected multiple simultaneously active connections
from Lazarus code. The next step will be to implement network
connection identification in C code.

After that, I will do my next commit to git.devuan.org


Automatic searching for Wifi hotspots probably will need a separate
thread to simplify the code, although I am confident this can be
achieved from the main thread without crippling it. However, without a
separate thread, the code will be far more complex and difficult to
read.

I am opting for a separate thread.

Edward

On 27/08/2015, Edward Bartolo  wrote:
> It worked.
>
> Now, I must find a way to determine whether we can communicate with a
> router. Found that also.
>
> "ip a | grep wlan0"
> With wifi switched on and connection active: state UP
>
> With wifi turned off and connection still active: state DOWN
>
> That is what I need.
>
>
> Edward
>
> On 27/08/2015, Steve Litt  wrote:
>> On Thu, 27 Aug 2015 15:40:49 +0100
>> Edward Bartolo  wrote:
>>
>>> I added another function to core_functions.c. It attempts to connect
>>> to eth0 but for some weird reason, probably a bug not from our part,
>>> it is failing.
>>>
>>> The function is:  int connectWired(const char ethx)
>>>
>>> And the error is: (passed command to execl is "ifup eth0")
>>> "This command should be called as ifup, ifdown, or ifquery"
>>>
>>> Any pointers as to what is the cause are appreciated.
>>
>> You might get lucky by sending execl the full path to ifup, perhaps
>> it's /sbin/ifup and execl didn't send the environment.
>>
>>
>>
>> SteveT
>>
>> Steve Litt
>> August 2015 featured book: Troubleshooting: Just the Facts
>> http://www.troubleshooters.com/tjust
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where to find the latest Devuan that runs under Qemu?

[fsmithred]

On 08/27/2015 09:38 AM, Steve Litt wrote:
> 
> Where can I find and download the latest Devuan capable of being run on
> Qemu (I assume this means an ISO, unless someone knows another way to
> do it).
> 

If you mean live-ISO, I made one today from an up-to-date alpha2-amd64
netinstall installation in virtualbox. Minimal changes -
added some live-* packages, refracta tools and dependencies.
removed systemd libpam-systemd systemd-shim and the stuff that pulled out
with it.

788MB. This is not an official devuan release (not an official refracta
release, either.)

I could upload it if anyone is interested.

fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where to find the latest Devuan that runs under Qemu?

[Go Linux]

On Thu, 8/27/15, fsmithred  wrote:

 Subject: Re: [DNG] Where to find the latest Devuan that runs under Qemu?
 To: dng@lists.dyne.org
 Date: Thursday, August 27, 2015, 6:23 PM
 
 On 08/27/2015 09:38 AM,
 Steve Litt wrote:
 > 
 >
On 08/27/2015 09:38 AM, Steve Litt wrote:
>>
>> Where can I find and download the latest Devuan capable of being run on
>> Qemu (I assume this means an ISO, unless someone knows another way to
>> do it).
>>
> 
> If you mean live-ISO, I made one today from an up-to-date alpha2-amd64
> netinstall installation in virtualbox. Minimal changes -
> added some live-* packages, refracta tools and dependencies.
> removed systemd libpam-systemd systemd-shim and the stuff that pulled out
> with it.
> 
> 788MB. This is not an official devuan release (not an official refracta
> release, either.)
> 
> I could upload it if anyone is interested.
> 
> fsr
> 



YES I'm interested!  I'm assuming xfce DE.  Does the sources.list point to the 
Devuan repos?  Will it upgrade from there?  About to install Alpha2 here but do 
love the Refracta respins . . .


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where to find the latest Devuan that runs under Qemu?

[Steve Litt]

On Thu, 27 Aug 2015 19:23:43 -0400
fsmithred  wrote:

> On 08/27/2015 09:38 AM, Steve Litt wrote:
> > 
> > Where can I find and download the latest Devuan capable of being
> > run on Qemu (I assume this means an ISO, unless someone knows
> > another way to do it).
> > 
> 
> If you mean live-ISO, I made one today from an up-to-date alpha2-amd64
> netinstall installation in virtualbox. 

I'm interested. Please uploade it.

Another interest: Where can I find an up-to-date alpha2-amd64
netinstall ISO? 



SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where to find the latest Devuan that runs under Qemu?

[Go Linux]

On Thu, 8/27/15, Steve Litt  wrote:

> Subject: Re: [DNG] Where to find the latest Devuan that runs under Qemu?
> To: dng@lists.dyne.org
> Date: Thursday, August 27, 2015, 7:47 PM
> 
> Another interest: Where can I find an up-to-date alpha2-amd64 netinstall ISO? 
>


 
 http://files.devuan.org/


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where to find the latest Devuan that runs under Qemu?

[fsmithred]

On 08/27/2015 08:47 PM, Steve Litt wrote:
> On Thu, 27 Aug 2015 19:23:43 -0400
> fsmithred  wrote:
> 
>> On 08/27/2015 09:38 AM, Steve Litt wrote:
>>>
>>> Where can I find and download the latest Devuan capable of being
>>> run on Qemu (I assume this means an ISO, unless someone knows
>>> another way to do it).
>>>
>>
>> If you mean live-ISO, I made one today from an up-to-date alpha2-amd64
>> netinstall installation in virtualbox. 
> 
> I'm interested. Please uploade it.
> 
> Another interest: Where can I find an up-to-date alpha2-amd64
> netinstall ISO? 
> 
> 
> 

Official downloads:
http://files.devuan.org/

Unofficial devuan-alpha2-amd64-live:
http://distro.ibiblio.org/refracta/files/other/

The live iso is still uploading. Give it until at least 10:15pm EDT
Thursday (2:15am UTC Friday) to finish. Should be 788MB.

fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] wpa_supplicant/ifup integration documentation

[Isaac Dunham]

On Thu, Aug 27, 2015 at 10:29:31AM +0200, Didier Kryn wrote:
> Le 25/08/2015 03:40, Isaac Dunham a ??crit :
> >For your perusal, here's an overview of how they work together; it's a 100+
> >line summary.
> >If anyone wants more details, here are some sources:
> >Manual pages:
> >interfaces(5), wpa_supplicant.conf(5), wpa_supplicant(8), wpa_cli(8),
> >wpa_action(8).
> >Scripts:
> >/sbin/wpa_action
> >/etc/network/if-*.d/wpasupplicant
> >/etc/wpa_supplicant/*.sh
> >(/etc/wpa_supplicant/functions.sh is going to be needed if you want a
> >low-level understanding of what's going on; the script authors have an
> >exceptional capacity for indirection.)
>
> >You will need to read the scripts for a practical understanding of how
> >it works, but the interfaces, wpa_cli, and wpa_action manpages are rather
> >helpful for understanding the glue.
> 
> Thanks, Isaac, I had made my best to RTFM :-) but what I couldn't find
> is how the line wpa_roam ... is passed to the script.

Did you look at the summary I attached?

> Here is the idea I got from looking at the scripts. Any line following
> the iface line is interpreted by ifup in the following way before invoking
> all the scripts:
> 
> The first token in the line is capitallized and prefixed with "IF_",
> then, an environment variable with this name is created and its  value is
> the rest of the line. Each line following the iface line is treated like
> this and all the scripts can then check the enviroment variables. This is

Correct.
man 5 interfaces, IFACE OPTIONS (just over INET ADDRESS FAMILY):
   Additionally,  all  options given in an interface definition stanza are
   exported to the environment in upper case with "IF_" prepended and with
   hyphens  converted  to underscores and non-alphanumeric characters dis-
   carded.

> not the whole story though, since I remember it is also possible to put
> command lines -- I did it a few years ago to configure bonding interfaces.

In man 5 interfaces, IFACE OPTIONS, at the top, see the descriptions of
pre-up, up, post-up, pre-down, down, and post-down options.

These, as well as scripts in /etc/network/if-*.d, are run directly by ifup.

> Therefore, asserting all this is still on my todo list, and maybe the
> only way is to look at the source of ifup, althoug I would have preferred a
> more authoritative description. For now, my feeling is still that it makes
> little sense to set up a parallel framework when what is missing is only a
> tinier version of wpa_gui, and maybe first a curses version.

wpa_config is supposed to be that curses version, though I'm sure it's
a long way off.
I could make something similar to wpa_config but using wpa_cli more
rather than writing a config file; *however*, this would be harder to
edit and would lose comments if you make the changes permanent.

Anyhow, ifup/wpa_supplicant integration features two paths:
-roaming/user-specified config file, as shown in wpa_action(8)
 Here, you have two files: interfaces and wpa_supplicant.conf
 wpa_config (but not the rest of wpanet) works with this method,
 and might eventually be enhanced for static configuration via this
 method.

-configuration in /etc/network/interfaces
 Here, you specify
...
wpa-ssid mynetwork
wpa-psk  "topsecret"
 in the configuration for a logical interface.
 Presumably, one *could* parse 
 iwlist IFACE scanning
 in a mapping script, though it's a brittle approach.

Edward and tilt! seem to be working on a tool that simply writes
a new interfaces file for the second approach.
wpanet is a knockoff of the first, originally intended for Busybox-based
systems.

HTH,
Isaac Dunham

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng