[DNG] curated list of news
FYI just found out devuan on voat https://voat.co/v/devuan to whoever concerns, thanks for curating this section! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Since eth0 is usually configured in /etc/network/interfaces, and a
normal installation creates a functioning interfaces file, I think, it
is better to leave what works unchanged. The backend can be modified a
little to call "ifup eth0", and if more than one ethX exist, which is
highly improbable on a mobile computer, I can use a separate directory
/etc/network/ethx, to use its respective interfaces file.
The most practical way, as I see it, is to provide functionality for
wifi support: wired connections are usually upped automatically by the
system without the need of additional software. So, the choice is
between adding otherwise existent functionality in the base system and
further complicate the backend, or using the KISS principle.
Obviously, supporting wlan1,, wlanN, is also on my agenda.
Edward
On 24/08/2015, Tilman Kranz wrote:
> Hi Edward,
>
> Alright! The project was uploaded to
>
> https://git.devuan.org/tilt/netman
>
> You have Master permissions for this project, you should be able
> to change everything to your liking.
>
> For example, you could transfer the entire thing into the "edbarx"
> namespace, so that people see that it's your project, not mine! :-D
>
> To do this:
>
> 1. Log into gitlab
> 2. Go to https://git.devuan.org/tilt/netman/edit
> 3. Scroll down until you see "Transfer project"
> 4. You should see "edbarx" as a namespace option.
>
>
> Kind regards,
> Tilman
>
> On 08/24/2015 08:51 PM, Edward Bartolo wrote:
>> Hi Tilman Kranz,
>>
>> I created a gitlab account as instructed with the user name edbarx
>>
>> The aim of my project is to help the open source cause, therefore it
>> should be public, but I am open to suggestions, as you have more
>> experience than me.
>>
>>
>> Edward
>>
>> On 24/08/2015, Tilman Kranz wrote:
>>> Hi Edward,
>>>
>>> the "netman" source is good, it builds well and works well. Now:
>>>
>>> (1) I would like to make a project called "netman" on Devuan gitlab
>>>
>>> https://git.devuan.org/
>>>
>>> Please create yourself an account there:
>>>
>>> https://git.devuan.org/users/sign_in?redirect_to_referer=yes
>>>
>>> and let me know your username there.
>>>
>>> (2) I will mark the "netman" project "private" and configure it so
>>> that only you and I can see it.
>>>
>>> (3) I will make GPLv3 headers in all source files, with a copyright
>>> note as follows:
>>>
>>> In the frontend:
>>>
>>> {* Copyright (c) 2015 Edward Bartolo *}
>>>
>>> In the backend:
>>>
>>> /* Copyright (c) 2015 Edward Bartolo */
>>>
>>> In the backend in essid_encoder.c/h (because I wrote that stuff):
>>>
>>> /* Copyright (c) 2015 Tilman Kranz */
>>>
>>> I will add a file LICENSE.txt that contains the GPLv3.
>>>
>>> Then I upload the sources into the project.
>>>
>>> (4) Then you can browse the project sourcecode, work with it,
>>> and get yourself accustomed to it.
>>>
>>> (5) If you like it and think it's fine to go, we can change
>>> the project from "private" to "internal" or "public",
>>> and other people can start working with it.
>>>
>>> Is that OK for you?
>>>
>
>
> --
> Tilman Kranz
> Freiberuflicher IT-Berater
> Wolfstraߟe 17
> D-74937 Spechbach
>
> Telefon (mobil): +49 162 9292803
> Telefon (fest): +49 6226 786368
> E-Mail: t.kr...@tk-sls.de
> Web: https://tk-sls.de
>
> UStID: DE298433832
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Hi Edward, On 08/25/2015 12:51 PM, Edward Bartolo wrote: [...] Please accept merge request #1 "cleanup of backend binaries". I forgot to add backend_src to the cleanup routine. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Hi Tilman Kranz, What should I do? Could give me more details as to what I should do, please? Edward On 25/08/2015, tilt! wrote: > Hi Edward, > > On 08/25/2015 12:51 PM, Edward Bartolo wrote: >> [...] > > Please accept merge request #1 "cleanup of backend binaries". > > I forgot to add backend_src to the cleanup routine. > > Kind regards, > T. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
"tilt!" writes:
> Hi Edward,
>
> On 08/25/2015 12:51 PM, Edward Bartolo wrote:
>> [...]
>
> Please accept merge request #1 "cleanup of backend binaries".
Two random remarks:
,
| size_t essid_safe_strlen(uint8_t * bytes)
| {
| size_t result;
|
| if(!bytes)
| return 0;
|
| result = 0;
|
| while(*bytes != 0) {
| bytes++;
| result++;
| }
|
| return result;
| }
`
A C string of length 0 is just a "\000". A NULL pointer is not a string.
Reimplementing strlen is - apart from that - a rather bizarre idea. A
usual implementation would look somewhat like this:
size_t strlen(char *s)
{
char *r;
r = s;
while (*r) ++r;
return r - s;
}
ie, it's not necessary to maintain a separate byte counter.
,
| uint8_t essid_allowed_chars[] =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-";
|
| [...]
|
| int essid_allowed_char(uint8_t c) {
| size_t i;
| size_t k;
|
| int rv;
|
| rv = 0;
|
| k = essid_safe_strlen(essid_allowed_chars);
|
| for (i=0; ihttps://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Hi, On 08/25/2015 02:09 PM, Rainer Weikusat wrote: > Considering that this enforces some kind of 'bastard URL-encoding' > (using + as prefix instead of %) for all other bytes, it's also going > make people who believe that UTF-8 would be a well supported way to > represent non-ASCII characters very unhappy. 1. This encoding is not about URLs but filenames. Your wording "bastard URL-encoding" is unclear to me, apart from that i would much prefer it if you could restrain yourself from using pejoratives when doing code reviews. However, should "+" for some reason turn out to be an undesireable escape character, it can be changed easily. 2. It is not safe to assume that SSIDs contain UTF-8. The relevant IEEE standard is botched. https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29 "Note that the 2012 version of the 802.11 standard defines a primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8, indicating how the array of octets can be interpreted." Imagining how many service sets still operate using the pre-2012 standard (and/or are botched implementations themselves that fail to recognize the issue), i think it is safe to assume that the character encoding of an SSID is "UNSPECIFIED" in the general case. Therefore, it is handled encoding-agnostic on a byte-per-byte basis, and this is what the code accomplishes. As i see it, when we have the main concerns of security of the installation under control, I will willingly contribute to evaluation of a (possible) scan result SSIDEncoding. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
"tilt!" writes: > On 08/25/2015 02:09 PM, Rainer Weikusat wrote: >> Considering that this enforces some kind of 'bastard URL-encoding' >> (using + as prefix instead of %) for all other bytes, it's also going >> make people who believe that UTF-8 would be a well supported way to >> represent non-ASCII characters very unhappy. > > 1. This encoding is not about URLs but filenames. > >Your wording "bastard URL-encoding" is unclear to me, apart from >that i would much prefer it if you could restrain yourself >from using pejoratives when doing code reviews. 'URL encoding' is part of an internet standard. Since you're basically using the same method (possibly unknowingly) but with a +-prefix instead of the usual %-prefix, that classifies as "bastard URL encoding". AFAIK, 'bastard' means 'illegitmate child'. I don't know what else it means or what else it can be construed to mean. > 2. It is not safe to assume that SSIDs contain UTF-8. > >The relevant IEEE standard is botched. > >https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29 > >"Note that the 2012 version of the 802.11 standard defines a >primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8, >indicating how the array of octets can be interpreted." > >Imagining how many service sets still operate using the pre-2012 >standard (and/or are botched implementations themselves that fail >to recognize the issue), i think it is safe to assume that the >character encoding of an SSID is "UNSPECIFIED" in the general case. > >Therefore, it is handled encoding-agnostic on a byte-per-byte basis, >and this is what the code accomplishes. The code replaces everything which is neither an ASCII letter nor a digit nor - with a three byte escape sequence composed of + followed by the hexadecimal representation of the byte value. This implies that it will eliminate any use of non-ASCII letters both UTF-8 and otherwise. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, Aug 25, 2015 at 01:09:27PM +0100, Rainer Weikusat wrote:
> "tilt!" writes:
>
> > Hi Edward,
> >
> > On 08/25/2015 12:51 PM, Edward Bartolo wrote:
> >> [...]
> >
> > Please accept merge request #1 "cleanup of backend binaries".
>
> Two random remarks:
>
> ,
> | size_t essid_safe_strlen(uint8_t * bytes)
> | {
> | size_t result;
> |
> | if(!bytes)
> | return 0;
> |
> | result = 0;
> |
> | while(*bytes != 0) {
> | bytes++;
> | result++;
> | }
> |
> | return result;
> | }
> `
>
> A C string of length 0 is just a "\000". A NULL pointer is not a string.
> Reimplementing strlen is - apart from that - a rather bizarre idea. A
> usual implementation would look somewhat like this:
>
> size_t strlen(char *s)
> {
> char *r;
>
> r = s;
> while (*r) ++r;
> return r - s;
> }
>
> ie, it's not necessary to maintain a separate byte counter.
>
> ,
> | uint8_t essid_allowed_chars[] =
> "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-";
> |
> | [...]
> |
> | int essid_allowed_char(uint8_t c) {
> | size_t i;
> | size_t k;
> |
> | int rv;
> |
> | rv = 0;
> |
> | k = essid_safe_strlen(essid_allowed_chars);
> |
> | for (i=0; i | if(c==essid_allowed_chars[i]) {
> | rv = 1;
> |
> | break;
> | }
> |
> | return rv;
> | }
> `
>
> A more sensible simple way to implement this would be
>
> char *essid_allowed_chars =
> "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-";
>
> int essid_allowed_char(int c)
> {
> return strchr(essid_allowed_chars, c) != NULL;
> }
>
> Considering that this enforces some kind of 'bastard URL-encoding'
> (using + as prefix instead of %) for all other bytes, it's also going
> make people who believe that UTF-8 would be a well supported way to
> represent non-ASCII characters very unhappy.
The Korean encoding before UTF-8 used two-byte characters. Sone of
those characters contained zero bytes as parts of a two-byte nonzero
encoding.
I had to use environment-dependent string copying to get that one right.
-- hendrik
> ___
> 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
On Tue, 25 Aug 2015 13:09:27 +0100, Rainer Weikusat wrote:
> ,
> | uint8_t essid_allowed_chars[] =
> "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-";
> |
> | [...]
> |
> | int essid_allowed_char(uint8_t c) {
> | size_t i;
> | size_t k;
> |
> | int rv;
> |
> | rv = 0;
> |
> | k = essid_safe_strlen(essid_allowed_chars);
> |
> | for (i=0; i | if(c==essid_allowed_chars[i]) {
> | rv = 1;
> |
> | break;
> | }
> |
> | return rv;
> | }
> `
>
> A more sensible simple way to implement this would be
>
> char *essid_allowed_chars =
> "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-";
>
> int essid_allowed_char(int c)
> {
> return strchr(essid_allowed_chars, c) != NULL;
> }
One minor nitpick, SCNR:
To exactly replicate the behavior that last line should read:
return c && ( strchr(essid_allowed_chars, c) != NULL );
or simply:
return c && strchr(essid_allowed_chars, c);
Rationale: strchr considers the terminating null character to be
part of the string, whereas the original code does not. (Not that
it would matter yet, given how the function is currently used in
the context of the original code, but it's the kind of thing that
tends to bite later on.)
--
Irrwahn
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] remove systemd for the love of Yog-Sothoth already
On Mon, 2015-08-24 at 17:09 +0200, aitor_czr wrote: > Hi Svante, > > Pristine-tar branch guarantees a constant checksum in the sources > *.bz2. The packager should not make changes in the source (this is > only for the developer), all the changes must be done in the debian > branch using quilt. Shortly i will write a little guide explaining how > to create the pristine-tar branch (Joey Hess wrote something about > that), etc... pristine-tar is needed to build the source package with dpkg-buildpackage (dpkg-source -b builds the source file). However I still have not found out how to build the source package from the pristine-tar branch and the binary files with dpkg-buildpackage. > On 24/08/15 14:00, Svante Signell wrote: > > > This issue is still hindering me from fully maintain packages, a clear > > TODO is needed, preferably somewhere on the Devuan website. I meant a developers guide here :) > > I've started > > writing one but it is just started. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, 25 Aug 2015 13:49:39 +0100, Rainer Weikusat wrote: > "tilt!" writes: >> On 08/25/2015 02:09 PM, Rainer Weikusat wrote: >>> Considering that this enforces some kind of 'bastard URL-encoding' >>> (using + as prefix instead of %) for all other bytes, it's also going >>> make people who believe that UTF-8 would be a well supported way to >>> represent non-ASCII characters very unhappy. >> >> 1. This encoding is not about URLs but filenames. >> 2. It is not safe to assume that SSIDs contain UTF-8. >> >>The relevant IEEE standard is botched. >> >>https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29 >> >>"Note that the 2012 version of the 802.11 standard defines a >>primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8, >>indicating how the array of octets can be interpreted." >> >>Imagining how many service sets still operate using the pre-2012 >>standard (and/or are botched implementations themselves that fail >>to recognize the issue), i think it is safe to assume that the >>character encoding of an SSID is "UNSPECIFIED" in the general case. >> >>Therefore, it is handled encoding-agnostic on a byte-per-byte basis, >>and this is what the code accomplishes. > > The code replaces everything which is neither an ASCII letter nor a > digit nor - with a three byte escape sequence composed of + followed by > the hexadecimal representation of the byte value. This implies that it > will eliminate any use of non-ASCII letters both UTF-8 and otherwise. Since the encoding is solely used to construct names for configuration files (one per SSID), the only inconvenience I can think of is you might end up with completely unintelligible names for those files, and only in extreme cases. AIUI these files are not intended to be maintained by a user or administrator but rather only be created, manipulated or destroyed by the software. Unless you are manually debugging the software in an environment which is crowded with wireless stations "é", "á", "ç" and the like, you shouldn't worry too much about it. As a user, you shouldn't care at all - could as well use a sensible hashing algorithm, or some database, or black magic. Or just go with hex encoding from the get go, since an SSID is just a sequence of octets. "\x00\x00\x00\x00" (in C string literal notation) would make a perfectly fine SSID, composed of five (sic!) null bytes, but it is not a sensible code sequence in any character set I am aware of. It is totally sensible to break down the character set to something that is more or less guaranteed to be valid for building names in any file system currently in use on this planet. That having said, I'm not sure how the dash (minus) ended up in the allowed character set, as this would allow for names starting with '-', which is not something I would consider good style, but other's mileages may vary. As mentioned above: if there is any real issue with the code at all, it is the fact that null characters (zero bytes) are not handled correctly by the code. But that's a feat it has in common with many consumer WiFi appliance configuration utilities (and a pile of professional tools too, I suspect). -- Irrwahn ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Irrwahn writes: > On Tue, 25 Aug 2015 13:49:39 +0100, Rainer Weikusat wrote: >> "tilt!" writes: >>> On 08/25/2015 02:09 PM, Rainer Weikusat wrote: Considering that this enforces some kind of 'bastard URL-encoding' (using + as prefix instead of %) for all other bytes, it's also going make people who believe that UTF-8 would be a well supported way to represent non-ASCII characters very unhappy. >>> >>> 1. This encoding is not about URLs but filenames. > > > >>> 2. It is not safe to assume that SSIDs contain UTF-8. >>> >>>The relevant IEEE standard is botched. >>> >>>https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29 >>> >>>"Note that the 2012 version of the 802.11 standard defines a >>>primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8, >>>indicating how the array of octets can be interpreted." >>> >>>Imagining how many service sets still operate using the pre-2012 >>>standard (and/or are botched implementations themselves that fail >>>to recognize the issue), i think it is safe to assume that the >>>character encoding of an SSID is "UNSPECIFIED" in the general case. >>> >>>Therefore, it is handled encoding-agnostic on a byte-per-byte basis, >>>and this is what the code accomplishes. >> >> The code replaces everything which is neither an ASCII letter nor a >> digit nor - with a three byte escape sequence composed of + followed by >> the hexadecimal representation of the byte value. This implies that it >> will eliminate any use of non-ASCII letters both UTF-8 and otherwise. > > Since the encoding is solely used to construct names for configuration > files (one per SSID), the only inconvenience I can think of is you might > end up with completely unintelligible names for those files, and only in > extreme cases. AIUI these files are not intended to be maintained by a user > or administrator but rather only be created, manipulated or destroyed by > the software. > > Unless you are manually debugging the software in an environment which is > crowded with wireless stations "é", "á", "ç" and the like, you > shouldn't worry too much about it. As a user, you shouldn't care at all - > could as well use a sensible hashing algorithm, or some database, or black > magic. Or just go with hex encoding from the get go, since an SSID is just > a sequence of octets. "\x00\x00\x00\x00" (in C string literal notation) > would make a perfectly fine SSID, composed of five (sic!) null bytes, but > it is not a sensible code sequence in any character set I am aware of. > > It is totally sensible to break down the character set to something that > is more or less guaranteed to be valid for building names in any file > system currently in use on this planet. This targets Linux with no chance of (and no intention to be) portable to anything else as it's basically a wrapper around a bunch of Linux (and even Debian) commands. There are exactly two bytes/ chars which must not appear in a filename under these circumstances, '\0' and '/'. Anything else is valid. Encoding other non-printable characters makes some sense in case these files are intended to be perused by humans, however, if this is not intended, it can as well be skipped as software doesn't need to 'look' at graphemes to distinguish byte sequences. Blindly extending this to "anything with bit 8 set" means it will replace all non-ASCII characters with "something completely unintelligible to humans" despite the machine still doesn't care. And that's not only the odd 'national characters' which appear in Western European alphabets but potentially, completely independent ones like Greek of Cyrillic. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Quote: Rainer Wrote: < my_little_vector_that_can_hold_anything; OR, if my memory serves me right, C's: void** weirdo_var; Therefore, to push variables onto the list, it requires type casting, which is fully supported, and dynamic allocation functions to allocate and FREE memory. On 25/08/2015, Irrwahn wrote: > On Tue, 25 Aug 2015 13:49:39 +0100, Rainer Weikusat wrote: >> "tilt!" writes: >>> On 08/25/2015 02:09 PM, Rainer Weikusat wrote: Considering that this enforces some kind of 'bastard URL-encoding' (using + as prefix instead of %) for all other bytes, it's also going make people who believe that UTF-8 would be a well supported way to represent non-ASCII characters very unhappy. >>> >>> 1. This encoding is not about URLs but filenames. > > > >>> 2. It is not safe to assume that SSIDs contain UTF-8. >>> >>>The relevant IEEE standard is botched. >>> >>>https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29 >>> >>>"Note that the 2012 version of the 802.11 standard defines a >>>primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8, >>>indicating how the array of octets can be interpreted." >>> >>>Imagining how many service sets still operate using the pre-2012 >>>standard (and/or are botched implementations themselves that fail >>>to recognize the issue), i think it is safe to assume that the >>>character encoding of an SSID is "UNSPECIFIED" in the general case. >>> >>>Therefore, it is handled encoding-agnostic on a byte-per-byte basis, >>>and this is what the code accomplishes. >> >> The code replaces everything which is neither an ASCII letter nor a >> digit nor - with a three byte escape sequence composed of + followed by >> the hexadecimal representation of the byte value. This implies that it >> will eliminate any use of non-ASCII letters both UTF-8 and otherwise. > > Since the encoding is solely used to construct names for configuration > files (one per SSID), the only inconvenience I can think of is you might > end up with completely unintelligible names for those files, and only in > extreme cases. AIUI these files are not intended to be maintained by a user > or administrator but rather only be created, manipulated or destroyed by > the software. > > Unless you are manually debugging the software in an environment which is > crowded with wireless stations "é", "á", "ç" and the like, you > shouldn't worry too much about it. As a user, you shouldn't care at all - > could as well use a sensible hashing algorithm, or some database, or black > magic. Or just go with hex encoding from the get go, since an SSID is just > a sequence of octets. "\x00\x00\x00\x00" (in C string literal notation) > would make a perfectly fine SSID, composed of five (sic!) null bytes, but > it is not a sensible code sequence in any character set I am aware of. > > It is totally sensible to break down the character set to something that > is more or less guaranteed to be valid for building names in any file > system currently in use on this planet. That having said, I'm not sure how > the dash (minus) ended up in the allowed character set, as this would allow > for names starting with '-', which is not something I would consider good > style, but other's mileages may vary. > > As mentioned above: if there is any real issue with the code at all, it is > the fact that null characters (zero bytes) are not handled correctly by the > code. But that's a feat it has in common with many consumer WiFi appliance > configuration utilities (and a pile of professional tools too, I suspect). > > -- > Irrwahn > > > ___ > 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
Am 25. August 2015 15:52:15 MESZ, >As mentioned above: if there is any real issue with the code at all, it >is >the fact that null characters (zero bytes) are not handled correctly by >the >code. But that's a feat it has in common with many consumer WiFi >appliance >configuration utilities (and a pile of professional tools too, I >suspect). > >-- >Irrwahn Correct. I wonder how iwlist & co. print such SSIDs. Regards, T. -- Sent from mobile thing. Formatting sucks. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
OOOps:
type
TDynamicRecord = record
RecordTypeID: integer;
ActualRecord: Pointer;
end;
should be:
type
TDynamicRecord = record
RecordTypeID: TRecordTypeID;
ActualRecord: Pointer;
end;
On 25/08/2015, Edward Bartolo wrote:
> Quote: Rainer Wrote:
> <
>
> A unallocated variable, be it anything from a simple basic variable
> like an int*, to the most complex of struct variables, is simply a
> placeholder for a memory address, or a pointer devoid of space, apart
> from the space for a memory address.
>
> Pointers can be any type of data. I used to put their flexibility in
> my Delphi Pascal projects. I also used null pointers as follows:
>
> type
>TRecordTypeID = (message0, message1, message2, message3);
>
> var
>aDynamicRecord: Pointer;
>
> type
>TDynamicRecord = record
> RecordTypeID: integer;
> ActualRecord: Pointer;
>end;
>
>
> This is equivalent to:
>
>
> enum TRecordTypeID = {message0, message1, message2, message3};
>
> void* aDynamicRecord;
>
> typedef struct TDynamicRecord {
>TRecordTypeID RecordTypeID;
>void* ActualRecord;
> };
>
>
> Lazarus and Delphi provide a class, TList, which is a list of untyped
> pointers. This is like: C++'s
> vector my_little_vector_that_can_hold_anything;
>
> OR, if my memory serves me right, C's:
> void** weirdo_var;
>
> Therefore, to push variables onto the list, it requires type casting,
> which is fully supported, and dynamic allocation functions to allocate
> and FREE memory.
>
> On 25/08/2015, Irrwahn wrote:
>> On Tue, 25 Aug 2015 13:49:39 +0100, Rainer Weikusat wrote:
>>> "tilt!" writes:
On 08/25/2015 02:09 PM, Rainer Weikusat wrote:
> Considering that this enforces some kind of 'bastard URL-encoding'
> (using + as prefix instead of %) for all other bytes, it's also going
> make people who believe that UTF-8 would be a well supported way to
> represent non-ASCII characters very unhappy.
1. This encoding is not about URLs but filenames.
>>
>>
>>
2. It is not safe to assume that SSIDs contain UTF-8.
The relevant IEEE standard is botched.
https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29
"Note that the 2012 version of the 802.11 standard defines a
primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8,
indicating how the array of octets can be interpreted."
Imagining how many service sets still operate using the pre-2012
standard (and/or are botched implementations themselves that fail
to recognize the issue), i think it is safe to assume that the
character encoding of an SSID is "UNSPECIFIED" in the general case.
Therefore, it is handled encoding-agnostic on a byte-per-byte basis,
and this is what the code accomplishes.
>>>
>>> The code replaces everything which is neither an ASCII letter nor a
>>> digit nor - with a three byte escape sequence composed of + followed by
>>> the hexadecimal representation of the byte value. This implies that it
>>> will eliminate any use of non-ASCII letters both UTF-8 and otherwise.
>>
>> Since the encoding is solely used to construct names for configuration
>> files (one per SSID), the only inconvenience I can think of is you might
>> end up with completely unintelligible names for those files, and only in
>> extreme cases. AIUI these files are not intended to be maintained by a
>> user
>> or administrator but rather only be created, manipulated or destroyed by
>> the software.
>>
>> Unless you are manually debugging the software in an environment which is
>> crowded with wireless stations "é", "á", "ç" and the like,
>> you
>> shouldn't worry too much about it. As a user, you shouldn't care at all -
>> could as well use a sensible hashing algorithm, or some database, or
>> black
>> magic. Or just go with hex encoding from the get go, since an SSID is
>> just
>> a sequence of octets. "\x00\x00\x00\x00" (in C string literal notation)
>> would make a perfectly fine SSID, composed of five (sic!) null bytes, but
>> it is not a sensible code sequence in any character set I am aware of.
>>
>> It is totally sensible to break down the character set to something that
>> is more or less guaranteed to be valid for building names in any file
>> system currently in use on this planet. That having said, I'm not sure
>> how
>> the dash (minus) ended up in the allowed character set, as this would
>> allow
>> for names starting with '-', which is not something I would consider good
>> style, but other's mileages may vary.
>>
>> As mentioned above: if there is any real issue with the code at all, it
>> is
>> the fact that null characters (zero bytes) are not handled correctly by
>> the
>> code. But that's a feat it has in common with many consumer WiFi
>> appliance
>> configuration utilities (and a pile of professional tools too, I
>> suspect).
>>
>> --
>> Irrwahn
>>
>>
>> ___
Re: [DNG] netman GIT project
We can easily avoid having to encode ESSIDs by creating a file
containing a texual lookup table as the following, but since the
project is already functional, it looks like rebuilding a house that
is already habitable.
essid1"my little wifi at home"
essid2"oops, wifi at my partner's!"
essid3"wifi at work, without my boss' knowing"
essid4"wifi at library"
Ok, you get it. No need of encoding anything and the user can describe
his wifi with whatever he deems justified.
Edward
On 25/08/2015, Edward Bartolo wrote:
> OOOps:
>
> type
>TDynamicRecord = record
> RecordTypeID: integer;
> ActualRecord: Pointer;
>end;
>
> should be:
>
> type
>TDynamicRecord = record
> RecordTypeID: TRecordTypeID;
> ActualRecord: Pointer;
>end;
>
> On 25/08/2015, Edward Bartolo wrote:
>> Quote: Rainer Wrote:
>> <> string.
>>
>>
>> A unallocated variable, be it anything from a simple basic variable
>> like an int*, to the most complex of struct variables, is simply a
>> placeholder for a memory address, or a pointer devoid of space, apart
>> from the space for a memory address.
>>
>> Pointers can be any type of data. I used to put their flexibility in
>> my Delphi Pascal projects. I also used null pointers as follows:
>>
>> type
>>TRecordTypeID = (message0, message1, message2, message3);
>>
>> var
>>aDynamicRecord: Pointer;
>>
>> type
>>TDynamicRecord = record
>> RecordTypeID: integer;
>> ActualRecord: Pointer;
>>end;
>>
>>
>> This is equivalent to:
>>
>>
>> enum TRecordTypeID = {message0, message1, message2, message3};
>>
>> void* aDynamicRecord;
>>
>> typedef struct TDynamicRecord {
>>TRecordTypeID RecordTypeID;
>>void* ActualRecord;
>> };
>>
>>
>> Lazarus and Delphi provide a class, TList, which is a list of untyped
>> pointers. This is like: C++'s
>> vector my_little_vector_that_can_hold_anything;
>>
>> OR, if my memory serves me right, C's:
>> void** weirdo_var;
>>
>> Therefore, to push variables onto the list, it requires type casting,
>> which is fully supported, and dynamic allocation functions to allocate
>> and FREE memory.
>>
>> On 25/08/2015, Irrwahn wrote:
>>> On Tue, 25 Aug 2015 13:49:39 +0100, Rainer Weikusat wrote:
"tilt!" writes:
> On 08/25/2015 02:09 PM, Rainer Weikusat wrote:
>> Considering that this enforces some kind of 'bastard URL-encoding'
>> (using + as prefix instead of %) for all other bytes, it's also going
>> make people who believe that UTF-8 would be a well supported way to
>> represent non-ASCII characters very unhappy.
>
> 1. This encoding is not about URLs but filenames.
>>>
>>>
>>>
> 2. It is not safe to assume that SSIDs contain UTF-8.
>
>The relevant IEEE standard is botched.
>
>https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29
>
>"Note that the 2012 version of the 802.11 standard defines a
>primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8,
>indicating how the array of octets can be interpreted."
>
>Imagining how many service sets still operate using the pre-2012
>standard (and/or are botched implementations themselves that fail
>to recognize the issue), i think it is safe to assume that the
>character encoding of an SSID is "UNSPECIFIED" in the general case.
>
>Therefore, it is handled encoding-agnostic on a byte-per-byte
> basis,
>and this is what the code accomplishes.
The code replaces everything which is neither an ASCII letter nor a
digit nor - with a three byte escape sequence composed of + followed by
the hexadecimal representation of the byte value. This implies that it
will eliminate any use of non-ASCII letters both UTF-8 and otherwise.
>>>
>>> Since the encoding is solely used to construct names for configuration
>>> files (one per SSID), the only inconvenience I can think of is you might
>>> end up with completely unintelligible names for those files, and only in
>>> extreme cases. AIUI these files are not intended to be maintained by a
>>> user
>>> or administrator but rather only be created, manipulated or destroyed by
>>> the software.
>>>
>>> Unless you are manually debugging the software in an environment which
>>> is
>>> crowded with wireless stations "é", "á", "ç" and the like,
>>> you
>>> shouldn't worry too much about it. As a user, you shouldn't care at all
>>> -
>>> could as well use a sensible hashing algorithm, or some database, or
>>> black
>>> magic. Or just go with hex encoding from the get go, since an SSID is
>>> just
>>> a sequence of octets. "\x00\x00\x00\x00" (in C string literal notation)
>>> would make a perfectly fine SSID, composed of five (sic!) null bytes,
>>> but
>>> it is not a sensible code sequence in any character set I am aware of.
>>>
>>> It is totally sensible to break down the character set to something that
>>> is more or less guaranteed t
Re: [DNG] netman GIT project
Am 25. August 2015 16:52:41 MESZ, schrieb Edward Bartolo : >We can easily avoid having to encode ESSIDs by creating a file >containing a texual lookup table as the following, but since the >project is already functional, it looks like rebuilding a house that >is already habitable. > >essid1"my little wifi at home" >essid2"oops, wifi at my partner's!" >essid3"wifi at work, without my boss' knowing" >essid4"wifi at library" > >Ok, you get it. No need of encoding anything and the user can describe >his wifi with whatever he deems justified. > >Edward IMHO: If we use a mapfile, we have the encoding problem *there* instead of the wifi directory filenames ... It will only move the problem, not solve it :D i wonder if we ever get to see such SSIDs from iwlist anyway - how is it supposed to print SSIDs that contain the zerobyte ... Kind regards, T. -- Mobile madness! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, 25 Aug 2015 15:24:01 +0100, Rainer Weikusat wrote: > Irrwahn writes: >> It is totally sensible to break down the character set to something that >> is more or less guaranteed to be valid for building names in any file >> system currently in use on this planet. > > This targets Linux with no chance of (and no intention to be) portable > to anything else as it's basically a wrapper around a bunch of Linux > (and even Debian) commands. There are exactly two bytes/ chars which must not > appear in a filename under these circumstances, '\0' and '/'. Anything > else is valid. Encoding other non-printable characters makes some sense > in case these files are intended to be perused by humans, however, if > this is not intended, it can as well be skipped as software doesn't need > to 'look' at graphemes to distinguish byte sequences. Blindly extending > this to "anything with bit 8 set" means it will replace all non-ASCII > characters with "something completely unintelligible to humans" despite > the machine still doesn't care. And that's not only the odd 'national > characters' which appear in Western European alphabets but potentially, > completely independent ones like Greek of Cyrillic. Well, the POSIX "Fully portable filenames" lists these characters: A–Z a–z 0–9 . _ - But you are probably right that we can safely assume modern, sane, unicode aware, "linuxy" filesystems for the case at hand. That leaves us with two reasonable approaches: A) Only escape '/' and '\0' (and the escape character, of course) and leave the rest as-is, making for plain human readable filenames, or B) Hex (or even base64 :P) encode the whole shebang and not give a hoot about readability. Personally, I'd opt for A. And while at it, treat an SSID as what it is: "a sequence of 0 to 32 octets", e.g. pass it around as a buffer with associated length information, just as a wireless station does. I'd go and have a stab at it, if only for the fun of it, but that would affect the backend incantations [*]. And since I wrote my last line of Pascal in 1987, I'd need Edward's consent and assistance. [*] Best way would probably be to escape the SSID in the frontend, pass the encoded "string" and only decode in the backend where actually needed. That way at least the argument handling wouldn't have to change much. -- Irrwahn ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] A better default windows manager
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 signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
For the attention of the packager: I found a way of using a pascal compiler command to compile the Lazarus project without having Lazarus running. The procedure is as follows: cd to-directory-containing-sources Issue this weirdo-of-a-command: fpc-2.6.4 -MObjFPC -Scghi -O1 -Tlinux -g -gl -vewnhi -Filib/x86_64-linux -Fl/opt/gnome/lib -Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux/gtk2 -Fu/usr/lib/lazarus/1.2.4/lcl/units/x86_64-linux -Fu/usr/lib/lazarus/1.2.4/components/lazutils/lib/x86_64-linux -Fu/usr/lib/lazarus/1.2.4/packager/units/x86_64-linux -Fu. -FUlib/x86_64-linux -l -dLCL -dLCLgtk2 netman.lpr Using this command can allow 'make' to compile all sources without using the IDE. Edward On 25/08/2015, Irrwahn wrote: > On Tue, 25 Aug 2015 15:24:01 +0100, Rainer Weikusat wrote: >> Irrwahn writes: > >>> It is totally sensible to break down the character set to something that >>> is more or less guaranteed to be valid for building names in any file >>> system currently in use on this planet. >> >> This targets Linux with no chance of (and no intention to be) portable >> to anything else as it's basically a wrapper around a bunch of Linux >> (and even Debian) commands. There are exactly two bytes/ chars which must >> not >> appear in a filename under these circumstances, '\0' and '/'. Anything >> else is valid. Encoding other non-printable characters makes some sense >> in case these files are intended to be perused by humans, however, if >> this is not intended, it can as well be skipped as software doesn't need >> to 'look' at graphemes to distinguish byte sequences. Blindly extending >> this to "anything with bit 8 set" means it will replace all non-ASCII >> characters with "something completely unintelligible to humans" despite >> the machine still doesn't care. And that's not only the odd 'national >> characters' which appear in Western European alphabets but potentially, >> completely independent ones like Greek of Cyrillic. > > Well, the POSIX "Fully portable filenames" lists these characters: > A–Z a–z 0–9 . _ - > But you are probably right that we can safely assume modern, sane, > unicode aware, "linuxy" filesystems for the case at hand. That leaves > us with two reasonable approaches: > > A) Only escape '/' and '\0' (and the escape character, of course) and > leave the rest as-is, making for plain human readable filenames, or > > B) Hex (or even base64 :P) encode the whole shebang and not give a hoot > about readability. > > Personally, I'd opt for A. And while at it, treat an SSID as what it is: > "a sequence of 0 to 32 octets", e.g. pass it around as a buffer with > associated length information, just as a wireless station does. > > I'd go and have a stab at it, if only for the fun of it, but that would > affect the backend incantations [*]. And since I wrote my last line of > Pascal in 1987, I'd need Edward's consent and assistance. > > [*] Best way would probably be to escape the SSID in the frontend, pass > the encoded "string" and only decode in the backend where actually needed. > That way at least the argument handling wouldn't have to change much. > > -- > Irrwahn > > > > ___ > 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
On Tue, 25 Aug 2015 17:02:55 +0200, Tilt! wrote: > > > Am 25. August 2015 16:52:41 MESZ, schrieb Edward Bartolo : >> We can easily avoid having to encode ESSIDs by creating a file >> containing a texual lookup table as the following, but since the >> project is already functional, it looks like rebuilding a house that >> is already habitable. >> >> essid1"my little wifi at home" >> essid2"oops, wifi at my partner's!" >> essid3"wifi at work, without my boss' knowing" >> essid4"wifi at library" >> >> Ok, you get it. No need of encoding anything and the user can describe >> his wifi with whatever he deems justified. >> >> Edward > > IMHO: > > If we use a mapfile, we have the encoding problem *there* instead of the wifi > directory filenames ... It will only move the problem, not solve it :D > > i wonder if we ever get to see such SSIDs from iwlist anyway - how is it > supposed to print SSIDs that contain the zerobyte ... If we can drop the requirement to cope with '\0's, as the frontend uses iwlist and grep(!) to acquire the SSID, this would leave us with just the '/' to encode. The most "evil" thing we'd had to expect would be "". Thinking about it, one can even do away with all the allocation stuff and just use a single fixed size buffer of 32 * 3 + 1 bytes to hold the filesystem friendly encoded version, since there are no thread safety contraints imposed on the backend. -- Irrwahn ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Irrwahn writes:
> On Tue, 25 Aug 2015 17:02:55 +0200, Tilt! wrote:
>> Am 25. August 2015 16:52:41 MESZ, schrieb Edward Bartolo :
>>> We can easily avoid having to encode ESSIDs by creating a file
>>> containing a texual lookup table as the following, but since the
>>> project is already functional, it looks like rebuilding a house that
>>> is already habitable.
>>>
>>> essid1"my little wifi at home"
>>> essid2"oops, wifi at my partner's!"
>>> essid3"wifi at work, without my boss' knowing"
>>> essid4"wifi at library"
>>>
>>> Ok, you get it. No need of encoding anything and the user can describe
>>> his wifi with whatever he deems justified.
>>>
>>> Edward
>>
>> IMHO:
>>
>> If we use a mapfile, we have the encoding problem *there* instead of the
>> wifi directory filenames ... It will only move the problem, not solve it :D
>>
>> i wonder if we ever get to see such SSIDs from iwlist anyway - how is it
>> supposed to print SSIDs that contain the zerobyte ...
>
> If we can drop the requirement to cope with '\0's, as the frontend
> uses iwlist and grep(!) to acquire the SSID, this would leave us with
> just the '/' to encode. The most "evil" thing we'd had to expect
> would be "".
>
> Thinking about it, one can even do away with all the allocation stuff
> and just use a single fixed size buffer of 32 * 3 + 1 bytes to hold
> the filesystem friendly encoded version, since there are no thread
> safety contraints imposed on the backend.
A suggestion for that: Create something like
struct encoded_essid {
uint8_t d[32 * 3 + 1];
};
and make the caller pass a pointer to that to the encoding routines. It
can then be allocated on the stack by the caller (if the caller so
desires).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Rethinking about it, there is no need to use the ESSID in the table. A table like the following would do the job neatly, in my humble opinion. ESSIDs are already saved in the interfaces files, so a table like the following is enough: 1 "my little wifi at home" 2 "my wifi at work" 3 "wifi at cafe" Users only need to remember the name of connections, not what iwlist found: ESSIDS and passwords are already saved. Using descriptions is more user oriented rather than using ESSIDs. So, the GUI would read this file. Display the pseudo names (user descriptions) and select the interfaces files using the table. For instance, if user clicked "my wifi at work", that would mean, file 2 which obviously already contains an ESSID and password. What we cannot avoid is, that ESSID names, must be of the required standard. I can implement this, but I need the opinion of others. Edward On 25/08/2015, Irrwahn wrote: > On Tue, 25 Aug 2015 17:02:55 +0200, Tilt! wrote: >> >> >> Am 25. August 2015 16:52:41 MESZ, schrieb Edward Bartolo >> : >>> We can easily avoid having to encode ESSIDs by creating a file >>> containing a texual lookup table as the following, but since the >>> project is already functional, it looks like rebuilding a house that >>> is already habitable. >>> >>> essid1"my little wifi at home" >>> essid2"oops, wifi at my partner's!" >>> essid3"wifi at work, without my boss' knowing" >>> essid4"wifi at library" >>> >>> Ok, you get it. No need of encoding anything and the user can describe >>> his wifi with whatever he deems justified. >>> >>> Edward >> >> IMHO: >> >> If we use a mapfile, we have the encoding problem *there* instead of the >> wifi directory filenames ... It will only move the problem, not solve it >> :D >> >> i wonder if we ever get to see such SSIDs from iwlist anyway - how is it >> supposed to print SSIDs that contain the zerobyte ... > > If we can drop the requirement to cope with '\0's, as the frontend > uses iwlist and grep(!) to acquire the SSID, this would leave us with > just the '/' to encode. The most "evil" thing we'd had to expect > would be "". > > Thinking about it, one can even do away with all the allocation stuff > and just use a single fixed size buffer of 32 * 3 + 1 bytes to hold > the filesystem friendly encoded version, since there are no thread > safety contraints imposed on the backend. > > -- > Irrwahn > ___ > 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] A better default windows manager
On Tue, 25 Aug 2015 17:29:43 +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 This is what Edward and Tilt are doing right now, although they're perhaps doing it a little differently than what I'd visualized. Edward's front end happens to be GUI, but a ncurses front end version would be pretty easy. 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] xfce not shutting down on Devuan
I solved installing slim and enabling the auto-login. Even using your config startx didn't worked out... Thank you all! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, 25 Aug 2015 17:06:52 +0100, Edward Bartolo wrote: > Rethinking about it, there is no need to use the ESSID in the table. > A table like the following would do the job neatly, in my humble > opinion. ESSIDs are already saved in the interfaces files, so a table > like the following is enough: > 1 "my little wifi at home" > 2 "my wifi at work" > 3 "wifi at cafe" > > Users only need to remember the name of connections, not what iwlist > found: ESSIDS and passwords are already saved. Using descriptions is > more user oriented rather than using ESSIDs. > > So, the GUI would read this file. Display the pseudo names (user > descriptions) and select the interfaces files using the table. For > instance, if user clicked "my wifi at work", that would mean, file > 2 which obviously already contains an ESSID and password. What we > cannot avoid is, that ESSID names, must be of the required standard. I > can implement this, but I need the opinion of others. Please don't get me wrong, but using a list is IMHO over-complicating the matter. I think your original idea was just fine, and can greatly improved upon, since there is one, and only one, use case for this whole encoding/escaping thing: constructing filenames for storing interface files. Thus, we need only a single function constructing valid path names, and that's it! I hope to be able to show you my stab at your code tommorrow. -- Irrwahn ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, 25 Aug 2015 17:06:52 +0100 Edward Bartolo wrote: > Rethinking about it, there is no need to use the ESSID in the table. > A table like the following would do the job neatly, in my humble > opinion. ESSIDs are already saved in the interfaces files, so a table > like the following is enough: > 1 "my little wifi at home" > 2 "my wifi at work" > 3 "wifi at cafe" > > Users only need to remember the name of connections, not what iwlist > found: ESSIDS and passwords are already saved. Using descriptions is > more user oriented rather than using ESSIDs. > > So, the GUI would read this file. Display the pseudo names (user > descriptions) and select the interfaces files using the table. For > instance, if user clicked "my wifi at work", that would mean, file > 2 which obviously already contains an ESSID and password. What we > cannot avoid is, that ESSID names, must be of the required standard. I > can implement this, but I need the opinion of others. 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
On Tue, 25 Aug 2015 17:06:52 +0100 Edward Bartolo wrote: > Rethinking about it, there is no need to use the ESSID in the table. > A table like the following would do the job neatly, in my humble > opinion. ESSIDs are already saved in the interfaces files, so a table > like the following is enough: > 1 "my little wifi at home" > 2 "my wifi at work" > 3 "wifi at cafe" > > Users only need to remember the name of connections, not what iwlist > found: ESSIDS and passwords are already saved. Using descriptions is > more user oriented rather than using ESSIDs. > > So, the GUI would read this file. Display the pseudo names (user > descriptions) and select the interfaces files using the table. For > instance, if user clicked "my wifi at work", that would mean, file > 2 which obviously already contains an ESSID and password. What we > cannot avoid is, that ESSID names, must be of the required standard. I > can implement this, but I need the opinion of others. Hi Edward, First of all, as far as I can tell, the storage of essids with their passwords is only the back end's business. The front end gets its list of essid candidates directly or indirectly from iwlist $device scanning, and tells the back end what it wants to do and the essid it wants to do it with. As far as the back end, if it becomes a problem to name an interface file after its essid, as long as the essid is reliably greppable, it's trivial to make a command to, in real time, translate essid to interface filename. I imagine most people will have less than 100 essids on record. Grepping 100 interface files takes much less than a second, so there's no performance reason to build an index table. That would improvement with 10,000 or 100,000 essids, but not 100. I think it would help the discussion if you gave us a few examples of these interface files, including at least one for a permanently wired connection. Anyway, the whole point is to keep it simple, so for this application I'd say tables are overkill: Just grep at runtime: in the human perception of time, it's just as fast. 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
Tilt!:
> i wonder if we ever get to see such SSIDs from iwlist anyway -
> how is it supposed to print SSIDs that contain the zerobyte ...
iwlib.c line 989..995:
/* Is it a non-ASCII character ??? */
if(isescape || !isascii(*s) || iscntrl(*s))
{
/* Escape */
sprintf(d, "\\x%02X", *s);
d += 4;
}
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
Re: [DNG] netman GIT project
On Tue, 25 Aug 2015 19:24:17 +0200 (CEST), Karl wrote:
> Tilt!:
>> i wonder if we ever get to see such SSIDs from iwlist anyway -
>> how is it supposed to print SSIDs that contain the zerobyte ...
>
> iwlib.c line 989..995:
> /* Is it a non-ASCII character ??? */
> if(isescape || !isascii(*s) || iscntrl(*s))
> {
> /* Escape */
> sprintf(d, "\\x%02X", *s);
> d += 4;
> }
Thank you. One problem, though:
Not a single version of the Wireless Tools for Linux sources I
happened to stumble upon doing a quick internet search contains
this snippet, or anything remotely like it. Care to share with us,
where this originates? Or give a little more context, particularly
how isescape is set?
Thanks
--
Irrwahn
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Irrwahn:
> On Tue, 25 Aug 2015 19:24:17 +0200 (CEST), Karl wrote:
> > Tilt!:
> >> i wonder if we ever get to see such SSIDs from iwlist anyway -
> >> how is it supposed to print SSIDs that contain the zerobyte ...
> >
> > iwlib.c line 989..995:
> > /* Is it a non-ASCII character ??? */
> > if(isescape || !isascii(*s) || iscntrl(*s))
> > {
> > /* Escape */
> > sprintf(d, "\\x%02X", *s);
> > d += 4;
> > }
>
> Thank you. One problem, though:
> Not a single version of the Wireless Tools for Linux sources I
> happened to stumble upon doing a quick internet search contains
> this snippet, or anything remotely like it. Care to share with us,
> where this originates?
$ apt-get source wireless-tools
$ cd wireless-tools-30~pre9
$ ls iw*.[ch]
iwconfig.c iwevent.c iwgetid.c iwlib.c iwlib.h iwlib-private.h iwlist.c
iwmulticall.c iwpriv.c iwspy.c
$ grep download debian/copyright
It was downloaded from:
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
$
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
under "Wireless Tools latest versions":
///
The main features of the latest beta is support for non-ASCII ESSIDs (such as
localised ESSID), support for displaying Scanning Capabilities, slightly bigger
scan buffer, fixing minor bug iwconfig parser and minor enhancement to ifrename
:
Wireless Tools version 30-pre9 (beta)
///
> Or give a little more context, particularly
> how isescape is set?
iwlib.c line 971..981:
/* Escape the escape to avoid ambiguity.
* We do a fast path test for performance reason. Compiler will
* optimise all that ;-) */
if(*s == '\\')
{
/* Check if we would confuse it with an escape sequence */
if((e-s) > 4 && (s[1] == 'x')
&& (isxdigit(s[2])) && (isxdigit(s[3])))
{
isescape = 1;
}
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
Re: [DNG] netman GIT project
On Tue, 25 Aug 2015 20:20:20 +0200 (CEST), Karl wrote:
> Irrwahn:
>> On Tue, 25 Aug 2015 19:24:17 +0200 (CEST), Karl wrote:
>>> Tilt!:
i wonder if we ever get to see such SSIDs from iwlist anyway -
how is it supposed to print SSIDs that contain the zerobyte ...
>>>
>>> iwlib.c line 989..995:
>>> /* Is it a non-ASCII character ??? */
>>> if(isescape || !isascii(*s) || iscntrl(*s))
>>> {
>>> /* Escape */
>>> sprintf(d, "\\x%02X", *s);
>>> d += 4;
>>> }
>>
>> Thank you. One problem, though:
>> Not a single version of the Wireless Tools for Linux sources I
>> happened to stumble upon doing a quick internet search contains
>> this snippet, or anything remotely like it. Care to share with us,
>> where this originates?
>
> $ apt-get source wireless-tools
> $ cd wireless-tools-30~pre9
> $ ls iw*.[ch]
> iwconfig.c iwevent.c iwgetid.c iwlib.c iwlib.h iwlib-private.h iwlist.c
> iwmulticall.c iwpriv.c iwspy.c
> $ grep download debian/copyright
> It was downloaded from:
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
> $
>
>
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
> under "Wireless Tools latest versions":
> ///
> The main features of the latest beta is support for non-ASCII ESSIDs (such
> as localised ESSID), support for displaying Scanning Capabilities, slightly
> bigger scan buffer, fixing minor bug iwconfig parser and minor enhancement to
> ifrename :
>
> Wireless Tools version 30-pre9 (beta)
> ///
>
>> Or give a little more context, particularly
>> how isescape is set?
>
> iwlib.c line 971..981:
> /* Escape the escape to avoid ambiguity.
>* We do a fast path test for performance reason. Compiler will
>* optimise all that ;-) */
> if(*s == '\\')
> {
> /* Check if we would confuse it with an escape sequence */
> if((e-s) > 4 && (s[1] == 'x')
> && (isxdigit(s[2])) && (isxdigit(s[3])))
> {
> isescape = 1;
> }
Thanks a lot, Karl! I was stupid enough to not simply apt-get the sources.
I checked, it is exactly the function that is used when printing the scan
results.
That makes escaping for file system path purposes quite easy, as everything
is already escaped, except the notorious '/'. however, that is already taken
care of in my modified version of Ed's netman.
Now, what about the consumers? I found out that wpa_supplicant can digest
printf-style escaping, provided the quoted string is prefixed with 'P':
# ssid: SSID (mandatory); network name in one of the optional formats:
# - an ASCII string with double quotation
# - a hex string (two characters per octet of SSID)
# - a printf-escaped ASCII string P""
I was not able to find information on how ifup passes on the information
from the wpa-ssid field. Assuming it is just handed down as is, the only
change in netman would be to prefix the SSID with 'P'.
--
Irrwahn
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
Since, netman does not touch /etc/network/interfaces, the system
should still be able to connect using a wired connection to ethX.
Obviously, the interface has to be activated using ifup ethX.
Therefore, to use a wired connection, the backend should use
/etc/network/interfaces as an interfaces file are simply call "ifup
ethX". I think, there is no need to recreate another interfaces file
which is already there waiting to be used.
The contents of interfaces files created by backend are as follows,
but if necessary, we can create more than more template, although it
doesn't look it will be necessary.
Interfaces File Contents:
auto lo
iface lo inet loopback
iface wlan0 inet dhcp
wpa-ssid EB-TP-LNK67
wpa-psk ""
The above connects to my WIFI. It is simple and always worked for
several years now.
On 25/08/2015, Irrwahn wrote:
> On Tue, 25 Aug 2015 20:20:20 +0200 (CEST), Karl wrote:
>> Irrwahn:
>>> On Tue, 25 Aug 2015 19:24:17 +0200 (CEST), Karl wrote:
Tilt!:
> i wonder if we ever get to see such SSIDs from iwlist anyway -
> how is it supposed to print SSIDs that contain the zerobyte ...
iwlib.c line 989..995:
/* Is it a non-ASCII character ??? */
if(isescape || !isascii(*s) || iscntrl(*s))
{
/* Escape */
sprintf(d, "\\x%02X", *s);
d += 4;
}
>>>
>>> Thank you. One problem, though:
>>> Not a single version of the Wireless Tools for Linux sources I
>>> happened to stumble upon doing a quick internet search contains
>>> this snippet, or anything remotely like it. Care to share with us,
>>> where this originates?
>>
>> $ apt-get source wireless-tools
>> $ cd wireless-tools-30~pre9
>> $ ls iw*.[ch]
>> iwconfig.c iwevent.c iwgetid.c iwlib.c iwlib.h iwlib-private.h
>> iwlist.c iwmulticall.c iwpriv.c iwspy.c
>> $ grep download debian/copyright
>> It was downloaded from:
>> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
>> $
>>
>>
>> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
>> under "Wireless Tools latest versions":
>> ///
>> The main features of the latest beta is support for non-ASCII ESSIDs
>> (such as localised ESSID), support for displaying Scanning Capabilities,
>> slightly bigger scan buffer, fixing minor bug iwconfig parser and minor
>> enhancement to ifrename :
>>
>> Wireless Tools version 30-pre9 (beta)
>> ///
>>
>>> Or give a little more context, particularly
>>> how isescape is set?
>>
>> iwlib.c line 971..981:
>> /* Escape the escape to avoid ambiguity.
>>* We do a fast path test for performance reason. Compiler will
>>* optimise all that ;-) */
>> if(*s == '\\')
>> {
>> /* Check if we would confuse it with an escape sequence */
>> if((e-s) > 4 && (s[1] == 'x')
>> && (isxdigit(s[2])) && (isxdigit(s[3])))
>> {
>> isescape = 1;
>> }
>
> Thanks a lot, Karl! I was stupid enough to not simply apt-get the sources.
> I checked, it is exactly the function that is used when printing the scan
> results.
>
> That makes escaping for file system path purposes quite easy, as everything
> is already escaped, except the notorious '/'. however, that is already taken
> care of in my modified version of Ed's netman.
>
> Now, what about the consumers? I found out that wpa_supplicant can digest
> printf-style escaping, provided the quoted string is prefixed with 'P':
>
> # ssid: SSID (mandatory); network name in one of the optional formats:
> # - an ASCII string with double quotation
> # - a hex string (two characters per octet of SSID)
> # - a printf-escaped ASCII string P""
>
> I was not able to find information on how ifup passes on the information
> from the wpa-ssid field. Assuming it is just handed down as is, the only
> change in netman would be to prefix the SSID with 'P'.
>
> --
> Irrwahn
>
>
> ___
> 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
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 ? 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
Re: [DNG] netman GIT project
On Tue, 25 Aug 2015 21:16:08 +0100, Edward Bartolo wrote:
> On 25/08/2015, Irrwahn wrote:
>> On Tue, 25 Aug 2015 20:20:20 +0200 (CEST), Karl wrote:
>>> Irrwahn:
On Tue, 25 Aug 2015 19:24:17 +0200 (CEST), Karl wrote:
> Tilt!:
>> i wonder if we ever get to see such SSIDs from iwlist anyway -
>> how is it supposed to print SSIDs that contain the zerobyte ...
>
> iwlib.c line 989..995:
> /* Is it a non-ASCII character ??? */
> if(isescape || !isascii(*s) || iscntrl(*s))
> {
> /* Escape */
> sprintf(d, "\\x%02X", *s);
> d += 4;
> }
Thank you. One problem, though:
Not a single version of the Wireless Tools for Linux sources I
happened to stumble upon doing a quick internet search contains
this snippet, or anything remotely like it. Care to share with us,
where this originates?
>>>
>>> $ apt-get source wireless-tools
>>> $ cd wireless-tools-30~pre9
>>> $ ls iw*.[ch]
>>> iwconfig.c iwevent.c iwgetid.c iwlib.c iwlib.h iwlib-private.h
>>> iwlist.c iwmulticall.c iwpriv.c iwspy.c
>>> $ grep download debian/copyright
>>> It was downloaded from:
>>> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
>>> $
>>>
>>>
>>> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
>>> under "Wireless Tools latest versions":
>>> ///
>>> The main features of the latest beta is support for non-ASCII ESSIDs
>>> (such as localised ESSID), support for displaying Scanning Capabilities,
>>> slightly bigger scan buffer, fixing minor bug iwconfig parser and minor
>>> enhancement to ifrename :
>>>
>>> Wireless Tools version 30-pre9 (beta)
>>> ///
>>>
Or give a little more context, particularly
how isescape is set?
>>>
>>> iwlib.c line 971..981:
>>> /* Escape the escape to avoid ambiguity.
>>>* We do a fast path test for performance reason. Compiler will
>>>* optimise all that ;-) */
>>> if(*s == '\\')
>>> {
>>> /* Check if we would confuse it with an escape sequence */
>>> if((e-s) > 4 && (s[1] == 'x')
>>> && (isxdigit(s[2])) && (isxdigit(s[3])))
>>> {
>>> isescape = 1;
>>> }
>>
>> Thanks a lot, Karl! I was stupid enough to not simply apt-get the sources.
>> I checked, it is exactly the function that is used when printing the scan
>> results.
>>
>> That makes escaping for file system path purposes quite easy, as everything
>> is already escaped, except the notorious '/'. however, that is already taken
>> care of in my modified version of Ed's netman.
>>
>> Now, what about the consumers? I found out that wpa_supplicant can digest
>> printf-style escaping, provided the quoted string is prefixed with 'P':
>>
>> # ssid: SSID (mandatory); network name in one of the optional formats:
>> # - an ASCII string with double quotation
>> # - a hex string (two characters per octet of SSID)
>> # - a printf-escaped ASCII string P""
>>
>> I was not able to find information on how ifup passes on the information
>> from the wpa-ssid field. Assuming it is just handed down as is, the only
>> change in netman would be to prefix the SSID with 'P'.
>>
> Since, netman does not touch /etc/network/interfaces, the system
> should still be able to connect using a wired connection to ethX.
> Obviously, the interface has to be activated using ifup ethX.
> Therefore, to use a wired connection, the backend should use
> /etc/network/interfaces as an interfaces file are simply call "ifup
> ethX". I think, there is no need to recreate another interfaces file
> which is already there waiting to be used.
Uh, I wasn't talking about wired connections, but sounds
reasonable.
> The contents of interfaces files created by backend are as follows,
> but if necessary, we can create more than more template, although it
> doesn't look it will be necessary.
>
> Interfaces File Contents:
>
> auto lo
> iface lo inet loopback
>
> iface wlan0 inet dhcp
> wpa-ssid EB-TP-LNK67
> wpa-psk ""
And that's exactly crunchpoint: How is the wpa-ssid line
processed by ifup, and does it accept the P"xyz\x0Ablah"
syntax used by wpa-supplicant?
--
Irrwahn
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] remove systemd for the love of Yog-Sothoth already
Hi again, I recomend you to use pristine-tar in combination with git-buildpackage. *** EXAMPLE 1: HOW TO GET THE SOURCES USING PRISTINE-TAR 1) Download any git repository (for example, systemd): $ git clone https://gitlab.com/aitor_cz/bulmages.git 2) Enter into the project: $ cd bulmages 3) Extract the pristine-tar branch: $ git checkout pristine-tar 4) There are two delta binaries in this branch (one belonging to the master branch, and the other belonging to the release branch): $ ls -s total 405956 405660 bulmages-master_0.16.0.20150107.1241-73c2dd9d.orig.tar.bz2.delta 288 bulmages-release_0.15.0-5b3c913b.orig.tar.bz2.delta 4 bulmages-master_0.16.0.20150107.1241-73c2dd9d.orig.tar.bz2.id 4 bulmages-release_0.15.0-5b3c913b.orig.tar.bz2.id 5) If you want to obtain the tarball (sources) of one of them (for example, the master branch) type the following: $ pristine-tar checkout ../bulmages-master_0.16.0.20150107.1241-73c2dd9d.orig.tar.bz2 pristine-tar: successfully generated ../bulmages-master_0.16.0.20150107.1241-73c2dd9d.orig.tar.bz2 6) Now, go to the parent directory, and check the hash: $ md5sum bulmages-master_0.16.0.20150107.1241-73c2dd9d.orig.tar.bz2 9359934456b86da8489d24a947828239 bulmages-master_0.16.0.20150107.1241-73c2dd9d.orig.tar.bz2 Your proccess will be physically equivalent !! This allows to check the purity of the sources, because the mantainer of a debian package must not do changes in it (the upstream branch is for developers). EXAMPLE 2: HOW TO BUILD WITH PRISTINE-TAR * 1) Download a concret branch: $ git clone --branch release15 --single-branch https://gitlab.com/aitor_cz/bulmages.git 2) Now we will use git-import-orig, so remove the metadatas in bulmages (the .git folder) $ rm -rf bulmages/.git $ mkdir release15 $ cd release15 $ git-import-orig --pristine-tar ../bulmages What will be the source package name? [] bulmages-release What is the upstream version? [] 0.15.0-5b3c913b gbp:info: Importing '../bulmages-release_0.15.0-5b3c913b.orig.tar.bz2' to branch 'master'... gbp:info: Source package is bulmages-release gbp:info: Upstream version is 0.15.0-5b3c913b pristine-tar: committed bulmages-release_0.15.0-5b3c913b.orig.tar.bz2.delta to branch pristine-tar gbp:info: Successfully imported version 0.15.0-5b3c913b of ../bulmages-release_0.15.0-5b3c913b.orig.tar.bz2 3) Extract the pristine-tar branch: $ git checkout pristine-tar Switched to branch 'pristine-tar' $ ls -l bulmages-release_0.15.0-5b3c913b.orig.tar.bz2.delta bulmages-release_0.15.0-5b3c913b.orig.tar.bz2.id The tarball bulmages-release_0.15.0-5b3c913b.orig.tar.bz2 is again in the parent directory. 4) If yout want to do some changes, commit them an build with git-buildpackage: $ git-buildpackage --git-export-dir="../build-area" \ --git-pristine-tar \ --git-tag \ --git-ignore-branch ** EXAMPLE 3: HOW TO GENERATE THE PRISTINE-TAR BRANCH ** As Joey Hess explains in his article: http://joeyh.name/blog/entry/generating_pristine_tarballs_from_git_repositories/ the above examples are from the perspective of a maintainer of a Debian package. But this can also be used by the authors who generate the pristine tarballs in the first place. Check them into git using pristine-tar. Then you can regenerate any tarball you've ever released using just your project's git repository. $ pristine-tar commit ../bulmages-release_0.15.0-5b3c913b.orig.tar.bz2 tags/0.15.0-5b3c913b Have a nice day :) Aitor. P.D.- There is another alternative for the second example: $ gbp buildpackage --git-upstream-tag=0.15.0-5b3c913b \ --git-debian-branch=release15 \ --git-no-pristine-tar \ --git-pristine-tar-commit On 25/08/15 16:24, Svante Signell wrote: On Mon, 2015-08-24 at 17:09 +0200, aitor_czr wrote: >Hi Svante, > >Pristine-tar branch guarantees a constant checksum in the sources >*.bz2. The packager should not make changes in the source (this is >only for the developer), all the changes must be done in the debian >branch using quilt. Shortly i will write a little guide explaining how >to create the pristine-tar branch (Joey Hess wrote something about >that), etc... pristine-tar is needed to build the source package with dpkg-buildpackage (dpkg-source -b builds the source file). However I still have not found out how to build the source package from the pristine-tar branch and the binary files with dpkg-buildpackage. >On 24/08/15 14:00, Svante Signell wrote: > > >This issue is still hindering me from fully maintain packages, a clear > >TODO is needed, preferably somewhere on the Devuan website. I meant a developers guide here:)
Re: [DNG] Mirroring Devuan
Hi, Jaromil, I did something similar in January, but it took me so long... I have the script in another hard disk. I will reanalize it (whenever i have the time) and share with you. I suppose rsync woult be the best tool to mantain the repository. I don't know if it would be better than Amprolla. Aitor. 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 ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
On Tue, Aug 25, 2015 at 10:35:21PM +0200, Irrwahn wrote: > On Tue, 25 Aug 2015 21:16:08 +0100, Edward Bartolo wrote: > > The contents of interfaces files created by backend are as follows, > > but if necessary, we can create more than more template, although it > > doesn't look it will be necessary. > > > > Interfaces File Contents: > > > > auto lo > > iface lo inet loopback > > > > iface wlan0 inet dhcp > > wpa-ssid EB-TP-LNK67 > > wpa-psk "" > > > > And that's exactly crunchpoint: How is the wpa-ssid line > processed by ifup, and does it accept the P"xyz\x0Ablah" > syntax used by wpa-supplicant? It is exported as IF_WPA_SSID in the environment passed to /etc/network/if-*.d/*. /etc/network/if-*.d/wpasupplicant sources a file that sources /etc/wpa_supplicant/functions.sh, which runs quoted strings through echo/sed, then passes the value of IF_WPA_SSID as an argument to wpa_cli_do, which is a shell function that calls wpa_cli. I have no idea whether the \ escapes hold up to all that, but as long as you have them adequately escaped, they do not need a different format for quoting. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman GIT project
I am being suggested to do away with sudo dependency to run the backend with root privileges. I will modify the frontend's code to run the backend without sudo, but this will require one to use change the backend's SUID to that of root. Today, if my concentration permits, I will try to add support for eth0 and add code to display the device nodes in the list box. I can also add support for eth1 and wlan1, but this in my opinion is an overkill as mobile computers do not usually have more than one wired connection. On 26/08/2015, Isaac Dunham wrote: > On Tue, Aug 25, 2015 at 10:35:21PM +0200, Irrwahn wrote: >> On Tue, 25 Aug 2015 21:16:08 +0100, Edward Bartolo wrote: >> > The contents of interfaces files created by backend are as follows, >> > but if necessary, we can create more than more template, although it >> > doesn't look it will be necessary. >> > >> > Interfaces File Contents: >> > >> > auto lo >> > iface lo inet loopback >> > >> > iface wlan0 inet dhcp >> > wpa-ssid EB-TP-LNK67 >> > wpa-psk "" >> >> >> >> And that's exactly crunchpoint: How is the wpa-ssid line >> processed by ifup, and does it accept the P"xyz\x0Ablah" >> syntax used by wpa-supplicant? > > It is exported as IF_WPA_SSID in the environment passed to > /etc/network/if-*.d/*. > /etc/network/if-*.d/wpasupplicant sources a file that sources > /etc/wpa_supplicant/functions.sh, which runs quoted strings through > echo/sed, then passes the value of IF_WPA_SSID as an argument to > wpa_cli_do, which is a shell function that calls wpa_cli. > I have no idea whether the \ escapes hold up to all that, but as long as > you have them adequately escaped, they do not need a different format for > quoting. > > 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
On Wed, 26 Aug 2015 05:39:36 +0100 Edward Bartolo wrote: > I am being suggested to do away with sudo dependency to run the > backend with root privileges. Wait a minute. Isn't the back end a daemon run at boot time? As such, why not run it as root, given that wpa_supplicant requires root privileges? 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
