Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?

[Guillermo Rodriguez Garcia]

El martes, 19 de septiembre de 2023, Roberto A. Foglietta <
roberto.foglie...@gmail.com> escribió:

>
> Guillermo confused the information with the entropy.
>
> I didn’t confuse anything. Please leave me out of your arguments, thank
you.



> Guillermo is getting mad and screaming
>
>
:-?
You definitely need help.

Guillermo




-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?

[Guillermo Rodriguez Garcia]

Hi Roberto,

El lun, 18 sept 2023 a las 11:54, Roberto A. Foglietta (<
roberto.foglie...@gmail.com>) escribió:

> On Mon, 18 Sept 2023 at 11:20, Guillermo Rodriguez Garcia
>  wrote:
> >
> >> # RAF: seeding the urandom device with some data and a few bits of
> randomness.
> >> #  The randomness is put at the beginning of some text data, which
> is going
> >> #  to be compressed. It is expected that the whole compressed data
> will be
> >> #  way different each time, even if a great part of the input is
> constant.
> >> #  Moreover, the size of the randomness changes each time into a
> range of
> >> #  [32, 64] bytes, and this adds more unpredictability. Like a
> hash, the
> >> #  compression algorithm will produce a way different binary output
> by just
> >> #  changing a few bytes and initial conditions.
> >> {
> >> n=$((33 + ${RANDOM:-15}%32))
> >> dd if=/dev/random bs=$n count=1 2>&1
> >> cat /proc/cmdline /proc/*stat /init*
> >> } | pigz -$((1 + n%9))c > /dev/urandom &
> >
>
> Hi Gulliermo,
>
> first of all, thank for the feedback.
>
> > Not sure whether seeding dev/urandom with output from dev/random makes
> much sense, since both use the same source of entropy.
>
> AFAIK, the /dev/random uses a source of entropy related to hardware
> events while /dev/urandom is a pseudo-random generator.


No, this is a common myth but it is not correct. Both random and urandom
use the same PRNG. See: https://www.2uo.de/myths-about-urandom/


> This should
> grant us that there is a difference between the two. immediately after
> a boot, it is supposed that many hardware events took place


Or not. This could be, for example, a cloned VM running on the cloud (which
is a typical use case for busybox).


> and
> therefore reading some bytes from /dev/random would not be such a big
> issue., IMHO.
>
> > Also note that dev/random will block if there is not enough entropy
> left, so doing this in an init script might not be a very good idea --
> specially on systems that don't have a good source of entropy available.
>
> As  as you might noticed in the function that I sent later answering
> to Jeff, I do not use anymore the /dev/random but /dev/urandom
>
> udvseed(){ local n=$((33+${RANDOM:-15}%32)) u=/dev/urandom;f(){ dd
> if=$u bs=$n count=1; };(cd /proc;f;cat cmdline *stat;f;) 2>&1|pigz
> -$((1+n%9))c >$u; }
>
> This makes your first statement something to consider. Also $RANDOM if
> available should be considered generated by the /dev/urandom and
> therefore belonging to its entropy pool. If $RANDOM is not available
> then my function is quite weak in term of unpredictability because
> read 48 bytes from /dev/urandom which is not seeded yet and use it
> with some proc data that might change but can be guessed and then
> everything is compressed with gzip -7. This is the worst scenario.
> However, even in the worst scenario due to gzip one single bit of
> difference in the input generates a completely different compressed
> output:
>

Compression (or any other deterministic manipulation of data) does not add
any entropy (or "unpredictability") since the processing is 100%
reproducible.
In terms of entropy the output of the function is as good (or as bad) as
the amount of entropy in the initial seed.

Best regards,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?

[Guillermo Rodriguez Garcia]

El lun, 18 sept 2023 a las 9:42, Roberto A. Foglietta (<
roberto.foglie...@gmail.com>) escribió:

> Hi all,
>
>  I am investigating the Android init procedure (one version, one
> device, not in general) and I found an interesting line about the
> initialization of the /dev/urandom (seeding, I suppose).
>
>  cat /proc/cmdline > /dev/urandom
>
>  Therefore, I developed a more sophisticated way to do that initialisation:
>
> # RAF: seeding the urandom device with some data and a few bits of
> randomness.
> #  The randomness is put at the beginning of some text data, which is
> going
> #  to be compressed. It is expected that the whole compressed data
> will be
> #  way different each time, even if a great part of the input is
> constant.
> #  Moreover, the size of the randomness changes each time into a range
> of
> #  [32, 64] bytes, and this adds more unpredictability. Like a hash,
> the
> #  compression algorithm will produce a way different binary output by
> just
> #  changing a few bytes and initial conditions.
> {
> n=$((33 + ${RANDOM:-15}%32))
> dd if=/dev/random bs=$n count=1 2>&1
> cat /proc/cmdline /proc/*stat /init*
> } | pigz -$((1 + n%9))c > /dev/urandom &
>

Not sure whether seeding dev/urandom with output from dev/random makes much
sense, since both use the same source of entropy.

Also note that dev/random will block if there is not enough entropy left,
so doing this in an init script might not be a very good idea -- specially
on systems that don't have a good source of entropy available.

Guillermo
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: The busybox website is unbearably slow

[Guillermo Rodriguez Garcia]

Perhaps the static website could be moved somewhere else (Github Pages,
Netlify, etc). This would solve the problem for the static sites, and
alleviate the load for git.busybox.net.

Guillermo

El jue, 19 ene 2023 a las 10:08, Denys Vlasenko ()
escribió:

> On Wed, Jan 18, 2023 at 5:45 PM Peter Korsgaard 
> wrote:
> > >>>>> "Xabier" == Xabier Oneca <--  xOneca > writes:
> > Hi,
> >
> >  > Yes, I see the same in git.busybox.net since a while back. I thought
> it was
> >  > my browser's fault (because it sticks in "performing TLS handshake"),
> but
> >  > now tried with wget and it connects and waits too.
> >
> > I've restarted Apache on the VM, which seems to have improved things
> > somewhat.
>
> It's slow because it is configured to have limited small number of
> concurrent
> connections. When there are more connections, they are held up and can
> time out.
>
> There are several periodic "git pull" scripts somewhere on the Net
> querying the site
> all the time. With larger connection limit, they can spawn so many git
> processes
> that machine OOMs (hangs) and needs to be manually rebooted.
> _______
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 2/4] httpd: Don't add Date header to response

[Guillermo Rodriguez Garcia]

Hi Sergey,

I think you are missing my point.
What I provided are examples only. You looked at these and concluded
that this specific case was due to ISPs disabling NTP a few years ago,
and also concluded that this only affected a "small amount of users"
(not sure how you reached this conclusion) and thus "we are safe
here".

But that is not the point. The point is that since the Date header is
mandated by the RFC, clients may (rightfully) rely on it being there,
and may be using it in ways that you are not aware of. Your initial
analysis where the Date header is "only useful for caching" is
incomplete. Regardless of what was the initial rationale for including
this header, the fact is that you do not (and cannot) know how people
may actually be using it.

I think disabling this is a bad idea. Regarding this:

> Anyway, the Date header is still compiled by default but those who don't need 
> it may disable it.

Yes but the help text should make it clear that disabling this may
break clients.
The help text you added says that the header is mandatory according to
the RFC, but that "it is almost useless and can be omitted". The
latter statement is not based on facts, but just your personal
opinion.

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 2/4] httpd: Don't add Date header to response

[Guillermo Rodriguez Garcia]

Hi,

El sáb., 29 ago. 2020 a las 21:37, Sergey Ponomarev
() escribió:
>
> > I have seen clients set the local date from there when ntp was not 
> > available.
>
> I'm just curious, could you please provide more details. What was the type of 
> clients? Embedded devices or something else.

Embedded devices.

> Why wasn't ntp available for them? How often does this happen in the wild?

Not sure. Some examples:

https://www.snbforums.com/threads/ntp-blocked-alternatives-to-ntpd-for-updating-time.46541/page-3#post-404882
https://askubuntu.com/questions/1035525/set-date-and-time-from-http-header-in-router-with-curl-or-wget

> Can clients fetch the date from some website on the internet?
> Anyways this is a hack but if someone really needs and control webserver then 
> it they can use a CGI script:

Well, that's the problem; this only works if you control *both* the
server (so you can setup a script) and the client.

But clients that you don't control may just assume that the Date
header is present (since it is mandated by RFC2616) and disabling this
would break them.

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 2/4] httpd: Don't add Date header to response

[Guillermo Rodriguez Garcia]

Just for the record, I think that it is not correct to say that the
Date header only makes sense for Cache-Control.
There might be other uses for it; for example I have seen clients set
the local date from there when ntp was not available.
There could be other uses too; there is no way to know what people is
using it for since it is mandated by RFC2616 and thus can be assumed
to be always there.

Guillermo

El dom., 9 ago. 2020 a las 0:24, Sergey Ponomarev
() escribió:
>
> In RFC 2616 sec. 14.18 said that sever MUST send Date header.
> But in fact the header have sense only for Cache-Control and can be omitted.
> In the same time the Date eats power, CPU and network resources which are 
> critical for embedded systems.
>
> Signed-off-by: Sergey Ponomarev 
> ---
>  networking/httpd.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/networking/httpd.c b/networking/httpd.c
> index 9141442c8..7a429d2b5 100644
> --- a/networking/httpd.c
> +++ b/networking/httpd.c
> @@ -214,6 +214,14 @@
>  //config:  help
>  //config:  Makes httpd send files using GZIP content encoding if the
>  //config:  client supports it and a pre-compressed .gz exists.
> +//config:
> +//config:config FEATURE_HTTPD_DATE
> +//config:  bool "Add Date header to response"
> +//config:  default y
> +//config:  depends on HTTPD
> +//config:  help
> +//config:  RFC2616 says that sever MUST add Date header to response.
> +//config:  But it is almost useless and can be omitted.
>
>  //applet:IF_HTTPD(APPLET(httpd, BB_DIR_USR_SBIN, BB_SUID_DROP))
>
> @@ -1071,16 +1079,18 @@ static void send_headers(unsigned responseNum)
>  * always fit into those kbytes.
>  */
>
> -   strftime(date_str, sizeof(date_str), RFC1123FMT, gmtime_r(, 
> ));
> -   /* ^^^ using gmtime_r() instead of gmtime() to not use static data */
> len = sprintf(iobuf,
> "HTTP/1.1 %u %s\r\n"
> -   "Date: %s\r\n"
> "Connection: close\r\n",
> -   responseNum, responseString,
> -   date_str
> +   responseNum, responseString
> );
>
> +#if ENABLE_FEATURE_HTTPD_DATE
> +   strftime(date_str, sizeof(date_str), RFC1123FMT, gmtime_r(, 
> ));
> +   /* ^^^ using gmtime_r() instead of gmtime() to not use static data */
> +   len += sprintf(iobuf + len, "Date: %s\r\n", date_str);
> +#endif
> +
> if (responseNum != HTTP_OK || found_mime_type) {
> len += sprintf(iobuf + len,
>     "Content-type: %s\r\n",
> --
> 2.25.1
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox



--
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] free: Add 'available' memory if provided by the kernel

[Guillermo Rodriguez Garcia]

/proc/meminfo and convert 
> > to mem_units */
> > +   seen_available = parse_meminfo(_kb, _kb);
> > +   cached = ((unsigned long long) cached_kb * 1024) / G.mem_unit;
> > +   available = ((unsigned long long) available_kb * 1024) / G.mem_unit;
> >
> > -   printf("   %11s%11s%11s%11s%11s%11s\n",
> > +   printf("   %12s%12s%12s%12s%12s%12s\n",
> > "total",
> > "used",
> > "free",
> > -   "shared", "buffers", "cached" /* swap and total don't have 
> > these columns */
> > +   "shared", "buff/cache", "available" /* swap and total don't 
> > have these columns */
> > );
> >
> > -#define FIELDS_6 "%11llu%11llu%11llu%11llu%11llu%11llu\n"
> > +#define FIELDS_6 "%12llu%12llu%12llu%12llu%12llu%12llu\n"
> >  #define FIELDS_3 (FIELDS_6 + 3*6)
> >  #define FIELDS_2 (FIELDS_6 + 4*6)
> >
> > @@ -115,16 +126,19 @@ int free_main(int argc UNUSED_PARAM, char **argv 
> > IF_NOT_DESKTOP(UNUSED_PARAM))
> > scale(info.totalram - info.freeram),
> > scale(info.freeram),
> > scale(info.sharedram),
> > -   scale(info.bufferram),
> > -   scale(cached)
> > +   scale(info.bufferram) + scale(cached),
> > +   scale(available)
> > );
> > -   /* Show alternate, more meaningful busy/free numbers by counting
> > +   /* On kernels < 3.14, MemAvailable is not provided.
> > +    * Show alternate, more meaningful busy/free numbers by counting
> >  * buffer cache as free memory. */
> > -   printf("-/+ buffers/cache:");
> > -   printf(FIELDS_2,
> > -   scale(info.totalram - info.freeram - info.bufferram - 
> > cached),
> > -   scale(info.freeram + info.bufferram + cached)
> > -   );
> > +   if (!seen_available) {
> > +   printf("-/+ buffers/cache:");
> > +   printf(FIELDS_2,
> > +   scale(info.totalram - info.freeram - info.bufferram 
> > - cached),
> > +   scale(info.freeram + info.bufferram + cached)
> > +   );
> > +   }
> >  #if BB_MMU
> > printf("Swap:  ");
> > printf(FIELDS_3,
> > --
> > 1.9.1
> >
> > ___
> > busybox mailing list
> > busybox@busybox.net
> > http://lists.busybox.net/mailman/listinfo/busybox



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Guillermo Rodriguez Garcia]

Not sure why that happens (I mean stderr behaviour being different
when httpd is started via inetd) but at least now you have solved your
issue.

Guillermo

2017-03-22 15:03 GMT+01:00 Dirk Lohse <d.lo...@meier-nt.de>:
> Hi,
>
> there is a difference between starting httpd in inetd and standalone/daemon 
> mode!
>
> I tried my test script in inetd mode
>   www stream tcp nowait root /bin/busybox httpd -i -u httpd -h /srv/www
> and I see the text I would not see. Btw: 
> http://lists.busybox.net/pipermail/busybox/2007-May/061465.html
>
> Starting it from cmdline with
>   httpd -h /srv/www
> it works like expected. A nice feature I found is starting with "-f" Don't 
> daemonize and I can see the output from stderr on cmdline. This makes 
> debugging quite easier :)
>
> Dirk
>
> -Ursprüngliche Nachricht-
> Von: Guillermo Rodriguez Garcia [mailto:guille.rodrig...@gmail.com]
> Gesendet: Dienstag, 21. März 2017 18:13
> An: Dirk Lohse
> Cc: busybox@busybox.net
> Betreff: Re: Busybox httpd sends output of stderr to the Website
>
> Looking at the source code of httpd.c from busybox 1.20.2 I see this 
> (send_cgi_and_exit, line 1408)
>
> /* User seeing stderr output can be a security problem.
> * If CGI really wants that, it can always do dup itself. */
> /* dup2(1, 2); */
>
> So it looks like it should be doing the right thing already (i.e. not sending 
> the child's stderr to its output)
>
> Where is your busybox 1.20.2 coming from? Perhaps there have been 3rd party 
> patches applied to it?
>
> Guillermo
>
> 2017-03-21 17:37 GMT+01:00 Dirk Lohse <d.lo...@meier-nt.de>:
>> Hi,
>>
>> when i run some cgi's with BusyBox internal httpd and there is some code 
>> that writes to stdout I get the result on the HTTP site - which is desired - 
>> because I produce HTTP-code within this cgi scripts. The output of stderr 
>> instead should not destroy my HTML-code and could be redirected to /dev/null.
>>
>> In BusyBox v1.19.4 all was fine. But on BusyBox version v1.20.2 httpd 
>> redirects output from stdout + stderr to the HTML-code.
>>
>> I've written a small test script to check this behavior on both versions:
>>
>> test.cgi:
>> #!/bin/sh
>>
>> echo "Content-Type: text/plain"
>> echo "Expires: 0"
>> echo
>>
>> echo "Hello World!"
>> echo "You should not see this text in your Browser" >&2
>>
>> when I call this script on the older version, I only see "Hello World!", on 
>> the new version instead I see also the last line.
>>
>> I've many code and libraries where everywhere an error message or warning 
>> could happen on stdout. So changing all the code is nearly impossible, and 
>> some warnings like "can't open file..." are necessary for debugging.
>>
>> My question: How can I tell the httpd to NOT redirect stdout to the website?
>>
>> Thanks,
>> Dirk
>>
>>
>> ___
>> busybox mailing list
>> busybox@busybox.net
>> http://lists.busybox.net/mailman/listinfo/busybox
>
>
>
> --
> Guillermo Rodriguez Garcia
> guille.rodrig...@gmail.com



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Busybox httpd sends output of stderr to the Website

[Guillermo Rodriguez Garcia]

Looking at the source code of httpd.c from busybox 1.20.2 I see this
(send_cgi_and_exit, line 1408)

/* User seeing stderr output can be a security problem.
* If CGI really wants that, it can always do dup itself. */
/* dup2(1, 2); */

So it looks like it should be doing the right thing already (i.e. not
sending the child's stderr to its output)

Where is your busybox 1.20.2 coming from? Perhaps there have been 3rd
party patches applied to it?

Guillermo

2017-03-21 17:37 GMT+01:00 Dirk Lohse <d.lo...@meier-nt.de>:
> Hi,
>
> when i run some cgi's with BusyBox internal httpd and there is some code that 
> writes to stdout I get the result on the HTTP site - which is desired - 
> because I produce HTTP-code within this cgi scripts. The output of stderr 
> instead should not destroy my HTML-code and could be redirected to /dev/null.
>
> In BusyBox v1.19.4 all was fine. But on BusyBox version v1.20.2 httpd 
> redirects output from stdout + stderr to the HTML-code.
>
> I've written a small test script to check this behavior on both versions:
>
> test.cgi:
> #!/bin/sh
>
> echo "Content-Type: text/plain"
> echo "Expires: 0"
> echo
>
> echo "Hello World!"
> echo "You should not see this text in your Browser" >&2
>
> when I call this script on the older version, I only see "Hello World!", on 
> the new version instead I see also the last line.
>
> I've many code and libraries where everywhere an error message or warning 
> could happen on stdout. So changing all the code is nearly impossible, and 
> some warnings like "can't open file..." are necessary for debugging.
>
> My question: How can I tell the httpd to NOT redirect stdout to the website?
>
> Thanks,
> Dirk
>
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

syslogd -D does not always drop duplicates

[Guillermo Rodriguez Garcia]

Hello all,

I am trying to get syslogd to drop duplicate messages (-D option) but
it does not seem to work. Simple test:

$ syslogd -K -D
$ echo test | logger
$ echo test | logger
$ echo test | logger
$ dmesg | tail
[...]
syslogd started: BusyBox v1.22.0
root: test
root: test
root: test
$

However it seems to be doing "something" since it manages to drop
duplicates in this case:

$ killall syslogd; syslogd -K -D
$ echo test | logger ; echo test | logger ; echo test | logger

$ dmesg | tail
[...]
syslogd exiting
syslogd started: BusyBox v1.22.0
root: test
$

I am probably missing something obvious, but what is it ?

Thank you,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: segfault bb_make_directory + dirname with musl

[Guillermo Rodriguez Garcia]

2016-12-02 8:48 GMT+01:00 Guillermo Rodriguez Garcia
<guille.rodrig...@gmail.com>:
> 2016-12-01 21:13 GMT+01:00 Daniel Sabogal <dsaboga...@gmail.com>:
>> On Wed, Nov 30, 2016 at 5:52 PM, Denys Vlasenko
>> <vda.li...@googlemail.com> wrote:
[...]
>>
>> This does prevent the segfault, but I'm not sure if depending on being able 
>> to
>> modify the result of dirname() is reliable.

(sorry for the previous empty mail)

I don't think it is reliable. The manpage for dirname says (emphasis mine):

   These  functions  may  return  pointers  to statically allocated memory
   which may be overwritten by subsequent calls.  Alternatively, they  may
   return  a  pointer to some part of path, so that *the string referred to
   by path should not be modified or freed* until the pointer  returned  by
       the function is no longer required.

Best,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: segfault bb_make_directory + dirname with musl

[Guillermo Rodriguez Garcia]

2016-12-01 21:13 GMT+01:00 Daniel Sabogal <dsaboga...@gmail.com>:
> On Wed, Nov 30, 2016 at 5:52 PM, Denys Vlasenko
> <vda.li...@googlemail.com> wrote:
>> On Wed, Nov 30, 2016 at 3:46 AM, Daniel Sabogal <dsaboga...@gmail.com> wrote:
>>> The following commands cause busybox to segfault on musl-based systems.
>>>
>>> $ install -D a /
>>> $ install -D a /b
>>> $ install -D a /b/
>>>
>>> This happens because the code in
>>>
>>> https://git.busybox.net/busybox/tree/coreutils/install.c?h=1_25_1#n196
>>>
>>> passes the result of dirname() to bb_make_directory() which modifies its
>>> contents. For paths of the above forms, musl's dirname returns a string
>>> literal "/" which shouldn't be modified.
>>>
>>> See http://git.musl-libc.org/cgit/musl/tree/src/misc/dirname.c
>>>
>>> There are a few other occurrences of the code shown above, but I've not
>>> checked to see if they could be made to segfault.
>>
>> Does this fix the problem?
>>
>> /* Bypass leading non-'/'s and then subsequent '/'s 
>> */
>> while (*s) {
>> if (*s == '/') {
>> do {
>> ++s;
>> } while (*s == '/');
>> c = *s; /* Save the current char */
>> added line==>   if (c)
>> *s = '\0'; /* and
>> replace it with nul */
>> break;
>
> This does prevent the segfault, but I'm not sure if depending on being able to
> modify the result of dirname() is reliable.
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: possible bug in 'sum' command, with a demo

[Guillermo Rodriguez Garcia]

The values returned by sum seem to be correct for the default SysV
algorithm. The coreutils version of sum yields the same values.

Guillermo

2016-09-22 17:57 GMT+02:00 Anne Salemme <asale...@crunchtime.com>:

> Hello,
>
>   I am using BusyBox version v1.22.1 inside MobaXterm, and came across
> what looks like a bug in the ‘sum’ command…maybe not a bug, but definitely
> not expected…here is a little demo for you…thanks, I love BusyBox!
>
>
>
> Demo shows that given two files with different contents, ‘sum’ gives them
> an identical checksum, but ‘cksum’ gives them different checksums (as
> expected).
>
>
>
> [2016-09-22 11:38.59]  ~/foo
>
> [asalemme.asalemme-win7] ➤ ls -l
>
> total 1
>
> -rw-r--r--1 asalemme UsersGrp 8 Sep 22 10:27 demo-107108
>
> -rw-r--r--1 asalemme UsersGrp 8 Sep 22 10:27 demo-145146
>
>
>  ✔
>
> 
> 
> ───
>
> [2016-09-22 11:39.07]  ~/foo
>
> [asalemme.asalemme-win7] ➤ sum *
>
> 59944 1 demo-107108
>
> 59944 1 demo-145146
>
>
>
> ✔
>
> 
> 
> ───
>
> [2016-09-22 11:39.14]  ~/foo
>
> [asalemme.asalemme-win7] ➤ cksum *
>
> 2984653705 8 demo-107108
>
> 1560277601 8 demo-145146
>
>
>  ✔
>
> 
> 
> ───
>
> [2016-09-22 11:39.20]  ~/foo
>
> [asalemme.asalemme-win7] ➤ od -c demo-107108
>
> 000   1   0   7   1   0   8  \n  \n
>
> 010
>
>
>
> ✔
>
> 
> 
> ───
>
> [2016-09-22 11:39.39]  ~/foo
>
> [asalemme.asalemme-win7] ➤ od -c demo-145146
>
> 000   1   4   5   1   4   6  \n  \n
>
> 010
>
>
>
>  ✔
>
> 
> 
> ───
>
> [2016-09-22 11:40.01]  ~/foo
>
> [asalemme.asalemme-win7] ➤
>
>
>
>
>
> Thanks again for a great product, and best regards.
>
>
>
> Anne Salemme
>
>
>
> [image: Signature-Logo_black]
>
> Anne Salemme| Linux Deployment Engineer
>
> CrunchTime! Information Systems, Inc.
>
> 129 Portland Street, Boston, MA 02114
>
> *asale...@crunchtime.com <asale...@crunchtime.com>*
>
> Web
> <http://t.signauxhuit.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs3My3lqMRYrD-f6D1RVQJSG056dS_6f36lDJz02?t=http%3a%2f%2fwww.crunchtime.com%2f=5659683090595840=2f2a6d7f-bfae-4f30-bea3-2908f3f9663a>
> – Twitter
> <http://t.signauxhuit.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs3My3lqMRYrD-f6D1RVQJSG056dS_6f36lDJz02?t=http%3a%2f%2fwww.twitter.com%2fgetcrunchtime=5659683090595840=2f2a6d7f-bfae-4f30-bea3-2908f3f9663a>
> – Video
> <http://t.signauxhuit.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs3My3lqMRYrD-f6D1RVQJSG056dS_6f36lDJz02?t=http%3a%2f%2fvimeo.com%2fchannels%2fgetcrunchtime=5659683090595840=2f2a6d7f-bfae-4f30-bea3-2908f3f9663a>
> – LinkedIn
> <http://t.signauxhuit.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs3My3lqMRYrD-f6D1RVQJSG056dS_6f36lDJz02?t=https%3a%2f%2fwww.linkedin.com%2fcompany%2fcrunchtime-information-systems=5659683090595840=2f2a6d7f-bfae-4f30-bea3-2908f3f9663a>
>
>
>
>
>
>
>
>
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] Compress common substrings in applet names to save space

[Guillermo Rodriguez Garcia]

2016-04-20 12:46 GMT+02:00 Denys Vlasenko :
> On Tue, Apr 19, 2016 at 2:15 PM, Ron Yorston  wrote:
>> The string of applet names seems ripe for compression:  it has a limited
>> range of characters and many common substrings.  If the compression is
>> too aggressive, though, the code required to handle it causes bloat.
>>
>> Recursively replace common pairs of characters with a character having
>> its top bit set; the lower 7 bits being an index into an array of
>> character pairs.  This is only done if it results in a net saving,
>> otherwise the current code is used.
>>
>> Provide an implementation of find_applet_by_name() which uses binary
>> search:  this reduces the number of string comparisons from an average
>> of 27.9 per lookup to 7.7.  This is important because of the added cost
>> of expanding strings before comparison.  (Compressing the input string
>> is uncompetitive.)
>>
>> The new version of find_applet_by_name() is about 8% faster than the
>> old one when strings aren't abbreviated.  It isn't used in that case,
>> though, as it's larger than the current implementation.
>>
>> When strings are abbreviated the new find_applet_by_name() is about
>> 34% slower than currently.  (All comparisons are for the default
>> configuration.)
>
> Crazy :D

Is this really worth it? 34% slower may have a visible impact if applets are
executed frequently. And then there's the added complexity. All of that for
just some 500 bytes ?

Guillermo
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: tar: write: Broken pi

[Guillermo Rodriguez Garcia]

The command line correctly includes the 'z' option for gunzip. Why do
you say "no gunzip argument" ?

Guillermo

2015-12-21 23:44 GMT+01:00 Marcus Diniz <mdi...@gmail.com>:
> I was wondering, should this be considered a bug?
>
> It's clear that tar is being called with no gunzip argument, and then it's
> trying to identify the magic number to continue if true for tar file.
>
> Since busybox is supposed to be small and fast, is this kind of error
> supposed to get handled?
>
> Marcus Diniz
>
> On Dec 21, 2015 20:12, "Heinrich Schuchardt" <xypron.g...@gmx.de> wrote:
>>
>> OpenWRT ChaosCalmer uses busybox 1.23.2.
>>
>> For many tar.gz files I receive errors like:
>>
>> user@MR3020:~/src$ wget http://tukaani.org/xz/xz-5.2.2.tar.gz
>> user@MR3020:~/src$ tar -xzf xz-5.2.2.tar.gz
>> tar: invalid tar magic
>> user@MR3020:~/src$ tar: write: Broken pipe
>>
>> GNU tar on Debian Jessie amd64 has no problem with the same file.
>>
>> Best regards
>>
>> Heinrich Schuchardt
>> ___
>> busybox mailing list
>> busybox@busybox.net
>> http://lists.busybox.net/mailman/listinfo/busybox
>
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Setting timezone offset properly with busybox

[Guillermo Rodriguez Garcia]

Try JST-9. The offset is the value added to localtime to arrive at UTC,
which is the opposite than the intuitive meaning.

El viernes, 24 de julio de 2015, Juha Lumme juha.lu...@gmail.com escribió:

 Hi,

 I have created root fs with buildroot 2014.1, and it runs busybox version
 1.22.1.

 I can't seem to understand how the timezone is meant to be set.
 NTP has set the system time appropriately to UTC:
 # date
 Fri Jul 24 02:03:16 UTC 2015

 In my case I would like to set Japan standard time, so I set the TZ
 variable (or write to /etc/TZ file) to JST9 (My current interpretation of
  http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html
 ) and check time time
 # export TZ=JST9
 # date
 Thu Jul 23 17:03:24 JST 2015

 Now the time zone seems to have been set appropriately, but the time is 6
 hours in the future. The appropriate time should be the original 02:03:16
 + 9 hours - 11:03:16. Where do I get this additional offset ?


 Br,
 Juha



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Setting timezone offset properly with busybox

[Guillermo Rodriguez Garcia]

By the way the time you were seeing was not 6 hours in the future, but 9
hours in the past (check the date)

El viernes, 24 de julio de 2015, Guillermo Rodriguez Garcia 
guille.rodrig...@gmail.com escribió:

 Try JST-9. The offset is the value added to localtime to arrive at UTC,
 which is the opposite than the intuitive meaning.

 El viernes, 24 de julio de 2015, Juha Lumme juha.lu...@gmail.com
 javascript:_e(%7B%7D,'cvml','juha.lu...@gmail.com'); escribió:

 Hi,

 I have created root fs with buildroot 2014.1, and it runs busybox version
 1.22.1.

 I can't seem to understand how the timezone is meant to be set.
 NTP has set the system time appropriately to UTC:
 # date
 Fri Jul 24 02:03:16 UTC 2015

 In my case I would like to set Japan standard time, so I set the TZ
 variable (or write to /etc/TZ file) to JST9 (My current interpretation of
  http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html
 ) and check time time
 # export TZ=JST9
 # date
 Thu Jul 23 17:03:24 JST 2015

 Now the time zone seems to have been set appropriately, but the time is 6
 hours in the future. The appropriate time should be the original 02:03:16
 + 9 hours - 11:03:16. Where do I get this additional offset ?


 Br,
 Juha



 --
 Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com
 javascript:_e(%7B%7D,'cvml','guille.rodrig...@gmail.com');



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: printf in top.c

[Guillermo Rodriguez Garcia]

Are you sure you are running your patched version of top and not the
original one?

El miércoles, 3 de junio de 2015, Wei, Catherine catherine@arris.com
escribió:

 Hi:
  Lately I'm trying to debug the top command in an embedded linux
 box. I've added some printf in top.c, for example:

 fprintf(stderr,catherine %lu %lu %lu %lu %lu
 %lu\n,used,mfree,shared,buffers,cached,total);
 printf(catherine--);

 in many place, even in the beginning of top_main() function, after
 building it, I copied the busybox bin file to my box, and the print log
 can not be printed out. I don't know why. Do I need some special config
 to build it? Could you please give me some advice? Thank you.

 By the way, the purpose that I'm debugging top command is that some
 memory display information is not right due to the change of
 /proc/meminfo, we may need to make a patch for busybox in our system.

 Best regard
 Catherine
 ___
 busybox mailing list
 busybox@busybox.net javascript:;
 http://lists.busybox.net/mailman/listinfo/busybox



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Guillermo Rodriguez Garcia]

El viernes, 13 de marzo de 2015, James Bowlin bit...@gmail.com escribió:

 On Fri, Mar 13, 2015 at 08:33 PM, Guillermo Rodriguez Garcia said:
  You are talking about a possible bug in the current
  implementation.  In my opinion this is completely independent
  from whether a redesign/architecture change is required or
  wanted.

 ISTM you are assuming the redesign will not fix the bug.


No, I am not asumming that.

I am saying: if there is a bug then let's fix it. The discussion on whether
mdev needs a redesign is independent of that. In other words I am saying
that there is a bug is not in itself a reason to do a redesign.


 If the
 different versions are runtime options then it will be easy to
 see if the new versions fix the bug or not.  Let's make it easy
 for me to see if your assumption is correct or not.


There was no such assumption.

[...]

 the only sane
 approach is to let the choice be at runtime so there is a
 fallback in case there is a bug that only shows up on specific
 hardware.  This approach seems so obvious to me that I can't
 imagine it is controversial.


No controversy on my side. In fact I am not advocating compile time options
over runtime options, nor the opposite. I was just trying to understand why
Michael's proposal was not good enough for Harald.

Guillermo


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Guillermo Rodriguez Garcia]

Hi James,

El viernes, 13 de marzo de 2015, James Bowlin bit...@gmail.com escribió:

 TL;DR: the current busybox (or my code) seems to be broken on one
 or two systems out of thousands; crucial modules don't get loaded
 using hotplug + coldplug.  Please give me a runtime option so I
 can give my users a boot-time option to try the new approach.


You are talking about a possible bug in the current implementation. In my
opinion this is completely independent from whether a redesign/architecture
change is required or wanted.

[...]


 BTW: I try to time most things in my initrd init script to keep
 an eye on what slows things down so we can stay as speedy as
 possible.  I use:

 cut -d  -f22 /proc/self/stat

 to get the time in hundredths of a second since the kernel
 booted.  But this itself and the associated arithmetic is not
 free time-wise.  So I disable most of the timing when I'm not in
 debug mode.  If there is a better/faster way to get the time to
 hundredths of a second or better, PLMK.


On embedded targets I normally use grabserial for boot timing (
http://elinux.org/Grabserial)

Just in case it's useful.

Guillermo


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Guillermo Rodriguez Garcia]

2015-03-13 11:19 GMT+01:00 Harald Becker ra...@gmx.de:
 On 13.03.2015 10:30, Guillermo Rodriguez Garcia wrote:

 There are many configuration options in BB that must be defined at
 build time. I don't see why this one would be different.

 You can activate both as the default (with cost of some byte overhead of
 code size), and let the user of the binary decide which mechanism he
 prefers, or even flip temporarily (without system interruption).

Sure. But this same argument could also be applied to many other
options in BB which currently are defined at build time.
I am just saying that in most other areas, Busybox does not work like this.


 Users that want a functional solution will not probably care much
 about the underlying implementation.

 Exactly that means, using only one mechanism, is forcing those users to do
 it in a specific way, with all sort of consequences.

I understand your argument. You are saying that users should be able
to choose at runtime. What I say is that my impression is that most
users belong to one of the following two groups: Those who don't
really care, and those who are happy making this choice at build time.

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Guillermo Rodriguez Garcia]

Hi Harald,

2015-03-13 8:25 GMT+01:00 Harald Becker ra...@gmx.de:
 On 13.03.2015 00:05, Michael Conrad wrote:
 In that case, I would offer this idea:

 All you do, is throwing in complex code sharing and the need to chose a
 mechanism ahead at build time, to allow for switching to some newer stuff
 ... but what about pre-generated binary versions, which mechanism shall be
 used in the default options, which mechanism shall be offered?

 With netlink active (sure the proven and better way for the job), you hit
 those like Isaac. With netlink disabled, spreading newer technology to the
 wide is usually blocked (don't talking about some experts who know how to
 build there own BB version).

 So why not allowing some innovation, to let the user chose which mechanism
 to use? What is wrong with this intention?

 I neither want to reinvent the wheel, nor go the udev way to create a big
 monolithic block, but I like to get the ability to setup the system the way
 I like, without blocking others to use the plug mechanism they like.

Michael's proposal would allow you to do what you want to do, since
you are one of those experts who know how to build their own BB
version. So what's wrong with his proposal?

Guillermo
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: RFD: Rework/extending functionality of mdev

[Guillermo Rodriguez Garcia]

2015-03-13 11:54 GMT+01:00 Harald Becker ra...@gmx.de:
 On 13.03.2015 11:25, Guillermo Rodriguez Garcia wrote:

 I understand your argument. You are saying that users should be able
 to choose at runtime. What I say is that my impression is that most
 users belong to one of the following two groups: Those who don't
 really care, and those who are happy making this choice at build time.


 Putting peoples in either-or-categories is not very handy, humans are to
 different, and you won't predict the exact needs of the next person coming
 around.

 So is either blocking any innovation or forcing one half of your
 either-or-group to do things in a specific way (if they doubt or not), your
 way? Not mine!

Perhaps my message is not getting across. What I am saying is that I
am not sure your suggestion is actually something others would find
useful. Other than the fact that you like it yourself I don't see a
lot of enthusiasm around about it.

Guillermo
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Wrong order of operation in mdev.txt

[Guillermo Rodriguez Garcia]

I think that it is just the numbers that are wrong as the text explicitly
says that steps 4-6 must be executed before the previous code snippet (so
4-6 would actually be run before 1-3)

But it is indeed misleading.

Guillermo

El domingo, 8 de marzo de 2015, Harald Becker ra...@gmx.de escribió:

 Hi !

 I just stumbled about a disordering of operations in docs/mdev.txt:

 ---cut-here---
 Basic Use
 ...
 [0] mount -t proc proc /proc
 [1] mount -t sysfs sysfs /sys
 [2] echo /sbin/mdev  /proc/sys/kernel/hotplug
 [3] mdev -s

 Alternatively, without procfs the above becomes:
 [1] mount -t sysfs sysfs /sys
 [2] sysctl -w kernel.hotplug=/sbin/mdev
 [3] mdev -s

 Of course, a more full setup would entail executing this before the
 previous
 code snippet:
 [4] mount -t tmpfs -o size=64k,mode=0755 tmpfs /dev
 [5] mkdir /dev/pts
 [6] mount -t devpts devpts /dev/pts
 ---cut-here---

 Look at the order of steps [3] and [4]. If you do mdev -s you populate
 the current /dev. In step [4] then you mount a tmpfs over the populated dev
 directory. This will result in a visible empty dev directory, as the
 populated directory gets hidden by the mounted tmpfs. So the order of steps
 should be 0, 1, 2, 4, 5, 6 then 3.

 Would be better someone changes the doc, as I'm not a native English
 speaker.

 --
 Harald

 ___
 busybox mailing list
 busybox@busybox.net
 http://lists.busybox.net/mailman/listinfo/busybox



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

2015-02-18 11:16 GMT+01:00 Denys Vlasenko vda.li...@googlemail.com:
 On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:
 2015-02-18 9:45 GMT+01:00 Denys Vlasenko vda.li...@googlemail.com:
 On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:
 I ended up using rdate on this particular case but I think it would be
 nice if ntpd could be used as described.

 I don't have enough knowledge about the protocol to know what are the
 implications of not waiting for the burst mode to end for option -q
 (as per Miroslav's patch). Can anyone shed some light?

 Time will be set after 2 reply packets from one peer.
 Which normally would take 2-3 seconds.

 If network is down or NTP server is not replying at all,
 ntpd -q can still wait indefinitely. I guess the same is true
 for ntpdate.

 In my tests, if the network is down, or the server is unreachable or
 does not reply, ntpdate returns almost immediately with an error
 message.


 If you plan for your machines to not hang at boot time
 in such a case, you need to think (and test) booting
 with network down.

 Can you provide any recommendations about this? What would be the best
 way to run ntpd to make sure it does not hang at boot if the network
 is down and/or the NTP server does not reply, but still sync the time
 as soon as the network is back up and/or the NTP server becomes
 available?

 I do not try to set time super-duper-early. I don't see a particular reason
 why that is important.

This depends on the actual application but there are many cases where
you want at least an approximate time being set before the user
application is run. For example for applications that need to schedule
work.

Note that it is not a matter of accuracy -- if there is no hardware
RTC or the battery is dead, then the time will be completely wrong.

The following would be ideal:

1. Run something such as ntpdate which sets an approximate time
quickly, but that also terminates quickly if there is no network
connectivity or NTP server does not respond
2. As soon as this is done, launch ntpd and leave it running in the
background. If I am not wrong, Busybox's ntpd can be left running in
the background mostly unattended and will just do its stuff when the
network and NTP server is available.
3. Then proceed with the rest of the initialisation.

So far the missing part of the puzzle is 1 :-)

BR,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

2015-02-18 12:30 GMT+01:00 Sven-Göran Bergh sgb-list+busy...@systemaxion.se:

 On 02/18/2015 12:04 PM, Guillermo Rodriguez Garcia wrote:

 2015-02-18 11:16 GMT+01:00 Denys Vlasenko vda.li...@googlemail.com:

 On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:

 2015-02-18 9:45 GMT+01:00 Denys Vlasenko vda.li...@googlemail.com:

 On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:

 I ended up using rdate on this particular case but I think it would be
 nice if ntpd could be used as described.

 I don't have enough knowledge about the protocol to know what are the
 implications of not waiting for the burst mode to end for option -q
 (as per Miroslav's patch). Can anyone shed some light?


 Time will be set after 2 reply packets from one peer.
 Which normally would take 2-3 seconds.

 If network is down or NTP server is not replying at all,
 ntpd -q can still wait indefinitely. I guess the same is true
 for ntpdate.


 In my tests, if the network is down, or the server is unreachable or
 does not reply, ntpdate returns almost immediately with an error
 message.


 If you plan for your machines to not hang at boot time
 in such a case, you need to think (and test) booting
 with network down.


 Can you provide any recommendations about this? What would be the best
 way to run ntpd to make sure it does not hang at boot if the network
 is down and/or the NTP server does not reply, but still sync the time
 as soon as the network is back up and/or the NTP server becomes
 available?


 I do not try to set time super-duper-early. I don't see a particular
 reason
 why that is important.


 This depends on the actual application but there are many cases where
 you want at least an approximate time being set before the user
 application is run. For example for applications that need to schedule
 work.

 Note that it is not a matter of accuracy -- if there is no hardware
 RTC or the battery is dead, then the time will be completely wrong.

 The following would be ideal:

 1. Run something such as ntpdate which sets an approximate time
 quickly, but that also terminates quickly if there is no network
 connectivity or NTP server does not respond
 2. As soon as this is done, launch ntpd and leave it running in the
 background. If I am not wrong, Busybox's ntpd can be left running in
 the background mostly unattended and will just do its stuff when the
 network and NTP server is available.
 3. Then proceed with the rest of the initialisation.

 So far the missing part of the puzzle is 1 :-)


 As I understand it you are looking for qd solution. In that case wouldn't
 just something like this do the trick?

Why qd? This is the typical (and intended) usage of ntpdate -- get
the time approximately right before starting ntpd.


 busybox timeout -t 2 busybox ntpd -nqp 

 Without a server reply ntpdate will not save you anyway.

Uhm, yes I guess that's a feasible workaround but it feels a bit
hackish. It would be nice if this could be done without this kind of
trick :)

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

2015-02-18 9:45 GMT+01:00 Denys Vlasenko vda.li...@googlemail.com:
 On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:
 I ended up using rdate on this particular case but I think it would be
 nice if ntpd could be used as described.

 I don't have enough knowledge about the protocol to know what are the
 implications of not waiting for the burst mode to end for option -q
 (as per Miroslav's patch). Can anyone shed some light?

 Time will be set after 2 reply packets from one peer.
 Which normally would take 2-3 seconds.

 If network is down or NTP server is not replying at all,
 ntpd -q can still wait indefinitely. I guess the same is true
 for ntpdate.

In my tests, if the network is down, or the server is unreachable or
does not reply, ntpdate returns almost immediately with an error
message.


 If you plan for your machines to not hang at boot time
 in such a case, you need to think (and test) booting
 with network down.

Can you provide any recommendations about this? What would be the best
way to run ntpd to make sure it does not hang at boot if the network
is down and/or the NTP server does not reply, but still sync the time
as soon as the network is back up and/or the NTP server becomes
available?

Best,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

Does this warrant a separate applet?

I thought that perhaps a command line option to the existing ntpd applet
would be enough -- but I am no expert in this field.

Guillermo

2015-01-29 11:03 GMT+01:00 Denys Vlasenko vda.li...@googlemail.com:

 On Tue, Jan 27, 2015 at 11:01 PM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:
  Hello Denys,
 
  El martes, 27 de enero de 2015, Denys Vlasenko vda.li...@googlemail.com
 
  escribió:
 
  On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia
  guille.rodrig...@gmail.com wrote:
   Hello all,
  
   Is there a way to make ntpd work just like ntpdate (just use the first
   response received to set the time)? This is to set the approximate
   time at boot as quickly as possible before starting other time
 sensitive
   services.
  
   The closest I can get is ntpd -nqp server but this seems to need
   5 valid samples in order to set the time.
 
  Would it work for you if you simply background it
  and let it do its work in parallel with the rest of the boot?
 
 
  Not in this particular case; I don't need time to be extremely accurate
 but
  I need approximate time to be set as quickly as possible before
 starting
  other services. That is (was) the typical use case of ntpdate: set the
 time
  quickly to an approximate value, then let ntpd do it's job.

 I think the best way to achieve this is to implement a sntp applet

 http://linux.die.net/man/8/sntp

 It can reuse ntpd's code.

 --
 vda




-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

Hello all,

Is there a way to make ntpd work just like ntpdate (just use the first
response received to set the time)? This is to set the approximate
time at boot as quickly as possible before starting other time sensitive
services.

The closest I can get is ntpd -nqp server but this seems to need
5 valid samples in order to set the time.

Thank you,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

Hello Denys,

El martes, 27 de enero de 2015, Denys Vlasenko vda.li...@googlemail.com
escribió:

 On Tue, Jan 27, 2015 at 7:27 PM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com javascript:; wrote:
  Hello all,
 
  Is there a way to make ntpd work just like ntpdate (just use the first
  response received to set the time)? This is to set the approximate
  time at boot as quickly as possible before starting other time sensitive
  services.
 
  The closest I can get is ntpd -nqp server but this seems to need
  5 valid samples in order to set the time.

 Would it work for you if you simply background it
 and let it do its work in parallel with the rest of the boot?


Not in this particular case; I don't need time to be extremely accurate but
I need approximate time to be set as quickly as possible before starting
other services. That is (was) the typical use case of ntpdate: set the time
quickly to an approximate value, then let ntpd do it's job.

(Note that ntpdate is deprecated now; alternatives for each typical
ntpdate use case are described here:
https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate)

One alternative (which is supported by busybox) would be rdate. However If
ntpd can be made to behave like ntpdate, I would rather use that to avoid
depending on two different servers (since rdate does not speak NTP).

Guillermo



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] udhcpd: Handle auto_time timeout overflow

[Guillermo Rodriguez Garcia]

El martes, 27 de enero de 2015, Tim Hentenaar t...@hentenaar.com escribió:

 Perhaps it wrongly assumes that since the operands for the subtraction
 are 32-bit unsigned integers, that the result will be also unsigned.


Uhm, why would that be a wrong assumption ?

Guillermo


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] udhcpd: Handle auto_time timeout overflow

[Guillermo Rodriguez Garcia]

El martes, 27 de enero de 2015, Cathey, Jim jcat...@ciena.com escribió:

 Because mathematically, differences are *always* signed!



 2 - 1 ==  1

 1 - 2 == -1


In modulo arithmetic , addition and substraction are the same for both
unsigned and signed operands.

Assume you have two 32-bit operands a and b. Let's assume a=1 and b=2.

The result of a-b is always 0x regardless of whether a and b are
signed or unsigned.

Signedness *will* be relevant when you need to compare with another value:

If the operand is unsigned, 0x  0
If the operand is signed, 0x (-1)  0

Guillermo


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: inittab: Start shell only if console is not null

[Guillermo Rodriguez Garcia]

Just for the record, I am now working around this as follows:

console::respawn:/sbin/ifconsole /sbin/getty -L 115200 ttyS0 vt100

/sbin/ifconsole is a shell script that checks if /dev/console can be
opened; if so, the line is executed; otherwise it just sleeps forever
(to prevent the respawning).

This works, but it is a crude hack. I really believe that Harald's
suggestion would be the right thing to do here.

Guillermo


2014-08-28 17:21 GMT+02:00 Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com:
 2014-08-28 16:38 GMT+02:00 Harald Becker ra...@gmx.de:
 My argument is that before adding code, it makes sense to ponder

 whether we really have a real problem here.


 Do you really insist on this endless respawning NOT BEING A BUG???

 I don't understand your stand point.


 If one respawn per second a big problem? I'm not sure.


 Problem means it may make diagnosing other problems a hell. It is the reason
 I neglect to use unpatched Busybox init for most of my applications and I
 know several people here in Germany thinking the same that this is really
 bad. I really wonder why this has not bean fixed earlier (anyhow not
 insisting on my patch). I even asked for this around 1995 to 1997 (as far as
 I remember), but it has been neglected due to the KISS principle and things
 shall be small for embedded devices ... but today we got more and more
 desktop related patches blowing up things more than that simple approach.
 And still you insist on this endless uncontrolled respawning? If you really
 like this endless respawning, why don't you use runit?

 I think it's the time to fix init to avoid endless uncontrolled respawning.

 Perhaps this fix could be implemented with a CONFIG_ option. You may
 either enable it by default and wait to see if there are complaints (I
 don't really think this would break any actual usage), or you may
 disable it by default so that only people who want the fixed
 behaviour would get it.

 But either way I think it would be convenient to fix this.

 Guillermo



-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: inittab: Start shell only if console is not null

[Guillermo Rodriguez Garcia]

Hello Harald,

Thank you for your lightning fast answer :)

2014-08-28 9:58 GMT+02:00 Harald Becker ra...@gmx.de:
 console::respawn:/sbin/getty -L 115200 ttyS0 vt100


 This is a special Busybox feature. BB uses the id field to specify a tty
 device, used to start the inittab command.

Yes I knew this.

 If the device open fails, the inittab line is skipped.

But I didn't know this. So it seems that if I use console as the id,
the device open succeeds when the system boots with console=ttyS0 but
fails when booting with console=null (not sure why -- shouldn't it be
possible to open /dev/null ?).

Is my understanding correct?

And, if this is indeed correct, then why leaving the id empty works
even when booting with console=null ?

Thank you,

Guillermo
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: inittab: Start shell only if console is not null

[Guillermo Rodriguez Garcia]

2014-08-28 10:17 GMT+02:00 Harald Becker ra...@gmx.de:

 But I didn't know this. So it seems that if I use console as the id,
 the device open succeeds when the system boots with console=ttyS0 but
 fails when booting with console=null (not sure why -- shouldn't it be
 possible to open /dev/null ?).


 Have not looked into code, but I ought it depends on the special function of
 the console.
 If you specify null as tty it usually succeeds, but if you give the name of
 a device which fail on open (as with console=null) the entry is skipped.

Indeed, opening /dev/null succeeds but opening /dev/console fails when
console=null. That's interesting.

One additional question. You mention that when the device open fails,
the inittab line is skipped. But for respawn lines, is the line really
skipped? I looked at the source code and it seems that init would
keep trying to spawn the process (and of course fail every time). This
is because the device open is done inside run() (see [1]), which is
already inside the main while loop.

Best regards,

Guillermo

 [1] 
https://gitorious.org/busybox/busybox/source/6e8e666bd9d62772713af7f06ce9495d21d51f4e:init/init.c#L348




 Harald




-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: inittab: Start shell only if console is not null

[Guillermo Rodriguez Garcia]

Hi Denys,

2014-08-28 11:05 GMT+02:00 Denys Vlasenko vda.li...@googlemail.com:
 On Thu, Aug 28, 2014 at 10:08 AM, Guillermo Rodriguez Garcia
 But I didn't know this. So it seems that if I use console as the id,
 the device open succeeds when the system boots with console=ttyS0 but
 fails when booting with console=null (not sure why -- shouldn't it be
 possible to open /dev/null ?).

 Is my understanding correct?

 init won't try to open /dev/null for
 console::respawn:/sbin/getty -L 115200 ttyS0 vt100
 line. It will try to open /dev/console.

Right. This was a misunderstanding on my side. I stand corrected.

 If that open fails, then respawning will not be done.

Actually I'm testing this and it seems that init keeps spawning child
processes forever, every second. Inside run(), vfork succeds but then
the device open fails and the child process _exits().

Is there a way to have init completely skip the line if the
controlling tty is not valid or cannot be opened.


 Therefore, your question should be
 why when I boot my kernel with console=null,
 /dev/console can't be opened?

Indeed.

 And, if this is indeed correct, then why leaving the id empty works
 even when booting with console=null ?

 The ::respawn:/sbin/getty -L 115200 ttyS0 vt100 line
 (empty id case) does not try to open anything.
 It just uses already-opened file descriptors 0,1,2 for stdio.
 It can't fail to open /dev/something since it does not open anything.

OK right. I was misled by the wording here:
http://spblinux.de/2.0/doc/init.html , where it says that If this
field is left blank, the controlling tty is set to the console. My
fault.

Thanks,

Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: inittab: Start shell only if console is not null

[Guillermo Rodriguez Garcia]

2014-08-28 15:48 GMT+02:00 Harald Becker ra...@gmx.de:
 What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY).
 What if execve fails because /usr/bin/BAR does not exist YET?

 Both cases can be solved when startup code send a SIGHUP to init when all
 this stuff is available (at end of rc scripts do kill -SIGHUP 1)

 Not to talk about: Normal respawning actions are started when sysinit
 actions has finished. All required devices and file systems shall be online
 at this time and so respawn actions will not get affected.


 What if some people who use bbox init expect respawn to retry until
 success
 in these cases?


 What about all those people who can't use Busybox init due to its endless
 and relatively fast respawning (wasting process id's).  Standard SYSV init
 never did this (detects fast respawning then puts action to sleep for
 minutes or exponential increasing time). Ok, this full fast respawn
 detection is complicated stuff, so I have chosen a simpler approach.

 Your argument here is confusing. Do you really look for people using bbox
 init due to it's long standing bug of endless respawning unavailable
 services? May intention was to do one step further into the right direction
 not to do endless uncontrolled respawning.


FWIW, I have tested the patch locally and I can confirm that it does
the job for me perfectly fine.

-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: inittab: Start shell only if console is not null

[Guillermo Rodriguez Garcia]

2014-08-28 16:38 GMT+02:00 Harald Becker ra...@gmx.de:
 My argument is that before adding code, it makes sense to ponder

 whether we really have a real problem here.


 Do you really insist on this endless respawning NOT BEING A BUG???

 I don't understand your stand point.


 If one respawn per second a big problem? I'm not sure.


 Problem means it may make diagnosing other problems a hell. It is the reason
 I neglect to use unpatched Busybox init for most of my applications and I
 know several people here in Germany thinking the same that this is really
 bad. I really wonder why this has not bean fixed earlier (anyhow not
 insisting on my patch). I even asked for this around 1995 to 1997 (as far as
 I remember), but it has been neglected due to the KISS principle and things
 shall be small for embedded devices ... but today we got more and more
 desktop related patches blowing up things more than that simple approach.
 And still you insist on this endless uncontrolled respawning? If you really
 like this endless respawning, why don't you use runit?

 I think it's the time to fix init to avoid endless uncontrolled respawning.

Perhaps this fix could be implemented with a CONFIG_ option. You may
either enable it by default and wait to see if there are complaints (I
don't really think this would break any actual usage), or you may
disable it by default so that only people who want the fixed
behaviour would get it.

But either way I think it would be convenient to fix this.

Guillermo
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox