Tim Hentenaar | 21 Jan 23:00 2015

[PATCH] udhcpd: Handle auto_time timeout overflow

Howdy y'all,

I've noticed an interesting issue with udhcpd and auto_time.

Some paths within the while loop don't go through continue_with_autotime.
Thus, if it takes a bit too long to reset timeout_end, the monotonic
timer may be far enough along that the subtraction which sets tv.tv_sec
will overflow, like so:

Jan 21 19:38:13 10.0.0.1 udhcpd[75]: Waking from select()
Jan 21 19:38:13 10.0.0.1 udhcpd[75]: tv_sec = 10
Jan 21 19:38:21 10.0.0.1 udhcpd[75]: Waking from select()
Jan 21 19:38:23 10.0.0.1 udhcpd[75]: Sending OFFER of 10.0.0.2
Jan 21 19:38:23 10.0.0.1 udhcpd[75]: tv_sec = -1
Jan 21 19:38:23 10.0.0.1 udhcpd[75]: Waking from select()
Jan 21 19:38:23 10.0.0.1 udhcpd[75]: Sending ACK to 10.0.0.2
Jan 21 19:38:23 10.0.0.1 udhcpd[75]: tv_sec = -1
Jan 21 19:38:43 10.0.0.2 udhcpc[47]: Sending renew...
Jan 21 19:38:43 10.0.0.2 udhcpc[47]: Lease of 10.0.0.2 obtained, lease time 30
Jan 21 19:38:43 10.0.0.1 udhcpd[75]: Waking from select()
Jan 21 19:38:43 10.0.0.1 udhcpd[75]: Sending ACK to 10.0.0.2
Jan 21 19:38:43 10.0.0.1 udhcpd[75]: tv_sec = -21
Jan 21 19:39:03 10.0.0.2 udhcpc[47]: Sending renew...
Jan 21 19:39:03 10.0.0.1 udhcpd[75]: Waking from select()
Jan 21 19:39:03 10.0.0.1 udhcpd[75]: Sending ACK to 10.0.0.2
Jan 21 19:39:03 10.0.0.2 udhcpc[47]: Lease of 10.0.0.2 obtained, lease time 30
Jan 21 19:39:03 10.0.0.1 udhcpd[75]: tv_sec = -41

This patch adds a quick and easy check for it, resetting tv_sec to 0,
which should fall through to write_leases() and continue_with_autotime,
(Continue reading)

Evgeniy Miheev | 19 Jan 23:00 2015
Picon

D-Link GPL Violations BusyBox and other

    Hello!

    I want to consult with you to the next question. Company D-Link is a manufacturer of the old router D-Link DI-524UP. The basis of the firmware for this equipment is necessary free software licensed GPL, since the device is embedded operating system, consisting of many components of the project GNU, BusyBox and other developers.
    On the company's website at http://tsd.dlink.com.tw/ were placed source code software are compiled in firmware version 1.01 for the device, as well as binary firmware versions 1.03, 1.04, 1.05, 1.06, 1.07 and 1.08 . According to the description of the file Security Issue_FW Release note.pdf difference between the firmware binary firmware versions 1.08 and older is to correct a backdoor security described at http://www.devttys0.com/2013/10/reverse-engineering-ad-link-backdoor/ and refinement of the program to connect PPoE.
    At my request, the company D-Link has provided source code binary firmware designated by them as version 1.08. Comparison of the contents of each file of the source code archive firmware versions 1.01 and 1.08 with each other, showed their full identity, except for files indicating the version and release of the program, as well as zero-length file.
    < VERSIONPKG = v1.08
    < ALPHA_VERSION = v5.0.1b02

    > VERSIONPKG = v1.01
    > ALPHA_VERSION = v4.0.0b10

    Detailed results of the comparison are on my FTP server at ftp://83.149.7.238/pub/

    I think that instead of source code binary firmware version 1.08 I have been provided the source code version 1.01 with the changes not to include this D-Link is a hotfix for version 1.08. Now available for download the source code firmware version of their designation as 1.01 and 1.08. Also available for download other versions of binary firmware.
    I ask for your assistance to address the following issues:
    1. To require the company D-Link made available for download the source code of the firmware DI-524UP same as the binary versions of the firmware;
    2. ordered the company to remove the D-Link version mismatch described me and made available for download the source code of the firmware DI-524UP version 1.08;

--
Best regards, Evgeny Miheev.
e-mail: thunder367 <at> gmail.com
_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
mike@grounded.net | 18 Jan 20:30 2015
Picon

Can OpenWrt code be used?

I have been looking for a way to add curl and mtr into BusyBox for windows but cannot find anything anywhere.

Was wondering if someone might know if those tools from the OpenWrt project could be re-compiled to work
with the win based BusyBox?

Thanks.
Picon

GPL Violations BusyBox

Hello!

Please tell me where to go on the violation of the GPL by D-Link? Does
the e-mail address gpl <at> busybox.net. Several times I sent him the
materials of this violation, but have not received confirmation.

--

-- 
Best regards, Evgeny Miheev. (RU: С уважением, Михеев Евгений.)
e-mail: thunder367 <at> gmail.com <mailto:thunder367 <at> gmail.com>
_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
mike@grounded.net | 15 Jan 17:50 2015
Picon

Adding mtr and curl packages

Hi to the list,

I have been searching for days and cannot seem to find a way of adding mtr (ping/traceroute) and curl into the
main package. 

What I am trying to find out about is, can packages be added, where are they> 
Or, do I use win mtr and win curl and how do I tie this into BusyBox so it knows about them.

Thanks very much.
Isaac Dunham | 11 Jan 07:23 2015
Picon

[PATCH] modprobe-small: do dir-stripping in filename2modname

filename2modname needs to do dir-stripping, or I get:
modprobe: remove 'kernel/drivers/usb/class/usblp': No such file or directory

While we're here, replace the guts with functionally equivalent code
from pathname_matches_modname(), and make that call filename2modname().

Unbreaks modprobe-small for me.

function                                             old     new   delta
find_alias                                           666     708     +42
process_module                                       781     745     -36
pathname_matches_modname                             125       -    -125
------------------------------------------------------------------------------
(add/remove: 0/1 grow/shrink: 1/1 up/down: 42/-161)          Total: -119 bytes
   text	   data	    bss	    dec	    hex	filename
 843355	   8004	   1792	 853151	  d049f	busybox_old
 843354	   8004	   1792	 853150	  d049e	busybox_unstripped
---
 modutils/modprobe-small.c | 22 +++++++---------------
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/modutils/modprobe-small.c b/modutils/modprobe-small.c
index dafe91e..57a04d3 100644
--- a/modutils/modprobe-small.c
+++ b/modutils/modprobe-small.c
 <at>  <at>  -148,18 +148,13  <at>  <at>  static void replace(char *s, char what, char with)

 static char *filename2modname(const char *filename, char *modname)
 {
-	int i;
-	const char *from;
-
-	// Disabled since otherwise "modprobe dir/name" would work
-	// as if it is "modprobe name". It is unclear why
-	// 'basenamization' was here in the first place.
-	//from = bb_get_last_path_component_nostrip(filename);
-	from = filename;
-	for (i = 0; i < (MODULE_NAME_LEN-1) && from[i] != '\0' && from[i] != '.'; i++)
-		modname[i] = (from[i] == '-') ? '_' : from[i];
-	modname[i] = '\0';
+	// Make sure that modname does not include the path.
+	// Otherwise rmmod/modprobe -r will fail.
+	const char *fname = bb_get_last_path_component_nostrip(filename);
+	const char *suffix = strrstr(fname, ".ko");

+	safe_strncpy(modname, fname, suffix - fname + 1);
+	replace(modname, '-', '_');
 	return modname;
 }

 <at>  <at>  -299,10 +294,7  <at>  <at>  static int pathname_matches_modname(const char *pathname, const char *modname)
 {
 	int r;
 	char name[MODULE_NAME_LEN];
-	const char *fname = bb_get_last_path_component_nostrip(pathname);
-	const char *suffix = strrstr(fname, ".ko");
-	safe_strncpy(name, fname, suffix - fname + 1);
-	replace(name, '-', '_');
+	filename2modname(pathname, name);
 	r = (strcmp(name, modname) == 0);
 	return r;
 }
--

-- 
2.2.1
Richard Moore | 8 Jan 23:42 2015

sh shell - pattern substitution bug?

Hi,

I think this is a pattern substitution bug with bb's bourne shell?
(afraid I cant find anything with a real shell (non-dash) to double 
check on, so apologies if it is me.)

busybox 1.23.0 (sh shell)
-------------------------------------
~ # i=stuff%%this%%that
~ # j=${i//%%/$'\x0A'}
~ # echo "$j"
stuff\
this\
that

ubuntu (bash shell)
-------------------
~$ i=stuff%%this%%that
~$ j=${i//%%/$'\x0A'}
~$ echo "$j"
stuff
this
that

Cheers

Rich
Denys Vlasenko | 7 Jan 18:32 2015

Re: Clarification of the ntpd applet license

Hi Paul,

On Thu, Dec 25, 2014 at 11:24 PM, Isaac Dunham <ibid.ag <at> gmail.com> wrote:
> On Thu, Dec 25, 2014 at 08:43:21PM +0100, Denys Vlasenko wrote:
>> >> Copyright notice there is already a mess (both GPL and BSD ... that's
>> >> wrong).
>> >>
>> >> With your patch, it adds another BSD clause. Also, ntpd_simple.c
>> >> also needs fixing, right?
>> >>
>> >> Please submit a patch which replaces existing notice with a consistent
>> >> one.
>> >
>> > I'm not licensing expert but IMO it's impossible to merge all licenses into
>> > one statement as you wish. If you use existing code, you cannot change
>> > license unless you are author. If licenses differ for parts of code, all of
>> > them should be mentioned.
>> >
>> > I dig on the Internet about possibility to "relicense" BSD code under GPL
>> > and it's not possible. However it's possible to license changes to BSD code
>> > under GPL. So in my opinion the best solution is to mention all of the
>> > license notices (from both OpenNTPd and NTPd) and license all busybox
>> > changes under GPL. What do you think about attached patch?
>>
>> Basically it says that the original source is under BSD license
>> and all changes are under GPL. This is possibly legal, but surely is a mess
>> (whoever would want to disentangle it will need to discover the original).
>>
>> How about just respecting original authors' BSD license?
>> I'm not a license zealot.
>> You and me, as authors, still can re-license all our changes.
>
> I prefer seeing the original license preserved in general, but if you
> take that course, I'd assume you will need to contact at least the
> first three of the other Busybox contributors who modified ntpd:
> Miroslav Lichvar
> Jean-Christophe Dubois
> Paul Marks

Paul, do you agree or object to your contribution to ntpd.c, namely:

commit b7841cf7b919b16d1bd4619154bf7cb4c22b4ccd
Author: Paul Marks <paul <at> pmarks.net>
Date:   Mon Jan 14 02:39:10 2013 +0100

    ntpd: fix incorrect m_status field in outgoing packets. Closes 5120

...
        /* Build a reply packet */
        memset(&msg, 0, sizeof(msg));
-       msg.m_status = G.stratum < MAXSTRAT ? G.ntp_status : LI_ALARM;
+       msg.m_status = G.stratum < MAXSTRAT ? (G.ntp_status & LI_MASK)
: LI_ALARM;

to be under BSD style license?

--

-- 
vda
Ercolino de spiacico | 7 Jan 00:47 2015
Picon

syslogd - logging locally and remotely based on log-level

Hello! I have a quick question about syslogd.
Is there any way to run two instances of syslogd covering range of log levels (not
overlapping)? I'm specifically asking about option "-l"

BusyBox v1.21.1 (2014-11-19 20:10:45 CET) multi-call binary.

Usage: syslogd [OPTIONS]

System logging utility
(this version of syslogd ignores /etc/syslog.conf)

        -n              Run in foreground
        -O FILE         Log to FILE (default:/var/log/messages)
        -l N            Log only messages more urgent than prio N (1-8)
        -S              Smaller output
        -s SIZE         Max size (KB) before rotation (default:200KB, 0=off)
        -b N            N rotated logs to keep (default:1, max=99, 0=purge)
        -R HOST[:PORT]  Log to IP or hostname on PORT (default PORT=514/UDP)
        -L              Log locally and via network (default is network only if -R)

What I would like to achieve is: having a syslogd instance1 that logs locally let's say
1-4 and syslogd instance2 that logs 5-8 remotely. Thus a message e.g. level 6 is not
logged under instance1 but instance2 only.

This can be very helpful for debugging.

Is this possible with the current busybox build? If not can it be considered an
improvement for the next release?

Many thanks!
Matthias Andree | 6 Jan 21:55 2015
Picon

1.23.0 FreeBSD build fails: 1 showstopper mempcpy(), 1 sendfile() incompat.

Happy new year!

I just tried to upgrade the busybox-unstable port on FreeBSD to 1.23.0,
but one issue of the two given below is a showstopper.

The first one pertains to an incompatibility around sendfile. Easily
sidestepped by deconfiguring it.

> libbb/copyfd.c:12:27: error: sys/sendfile.h: No such file or directory
> libbb/copyfd.c: In function 'bb_full_fd_action':
> libbb/copyfd.c:65: warning: passing argument 3 of 'sendfile' makes integer from pointer without a cast
> libbb/copyfd.c:65: error: too few arguments to function 'sendfile'

FreeBSD's sendfile() is documented here:
<https://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=2&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html>

The showstopper pertains to using a GNUism, namely mempcpy():

> libbb/lib.a(replace.o): In function `xmalloc_substitute_string':
> replace.c:(.text.xmalloc_substitute_string+0x6c): undefined reference to `mempcpy'
> replace.c:(.text.xmalloc_substitute_string+0x7c): undefined reference to `mempcpy'

This needs to be replaced by memcpy + pointer arithmetics, or a
replacement mempcpy() function on systems that don't bring their own.

Best regards,
Matthias

_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
tito | 5 Jan 00:14 2015
Picon

MInor fixes and problems for malloced getpw/grxxx functions for bb

Hi Denys,

while trying to fully understand the new pwd_grp code I've spotted
some minor problems that need to be fixed:

1) in function parse_common count should start at 1 as line numbers are off by one.

--- libpwdgrp/pwd_grp.c.original        2015-01-04 22:36:40.000000000 +0100
+++ libpwdgrp/pwd_grp.c 2015-01-04 22:40:17.904401220 +0100
 <at>  <at>  -189,7 +189,7  <at>  <at>  static int tokenize(char *buffer, int ch
 static char *parse_common(FILE *fp, struct passdb *db,
                const char *key, int field_pos)
 {
-       int count = 0;
+       int count = 1;
        char *buf;

        while ((buf = xmalloc_fgetline(fp)) != NULL) {

2) in parse_common the use of key variable seems problematic to me:

	if (!key) {
			/* no key specified: sequential read, return a record */
			break;
	}

This variable string is passed on from the caller and eventually from the user
we have no guarantee that it will be non NULL when we don't want a sequential read.
If the calling app passes a bad pointer it will get a record returned.
I  used field_pos set to -1 to signal the parser that I wanted a sequential read.

				if (field_pos >= 0) {
					if (*(s = nth_string(buf, field_pos))) {
						if (key && *key) {
							if (strcmp(key, s) == 0) {
								/* record found */
								break;
							}
						} /* else skip: caller passed bad key */
					} /* else skip: field is empty */
				} else {  /* field_pos < 0 */
					/* No field specified (-1): sequential read, return current record */
					break;
				}

3)  in parse_common function 

               while ((buf = xmalloc_fgetline(fp)) != NULL) {

     does not set errno to ENOENT on EOF, this makes segfault
     code that works with glibc like e.g.:

    	while (1) {
		ret = getpwent_r(&pwd, buffer, 256, &pw);
		if (ret) {
			if (ret != ENOENT) {
				printf("getpwent_r: ret %s\n", strerror(ret));
			}
			break;
		}
		printf("%s (%d)\tHOME %s\tSHELL %s\n", pw->pw_name,
			pw->pw_uid, pw->pw_dir, pw->pw_shell);
	}

       Man page for getpwent_r says: 

RETURN VALUE
       On  success,  these  functions  return  0  and *pwbufp is a pointer to the struct passwd.  On
       error, these functions return an error value and *pwbufp is NULL.

ERRORS
       ENOENT No more entries.

       ERANGE Insufficient buffer space supplied.  Try again with larger buffer.

The fix with the actual code is not so easy because if you fix the getpwent_r case  (return ENOENT on EOF)
you break the getpwnam_r/getspnam_r case (0 on USER not found).

4) in function parse_common: 

		while (p < S.tokenize_end)
			if (*p++ == ',')
				cnt++;

would be more readable with braces {}, but that is just my personal taste ;-)

Ciao,
Tito

Gmane