Hi Edward,
I thick you must change all the headers like:
#include "paths.h"
#include "automated_scanner.h"
#include "core_functions.h"
#include "caller.h"
etc... in the *.c files of the backend of netman by:
#include "../include/paths.h"
#include "../include/automated_scanner.h"
#include "../include/core_functions.h"
#include "../include/caller.h"
because they are not found by the compiler.
Cheers,
Aitor.
On 14/09/15 09:24, Edward Bartolo wrote:
Hi,
I tested my installation, Devuan 64 bit, for unwanted behaviour when
/etc/network/interfaces contains lines as follows but which point to
inexistent physical devices:
iface wlan1 inet dhcp
The OS didn't complain and I was able to use netman as usual without
the least of issues. Needless to state, I kept the original "iface
wlan0 inet dhcp".
This is with "iface wlan1 inet dhcp" present in /etc/network/interfaces:
# ifup wlan1
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Cannot find device "wlan1"
Bind socket to interface: No such device
If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug. These pages explain the proper
process and the information we find helpful for debugging..
exiting.
Failed to bring up wlan1.
And this is with "iface wlan1 inet dhcp" removed from /etc/network/interfaces:
root@edbarx-pc:/dev# ifup wlan1
Ignoring unknown interface wlan1=wlan1.
Both instances fail to connect but with different error messages.
Edward.
On 14/09/2015, Edward Bartolo <edb...@gmail.com> wrote:
Hi all,
The additional ability to recognize wlan1, wlan2, wlan3, etc, in
something I will do as soon as I can.
Regarding the use of "iface wlan0 inet dhcp" in
/etc/network/interfaces, I have no other option unless someone really
versed in network configuration provides an alternative that works and
that doesn't disrupt the already working code.
I have already a germinating idea of how to implement support for
wlanN. This is by naming the essid files as wlanX_essid. This way only
the essid saving function and the frontend essid listing functions
would need to be changed. The connecting functions of the backend
would simply parse the filename to extract the device name, and it
would be done.
However, at this time of the year, I am very busy doing other work
besides programming for Devuan. At the moment, I am busy planting my
vegetables which cannot wait as that depends on the season, and a
couple of weeks makes a whole difference.
Edward
On 13/09/2015, aitor_czr <aitor_...@gnuinos.org> wrote:
Ok, I like XFCE4 of course.
Aitor.
El 13/09/15 a las 20:13, Edward Bartolo escribió:
Hi aitor, I forgot to write that the final step is to let netman be
automatically run as soon as a user boots into XFCE4 or desktop or
window manager. Edward On 13/09/2015, Edward Bartolo <edb...@gmail.com>
wrote:
Hi aitor,
I think, the time has come to start thinking about producing a .deb
package for netman. However, we will have to use a post installation
script to add the line:
"iface wlan0 inet dhcp"
to /etc/network/interfaces. The script has also to create a new
directory under /usr/bin with the name netman ie /usr/bin/netman will
hold both the frontend and the backend.
The SUID for backend must be changed to that belonging to root. I do
this as follows:
chown root:root backend
chmod u+s backend
A new directory under /etc/network with the name wifi must be created
i.e. /etc/network/wifi must be an existing directory.
Then, the final steps would be to create a launcher for netman, the
frontend. To enable automatic attempts at connecting basing on
installed essid files under /etc/network/wifi, the parameter
--auto-conn must be passed to netman upon invocation. --auto-conn need
not be used and netman would not attempt to connect without user
intervention. This feature is for those who want to control what
happens on their machine.
Edward
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
