[DNG] Problem with debhelper
Recently i debianized the latest release of bulmages (acounting and
invoicing program) in Qt5:
http://gnuinos.org/release16/?dir=devuan/pool/main/b/bulmages
And i had the following issue: the resulting packages were all empty!
This was due to the fact that the latest release is located in
/usr/local, so i had to comment with some lines in the dh_usrlocal
script, written in perl by Joey Hess. For example:
## doit("rmdir $tmp/usr/local");
Is there any way avoid that? Is this a bug in dh?
Thanks in advance.
Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Problem with debhelper
Il 22/ago/2015 10:40 AM, "aitor_czr" ha scritto: > the resulting packages were all empty! This was due to the fact that the latest release is located in /usr/local, so i had to comment with some lines in the dh_usrlocal script Well, packages are not supposed to put anything in /usr/local (so it can be used as an alternate root folder for non-packaged software and avoid replacing files with the same name); If that program's source has a ./configure program, you may be able to fix the problem by adding this argument → --prefix=/ ← (Don't ask me how to do have dpkg-buildpackage do that, though!) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Problem with debhelper
On 08/22/2015 11:54 AM, Riccardo Boninsegna wrote: [...] If that program's source has a ./configure program, you may be able to fix the problem by adding this argument → --prefix=/ ← (Don't ask me how to do have dpkg-buildpackage do that, though!) In debian/rules: override_dh_auto_configure: dh_auto_configure -- --prefix=/usr Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirroring Devuan
On 20/08/15 04:21, Hendrik Boom wrote: On Wed, Aug 19, 2015 at 10:42:29AM +0200, Jaromil wrote: dear Karl, thanks for your analysis 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 however it is sort of low priority for now but good to remind nextime about this one soon he'll be having some beach coding time ;-) You mean that when I went through the insttaller step of choosing a devuan mirror, they all pointed to the same place? Yup, but given that httpredir all the debian packages should come from your local debian mirror anyway - and that's still > 95% of packages for a standard install. However, we're working on a mechanism to improve the use of local mirrors for where httpredir for debian gets it wrong (like it does for me in NZ). We may also extend this for deb-multimedia to use local mirrors too. Once we've got a beta for devuan out the I'll work with nextime to produce a package for amprolla that makes building private mirrors a walk in the park, and also will make building official CC mirrors easier too. Regards, Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirroring Devuan
Hello, On 08/22/2015 01:33 PM, Daniel Reurich wrote: [...] given that httpredir all the debian packages should come from your local debian mirror anyway - and that's still > 95% of packages for a standard install. Thanks for the explanation. This explains why I sometimes (rarely happens) have apt-get install blocking; sometimes I get redirected to a unreachable mirror. In the cases I have seen, it was a mirror with an ipv6 address. I use an ipv6 tunnel currently, and that might be the actual cause of those issues. Restarting apt-get usually resolves the issue. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
LOoks good to me, if I understand what I'm looking at. I'd recommend you change the name of the picklist form. Calling it "Network Manager" would cause confusion in the marketplace, and might lead some folks to not use it because they didn't want NetworkManager. How bout "Pick a Network" or some such? The title for the formEditConnect form should be changed to something meaningful to the user. I'd recommend "Input ESSID and Password. By the way, if I'm understanding that process correctly, your formEditConnect should only happen: 1) If the user chooses an ESSID that hasn't had a password input yet, or 2) The user decides to input an ESSID not on the list If it's #1, that means that the ESSID field should be pre-filled, and probably read-only. Thanks, SteveT On Sat, 22 Aug 2015 07:11:50 +0100 Edward Bartolo wrote: > This is a screenshot. It is not the type of Microsoft Aero designs but > it functions and it gives the necessary information while respecting > the intelligence of users. > > http://s17.postimg.org/6frwnwmhb/2015_08_22_070752_1600x900_scrot.png > > > > On 22/08/2015, Edward Bartolo wrote: > > GUI frontend is ready. > > > > Now, it is time for users to discover deep bugs that only show their > > heads when the user number increases. > > > > A popup window has been provided to display detailed information > > about any available wifi hotspots. This simplified the design and > > implementation of the GUI. > > > > Hopefully, users find it useful. > > > > On 21/08/2015, Edward Bartolo wrote: > >> I think, I can also upload the Lazarus code of the frontend. I am > >> using the application, and for those who love the principle of > >> "Keep it simple stuptid", it is a nice simple application which is > >> run on request. It is also controlled by the user, instead of > >> automatically making decisions behind the scenes. > >> > >> Automation will definitely take more time to do, but for the KISS > >> lovers, the application can be provided as is, with a version > >> number of 0.1 or something similar. > >> > >> When the C backend is hardened enough, it will be time for upload > >> to git.devuan.org. > >> > >> Cheers, and may DEVUAN be enjoyed by anyone wanting software > >> freedom. > >> > >> Edward > >> > >> On 21/08/2015, Edward Bartolo wrote: > >>> At long last, the backend runs without the frontend having for it > >>> to finish as I wished. This got rid of frontend hangs. > >>> > >>> > >>> > >>> On 21/08/2015, Steve Litt wrote: > On Fri, 21 Aug 2015 06:47:13 +0100 > Edward Bartolo wrote: > > > Parsing headaches: > > > > I have this chunk of data retrieved from the backend which I > > need to parse *reliably*. The goal is to read the SSID and the > > corresponsing signal strength. > > > > How should I proceed. This part of code will be done from within > > Lazarus. Please, be informed that Lazarus generated GUI uses > > GTK* as a base. The executable can is also statically built > > which means an increased portability. Executables are about 3 > > MB. In the past I have written such applications that dwarf > > what I am doing and still the size is small. > > > > Here is what I want to parse: > > > > root@edbarx-pc:/home/edbarx# iwlist wlan0 scan | grep -B 4 ESSID > > > > < > > Channel:1 > > Frequency:2.412 GHz (Channel 1) > > Quality=70/70 Signal level=-34 dBm > > Encryption key:on > > ESSID:"EB-TP-LNK67" > > -- > > Channel:6 > > Frequency:2.437 GHz (Channel 6) > > Quality=24/70 Signal level=-86 dBm > > Encryption key:on > > ESSID:"TNCAPA0332D" > > -- > > Channel:11 > > Frequency:2.462 GHz (Channel 11) > > Quality=30/70 Signal level=-80 dBm > > Encryption key:on > > ESSID:"Home WiFi" > > >>> > > :-) > > Hi Edward, > > At this point you're a lot more knowledgeable on this situation > than I, but I'll give you an opinion. If this problem were any > more complex, I'd suggest spawning awk, but it looks to me like > as long as you can get these lines into Lazarus, I think you're > golden. > > Please refer to http://dpaste.com/0FZE769 ... > > First thing: By using grep -B, you're throwing away some > information you need: Specifically, encryption type. I'd > recommend you pull *all* the output from iwscan $device scanning > into a Turbo Pascal (you know what I mean) file linked into your > Lazarus program, except "^\s+IE: Unknown". > > It's pretty easy to parse: > > * Throw away anything beginning with "
[DNG] C string handling (was: Systemd Shims)
Roger Leigh writes:
> On 20/08/2015 11:27, Rainer Weikusat wrote:
>> Roger Leigh writes:
>>> On 19/08/2015 17:39, Rainer Weikusat wrote:
[...]
p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);
strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);
[...]
> The rationale for the use of the constants is fine. But consider that
> the code does not document where those numbers come from, and fact
> that code to calculate the buffer size and the code to copy data into
> the buffer are separate steps.
There is no good reason to document them because (as I tried to explain
in the earlier mail), they're immediately obvious when considering what
the code does (concatenate a string, a char and another string) and how
it does that (by employing the C standard library strlen and strcpy
functions to manipulate strings represented as 0-terminated sequence of
characters).
The underlying convention and its implications are not immediately
obvious in themselves but that's "you are expected to understand this"
stuff for anyone using C. They're arguably arbitrary but this is true
for any such convention. As a simple and probably almost beaten to death
example, what's the meaning of
"-1" + "-1"
?
In C and C++, this is an error, in Java, the result is "-1-1" and in
Perl -2 (the number).
> This is where problems can occur. Maybe not right now, after all you
> got it right when you wrote it, one would hope. But when it comes to
> future modifications, you must update all the size calculations and
> constants in line with any changes to how the buffer is filled, and
> this is a prime candidate for mistakes and consequent crashes and/or
> buffer overflows. When it comes to making modifications, you or
> whoever is making the change, needs to work out exactly what the
> intent of the orginal code was--i.e. re-derive all the constants and
> re-compute them correctly to match the new behaviour. This is often
> non-trivial depending on the nature of the string manipulation.
It's already non-trivial for the given case but simple enough to
understand if the necessary background knowledge is available. I also
generally agree that this code is much too complicated considering what
it does (but this is very much a matter of perpsective) and that the
complexity of the C implementation of even fairly simple string
operations limits the possible complexity of (abstract) string
manipulation humans can be expected to handle reliably, or, put into
other terms, that C string handling is a PITA, the more the more
complicated it gets.
But it doesn't always get complicated and in this situation, it has
another desirable property: There's no rabbit hidden somewhere in it
which could jump out at an inconvenient moment[*]: The correctness of
this simple algorithm is easy to assert. Pulling in a few thenthousands
lines of highly abstracted C++ library code would make that much more
difficult.
[*] In theory. In practice, people working on glibc are "mad
scientist"-style x86 machine code hackers and the actual implementation
of something like strcpy might (and likely will) be anything but
straight-forward.
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/strcpy.S;h=23231088fdc6ab7e2ff423a13ed32eff3884c3c0;hb=HEAD
(Partial) explanation of this (only of the interesting part): Adding a
same-sized anything to a number constructed like 0xfefefeff causes all 1
bits in the sum to be the opposite of what they were in the original
anything provided all anything bytes were non-zero, ie each addition
caused a carryover into the next higher byte. The final increment will
only result in zero if all 1 bits are set after the xor (the or sets all
other bits). There are four cases here (or two with two subcases):
Assuming the original byte was non-zero,
1) The 1 bit of the original byte was set
1a) An overflow happened when adding the previous byte. The 1-bit is now
clear and the xor will set it back to 1.
1b) No overflow. 1 still set, xor will clear it.
2) 1 bit not set
2a) overflow, one bit now set, xor will leave it alone
2b) no overflow, still zero, will remain zero.
If there was no zero byte, either 1a or 2a will have happened for every
byte, hence, all 1 bits are now set and the increment results in a
0.
I sort-of appreciate this as a puzzle and (as I verified at some time in
the past) the algorithm is either optimal or at least better than any
simpler variant I could come up with, however, I can see no particular
value in it beyond that it's surely a complicated card trick and that I
don't expect to come into a situation where the performance of
char *strcpy(char *d, char *s)
{
char *r;
r = d;
while (*r = *s) ++r, ++s; /* no cutesy increments */
return d;
}
would be a problem for a string one would realistically consider
copying.
__
Re: [DNG] Problem with debhelper
aitor_czr writes:
> Recently i debianized the latest release of bulmages (acounting and
> invoicing program) in Qt5:
>
> http://gnuinos.org/release16/?dir=devuan/pool/main/b/bulmages
>
> And i had the following issue: the resulting packages were all empty!
> This was due to the fact that the latest release is located in
> /usr/local, so i had to comment with some lines in the dh_usrlocal
> script, written in perl by Joey Hess. For example:
>
> ## doit("rmdir $tmp/usr/local");
>
> Is there any way avoid that? Is this a bug in dh?
"Use it as intended"? In case you want to create a package installing
something in /usr/local (eg, because it's a "local" package not intended
for standalone distribution), the dh_usrlocal step can be skipped:
binary:
dh binary --before dh_usrlocal
dh binary --after dh_usrlocal
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] *****SPAM***** Re: C string handling
Spam detection software, running on the system "tupac2", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 22/08/2015 16:40, Rainer Weikusat wrote: > [*] In theory. In practice, people working on glibc are "mad > scientist"-style x86 machine code hackers and the actual implementation > of something like strcpy might (and likely will) be anything but > straight-forward. [...] Content analysis details: (5.3 points, 5.0 required) pts rule name description -- -- 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [82.216.6.62 listed in dnsbl.sorbs.net] 1.7 URIBL_BLACKContains an URL listed in the URIBL blacklist [URIs: musl-libc.org] 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL [82.216.6.62 listed in zen.spamhaus.org] --- Begin Message --- On 22/08/2015 16:40, Rainer Weikusat wrote: [*] In theory. In practice, people working on glibc are "mad scientist"-style x86 machine code hackers and the actual implementation of something like strcpy might (and likely will) be anything but straight-forward. That's the reason why my go-to reference for C library implementation is not the glibc, but musl: http://musl-libc.org/ -- Laurent --- End Message --- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
On 22/08/2015 16:58, Laurent Bercot wrote: Spam detection software, running on the system "tupac2", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Oh, for fuck's sake. If I can't post legitimate mails to the list from my legitimate IP and link a legitimate site without being barked at by deficient "antispam" software, I guess it's time for me to leave. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
> > from my legitimate IP > 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address >[82.216.6.62 listed in dnsbl.sorbs.net] Note the 'dynamic'. I wouldn't quite take this personally, and I doubt anyone on the list is to blame for that, with the possible exception of yourself for not arranging yourself around the fact that these days, MTAs behind dynamic IPs are automatically suspicious. Yes, it sucks, I have the same problem, MXs typically don't even accept mail directly from here. No, it doesn't help to whine about it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
On Sat, Aug 22, 2015 at 05:20:15PM +0200, Timo Buhrmester wrote: > > > from my legitimate IP > > 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address > >[82.216.6.62 listed in dnsbl.sorbs.net] > Note the 'dynamic'. > > I wouldn't quite take this personally, and I doubt anyone on the list is to blame for that, with the possible exception of yourself for not arranging yourself around the fact that these days, MTAs behind dynamic IPs are automatically suspicious. My address sometimes gets blocked as coming from a dynamically assigned IP address, even though the IP address is a static address. My ISP says they're onto it, but from the results they got it seems to me that the Trend antispam organisation isn't interested. -- hendrik > > Yes, it sucks, I have the same problem, MXs typically don't even > accept mail directly from here. No, it doesn't help to whine about > it. > ___ > 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] Problem with debhelper
Thaks, i will try it.
Aitor.
On 22/08/15 16:58, Rainer Weikusat wrote:
"Use it as intended"? In case you want to create a package installing
something in /usr/local (eg, because it's a "local" package not intended
for standalone distribution), the dh_usrlocal step can be skipped:
binary:
dh binary --before dh_usrlocal
dh binary --after dh_usrlocal
aitor_czr writes:
>Recently i debianized the latest release of bulmages (acounting and
>invoicing program) in Qt5:
>
>http://gnuinos.org/release16/?dir=devuan/pool/main/b/bulmages
>
>And i had the following issue: the resulting packages were all empty!
>This was due to the fact that the latest release is located in
>/usr/local, so i had to comment with some lines in the dh_usrlocal
>script, written in perl by Joey Hess. For example:
>
>## doit("rmdir $tmp/usr/local");
>
>Is there any way avoid that? Is this a bug in dh?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] C string handling
Gentlemen, On 08/22/2015 04:40 PM, Rainer Weikusat wrote: Roger Leigh writes: On 20/08/2015 11:27, Rainer Weikusat wrote: Roger Leigh writes: On 19/08/2015 17:39, Rainer Weikusat wrote: [...] p_len = strlen(IFACES_PATH); e_len = strlen(essid); path = alloca(p_len + e_len + 2); strcpy(path, IFACES_PATH); path[p_len] = '/'; strcpy(path + p_len + 1, essid); [...] I am fully aware of the C string problem. The code has other problems, too. Edward is not to blame for this at all, because he is no C programmer. I am using Edward's submission as template for what the back-end must understand as arguments, what commandlines it must execute, what it is supposed to print, how it is supposed to exit etc. (think contract programming). Believe me, I already rewrote specifically this section of the code, so don't bother too much. On a sidenote, I try to get rid of the exec()s and replace them with execl()s. I hope the surrounding PASCAL process thread can handle that in terms of catching the stdout. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
On 22/08/2015 17:20, Timo Buhrmester wrote: I wouldn't quite take this personally, and I doubt anyone on the list is to blame for that, with the possible exception of yourself for not arranging yourself around the fact that these days, MTAs behind dynamic IPs are automatically suspicious. Well, it always helps to make the list host aware that list services that use PBL are not a good idea, and serve the interests that are exactly opposite to the Devuan philosophy. I'm not letting ISPs take over users' freedom to host their own MTAs, and you should not either. :P -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
Hi, On 08/22/2015 09:18 PM, Laurent Bercot wrote: On 22/08/2015 17:20, Timo Buhrmester wrote: [...] the fact that these days, MTAs behind dynamic IPs are >> automatically suspicious. Well, it always helps to make the list host aware that list services that use PBL are not a good idea, and serve the interests that are exactly opposite to the Devuan philosophy. I'm not letting ISPs take over users' freedom to host their own MTAs, and you should not either. :P I agree with Laurent, the RCVD_IN_DYNABLOCK rule weight should be lowered below treshhold, because 1. it's incorrect to mark a mail as spam solely based on this criterion, because a significant portion of internet users are in dynablocks, and not all of them are spammers; 2. the list already has moderation in place for off-list mails, so why be so rigid. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
> My address sometimes gets blocked as coming from a dynamically > assigned IP address, even though the IP address is a static address. Okay, that's odd. But what could the ISP do about it? > list services that use PBL are not a good idea and serve the interests > that are exactly opposite to the Devuan philosophy. It's a trade-off, as usual. I don't know how much actual spam gets filtered out, so I can't tell whether the trade-off is worth it. > I'm not letting ISPs take over users' freedom to host their own MTAs, > and you should not either. :P My ISP doesn't filter my connection, so they're holding to their end of the deal. Beyond that, there's really nothing they could do about foreign MTAs refusing to accept mail from here. But I still want to run a local MTA, and I do, as my mail headers should confirm. I am just forced to send outgoing mail via a relay (incoming mail is handed to postfix by fetchmail). It is unfortunate, but still the least painful feasible way of doing EMail these days, given the constraints, apart from throwing money at it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
On Sat, 22 Aug 2015 21:46:05 +0200 "tilt!" wrote: > I agree with Laurent, the RCVD_IN_DYNABLOCK rule weight should > be lowered below treshhold, because > > 1. it's incorrect to mark a mail as spam solely based on this > criterion, because a significant portion of internet users are > in dynablocks, and not all of them are spammers; > > 2. the list already has moderation in place for off-list mails, > so why be so rigid. 3. Because if we start blowing off people with confirmed records of writing code, such as Laurent has done with s6, then what would distinquish our list from Debian-User? 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] CLI backend: (E)SSID issues
Hello, it has come to my attention that an SSID is defined by a (closed) IEEE standard as (I quote inofficial source [1]): > [...] "0-32 octets with arbitrary contents. A 0-length > SSID indicates the wildcard SSID (in probe request > frames for instance)" This means that #1 SSIDs can have length zero. #2 SSIDs can contain the zerobyte. In the context of the CLI Back-En's (E)SSID encoder, this has the following consequences: a) I refuse to support case #1. It is a special case that to the extent of my knowledge only has use in special purpose frames exchanged in procedures of broadcasting or ad-hoc networking. If someone shows me otherwise, I will reconsider; it's of course not impossible to support it, just additional effort. b) I am currently unable to support case #2, because the frontend does not pass the information "length of the SSID" to the backend. Instead it passes ans an entry of argv[] a C-type string which is a sequence of nonzero bytes terminated by a zerobyte. Thus, the backend is not capable of receiveing an SSID completely that contains the zerobyte, and furthermore, the backend had no way of determining the actual length of the SSID in bytes. Ceterum censeo standards should be open. Kind regards, T. Links: [1]: stackoverflow.com. "Is there a standard that defines what is a valid SSID and password?". Answer #1. URL: http://stackoverflow.com/a/5017144 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] CLI backend: (E)SSID issues
On Sat, 22 Aug 2015 23:57:54 +0200 "tilt!" wrote: > Hello, > > it has come to my attention that an SSID is defined by a > (closed) IEEE standard as (I quote inofficial source [1]): > > > [...] "0-32 octets with arbitrary contents. A 0-length > > SSID indicates the wildcard SSID (in probe request > > frames for instance)" > > This means that > > #1 SSIDs can have length zero. > #2 SSIDs can contain the zerobyte. > > In the context of the CLI Back-En's (E)SSID encoder, this has > the following consequences: > > a) I refuse to support case #1. It is a special case that > to the extent of my knowledge only has use in special > purpose frames exchanged in procedures of broadcasting > or ad-hoc networking. > > If someone shows me otherwise, I will reconsider; > it's of course not impossible to support it, just > additional effort. > > b) I am currently unable to support case #2, because the > frontend does not pass the information "length of the > SSID" to the backend. Instead it passes ans an entry > of argv[] a C-type string which is a sequence of nonzero > bytes terminated by a zerobyte. Thus, the backend is not > capable of receiveing an SSID completely that contains > the zerobyte, and furthermore, the backend had no way of > determining the actual length of the SSID in bytes. > > Ceterum censeo standards should be open. If somebody's silly enough to put nullbytes in their ESSID or have it blank (as opposed to not advertised), then I don't want to use their silly setup. I think it's perfectly fine not to support those two IMHO ridiculous situations. 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
