From rep.dot.nop at gmail.com Sat Sep 1 13:09:04 2007 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sat, 1 Sep 2007 22:09:04 +0200 Subject: [patch,RFC,CFT] debloat du #1 Message-ID: <20070901200904.GR11697@aon.at> Hi, I have this patch lying around for some months now.. Ideally, du would reuse recursive_action, but the attached patch only does the non-intrusive (i.e. i didn't rewrite it, which would have been saner, perhaps) part 1/2, that is switch to globals and debloat the logic a little bit. This patch does not move the whole applet to recursive_action as of now (i will not do this anytime soon, so feel free to do this yourself, or rewrite it completely). The reason why i didn't apply it outright is that i did not really test it (just a little bit, and it worked for me, but hey). vda, please apply if you think it's worthwile, or, even better, rewrite the whole mess to use recursive_action right from the start.. Also, i didn't record any stats, size(1)-wise, so better double-check if it makes sense in the first place.. :-/ Note that this may not be cleaned-up completely, didn't look before i hit :x\ny HTH && cheers, -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox.cow-coreutils-du-step1.00.diff Type: text/x-diff Size: 6834 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070901/fe3ecc14/attachment.bin From john.gumb at tandberg.net Sat Sep 1 17:39:43 2007 From: john.gumb at tandberg.net (John Gumb) Date: Sun, 02 Sep 2007 01:39:43 +0100 Subject: PAM authentication bug? Message-ID: <1188693584.8352.14.camel@JgumbLpt.uk.rd.tandberg.com> Folks Looks like there's a bug in loginutils/login.c if PAM authentication is enabled. Symptoms are that if a valid username is entered with an incorrect password then the user is allowed to log in. Problem is if pam authentication fails the code just goes on to do a getpwnam(username) which will succeed so long as the username is valid. In the authentication failure case we need to goto auth_failed. --- loginutils/login.c.orig 2007-09-02 00:50:09.000000000 +0100 +++ loginutils/login.c 2007-09-02 00:50:58.000000000 +0100 @@ -324,6 +324,11 @@ } safe_strncpy(username, pamuser, sizeof(username)); } + else + { + goto auth_failed; + } + /* If we get here, the user was authenticated, and is * granted access. */ pw = getpwnam(username); seems to fix it. cheers John From landau_alex at yahoo.com Sun Sep 2 06:19:08 2007 From: landau_alex at yahoo.com (Alex Landau) Date: Sun, 2 Sep 2007 06:19:08 -0700 (PDT) Subject: fork() on NOMMU In-Reply-To: <200708311734.45379.vda.linux@googlemail.com> Message-ID: <596342.38345.qm@web62508.mail.re1.yahoo.com> --- Denys Vlasenko wrote: > To ifdef out things that do not work on NOMMU (for example, > mount's NFS-related option to auto-background should be disabled). > > You already did it for httpd by adding #ifdefs which basically > enforced httpd -i. Send similar patches for tar/mount/whatever. > Attached patch does that for mount. It ignores the options "fg" and "bg" (always doing "fg"). Do you think a message (+exit?) should be printed if "bg" is passed? I never used bg myself, so don't know how useful it is... For tar it's trickier... I'm thinking of changing the prototype of open_transformer to (int fd, func_ptr, decompressor_prog). the decompressor_prog is a string equal to "gzip -cdf", "bzip2 -cdf" or something similar (maybe just "gzip, "bzip2", and open_transformer itself would add "-cdf"). Then define a macro with the same name that on MMU will just withdraw the last argument, and on NOMMU withdraw the func_ptr (similar to daemonize_or_reexec). open_transformer itself will have an "#if BB_MMU" that will decide to fork and use func_ptr or to vfork and exec decompressor_prog. Sounds OK? > Note that this is not a best solution. More like as > a stopgap fix. > > For example, in 1.7.0 httpd goes further and actually > does NOMMU specific things to retain ability to run > in standalone mode: it vforks + re-exec itself as child. I don't see the need for this in mount. Feel free to add if you wish... Alex ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 -------------- next part -------------- A non-text attachment was scrubbed... Name: mount-nommu.diff Type: text/x-patch Size: 1007 bytes Desc: 4006543762-mount-nommu.diff Url : http://busybox.net/lists/busybox/attachments/20070902/5680e3b8/attachment.bin From farmatito at tiscali.it Sun Sep 2 12:20:53 2007 From: farmatito at tiscali.it (Tito) Date: Sun, 2 Sep 2007 21:20:53 +0200 Subject: [RFC] tail.c size reduction Message-ID: <200709022120.53410.farmatito@tiscali.it> Hi to all, this is a drop in replacement for tail.c. It is a result of a few sleepless nights of hacking that started by looking at and trying to understand mjn3's code. At the end I rewrote tail following a different italian creative and instinctive way. bloat-o-meter is not that bad: * scripts/bloat-o-meter busybox_old busybox_unstripped * function old new delta * xmalloc_fgetc - 40 +40 * .rodata 122102 122134 +32 * header_fmt 13 - -13 * eat_num 37 - -37 * tail_read 126 - -126 * tail_main 1109 784 -325 * ------------------------------------------------------------------------------ * (add/remove: 1/3 grow/shrink: 1/1 up/down: 72/-501) Total: -429 bytes The functionality should be the same as the original, at least that is what my little testing says, but as the size reduction is that big I fear that i've overlooked something very stupid somewhere. That's why i'm posting it to the list for auditing and inspection by better coders than me that will see my obvious errors. Critics, hints, improvements, test cases and flames are, as always, welcome. Ciao, Tito BTW.: Denis, the two test scripts in testsuit/tail are identical as diff tail-n-works tail-works shows. Maybe one could be removed? -------------- next part -------------- A non-text attachment was scrubbed... Name: tail.c Type: text/x-csrc Size: 7775 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070902/24acad69/attachment.c From vda.linux at googlemail.com Mon Sep 3 04:36:57 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 3 Sep 2007 12:36:57 +0100 Subject: PAM authentication bug? In-Reply-To: <1188693584.8352.14.camel@JgumbLpt.uk.rd.tandberg.com> References: <1188693584.8352.14.camel@JgumbLpt.uk.rd.tandberg.com> Message-ID: <200709031236.57707.vda.linux@googlemail.com> Hi John, On Sunday 02 September 2007 01:39, John Gumb wrote: > Looks like there's a bug in loginutils/login.c if PAM authentication is > enabled. > > Symptoms are that if a valid username is entered with an incorrect > password then the user is allowed to log in. > > Problem is if pam authentication fails the code just goes on to do a > getpwnam(username) which will succeed so long as the username is valid. > In the authentication failure case we need to goto auth_failed. > > --- loginutils/login.c.orig 2007-09-02 00:50:09.000000000 +0100 > +++ loginutils/login.c 2007-09-02 00:50:58.000000000 +0100 > @@ -324,6 +324,11 @@ > } > safe_strncpy(username, pamuser, > sizeof(username)); > } > + else > + { > + goto auth_failed; > + } > + > /* If we get here, the user was authenticated, and is > * granted access. */ > pw = getpwnam(username); > > seems to fix it. PAM login support is new. Thanks for spotting this bug. Can you test attached patch? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 4.patch Type: text/x-diff Size: 2101 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070903/f6b27f11/attachment.bin From vda.linux at googlemail.com Mon Sep 3 12:13:16 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 3 Sep 2007 20:13:16 +0100 Subject: [RFC] tail.c size reduction In-Reply-To: <200709022120.53410.farmatito@tiscali.it> References: <200709022120.53410.farmatito@tiscali.it> Message-ID: <200709032013.16588.vda.linux@googlemail.com> On Sunday 02 September 2007 20:20, Tito wrote: > Hi to all, > this is a drop in replacement for tail.c. > It is a result of a few sleepless nights of hacking > that started by looking at and trying > to understand mjn3's code. > At the end I rewrote tail following a different > italian creative and instinctive way. > bloat-o-meter is not that bad: > > * scripts/bloat-o-meter busybox_old busybox_unstripped > * function old new delta > * xmalloc_fgetc - 40 +40 > * .rodata 122102 122134 +32 > * header_fmt 13 - -13 > * eat_num 37 - -37 > * tail_read 126 - -126 > * tail_main 1109 784 -325 > * ------------------------------------------------------------------------------ > * (add/remove: 1/3 grow/shrink: 1/1 up/down: 72/-501) Total: -429 bytes > > The functionality should be the same as the original, at least > that is what my little testing says, but as the size reduction > is that big I fear that i've overlooked something very stupid somewhere. > That's why i'm posting it to the list for auditing and inspection by > better coders than me that will see my obvious errors. do { /* With no FILE or When FILE is -, read standard input. */ if (argc == 0 || LONE_DASH(*argv)) { opt |= ~0x1; /* unset FOLLOW */ llist_add_to_end(&flist, stdin); llist_add_to_end(&nlist, (char *)bb_msg_standard_input); continue; } file = fopen_or_warn(*argv, "r"); if (!file) { status = EXIT_FAILURE; continue; } /* Create lists of FILE* pointers and file names to reuse for -f FOLLOW */ llist_add_to_end(&flist, file); llist_add_to_end(&nlist, *argv); } while (*++argv); If you run tail with no arguments, you go into first if and then "contunue". Then you do ++argv ... and happily continue into environment vector which is typically immediately follows argv[] in memory. cat. deals with it like this: static const char *const argv_dash[] = { "-", NULL }; if (!*argv) argv = (char**) &argv_dash; do { if (LONE_DASH(*argv)) ... Size: I think this do { /* With no FILE or When FILE is -, read standard input. */ if (argc == 0 || LONE_DASH(*argv)) { Will be smaller in this form: do { char *arg = *argv; /* With no FILE or When FILE is -, read standard input. */ if (!arg || LONE_DASH(arg)) { arg is better than *argv since gcc can have doubts that *argv doesn't change across function calls. Help it. Why "!arg" instead of "argc == 0": You need arg for LONE_DASH(), thus gcc pulls it into register, thus !arg is as easy to evaluate as argc == 0, but does not require gcc to allocate another register for argc. But ultimate test in bloatcheck, of course. while (flist) { count = 0; /* if we are reading stdin print the header before reading as read can block */ if ((FILE*)flist->data == stdin) tail_xprint_header(fmt + first_file, nlist->data); Like arg above, temporary FILE *curfile = (FILE*)flist->data; may be smaller, and will be more readable for sure. while ((line = (((COUNT_BYTES) ? xmalloc_fgetc : xmalloc_fgets)((FILE*)flist->data)))) { malloc for each byte? :( /* Show if there was an error while reading */ if (ferror((FILE*)flist->data)) { bb_perror_msg("%s", nlist->data); status = EXIT_FAILURE; } /* Create a list of the lines or chars */ llist_add_to_end(&slist, line); /* If we exceed our -n or -c value remove one element from the head of the list */ if (++count > n) free(llist_pop(&slist)); what will happen if count wraps around? "malloc for each byte" and count problems can be solved together: always store lines, not chars, and deal with COUNT_BYTES case by printing only a part of first line of output, so that total output size is correct. } /* Print the header if needed */ if ((FILE*)flist->data != stdin && ((VERBOSE && argc > 0) || (VERBOSE && slist && argc < 0)) ) tail_xprint_header(fmt + first_file, nlist->data); ((VERBOSE && argc > 0) || (VERBOSE && slist && argc < 0)) == VERBOSE && ((argc > 0) || (slist && argc < 0)) /* Zero first file flag */ first_file = 0; /* Print what we have read */ while ((line = llist_pop(&slist))) { tail_xprint_header("%s", line); free(line); } /* Was the file truncated ? */ if (!slist && lseek(fileno((FILE*)flist->data), 0, SEEK_END) < lseek(fileno((FILE*)flist->data), 0, SEEK_CUR) ) bb_error_msg("file truncated"); Hard to read, and racy (which llseek is done first?). if (!FOLLOW) { /* Close the current file */ fclose_if_not_stdin(llist_pop(&flist)); /* Move the head of the list to the next file name */ llist_pop(&nlist); } else { /* FOLLOW */ /* Sleep for approximately S seconds (default 1) between iterations */ USE_FEATURE_FANCY_TAIL(sleep(xatou(str_s));) /* Move FILE* pointer from the top to the end fo the list */ llist_add_to_end(&flist, llist_pop(&flist)); /* Move filename from the top to the end fo the list */ llist_add_to_end(&nlist, llist_pop(&nlist)); /* Decrement argc as this is our indicator of the first complete iteration of the list */ argc--; } } -- vda From vda.linux at googlemail.com Mon Sep 3 12:48:45 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 3 Sep 2007 20:48:45 +0100 Subject: [patch,RFC,CFT] debloat du #1 In-Reply-To: <20070901200904.GR11697@aon.at> References: <20070901200904.GR11697@aon.at> Message-ID: <200709032048.45489.vda.linux@googlemail.com> On Saturday 01 September 2007 21:09, Bernhard Fischer wrote: > Hi, > > I have this patch lying around for some months now.. > Ideally, du would reuse recursive_action, but the attached patch only > does the non-intrusive (i.e. i didn't rewrite it, which would have been > saner, perhaps) part 1/2, that is switch to globals and debloat the logic > a little bit. This patch does not move the whole applet to > recursive_action as of now (i will not do this anytime soon, so feel > free to do this yourself, or rewrite it completely). > > The reason why i didn't apply it outright is that i did not really test > it (just a little bit, and it worked for me, but hey). > > vda, please apply if you think it's worthwile, or, even better, rewrite > the whole mess to use recursive_action right from the start.. > > Also, i didn't record any stats, size(1)-wise, so better double-check if > it makes sense in the first place.. :-/ text data bss dec hex filename 864 12 28 904 388 busybox.t3/coreutils/du.o 867 0 0 867 363 busybox.t4/coreutils/du.o function old new delta du_main 340 348 +8 print 39 40 +1 status 129 125 -4 slink_depth 4 - -4 print_files 4 - -4 one_file_system 4 - -4 max_print_depth 4 - -4 du_depth 4 - -4 disp_hr 4 - -4 count_hardlinks 4 - -4 du 407 401 -6 dir_dev 8 - -8 ------------------------------------------------------------------------------ (add/remove: 0/8 grow/shrink: 2/2 up/down: 9/-46) Total: -37 bytes Applied, thanks. -- vda From farmatito at tiscali.it Mon Sep 3 13:49:00 2007 From: farmatito at tiscali.it (Tito) Date: Mon, 3 Sep 2007 22:49:00 +0200 Subject: [RFC] tail.c size reduction In-Reply-To: <200709032013.16588.vda.linux@googlemail.com> References: <200709022120.53410.farmatito@tiscali.it> <200709032013.16588.vda.linux@googlemail.com> Message-ID: <200709032249.00136.farmatito@tiscali.it> On Monday 03 September 2007 21:13:16 Denys Vlasenko wrote: > On Sunday 02 September 2007 20:20, Tito wrote: > > Hi to all, > > this is a drop in replacement for tail.c. > > It is a result of a few sleepless nights of hacking > > that started by looking at and trying > > to understand mjn3's code. > > At the end I rewrote tail following a different > > italian creative and instinctive way. > > bloat-o-meter is not that bad: > > > > * scripts/bloat-o-meter busybox_old busybox_unstripped > > * function old new delta > > * xmalloc_fgetc - 40 +40 > > * .rodata 122102 122134 +32 > > * header_fmt 13 - -13 > > * eat_num 37 - -37 > > * tail_read 126 - -126 > > * tail_main 1109 784 -325 > > * ------------------------------------------------------------------------------ > > * (add/remove: 1/3 grow/shrink: 1/1 up/down: 72/-501) Total: -429 bytes > > > > The functionality should be the same as the original, at least > > that is what my little testing says, but as the size reduction > > is that big I fear that i've overlooked something very stupid somewhere. > > That's why i'm posting it to the list for auditing and inspection by > > better coders than me that will see my obvious errors. > > do { > /* With no FILE or When FILE is -, read standard input. */ > if (argc == 0 || LONE_DASH(*argv)) { > opt |= ~0x1; /* unset FOLLOW */ > llist_add_to_end(&flist, stdin); > llist_add_to_end(&nlist, (char *)bb_msg_standard_input); > continue; > } > file = fopen_or_warn(*argv, "r"); > if (!file) { > status = EXIT_FAILURE; > continue; > } > /* Create lists of FILE* pointers and file names to reuse for -f FOLLOW */ > llist_add_to_end(&flist, file); > llist_add_to_end(&nlist, *argv); > } while (*++argv); > > If you run tail with no arguments, you go into first if and then "contunue". > Then you do ++argv ... and happily continue into environment vector which > is typically immediately follows argv[] in memory. Fixed. ./busybox tail file1 file2 - iteration iteration iteration ==> file1 <== 1 ==> file2 <== 23456789a ==> standard input <== root at localhost:~/Desktop/busybox# ./busybox tail - iteration ==> standard input <== root at localhost:~/Desktop/busybox# ./busybox tail iteration ==> standard input <== This for me is smaller than the cat solution. do { /* With no FILE or When FILE is -, read standard input. */ if (!*argv || LONE_DASH(*argv)) { opt |= ~0x1; /* unset FOLLOW */ llist_add_to_end(&flist, stdin); llist_add_to_end(&nlist, (char *)bb_msg_standard_input); if (!*argv) break; continue; } file = fopen_or_warn(*argv, "r"); if (!file) { status = EXIT_FAILURE; continue; } /* Create lists of FILE* pointers and file names to reuse for -f FOLLOW */ llist_add_to_end(&flist, file); llist_add_to_end(&nlist, *argv); } while (*++argv); > cat. deals with it like this: > > static const char *const argv_dash[] = { "-", NULL }; > > if (!*argv) > argv = (char**) &argv_dash; > do { > if (LONE_DASH(*argv)) ... > > > > Size: I think this > > do { > /* With no FILE or When FILE is -, read standard input. */ > if (argc == 0 || LONE_DASH(*argv)) { > > Will be smaller in this form: > > do { > char *arg = *argv; > /* With no FILE or When FILE is -, read standard input. */ > if (!arg || LONE_DASH(arg)) { > > arg is better than *argv since gcc can have doubts that *argv doesn't > change across function calls. Help it. > > Why "!arg" instead of "argc == 0": > You need arg for LONE_DASH(), thus gcc pulls it into register, thus > !arg is as easy to evaluate as argc == 0, but does not require gcc > to allocate another register for argc. > > But ultimate test in bloatcheck, of course. > > > while (flist) { > count = 0; > /* if we are reading stdin print the header before reading as read can block */ > if ((FILE*)flist->data == stdin) > tail_xprint_header(fmt + first_file, nlist->data); > > Like arg above, temporary FILE *curfile = (FILE*)flist->data; > may be smaller, and will be more readable for sure. > > while ((line = (((COUNT_BYTES) ? xmalloc_fgetc : xmalloc_fgets)((FILE*)flist->data)))) { > > malloc for each byte? :( To have something you can free as a line of xmalloc_fgets. > > /* Show if there was an error while reading */ > if (ferror((FILE*)flist->data)) { > bb_perror_msg("%s", nlist->data); > status = EXIT_FAILURE; > } > /* Create a list of the lines or chars */ > llist_add_to_end(&slist, line); > /* If we exceed our -n or -c value remove one element from the head of the list */ > if (++count > n) > free(llist_pop(&slist)); > > what will happen if count wraps around? Don't understand what the meaning of "wraps around is" ? > > "malloc for each byte" and count problems can be solved > together: always store lines, not chars, and deal with > COUNT_BYTES case by printing only a part of first line of output, > so that total output size is correct. How can you know that bytes < bytes_of_the_line, so to print only a part of the line ??? Don't you need two counters? one for the lines and one for the chars you're printing. > > } > /* Print the header if needed */ > if ((FILE*)flist->data != stdin > && ((VERBOSE && argc > 0) || (VERBOSE && slist && argc < 0)) > ) > tail_xprint_header(fmt + first_file, nlist->data); > > ((VERBOSE && argc > 0) || (VERBOSE && slist && argc < 0)) == VERBOSE && ((argc > 0) || (slist && argc < 0)) > > /* Zero first file flag */ > first_file = 0; > /* Print what we have read */ > while ((line = llist_pop(&slist))) { > tail_xprint_header("%s", line); > free(line); > } > > /* Was the file truncated ? */ > if (!slist && lseek(fileno((FILE*)flist->data), 0, SEEK_END) > < lseek(fileno((FILE*)flist->data), 0, SEEK_CUR) > ) > bb_error_msg("file truncated"); > > Hard to read, and racy (which llseek is done first?). Have to fix this any way....i discovered right now that in some circumstances it doesn't work as expected. > > if (!FOLLOW) { > /* Close the current file */ > fclose_if_not_stdin(llist_pop(&flist)); > /* Move the head of the list to the next file name */ > llist_pop(&nlist); > } else { > /* FOLLOW */ > /* Sleep for approximately S seconds (default 1) between iterations */ > USE_FEATURE_FANCY_TAIL(sleep(xatou(str_s));) > /* Move FILE* pointer from the top to the end fo the list */ > llist_add_to_end(&flist, llist_pop(&flist)); > /* Move filename from the top to the end fo the list */ > llist_add_to_end(&nlist, llist_pop(&nlist)); > /* Decrement argc as this is our indicator of the first complete iteration of the list */ > argc--; > } > } > > > -- > vda > Thanks for your review, i learned something.... :-) I'll try to fix it and improve it, and if the size savings are still big enough i'll repost it. Ciao, Tito From andang76 at gmail.com Tue Sep 4 03:17:13 2007 From: andang76 at gmail.com (Andrea) Date: Tue, 04 Sep 2007 12:17:13 +0200 Subject: mac address filtering implementation Message-ID: <46DD30A9.2050601@gmail.com> hi all, this is my first message in ml. I'm trying to implement a wireless access point using me2000 (busybox based) over a Wrap routerboard. A thing I'm not able to implement is a MAC address filtering feature like some access point (DLink, for example)does. I've tried to use ipfilter mac address filtering (using something like described here: http://www.cyberciti.biz/tips/iptables-mac-address-filtering.html ), but I'm not satisfied of the result: traffic is not permitted, but the client is connected to the wireless network. How do ordinary routers implement mac address filtering? P.S. I know the issue of mac address filtering insecurity Thanks, Andrea From vda.linux at googlemail.com Tue Sep 4 07:08:46 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 4 Sep 2007 15:08:46 +0100 Subject: mac address filtering implementation In-Reply-To: <46DD30A9.2050601@gmail.com> References: <46DD30A9.2050601@gmail.com> Message-ID: <200709041508.46582.vda.linux@googlemail.com> On Tuesday 04 September 2007 11:17, Andrea wrote: > hi all, this is my first message in ml. > > I'm trying to implement a wireless access point using me2000 (busybox > based) over a Wrap routerboard. > > A thing I'm not able to implement is a MAC address filtering feature > like some access point (DLink, for example)does. > > I've tried to use ipfilter mac address filtering (using something like > described here: > http://www.cyberciti.biz/tips/iptables-mac-address-filtering.html ), but > I'm not satisfied of the result: traffic is not permitted, but the > client is connected to the wireless network. No surprise. You blocked it at "ethernet" level so to speak, but wireless isn't ethernet in fact, although most OSes try to make it look like it is. Wireless protocols (802.11a,b,g,...) actually are far more complex than ethernet. Packets have three or four MACs, not two, they are bigger than ethernet ones but can be split in-flight. Each node can be in different mode. Protocols define: "ad-hoc" mode when members of "cell" constantly emin beacon frames "hey, and btw I'm in cell MYCELL", "infrastructure" (managed, AP client etc) mode when there is an "access point", a master of sorts, and all other cell members are registering themself at. Only AP emits beacons. "master" mode - when you are the AP. and if it's not enough, there is a WDS mode, sort of inter-cell links. IOW, total chaos. Protocol developers should be shot. IIUC you basically want to block clients from coonecting to the AP. First, you should find out what is the current state of affairs in Linux's wireless support (it used to be a mess, maybe it still is). You should learn what is the standard way to ask your wireless device (which is in master mode) to not accept clients with these MACs. If there is no standard way to do it (remeber "Linux's wireless is a mess" part?), the drivers for your device may still support it via driver-specific ioctl/whatever, so go read doc for your particular device and driver. If you will give more details about your wireless card, kernel version and driver you use, maybe someone will be able to help more. -- vda From natanael.copa at gmail.com Tue Sep 4 09:29:57 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Tue, 04 Sep 2007 18:29:57 +0200 Subject: CONFIG_BUSYBOX_EXEC_PATH="/bin/busybox" and --install -s Message-ID: <1188923397.22371.32.camel@nc.nor.wtbts.org> Hi, I'm upgrading to busybox-1.7.0 and ran into a warning message upn executing --install -s: busybox: /bin/busybox: Invalid argument THe problem is that i have set CONFIG_BUSYBOX_EXEC_PATH="/bin/busybox" in applets/applets.c (around row 581) xmalloc_readlink_or_warn() is called: if (ENABLE_FEATURE_INSTALLER && strcmp(argv[1], "--install") == 0) { const char *busybox; busybox = xmalloc_readlink_or_warn(bb_busybox_exec_path); if (!busybox) busybox = bb_busybox_exec_path; /* -s makes symlinks */ install_links(busybox, argv[2] && strcmp(argv[2], "-s") == 0); return 0; } There is no xmalloc_realink() without the "_or_warn". There is a xmalloc_realpath() but.... It looks too me that nothing else is using this func at all, so it could be removed entirely. It does also consume lots of stackspace on uclibc by declaring char buf[PATH_MAX+1] on stack: char *xmalloc_realpath(const char *path) { #if defined(__GLIBC__) && !defined(__UCLIBC__) /* glibc provides a non-standard extension */ return realpath(path, NULL); #else char buf[PATH_MAX+1]; /* on error returns NULL (xstrdup(NULL) ==NULL) */ return xstrdup(realpath(path, buf)); #endif } I'd recommend to add busybox-1.7.0-install-warn.patch to fixes-1.7.0 and commit busybox-svn-xmalloc_readlink.patch which declares an xmalloc_readlink() and removes xmalloc_realpath() entirely to svn for next release. Or do you prefer to keep and use xmalloc_realpath() but fix it to use char *buf = xmalloc(PATH_MAX+1) as done in the attatched busybox-1.7.0-realpath-stack.patch? -nc -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.7.0-install-warn.patch Type: text/x-patch Size: 412 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070904/4a050c85/attachment-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-svn-xmalloc_readlink.patch Type: text/x-patch Size: 2160 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070904/4a050c85/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.7.0-realpath-stack.patch Type: text/x-patch Size: 457 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070904/4a050c85/attachment-0005.bin From bock at blacknet.de Tue Sep 4 09:03:25 2007 From: bock at blacknet.de (Goetz Bock) Date: Tue, 4 Sep 2007 18:03:25 +0200 Subject: mac address filtering implementation In-Reply-To: <46DD30A9.2050601@gmail.com> References: <46DD30A9.2050601@gmail.com> Message-ID: <20070904160324.GB31346@priv.blacknet.de> On Tue, Sep 04 '07 at 12:17, Andrea wrote: > I'm trying to implement a wireless access point using me2000 (busybox > based) over a Wrap routerboard. > > A thing I'm not able to implement is a MAC address filtering feature > like some access point (DLink, for example)does. The "normal" way to do this with linux is to use hostapd. It supports some chipsets (prism2/2.5/3, prismng, madwifi, ...) and can implement connection policies for you. You may need to also add wpasupplicant to the mix. Cu, Goetz. -- Goetz Bock (c) 2007 as blacknet.de - Munich - Germany /"\ IT Consultant Creative Commons secure mobile Linux everNETting \ / X ASCII Ribbon Campaign against HTML email & microsoft attachments / \ From natanael.copa at gmail.com Tue Sep 4 10:33:48 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Tue, 04 Sep 2007 19:33:48 +0200 Subject: [PATCH] vi should be in /usr/bin and not in /bin Message-ID: <1188927228.22371.41.camel@nc.nor.wtbts.org> Hi, While porting openbsd's sendbug I realized that busybox vi is in /bin and not in /usr/bin where I would expect an application like vi. Attatched is a patch to fix this. btw... since cttyhack is supposed to be called from inittab, i think that /sbin might be a better place than /usr/bin. -nc -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-svn-vi-path.patch Type: text/x-patch Size: 658 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070904/af60123e/attachment.bin From vda.linux at googlemail.com Tue Sep 4 12:05:15 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 4 Sep 2007 20:05:15 +0100 Subject: fork() on NOMMU In-Reply-To: <596342.38345.qm@web62508.mail.re1.yahoo.com> References: <596342.38345.qm@web62508.mail.re1.yahoo.com> Message-ID: <200709042005.16277.vda.linux@googlemail.com> On Sunday 02 September 2007 14:19, Alex Landau wrote: > > --- Denys Vlasenko wrote: > > > To ifdef out things that do not work on NOMMU (for example, > > mount's NFS-related option to auto-background should be disabled). > > > > You already did it for httpd by adding #ifdefs which basically > > enforced httpd -i. Send similar patches for tar/mount/whatever. > > > > Attached patch does that for mount. > It ignores the options "fg" and "bg" (always doing "fg"). Do you think a message (+exit?) > should be printed if "bg" is passed? I never used bg myself, so don't know how useful it > is... Thanks, applied. Sorry for the delay. > For tar it's trickier... I'm thinking of changing the prototype of open_transformer to > (int fd, func_ptr, decompressor_prog). the decompressor_prog is a string equal to "gzip > -cdf", "bzip2 -cdf" or something similar (maybe just "gzip, "bzip2", and open_transformer > itself would add "-cdf"). Then define a macro with the same name that on MMU will just > withdraw the last argument, and on NOMMU withdraw the func_ptr (similar to > daemonize_or_reexec). open_transformer itself will have an "#if BB_MMU" that will decide > to fork and use func_ptr or to vfork and exec decompressor_prog. > Sounds OK? Yes. -- vda From vda.linux at googlemail.com Tue Sep 4 12:21:03 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 4 Sep 2007 20:21:03 +0100 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <1188927228.22371.41.camel@nc.nor.wtbts.org> References: <1188927228.22371.41.camel@nc.nor.wtbts.org> Message-ID: <200709042021.03468.vda.linux@googlemail.com> Hi Natanael, On Tuesday 04 September 2007 18:33, Natanael Copa wrote: > While porting openbsd's sendbug I realized that busybox vi is in /bin > and not in /usr/bin where I would expect an application like vi. Aha, you met yet another idiotic script/program with /usr/bin prefixed to every program it calls? See why I insist that it's a bug and programs should never do it, but should search PATH for that instead? > Attatched is a patch to fix this. > > btw... since cttyhack is supposed to be called from inittab, i think > that /sbin might be a better place than /usr/bin. Let me think about it till tomorrow. -- vda From pgf at brightstareng.com Tue Sep 4 13:14:57 2007 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 04 Sep 2007 16:14:57 -0400 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: vda.linux's message of Tue, 04 Sep 2007 20:21:03 +0100. <200709042021.03468.vda.linux@googlemail.com> Message-ID: <12775.1188936897@brightstareng.com> > On Tuesday 04 September 2007 18:33, Natanael Copa wrote: > > While porting openbsd's sendbug I realized that busybox vi is in /bin > > and not in /usr/bin where I would expect an application like vi. /usr/bin might have been correct at one time, when it was common to have "ed" in /bin. but it's currently the case that vi is often the only editor on the system, and/or the only editor the user will know how to use. so linux puts it in /bin now. (i just checked recent fedora, debian, and ubuntu systems.) paul =--------------------- paul fox, pgf at brightstareng.com From rep.dot.nop at gmail.com Tue Sep 4 14:27:33 2007 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Tue, 4 Sep 2007 23:27:33 +0200 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <12775.1188936897@brightstareng.com> References: <200709042021.03468.vda.linux@googlemail.com> <12775.1188936897@brightstareng.com> Message-ID: <20070904212733.GY11697@aon.at> On Tue, Sep 04, 2007 at 04:14:57PM -0400, Paul Fox wrote: > > On Tuesday 04 September 2007 18:33, Natanael Copa wrote: > > > While porting openbsd's sendbug I realized that busybox vi is in /bin > > > and not in /usr/bin where I would expect an application like vi. > >/usr/bin might have been correct at one time, when it was common >to have "ed" in /bin. but it's currently the case that vi is >often the only editor on the system, and/or the only editor the >user will know how to use. so linux puts it in /bin now. (i >just checked recent fedora, debian, and ubuntu systems.) $ cat /etc/debian_version lenny/sid $ ls -ln /bin/vi* /usr/bin/vi ls: /bin/vi*: No such file or directory lrwxrwxrwx 1 0 0 20 2007-03-30 08:03 /usr/bin/vi -> /etc/alternatives/vi From pgf at brightstareng.com Tue Sep 4 15:03:23 2007 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 04 Sep 2007 18:03:23 -0400 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: rep.dot.nop's message of Tue, 04 Sep 2007 23:27:33 +0200. <20070904212733.GY11697@aon.at> Message-ID: <15028.1188943403@brightstareng.com> > On Tue, Sep 04, 2007 at 04:14:57PM -0400, Paul Fox wrote: > > > On Tuesday 04 September 2007 18:33, Natanael Copa wrote: > > > > While porting openbsd's sendbug I realized that busybox vi is in /bin > > > > and not in /usr/bin where I would expect an application like vi. > > > >/usr/bin might have been correct at one time, when it was common > >to have "ed" in /bin. but it's currently the case that vi is > >often the only editor on the system, and/or the only editor the > >user will know how to use. so linux puts it in /bin now. (i > >just checked recent fedora, debian, and ubuntu systems.) > > $ cat /etc/debian_version > lenny/sid > $ ls -ln /bin/vi* /usr/bin/vi > ls: /bin/vi*: No such file or directory > lrwxrwxrwx 1 0 0 20 2007-03-30 08:03 /usr/bin/vi -> /etc/alternatives/vi you're absolutely right. i clearly must have read the output wrong, because i did check. sigh. :-/ it's in /bin on fedora core 5. it's in /usr/bin on debian sarge, ubuntu 6 and ubuntu 7. sorry for the noise. (but i still think it should be in /bin these days.) paul =--------------------- paul fox, pgf at brightstareng.com From natanael.copa at gmail.com Tue Sep 4 16:22:34 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed, 5 Sep 2007 01:22:34 +0200 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <15028.1188943403@brightstareng.com> References: <20070904212733.GY11697@aon.at> <15028.1188943403@brightstareng.com> Message-ID: <20070905012234.7ff3dd4c.natanael.copa@gmail.com> On Tue, 04 Sep 2007 18:03:23 -0400 Paul Fox wrote: > it's in /bin on fedora core 5. > > it's in /usr/bin on debian sarge, ubuntu 6 and ubuntu 7. and gentoo, openbsd and freebsd. > sorry for the noise. (but i still think it should be in /bin these days.) > You do have a point but i still think it belongs to /usr/bin util majority have switched to /bin (and/or removed ed completely). And in emergency its still possible to run '/bin/busybox vi' -- Natanael Copa From pclouds at gmail.com Tue Sep 4 20:03:21 2007 From: pclouds at gmail.com (Nguyen Thai Ngoc Duy) Date: Wed, 5 Sep 2007 10:03:21 +0700 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <15028.1188943403@brightstareng.com> References: <20070904212733.GY11697@aon.at> <15028.1188943403@brightstareng.com> Message-ID: On 9/5/07, Paul Fox wrote: > it's in /bin on fedora core 5. > > it's in /usr/bin on debian sarge, ubuntu 6 and ubuntu 7. It's in /usr/bin as well on Gentoo (somewhat latest version). -- Duy From andang76 at gmail.com Wed Sep 5 00:13:05 2007 From: andang76 at gmail.com (Andrea) Date: Wed, 05 Sep 2007 09:13:05 +0200 Subject: mac address filtering implementation In-Reply-To: <200709041508.46582.vda.linux@googlemail.com> References: <46DD30A9.2050601@gmail.com> <200709041508.46582.vda.linux@googlemail.com> Message-ID: <46DE5701.40804@gmail.com> Denys Vlasenko ha scritto: > No surprise. You blocked it at "ethernet" level so to speak, > but wireless isn't ethernet in fact, although most OSes > try to make it look like it is. [snip] Gulp! What a mess! Thanks for the explanation From andang76 at gmail.com Wed Sep 5 00:14:30 2007 From: andang76 at gmail.com (Andrea) Date: Wed, 05 Sep 2007 09:14:30 +0200 Subject: mac address filtering implementation In-Reply-To: <20070904160324.GB31346@priv.blacknet.de> References: <46DD30A9.2050601@gmail.com> <20070904160324.GB31346@priv.blacknet.de> Message-ID: <46DE5756.5000503@gmail.com> Goetz Bock ha scritto: > > The "normal" way to do this with linux is to use hostapd. > > It supports some chipsets (prism2/2.5/3, prismng, madwifi, ...) and can > implement connection policies for you. > > You may need to also add wpasupplicant to the mix. Ok, I'll try. thanks From strange at nsk.no-ip.org Wed Sep 5 02:21:18 2007 From: strange at nsk.no-ip.org (Luciano Rocha) Date: Wed, 5 Sep 2007 10:21:18 +0100 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <20070905012234.7ff3dd4c.natanael.copa@gmail.com> References: <20070904212733.GY11697@aon.at> <15028.1188943403@brightstareng.com> <20070905012234.7ff3dd4c.natanael.copa@gmail.com> Message-ID: <20070905092118.GA5040@bit.office.eurotux.com> On Wed, Sep 05, 2007 at 01:22:34AM +0200, Natanael Copa wrote: > > sorry for the noise. (but i still think it should be in /bin these days.) /bin and /usr/bin distinction is blurred this days. There are a lot of binaries in Fedora living in /bin or /sbin that require libraries in /usr/lib. > (and/or removed ed completely) I surelly hope not. Ed is part of the Single Unix specification and very usefull for editing files in scripts. -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070905/beac2aba/attachment.pgp From stanliao at globalunichip.com Wed Sep 5 02:47:44 2007 From: stanliao at globalunichip.com (stanliao at globalunichip.com) Date: Wed, 5 Sep 2007 17:47:44 +0800 Subject: source level debug Message-ID: Hi All, Linux and busybox is run on our SOC chip. And we apply insight, which is run on a host computer, and gdbserver, which is run on the target board, to debug applications. In our applications, there are some assembly files for audio/speech codecs. Excuse me, how could I make program in the assembly files debugged in source level? Thanks a lot. Best Regards, Stan Liao From landau_alex at yahoo.com Wed Sep 5 04:12:33 2007 From: landau_alex at yahoo.com (Alex Landau) Date: Wed, 5 Sep 2007 04:12:33 -0700 (PDT) Subject: [PATCH] Tar with transformer (gzip, bzip2, ...) on NOMMU Message-ID: <169256.41045.qm@web62501.mail.re1.yahoo.com> Hi, The attached patch makes "tar -xzf" work on NOMMU. - The main part is the open_transformer function that instead of forking and running a "transformation" function (that should decompress the archive), vforks and execs the appropriate decompressor. - A bit of preprocessor magic (include/unarchive.h) removes the unused arguments at the time of call (the transformer function is unused on NOMMU, and the external helper to exec is unused on MMU). - Changed components and how thorough they were tested: * tar -xzf - fullly tested on MMU and NOMMU. * tar -xjf - same. * tar -xaf (LZMA) - same. * LZMA (archival/bbunzip.c) - added -f option (same meaning as for gunzip). It was present in the usage message, seems to be implemented by the common function bbunpack(), but just was not passed to getopt32(). * tar -xZf (uncompress) - compile-tested only (both MMU and NOMMU). I don't have .Z files to test on... Should work as long as uncompress can be invoked as "uncompress -cf -". * rpm - compile-tested on both MMU and NOMMU. Sort of runtime tested on MMU. I downloaded an rpm file and ran ./busybox rpm -i .rpm. It complained that it can't create some file under /etc. That's normal since I'm not root. The files it tried to create have the correct names, so it should work (tm). - The patch should change nothing on MMU machines. Someone using rpm and compress, please verify that... - gzip, bzip2 and lzma work for me on NOMMU (and on MMU too, of course). - The patch touches quite a lot of files, but the changes are minor in most cases (except open_transformer that is at the core). Diffstat below. archival/bbunzip.c | 2 +- archival/libunarchive/Kbuild | 1 - archival/libunarchive/get_header_tar_bz2.c | 2 +- archival/libunarchive/get_header_tar_gz.c | 9 ++++++++- archival/libunarchive/get_header_tar_lzma.c | 2 +- archival/libunarchive/open_transformer.c | 22 +++++++++++++++++++++- archival/rpm.c | 26 +++++++++++++++++++++++--- archival/tar.c | 2 +- include/unarchive.h | 6 ++++++ 9 files changed, 62 insertions(+), 10 deletions(-) Thanks, Alex ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: tar-nommu.diff Type: text/x-patch Size: 8102 bytes Desc: 803123106-tar-nommu.diff Url : http://busybox.net/lists/busybox/attachments/20070905/71018977/attachment-0001.bin From vda.linux at googlemail.com Wed Sep 5 04:14:07 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 5 Sep 2007 12:14:07 +0100 Subject: CONFIG_BUSYBOX_EXEC_PATH="/bin/busybox" and --install -s In-Reply-To: <1188923397.22371.32.camel@nc.nor.wtbts.org> References: <1188923397.22371.32.camel@nc.nor.wtbts.org> Message-ID: <200709051214.07304.vda.linux@googlemail.com> On Tuesday 04 September 2007 17:29, Natanael Copa wrote: > I'm upgrading to busybox-1.7.0 and ran into a warning message upn > executing --install -s: > > busybox: /bin/busybox: Invalid argument > > THe problem is that i have set CONFIG_BUSYBOX_EXEC_PATH="/bin/busybox" > > in applets/applets.c (around row 581) xmalloc_readlink_or_warn() is > called: > > if (ENABLE_FEATURE_INSTALLER && strcmp(argv[1], "--install") == 0) { > const char *busybox; > busybox = xmalloc_readlink_or_warn(bb_busybox_exec_path); > if (!busybox) > busybox = bb_busybox_exec_path; > > There is no xmalloc_realink() without the "_or_warn". There is a > xmalloc_realpath() but.... I am adding one. > It looks too me that nothing else is using this func at all, so it could > be removed entirely. It does also consume lots of stackspace on uclibc > by declaring char buf[PATH_MAX+1] on stack. Thanks to -gc-sections, it never actually links in. > I'd recommend to add busybox-1.7.0-install-warn.patch to fixes-1.7.0 and > commit busybox-svn-xmalloc_readlink.patch which declares an > xmalloc_readlink() and removes xmalloc_realpath() entirely to svn for > next release. > > Or do you prefer to keep and use xmalloc_realpath() but fix it to use > char *buf = xmalloc(PATH_MAX+1) as done in the attatched > busybox-1.7.0-realpath-stack.patch? Oops.. I didn't read your mail to the end, and created another patch myself :( basically diplicating your first suggestion. I will apply this patch to svn and add it to 1.7.0 fixes. Thanks! -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 3.patch Type: text/x-diff Size: 2678 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070905/0004a0c8/attachment.bin From vda.linux at googlemail.com Wed Sep 5 04:31:10 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 5 Sep 2007 12:31:10 +0100 Subject: [PATCH] Tar with transformer (gzip, bzip2, ...) on NOMMU In-Reply-To: <169256.41045.qm@web62501.mail.re1.yahoo.com> References: <169256.41045.qm@web62501.mail.re1.yahoo.com> Message-ID: <200709051231.10150.vda.linux@googlemail.com> On Wednesday 05 September 2007 12:12, Alex Landau wrote: > The attached patch makes "tar -xzf" work on NOMMU. > > - The main part is the open_transformer function that instead of forking and running a > "transformation" function (that should decompress the archive), vforks and execs the > appropriate decompressor. > - A bit of preprocessor magic (include/unarchive.h) removes the unused arguments at the > time of call (the transformer function is unused on NOMMU, and the external helper to > exec is unused on MMU). > - Changed components and how thorough they were tested: > * tar -xzf - fullly tested on MMU and NOMMU. > * tar -xjf - same. > * tar -xaf (LZMA) - same. > * LZMA (archival/bbunzip.c) - added -f option (same meaning as for gunzip). > It was present in the usage message, seems to be implemented by the > common function bbunpack(), but just was not passed to getopt32(). > * tar -xZf (uncompress) - compile-tested only (both MMU and NOMMU). > I don't have .Z files to test on... Should work as long as uncompress can be > invoked as "uncompress -cf -". > * rpm - compile-tested on both MMU and NOMMU. Sort of runtime tested on MMU. > I downloaded an rpm file and ran ./busybox rpm -i .rpm. It > complained that it can't create some file under /etc. That's normal since > I'm not root. The files it tried to create have the correct names, so it should > work (tm). > - The patch should change nothing on MMU machines. Someone using rpm and compress, please > verify that... > - gzip, bzip2 and lzma work for me on NOMMU (and on MMU too, of course). > - The patch touches quite a lot of files, but the changes are minor in most cases (except > open_transformer that is at the core). Diffstat below. > > archival/bbunzip.c | 2 +- > archival/libunarchive/Kbuild | 1 - > archival/libunarchive/get_header_tar_bz2.c | 2 +- > archival/libunarchive/get_header_tar_gz.c | 9 ++++++++- > archival/libunarchive/get_header_tar_lzma.c | 2 +- > archival/libunarchive/open_transformer.c | 22 +++++++++++++++++++++- > archival/rpm.c | 26 +++++++++++++++++++++++--- > archival/tar.c | 2 +- > include/unarchive.h | 6 ++++++ > 9 files changed, 62 insertions(+), 10 deletions(-) Applied with very minor changes, many thanks! (bloatcheck says 0 bytes difference for MMU) -- vda From iggarpe at terra.es Wed Sep 5 04:28:39 2007 From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Wed, 05 Sep 2007 13:28:39 +0200 Subject: [PATCH] subsecond timer period support in watchdog Message-ID: <46DE92E7.2040908@terra.es> See ISSUE 0001482 Patch is quasi-trivial, and a must for dumb hardware watchdogs with fixed timeout values near or below 1s. Regards. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: busybox-trunk-watchdog-ms.patch Url: http://busybox.net/lists/busybox/attachments/20070905/79fce348/attachment.diff From iggarpe at terra.es Wed Sep 5 04:31:52 2007 From: iggarpe at terra.es (=?ISO-8859-1?Q?Ignacio_Garc=EDa_P=E9rez?=) Date: Wed, 05 Sep 2007 13:31:52 +0200 Subject: [PATCH] subsecond timer period support in watchdog (FIXED) Message-ID: <46DE93A8.1060507@terra.es> Missed a trivial bug. Sorry. Regards. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: busybox-trunk-watchdog-ms-v2.patch Url: http://busybox.net/lists/busybox/attachments/20070905/df03e551/attachment.diff From vda.linux at googlemail.com Wed Sep 5 04:58:00 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 5 Sep 2007 12:58:00 +0100 Subject: [PATCH] subsecond timer period support in watchdog In-Reply-To: <46DE92E7.2040908@terra.es> References: <46DE92E7.2040908@terra.es> Message-ID: <200709051258.00518.vda.linux@googlemail.com> On Wednesday 05 September 2007 12:28, Ignacio Garc?a P?rez wrote: > See ISSUE 0001482 > > Patch is quasi-trivial, and a must for dumb hardware watchdogs with > fixed timeout values near or below 1s. Applied to svn, thanks. -- vda From psmith at netezza.com Wed Sep 5 04:48:52 2007 From: psmith at netezza.com (Paul Smith) Date: Wed, 05 Sep 2007 07:48:52 -0400 Subject: [PATCH] subsecond timer period support in watchdog (FIXED) In-Reply-To: <46DE93A8.1060507@terra.es> References: <46DE93A8.1060507@terra.es> Message-ID: <1188992933.23174.16.camel@homebase.localnet> On Wed, 2007-09-05 at 13:31 +0200, Ignacio Garc?a P?rez wrote: > + static const struct suffix_mult suffixes[] = { I'm not a bb dev, but it seems to me that having this static increases the binary size (a bit) for no particularly good reason, as this code doesn't seem to run often enough to benefit from it. Thoughts? From dacker at roinet.com Wed Sep 5 05:21:14 2007 From: dacker at roinet.com (David Acker) Date: Wed, 05 Sep 2007 08:21:14 -0400 Subject: mac address filtering implementation In-Reply-To: <20070904160324.GB31346@priv.blacknet.de> References: <46DD30A9.2050601@gmail.com> <20070904160324.GB31346@priv.blacknet.de> Message-ID: <46DE9F3A.7010900@roinet.com> Goetz Bock wrote: > On Tue, Sep 04 '07 at 12:17, Andrea wrote: >> I'm trying to implement a wireless access point using me2000 (busybox >> based) over a Wrap routerboard. >> >> A thing I'm not able to implement is a MAC address filtering feature >> like some access point (DLink, for example)does. > > The "normal" way to do this with linux is to use hostapd. > > It supports some chipsets (prism2/2.5/3, prismng, madwifi, ...) and can > implement connection policies for you. > > You may need to also add wpasupplicant to the mix. > Some radio drivers support their own interfaces. For example, the hostap driver (not to be confused with the hostapd user space daemon) supports special iwpriv commands maccmd and addmac. Others might support similar calls so you might want to check iwpriv for your radio. -Ack From vda.linux at googlemail.com Wed Sep 5 05:42:37 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 5 Sep 2007 13:42:37 +0100 Subject: [PATCH] subsecond timer period support in watchdog (FIXED) In-Reply-To: <1188992933.23174.16.camel@homebase.localnet> References: <46DE93A8.1060507@terra.es> <1188992933.23174.16.camel@homebase.localnet> Message-ID: <200709051342.38159.vda.linux@googlemail.com> On Wednesday 05 September 2007 12:48, Paul Smith wrote: > On Wed, 2007-09-05 at 13:31 +0200, Ignacio Garc?a P?rez wrote: > > + static const struct suffix_mult suffixes[] = { > > I'm not a bb dev, but it seems to me that having this static increases > the binary size (a bit) for no particularly good reason, as this code > doesn't seem to run often enough to benefit from it. Thoughts? It's 24 bytes. If you are unhappy with it, propose different solution for the problem "people need 0.25 seconds periodic watchdogs". For example, you can add CONFIG_FEATURE_WATCHDOG_MS, I will be happy to apply such patch. -- vda From psmith at netezza.com Wed Sep 5 05:55:35 2007 From: psmith at netezza.com (Paul Smith) Date: Wed, 05 Sep 2007 08:55:35 -0400 Subject: [PATCH] subsecond timer period support in watchdog (FIXED) In-Reply-To: <200709051342.38159.vda.linux@googlemail.com> References: <46DE93A8.1060507@terra.es> <1188992933.23174.16.camel@homebase.localnet> <200709051342.38159.vda.linux@googlemail.com> Message-ID: <1188996935.23174.25.camel@homebase.localnet> On Wed, 2007-09-05 at 13:42 +0100, Denys Vlasenko wrote: > If you are unhappy with it, propose different solution > for the problem "people need 0.25 seconds periodic watchdogs". True, it's not much memory. And I'm not saying that the change should be done differently. All I'm saying is that you can remove the static keyword, so this variable appears on the stack instead of being global. This will reduce the size of the application. I don't see any advantage in making this particular variable static but if there is one that I'm missing, that's fine. Personally it doesn't bother me since my embedded systems tend to have lots of RAM :-) ; it was just something I noticed in passing. Cheers! From pgf at brightstareng.com Wed Sep 5 11:48:04 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 05 Sep 2007 14:48:04 -0400 Subject: fix for "find / /boot -xdev" Message-ID: <20262.1189018084@brightstareng.com> currently, busybox find / /boot -xdev gives no output at all, rather than giving equivalent of find / -xdev; find /boot -xdev the bug was introduced (by me :-/ ) in r14665. i'll commit this patch tomorrow if no objections. paul Index: findutils/find.c =================================================================== --- findutils/find.c (revision 19794) +++ findutils/find.c (working copy) @@ -383,9 +383,11 @@ #if ENABLE_FEATURE_FIND_XDEV if (S_ISDIR(statbuf->st_mode) && xdev_count) { for (i = 0; i < xdev_count; i++) { - if (xdev_dev[i] != statbuf->st_dev) - return SKIP; + if (xdev_dev[i] == statbuf->st_dev) + break; } + if (i == xdev_count) + return SKIP; } #endif i = exec_actions(actions, fileName, statbuf); =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Wed Sep 5 14:20:53 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 05 Sep 2007 17:20:53 -0400 Subject: patch: tftp retry/timeout tweaking Message-ID: <10930.1189027253@brightstareng.com> currently the busybox tftp client will retry forever, due to a misplaced reinitialization of the retry counter. in addition, it times out for a full 5 seconds on any lost packet, which blows performance completely on a marginal network. this patch cleans up both of these issues, by providing a simple exponential backoff mechanism. i just blew away my baseline with a "make clean", but i believe the size cost was about 47 bytes. i'll commit tomorrow if no one objects. paul Index: networking/tftp.c =================================================================== --- networking/tftp.c (revision 19794) +++ networking/tftp.c (working copy) @@ -21,12 +21,12 @@ #include "libbb.h" - #if ENABLE_FEATURE_TFTP_GET || ENABLE_FEATURE_TFTP_PUT #define TFTP_BLOCKSIZE_DEFAULT 512 /* according to RFC 1350, don't change */ -#define TFTP_TIMEOUT 5 /* seconds */ -#define TFTP_NUM_RETRIES 5 /* number of retries */ +#define TFTP_TIMEOUT 50000 /* 50ms, in microseconds */ +#define TFTP_MAXTIMEOUT 999000 /* about 1 second, in microseconds */ +#define TFTP_NUM_RETRIES 12 /* number of backed-off retries */ /* opcodes we support */ #define TFTP_RRQ 1 @@ -124,7 +124,7 @@ uint16_t opcode; uint16_t block_nr = 1; uint16_t recv_blk; - int timeout = TFTP_NUM_RETRIES; + int retries, waittime; char *cp; unsigned org_port; @@ -206,6 +206,10 @@ send_len = cp - xbuf; /* NB: send_len value is preserved in code below * for potential resend */ + + retries = TFTP_NUM_RETRIES; /* re-initialize */ + waittime = TFTP_TIMEOUT; + send_again: #if ENABLE_DEBUG_TFTP fprintf(stderr, "sending %u bytes\n", send_len); @@ -218,11 +222,10 @@ if (finished && (opcode == TFTP_ACK)) goto ret; - timeout = TFTP_NUM_RETRIES; /* re-initialize */ recv_again: /* Receive packet */ - tv.tv_sec = TFTP_TIMEOUT; - tv.tv_usec = 0; + tv.tv_sec = 0; + tv.tv_usec = waittime; FD_ZERO(&rfds); FD_SET(socketfd, &rfds); switch (select(socketfd + 1, &rfds, NULL, NULL, &tv)) { @@ -248,12 +251,18 @@ goto recv_again; goto process_pkt; case 0: - timeout--; - if (timeout == 0) { - bb_error_msg("last timeout"); + retries--; + if (retries == 0) { + bb_error_msg("timeout"); goto ret; } - bb_error_msg("last timeout" + 5); + + /* exponential backoff with limit */ + waittime += waittime/2; + if (waittime > TFTP_MAXTIMEOUT) { + waittime = TFTP_MAXTIMEOUT; + } + goto send_again; /* resend last sent pkt */ default: bb_perror_msg("select"); =--------------------- paul fox, pgf at brightstareng.com From natanael.copa at gmail.com Wed Sep 5 14:37:34 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed, 05 Sep 2007 23:37:34 +0200 Subject: patch: tftp retry/timeout tweaking In-Reply-To: <10930.1189027253@brightstareng.com> References: <10930.1189027253@brightstareng.com> Message-ID: <1189028254.28259.53.camel@nc.nor.wtbts.org> On Wed, 2007-09-05 at 17:20 -0400, Paul Fox wrote: > currently the busybox tftp client will retry forever, due > to a misplaced reinitialization of the retry counter. should this be added to fixes-1.7.0? -nc From natanael.copa at gmail.com Wed Sep 5 14:38:24 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed, 05 Sep 2007 23:38:24 +0200 Subject: fix for "find / /boot -xdev" In-Reply-To: <20262.1189018084@brightstareng.com> References: <20262.1189018084@brightstareng.com> Message-ID: <1189028304.28259.55.camel@nc.nor.wtbts.org> On Wed, 2007-09-05 at 14:48 -0400, Paul Fox wrote: > currently, > busybox find / /boot -xdev > gives no output at all, rather than giving equivalent of > find / -xdev; find /boot -xdev > > the bug was introduced (by me :-/ ) in r14665. > > i'll commit this patch tomorrow if no objections. Does this need to be added to fixes-1.7.0? -nc From pgf at brightstareng.com Wed Sep 5 14:47:23 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 05 Sep 2007 17:47:23 -0400 Subject: fix for "find / /boot -xdev" In-Reply-To: natanael.copa's message of Wed, 05 Sep 2007 23:38:24 +0200. <1189028304.28259.55.camel@nc.nor.wtbts.org> Message-ID: <11570.1189028843@brightstareng.com> > On Wed, 2007-09-05 at 14:48 -0400, Paul Fox wrote: > > currently, > > busybox find / /boot -xdev > > gives no output at all, rather than giving equivalent of > > find / -xdev; find /boot -xdev > > > > the bug was introduced (by me :-/ ) in r14665. > > > > i'll commit this patch tomorrow if no objections. > > Does this need to be added to fixes-1.7.0? perhaps. but the bug has existed since 03/2006, and no one else has reported it. paul =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Wed Sep 5 14:48:36 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 05 Sep 2007 17:48:36 -0400 Subject: patch: tftp retry/timeout tweaking In-Reply-To: natanael.copa's message of Wed, 05 Sep 2007 23:37:34 +0200. <1189028254.28259.53.camel@nc.nor.wtbts.org> Message-ID: <11633.1189028916@brightstareng.com> > On Wed, 2007-09-05 at 17:20 -0400, Paul Fox wrote: > > currently the busybox tftp client will retry forever, due > > to a misplaced reinitialization of the retry counter. > > should this be added to fixes-1.7.0? > perhaps the infinite timeout should be fixed, but the backoff part isn't critical. it's mainly just really annoying. paul =--------------------- paul fox, pgf at brightstareng.com From landau_alex at yahoo.com Wed Sep 5 22:25:04 2007 From: landau_alex at yahoo.com (Alex Landau) Date: Wed, 5 Sep 2007 22:25:04 -0700 (PDT) Subject: [PATCH] Tar with transformer (gzip, bzip2, ...) on NOMMU In-Reply-To: <200709051231.10150.vda.linux@googlemail.com> Message-ID: <68903.25151.qm@web62510.mail.re1.yahoo.com> --- Denys Vlasenko wrote: > On Wednesday 05 September 2007 12:12, Alex Landau wrote: > [snip] > Applied with very minor changes, many thanks! > > (bloatcheck says 0 bytes difference for MMU) Thanks. Small question: in open_transformer() you changed perror() and _exit() to bb_perror_and_die() which is not defined. Forgot to svn add? Also, you removed the comment saying that we should use _exit() and not exit(), so I guess bb_perror_and_die is not just a mistyped bb_perror_msg_and_die... Alex ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ From andang76 at gmail.com Thu Sep 6 00:45:32 2007 From: andang76 at gmail.com (Andrea) Date: Thu, 06 Sep 2007 09:45:32 +0200 Subject: mac address filtering implementation In-Reply-To: <46DE9F3A.7010900@roinet.com> References: <46DD30A9.2050601@gmail.com> <20070904160324.GB31346@priv.blacknet.de> <46DE9F3A.7010900@roinet.com> Message-ID: <46DFB01C.8000502@gmail.com> > Some radio drivers support their own interfaces. For example, the hostap driver (not to be confused with the hostapd > user space daemon) supports special iwpriv commands maccmd and addmac. Others might support similar calls so you might > want to check iwpriv for your radio. Solved in this way. It seems work From hinko.kocevar at cetrtapot.si Thu Sep 6 02:50:01 2007 From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si) Date: Thu, 06 Sep 2007 11:50:01 +0200 Subject: compiling busybox-1.6.1 for cris architecture fails In-Reply-To: <200708311345.39236.vda.linux@googlemail.com> References: <46D6BFDF.1070602@cetrtapot.si> <200708311236.12337.vda.linux@googlemail.com> <46D80456.1000009@cetrtapot.si> <200708311345.39236.vda.linux@googlemail.com> Message-ID: <46DFCD49.8050807@cetrtapot.si> Denys Vlasenko wrote: > On Friday 31 August 2007 13:06, hinko.kocevar at cetrtapot.si wrote: >>> >>> Does it make sense to you to jump to 1.7.0, since you >>> have to jump anyway? >> I'll try it out. I guess it is not that of a problem, just that it is >> labeled unstable and I hesitate to break something else by introducing >> untested code in the production systems [like it is not enough that our >> own untested stuff makes it there :-/]... >> I've tried using 1.7.0 source and it fails the same as 1.6.1. > Nothing especially interesting. > > You may go into trylink and set debug=true, you will make > trylink report commands it tries to run. > trylink with "debug=true": /home/hinkok/delo/fw/car2_R1.gen/pkg/busybox-R2/build/uclibc/static/scripts/trylink gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM -D_REENTRANT -mno-mul-bug-workaround -muclibc=/fw/car2_R1.gen/stage.uclibc -L/fw/car2_R1.gen/stage.uclibc/lib -Wl,-rpath-link,/fw/car2_R1.gen/stage.uclibc/lib -o busybox_unstripped -Wl,-Map -Wl,busybox_unstripped.map -Wl,--warn-common -Wl,--sort-common -Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a ipsvd/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a archival/built-in.o archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o ipsvd/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o -Wl,--end-group Trying libraries: crypt m Trying: gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM -D_REENTRANT -mno-mul-bug-workaround -muclibc=/fw/car2_R1.gen/stage.uclibc -L/fw/car2_R1.gen/stage.uclibc/lib -Wl,-rpath-link,/fw/car2_R1.gen/stage.uclibc/lib -o busybox_unstripped -Wl,-Map -Wl,busybox_unstripped.map -Wl,--warn-common -Wl,--sort-common -Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a ipsvd/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a archival/built-in.o archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o ipsvd/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group Failed: gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM -D_REENTRANT -mno-mul-bug-workaround -muclibc=/fw/car2_R1.gen/stage.uclibc -L/fw/car2_R1.gen/stage.uclibc/lib -Wl,-rpath-link,/fw/car2_R1.gen/stage.uclibc/lib -o busybox_unstripped -Wl,-Map -Wl,busybox_unstripped.map -Wl,--warn-common -Wl,--sort-common -Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a ipsvd/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a archival/built-in.o archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o ipsvd/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group > Do gcc -v hello_world.c and compare linker flags used for it and for bbox. > Compiler output with '-v' flag on hello.c: hinkok at genovefa /tmp $ gcc_cris -mlinux -DLINUX -DLINUX_SYSTEM -D_REENTRANT -mno-mul-bug-workaround -muclibc=/fw/car2_R1.gen/stage.uclibc/ hello.c -v Reading specs from /usr/local/cris/lib/gcc-lib/cris-axis-linux-gnu/3.2.1/specs Configured with: /usr/src/redhat/BUILD/cris-dist-1.62/./gnu-toplev/configure --enable-version-specific-runtime-libs --disable-nls --target=cris-axis-linux-gnu --without-newlib --with-headers=installed --enable-languages=c,c++ --enable-shared --enable-threads=posix --prefix=/usr/local/cris Thread model: posix gcc version 3.2.1 Axis release R62/1.62 /usr/local/cris/lib/gcc-lib/cris-axis-linux-gnu/3.2.1/cc1 -lang-c -nostdinc -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -Dcris -DCRIS -DGNU_CRIS -D__cris__ -D__CRIS__ -D__GNU_CRIS__ -D__cris -D__CRIS -D__GNU_CRIS -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__CRIS_ABI_version=2 -D__gnu_linux__ -D__linux__ -D__unix__ -D__ELF__ -fno-leading-underscore -D__NO_UNDERSCORES__ -D__arch_v10 -D__CRIS_arch_version=10 -Dlinux -Dunix -Asystem(unix) -Asystem(posix) -Acpu(cris) -Amachine(cris) -DLINUX -DLINUX_SYSTEM -D_REENTRANT -isystem /fw/car2_R1.gen/stage.uclibc//include -isystem /fw/car2_R1.gen/stage.uclibc//include/uC-libc -isystem /usr/local/cris/lib/gcc-lib/cris-axis-linux-gnu/3.2.1/include -isystem /fw/car2_R1.gen/stage.uclibc//include/gcc hello.c -march=v10 -quiet -dumpbase hello.c -mlinux -mno-mul-bug-workaround -version -o /tmp/cc1U4Tdp.s > And btw, note that gcc commands which compile .c files into .o contains > -static-libgcc - maybe this is the problem? > > Makefile.flags > ============== > CFLAGS += $(call cc-option,-funsigned-char -static-libgcc,) > ^^^^^^^^^^^^^^ Nope. It compiles with the "-static-libgcc" flag just fine. regards, Hinko -- ?ETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenia, Europe Tel. +386 (0) 4 280 66 03 E-mail: hinko.kocevar at cetrtapot.si Http: www.cetrtapot.si From nitalohia at yahoo.co.in Wed Sep 5 22:24:32 2007 From: nitalohia at yahoo.co.in (nita lohia) Date: Thu, 6 Sep 2007 06:24:32 +0100 (BST) Subject: unknown server error Message-ID: <642715.33242.qm@web7815.mail.in.yahoo.com> hello, i m getting an error "Unknown server error" when i ive command "hostname -i" or even ping localhost I am using busybox with arm linux. i m having files /etc/hosts /etc/host.conf /etc/resolve.conf /etc/nsswitch.conf can u help me ? --------------------------------- 5, 50, 500, 5000 - Store N number of mails in your inbox. Click here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20070906/2e47cb91/attachment-0001.htm From natanael.copa at gmail.com Thu Sep 6 03:38:02 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 06 Sep 2007 12:38:02 +0200 Subject: unknown server error In-Reply-To: <642715.33242.qm@web7815.mail.in.yahoo.com> References: <642715.33242.qm@web7815.mail.in.yahoo.com> Message-ID: <1189075082.15328.18.camel@nc.nor.wtbts.org> On Thu, 2007-09-06 at 06:24 +0100, nita lohia wrote: > hello, > > i m getting an error > "Unknown server error" > > when i ive command > "hostname -i" > > or even ping localhost > > I am using busybox with arm linux. > > i m having files > /etc/hosts > /etc/host.conf > /etc/resolve.conf ^^^ did you try /etc/resolv.conf? > /etc/nsswitch.conf > > can u help me ? -nc From vda.linux at googlemail.com Thu Sep 6 05:48:49 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Sep 2007 13:48:49 +0100 Subject: unknown server error In-Reply-To: <642715.33242.qm@web7815.mail.in.yahoo.com> References: <642715.33242.qm@web7815.mail.in.yahoo.com> Message-ID: <200709061348.49129.vda.linux@googlemail.com> On Thursday 06 September 2007 06:24, nita lohia wrote: > hello, > > i m getting an error > "Unknown server error" > > when i ive command > "hostname -i" > > or even ping localhost > > I am using busybox with arm linux. > > i m having files > /etc/hosts > /etc/host.conf > /etc/resolve.conf > /etc/nsswitch.conf > > can u help me ? Plase do strace -o hostname.log hostname -i strace -o ping.log ping localhost and show resulting log files. Also show your .config and describe how do you build busybox (against which lib - glibc? uclibc?) -- vda From fabio.busatto at sikurezza.org Thu Sep 6 05:50:51 2007 From: fabio.busatto at sikurezza.org (Fabio Busatto) Date: Thu, 6 Sep 2007 14:50:51 +0200 Subject: umount patch Message-ID: <20070906125051.GC2793@nachos.phaseit.com> Hi, this is a very simple patch to add support in umount for -i option. It is required for compatibility with util-linux umount, and some software like fuse needs it (see recent post about mount patch). The patch let umount to recognize and silently ignore the option. Bye :) Fabio diff -uNr busybox-orig/util-linux/umount.c busybox/util-linux/umount.c --- busybox-orig/util-linux/umount.c 2007-09-06 09:20:17.000000000 +0200 +++ busybox/util-linux/umount.c 2007-09-06 14:27:15.000000000 +0200 @@ -12,10 +12,10 @@ #include #include "libbb.h" -#define OPTION_STRING "flDnravdt:" +#define OPTION_STRING "flDnravdit:" #define OPT_FORCE 1 #define OPT_LAZY 2 -#define OPT_DONTFREELOOP 4 +#define OPT_DONTFREELOOP 4 #define OPT_NO_MTAB 8 #define OPT_REMOUNT 16 #define OPT_ALL (ENABLE_FEATURE_UMOUNT_ALL ? 32 : 0) -- Fabio Busatto From nitalohia at yahoo.co.in Thu Sep 6 04:36:33 2007 From: nitalohia at yahoo.co.in (nita lohia) Date: Thu, 6 Sep 2007 12:36:33 +0100 (BST) Subject: unknown server error In-Reply-To: <1189075082.15328.18.camel@nc.nor.wtbts.org> Message-ID: <394274.68819.qm@web7806.mail.in.yahoo.com> Hello here is full discription: #include #include int main() { struct hostenv *hp; char host[120]; if(gethostname(host,sizeof(host))<0) return -1; printf("host:%s\n",host); if(hp=gethostbyname(host)==NULL) { printf("%s",hstrerror(h_errno)); return -1; } printf("hello"); return 0; } O/p : host:SetuVFX88L Unknown server error files /etc/hosts 127.0.0.1 localhost.localdomain localhost 192.168.1.104 SetuVFX88L /etc/host.conf order host,bind multi on /etc/networks NETWORKING=yes HOSTNAME=SetuVFX88L /etc/resolv.conf nameserver 192.168.1.104 /etc/nsswitch.conf hosts: files dns i m using busybox and arm-linux....... ping SetuVFX88L hostname -i working fine....... can any one help me ? --------------------------------- DELETE button is history. Unlimited mail storage is just a click away. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20070906/446fe87c/attachment.htm From strange at nsk.no-ip.org Thu Sep 6 06:33:01 2007 From: strange at nsk.no-ip.org (Luciano Rocha) Date: Thu, 6 Sep 2007 14:33:01 +0100 Subject: unknown server error In-Reply-To: <394274.68819.qm@web7806.mail.in.yahoo.com> References: <1189075082.15328.18.camel@nc.nor.wtbts.org> <394274.68819.qm@web7806.mail.in.yahoo.com> Message-ID: <20070906133301.GA2272@bit.office.eurotux.com> On Thu, Sep 06, 2007 at 12:36:33PM +0100, nita lohia wrote: > Hello > > here is full discription: > > #include > #include Also include for gethostname(). > int main() > { > struct hostenv *hp; This is struct hostent, not hostenv. > char host[120]; > if(gethostname(host,sizeof(host))<0) > return -1; > printf("host:%s\n",host); > if(hp=gethostbyname(host)==NULL) Group this correctly: if((hp=gethostbyname(host))==NULL) > { > printf("%s",hstrerror(h_errno)); This is obsolete, use perror(host) directly; > return -1; > } > printf("hello"); Don't forget \n. Also, to see the result: printf("host %s: %s\n", host, inet_ntoa(*(struct in_addr *)hp->h_addr_list[0])); (with include of: > return 0; > } > O/p : > host:SetuVFX88L > Unknown server error Here, with the changes: host:bit.office.eurotux.com hello host bit.office.eurotux.com: 10.10.10.8 > > files > > /etc/hosts > 127.0.0.1 localhost.localdomain localhost > 192.168.1.104 SetuVFX88L Are you using glibc, and included the needed libraries for name resolve? libnss_* -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070906/34c62e98/attachment.pgp From tomas at slax.org Thu Sep 6 08:58:11 2007 From: tomas at slax.org (Tomas M) Date: Thu, 06 Sep 2007 15:58:11 +0000 Subject: umount patch In-Reply-To: <20070906125051.GC2793@nachos.phaseit.com> References: <20070906125051.GC2793@nachos.phaseit.com> Message-ID: <46E02393.5020002@slax.org> Fabio Busatto wrote: > Hi, this is a very simple patch to add support in umount for -i option. Ah, good point, I sent a patch for 'mount -i' some time ago (which was already included in CVS), but I entirely forgot that 'umount' needs -i as well! So I vote for this -i option as well. Tomas M slax.org From vda.linux at googlemail.com Thu Sep 6 09:32:10 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Sep 2007 17:32:10 +0100 Subject: unknown server error In-Reply-To: <394274.68819.qm@web7806.mail.in.yahoo.com> References: <394274.68819.qm@web7806.mail.in.yahoo.com> Message-ID: <200709061732.10331.vda.linux@googlemail.com> On Thursday 06 September 2007 12:36, nita lohia wrote: > Hello > > here is full discription: > > #include > #include > int main() > { > struct hostenv *hp; > char host[120]; > if(gethostname(host,sizeof(host))<0) > return -1; > printf("host:%s\n",host); > if(hp=gethostbyname(host)==NULL) > { > printf("%s",hstrerror(h_errno)); > return -1; > } > printf("hello"); > return 0; > } My o/p ;) $ ./a.out host:vda.at.work hello -- vda From vda.linux at googlemail.com Thu Sep 6 09:38:45 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Sep 2007 17:38:45 +0100 Subject: umount patch In-Reply-To: <46E02393.5020002@slax.org> References: <20070906125051.GC2793@nachos.phaseit.com> <46E02393.5020002@slax.org> Message-ID: <200709061738.45672.vda.linux@googlemail.com> On Thursday 06 September 2007 16:58, Tomas M wrote: > Fabio Busatto wrote: > > Hi, this is a very simple patch to add support in umount for -i option. > > Ah, good point, I sent a patch for 'mount -i' some time ago (which was > already included in CVS), but I entirely forgot that 'umount' > needs -i as well! > > So I vote for this -i option as well. Applied, thanks! -- vda From natanael.copa at gmail.com Thu Sep 6 09:49:32 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 06 Sep 2007 18:49:32 +0200 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <200709042021.03468.vda.linux@googlemail.com> References: <1188927228.22371.41.camel@nc.nor.wtbts.org> <200709042021.03468.vda.linux@googlemail.com> Message-ID: <1189097372.15328.32.camel@nc.nor.wtbts.org> On Tue, 2007-09-04 at 20:21 +0100, Denys Vlasenko wrote: > Hi Natanael, > > On Tuesday 04 September 2007 18:33, Natanael Copa wrote: > > While porting openbsd's sendbug I realized that busybox vi is in /bin > > and not in /usr/bin where I would expect an application like vi. ... > Let me think about it till tomorrow. Do you know what you want? (I wonder if i should my revert my patch for my local build) -nc > -- > vda From natanael.copa at gmail.com Thu Sep 6 09:52:09 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 06 Sep 2007 18:52:09 +0200 Subject: fix for "find / /boot -xdev" In-Reply-To: <11570.1189028843@brightstareng.com> References: <11570.1189028843@brightstareng.com> Message-ID: <1189097529.15328.35.camel@nc.nor.wtbts.org> On Wed, 2007-09-05 at 17:47 -0400, Paul Fox wrote: > > On Wed, 2007-09-05 at 14:48 -0400, Paul Fox wrote: > > > currently, > > > busybox find / /boot -xdev > > > gives no output at all, rather than giving equivalent of > > > find / -xdev; find /boot -xdev > > > > > > the bug was introduced (by me :-/ ) in r14665. > > > > > > i'll commit this patch tomorrow if no objections. > > > > Does this need to be added to fixes-1.7.0? > > perhaps. but the bug has existed since 03/2006, and no one else > has reported it. Nothing is better than patching before end users discover the bugs. ;) -nc From vda.linux at googlemail.com Thu Sep 6 09:53:29 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Sep 2007 17:53:29 +0100 Subject: patch: tftp retry/timeout tweaking In-Reply-To: <10930.1189027253@brightstareng.com> References: <10930.1189027253@brightstareng.com> Message-ID: <200709061753.29196.vda.linux@googlemail.com> On Wednesday 05 September 2007 22:20, Paul Fox wrote: > currently the busybox tftp client will retry forever, due > to a misplaced reinitialization of the retry counter. > > in addition, it times out for a full 5 seconds on any lost > packet, which blows performance completely on a marginal > network. > > this patch cleans up both of these issues, by providing a > simple exponential backoff mechanism. > > i just blew away my baseline with a "make clean", but i believe > the size cost was about 47 bytes. > > i'll commit tomorrow if no one objects. Go for it! :) > - timeout = TFTP_NUM_RETRIES; /* re-initialize */ > recv_again: > /* Receive packet */ > - tv.tv_sec = TFTP_TIMEOUT; > - tv.tv_usec = 0; > + tv.tv_sec = 0; > + tv.tv_usec = waittime; > FD_ZERO(&rfds); > FD_SET(socketfd, &rfds); > switch (select(socketfd + 1, &rfds, NULL, NULL, &tv)) { Select bitmasks are quite big: 128 bytes I found out that using poll for waiting on one descriptor only prodices noticeably smaller code. For one, you have max timeout of 999000 us just because you don't want to mess with tv_usec overflow. With poll, it's trivial to have e.g. 2 second timeout - int poll(struct pollfd *ufds, nfds_t nfds, int timeout_in_ms); ^^^^^^^^^^^^^ (I can imagine that it drives people mad when they need _micro_seconds...) -- vda From vda.linux at googlemail.com Thu Sep 6 09:54:38 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Sep 2007 17:54:38 +0100 Subject: fix for "find / /boot -xdev" In-Reply-To: <1189028304.28259.55.camel@nc.nor.wtbts.org> References: <20262.1189018084@brightstareng.com> <1189028304.28259.55.camel@nc.nor.wtbts.org> Message-ID: <200709061754.38953.vda.linux@googlemail.com> On Wednesday 05 September 2007 22:38, Natanael Copa wrote: > On Wed, 2007-09-05 at 14:48 -0400, Paul Fox wrote: > > currently, > > busybox find / /boot -xdev > > gives no output at all, rather than giving equivalent of > > find / -xdev; find /boot -xdev > > > > the bug was introduced (by me :-/ ) in r14665. > > > > i'll commit this patch tomorrow if no objections. > > Does this need to be added to fixes-1.7.0? Sure, I will be happy to do it. I just added first four patches to http://busybox.net/downloads/fixes-1.7.0/ -- vda From vda.linux at googlemail.com Thu Sep 6 10:11:37 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 6 Sep 2007 18:11:37 +0100 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <1189097372.15328.32.camel@nc.nor.wtbts.org> References: <1188927228.22371.41.camel@nc.nor.wtbts.org> <200709042021.03468.vda.linux@googlemail.com> <1189097372.15328.32.camel@nc.nor.wtbts.org> Message-ID: <200709061811.37733.vda.linux@googlemail.com> On Thursday 06 September 2007 17:49, Natanael Copa wrote: > On Tue, 2007-09-04 at 20:21 +0100, Denys Vlasenko wrote: > > Hi Natanael, > > > > On Tuesday 04 September 2007 18:33, Natanael Copa wrote: > > > While porting openbsd's sendbug I realized that busybox vi is in /bin > > > and not in /usr/bin where I would expect an application like vi. > ... > > Let me think about it till tomorrow. > > Do you know what you want? (I wonder if i should my revert my patch for > my local build) I feel that software generally shouldn't depend on where binaries are, and should just use PATH. Users (admins) should have freedom to decide what does to /bin, and what to /usr/bin. (btw I don't really understand why busybox has --install option, I do it with shell script, but I won't remove --install) -- vda From pgf at brightstareng.com Thu Sep 6 10:35:12 2007 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 06 Sep 2007 13:35:12 -0400 Subject: fix for "find / /boot -xdev" In-Reply-To: vda.linux's message of Thu, 06 Sep 2007 17:54:38 +0100. <200709061754.38953.vda.linux@googlemail.com> Message-ID: <25368.1189100112@brightstareng.com> > On Wednesday 05 September 2007 22:38, Natanael Copa wrote: > > On Wed, 2007-09-05 at 14:48 -0400, Paul Fox wrote: > > > currently, > > > busybox find / /boot -xdev > > > gives no output at all, rather than giving equivalent of > > > find / -xdev; find /boot -xdev > > > ... > > Does this need to be added to fixes-1.7.0? > > Sure, I will be happy to do it. committed to the trunk. paul =--------------------- paul fox, pgf at brightstareng.com From natanael.copa at gmail.com Thu Sep 6 11:36:45 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 06 Sep 2007 20:36:45 +0200 Subject: [PATCH] vi should be in /usr/bin and not in /bin In-Reply-To: <200709061811.37733.vda.linux@googlemail.com> References: <1188927228.22371.41.camel@nc.nor.wtbts.org> <200709042021.03468.vda.linux@googlemail.com> <1189097372.15328.32.camel@nc.nor.wtbts.org> <200709061811.37733.vda.linux@googlemail.com> Message-ID: <1189103805.15328.54.camel@nc.nor.wtbts.org> On Thu, 2007-09-06 at 18:11 +0100, Denys Vlasenko wrote: > On Thursday 06 September 2007 17:49, Natanael Copa wrote: > > On Tue, 2007-09-04 at 20:21 +0100, Denys Vlasenko wrote: > > > Hi Natanael, > > > > > > On Tuesday 04 September 2007 18:33, Natanael Copa wrote: > > > > While porting openbsd's sendbug I realized that busybox vi is in /bin > > > > and not in /usr/bin where I would expect an application like vi. > > ... > > > Let me think about it till tomorrow. > > > > Do you know what you want? (I wonder if i should my revert my patch for > > my local build) > > I feel that software generally shouldn't depend on where binaries are, > and should just use PATH. > > Users (admins) should have freedom to decide what does to /bin, > and what to /usr/bin. Hmmm... I just discovered /usr/include/paths.h The reason I brought this up in first place is because I'm porting openbsd's sendbug and it just uses _PATH_VI which is defined in /usr/include/paths.h. $ grep _PATH_VI /usr/include/paths.h #define _PATH_VI "/usr/bin/vi" well... I guess I'll keep it in /usr/bin > (btw I don't really understand why busybox has --install option, > I do it with shell script, but I won't remove --install) Handy. You just need one single /bin/busybox and don't depend on lots of other stuff. > -- > vda From pgf at brightstareng.com Thu Sep 6 12:17:22 2007 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 06 Sep 2007 15:17:22 -0400 Subject: patch: short form for unzip archive listing Message-ID: <12175.1189106242@brightstareng.com> if you're dealing with zip archives in a script, it's useful to be able to get a script-friendly listing. the current '-l' command is more like 'ls -l', i.e. lots of information, but not script-friendly. this patch overloads the existing '-q' flag so that if '-l' and '-q' are used together, a "short form" listing (just pathnames) is generated. (without this patch, the options make no sense to use together.) i don't quite understand the bloatcheck, since i actually added a few characters to the usage message, but i guess overall it now compresses better? odd. function old new delta unzip_main 1807 1858 +51 packed_usage 23173 23151 -22 .rodata 122070 122038 -32 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 1/2 up/down: 51/-54) Total: -3 bytes i can commit in a day or two if no one objects. paul Index: archival/unzip.c =================================================================== --- archival/unzip.c (revision 19797) +++ archival/unzip.c (working copy) @@ -97,7 +97,8 @@ int unzip_main(int argc, char **argv) { zip_header_t zip_header; - enum {v_silent, v_normal, v_list} verbosity = v_normal; + int verbose = 1; + int listing = 0; enum {o_prompt, o_never, o_always} overwrite = o_prompt; unsigned int total_size = 0; unsigned int total_entries = 0; @@ -115,7 +116,7 @@ case 0: /* Options */ switch (opt) { case 'l': /* List */ - verbosity = v_list; + listing = 1; break; case 'n': /* Never overwrite existing files */ @@ -130,7 +131,7 @@ dst_fd = STDOUT_FILENO; case 'q': /* Be quiet */ - verbosity = (verbosity == v_normal) ? v_silent : verbosity; + verbose = 0; break; case 1 : /* The zip file */ @@ -205,7 +206,7 @@ if (base_dir) xchdir(base_dir); - if (verbosity != v_silent) + if (verbose) printf("Archive: %s\n", src_fn); failed = 0; @@ -245,7 +246,7 @@ /* Skip extra header bytes */ unzip_skip(src_fd, zip_header.formatted.extra_len); - if ((verbosity == v_list) && !list_header_done){ + if (listing && verbose && !list_header_done){ puts(" Length Date Time Name\n" " -------- ---- ---- ----"); list_header_done = 1; @@ -259,7 +260,8 @@ } else { /* Extract entry */ total_size += zip_header.formatted.ucmpsize; - if (verbosity == v_list) { /* List entry */ + if (listing) { /* List entry */ + if (verbose) { unsigned int dostime = zip_header.formatted.modtime | (zip_header.formatted.moddate << 16); printf("%9u %02u-%02u-%02u %02u:%02u %s\n", zip_header.formatted.ucmpsize, @@ -270,7 +272,11 @@ (dostime & 0x000007e0) >> 5, dst_fn); total_entries++; - i = 'n'; + } else { + /* short listing -- filenames only */ + printf("%s\n", dst_fn); + } + i = 'n'; } else if (dst_fd == STDOUT_FILENO) { /* Extracting to STDOUT */ i = -1; } else if (last_char_is(dst_fn, '/')) { /* Extract directory */ @@ -278,7 +284,7 @@ if (errno != ENOENT) { bb_perror_msg_and_die("cannot stat '%s'",dst_fn); } - if (verbosity == v_normal) { + if (verbose) { printf(" creating: %s\n", dst_fn); } unzip_create_leading_dirs(dst_fn); @@ -326,7 +332,7 @@ unzip_create_leading_dirs(dst_fn); dst_fd = xopen(dst_fn, O_WRONLY | O_CREAT | O_TRUNC); case -1: /* Unzip */ - if (verbosity == v_normal) { + if (verbose) { printf(" inflating: %s\n", dst_fn); } if (unzip_extract(&zip_header, src_fd, dst_fd)) { @@ -368,7 +374,7 @@ } } - if (verbosity == v_list) { + if (listing && verbose) { printf(" -------- -------\n" "%9d %d files\n", total_size, total_entries); } Index: include/usage.h =================================================================== --- include/usage.h (revision 19795) +++ include/usage.h (working copy) @@ -3763,7 +3763,7 @@ #define unzip_full_usage \ "Extract files from ZIP archives" \ "\n\nOptions:\n" \ - " -l List archive contents (short form)\n" \ + " -l List archive contents (with -q for short form)\n" \ " -n Never overwrite existing files (default)\n" \ " -o Overwrite files without prompting\n" \ " -p Send output to stdout\n" \ =--------------------- paul fox, pgf at brightstareng.com From k at kcomputing.com Thu Sep 6 12:17:27 2007 From: k at kcomputing.com (Kevin P. Dankwardt) Date: Thu, 06 Sep 2007 14:17:27 -0500 Subject: unknown server error In-Reply-To: <642715.33242.qm@web7815.mail.in.yahoo.com> References: <642715.33242.qm@web7815.mail.in.yahoo.com> Message-ID: <46E05247.2060403@kcomputing.com> I see this a lot. It happens, at least to me, when I don't have libnss_files.so.2. This library, by-the-way, can't be statically linked so you aways need it and ld-linux if you want to resolve hosts by name. -kevin dankwardt nita lohia wrote: > hello, > > i m getting an error > "Unknown server error" > > when i ive command > "hostname -i" > > or even ping localhost > > I am using busybox with arm linux. > > i m having files > /etc/hosts > /etc/host.conf > /etc/resolve.conf > /etc/nsswitch.conf > > can u help me ? > > ------------------------------------------------------------------------ > 5, 50, 500, 5000 - Store N number of mails in your inbox. Click here. > > > ------------------------------------------------------------------------ > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From tapojoychatterjee at yahoo.co.in Thu Sep 6 14:49:06 2007 From: tapojoychatterjee at yahoo.co.in (Tapojoy chatterjee) Date: Thu, 6 Sep 2007 22:49:06 +0100 (BST) Subject: issue regarding ESC in vi Message-ID: <952496.93304.qm@web7909.mail.in.yahoo.com> hi whenever we press ESC in vi there is flashing of the terminal..is there a way around it Tapojoy Chatterjee --------------------------------- 5, 50, 500, 5000 - Store N number of mails in your inbox. Click here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20070906/b1891db1/attachment.htm From tapojoychatterjee at yahoo.co.in Fri Sep 7 05:55:42 2007 From: tapojoychatterjee at yahoo.co.in (Tapojoy chatterjee) Date: Fri, 7 Sep 2007 13:55:42 +0100 (BST) Subject: '/' in scripts not getting solved Message-ID: <520936.87405.qm@web7902.mail.in.yahoo.com> Hi In busybox 1.7.0 am not able to execute a script containing a mathematical expression "$a/$b" while the script executes with no noise in busybox 1.5.. Do help regarding it Tapojoy Chatterjee --------------------------------- Unlimited freedom, unlimited storage. Get it now -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20070907/66f73851/attachment.htm From pgf at brightstareng.com Fri Sep 7 06:08:54 2007 From: pgf at brightstareng.com (Paul Fox) Date: Fri, 07 Sep 2007 09:08:54 -0400 Subject: '/' in scripts not getting solved In-Reply-To: tapojoychatterjee's message of Fri, 07 Sep 2007 13:55:42 +0100. <520936.87405.qm@web7902.mail.in.yahoo.com> Message-ID: <28358.1189170534@brightstareng.com> > Hi > In busybox 1.7.0 am not able to execute a script containing a > mathematical expression "$a/$b" while the script executes with > no noise in busybox 1.5. we can't help you if you don't share the script. if your whole script is too big, send us a smaller test case. paul =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Fri Sep 7 06:37:35 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 7 Sep 2007 14:37:35 +0100 Subject: '/' in scripts not getting solved In-Reply-To: <520936.87405.qm@web7902.mail.in.yahoo.com> References: <520936.87405.qm@web7902.mail.in.yahoo.com> Message-ID: <200709071437.35653.vda.linux@googlemail.com> On Friday 07 September 2007 13:55, Tapojoy chatterjee wrote: > Hi > In busybox 1.7.0 am not able to execute a script containing a mathematical expression "$a/$b" while the script executes with no noise in busybox 1.5.. Can you give exact steps how to reproduce that? (And which shell is that - we have four). $ ./busybox ash $ a=3333 $ b=56 $ echo $(( $a/$b )) 59 -- vda From vda.linux at googlemail.com Fri Sep 7 06:49:39 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 7 Sep 2007 14:49:39 +0100 Subject: issue regarding ESC in vi In-Reply-To: <952496.93304.qm@web7909.mail.in.yahoo.com> References: <952496.93304.qm@web7909.mail.in.yahoo.com> Message-ID: <200709071449.39315.vda.linux@googlemail.com> On Thursday 06 September 2007 22:49, Tapojoy chatterjee wrote: > hi > whenever we press ESC in vi there is flashing of the terminal..is there a way around it I'm not using vi myself, but looking at vi.c, there is some obscure way to toggle bell/flash notification. grep for "bell" in vi.c -- vda From pgf at brightstareng.com Fri Sep 7 08:35:40 2007 From: pgf at brightstareng.com (Paul Fox) Date: Fri, 07 Sep 2007 11:35:40 -0400 Subject: patch: allow default PATH extension at build time Message-ID: <31600.1189179340@brightstareng.com> this is a pretty non-intrusive patch. no code change, no additional bytes! :-) on our product(s), we try and keep locally developed executables in a bin directory that is separate from the things that traditionally come with a linux distribution. this is for our own convenience, and sanity. but we want all system programs, daemons, etc, to be able to get at those local executables easily -- this is an embedded system, after all. it's inconvenient to externally augment the PATH of things started directly from init, or at boot time, etc, so this patch allows appending extra text to the default system PATH that's provided by init (and by the shell). (this patch is a lot smaller than it used to be, because all instances of the default PATH have recently been consolidated to messages.c -- thanks, vda.) i'll commit in a day or two if no one objects. paul p.s. the patch also rearranges the version text ifdef, for symmetry with my addition. Index: libbb/messages.c =================================================================== --- libbb/messages.c (revision 19795) +++ libbb/messages.c (working copy) @@ -7,13 +7,21 @@ #include "libbb.h" +/* allow default system PATH to be extended via CFLAGS */ +#ifndef BB_ADDITIONAL_PATH +#define BB_ADDITIONAL_PATH +#endif + +/* allow version to be extended, via CFLAGS */ #ifndef BB_EXTRA_VERSION -#define BANNER "BusyBox v" BB_VER " (" BB_BT ")" -#else +#define BB_EXTRA_VERSION BB_BT +#endif + #define BANNER "BusyBox v" BB_VER " (" BB_EXTRA_VERSION ")" -#endif + const char bb_banner[] ALIGN1 = BANNER; + const char bb_msg_memory_exhausted[] ALIGN1 = "memory exhausted"; const char bb_msg_invalid_date[] ALIGN1 = "invalid date '%s'"; const char bb_msg_write_error[] ALIGN1 = "write error"; @@ -39,7 +47,8 @@ const char bb_default_login_shell[] ALIGN1 = LIBBB_DEFAULT_LOGIN_SHELL; /* util-linux manpage says /sbin:/bin:/usr/sbin:/usr/bin, * but I want to save a few bytes here. Check libbb.h before changing! */ -const char bb_PATH_root_path[] ALIGN1 = "PATH=/sbin:/usr/sbin:/bin:/usr/bin"; +const char bb_PATH_root_path[] ALIGN1 = + "PATH=/sbin:/usr/sbin:/bin:/usr/bin" BB_ADDITIONAL_PATH; const int const_int_0; =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Fri Sep 7 09:55:13 2007 From: pgf at brightstareng.com (Paul Fox) Date: Fri, 07 Sep 2007 12:55:13 -0400 Subject: issue regarding ESC in vi In-Reply-To: vda.linux's message of Fri, 07 Sep 2007 14:49:39 +0100. <200709071449.39315.vda.linux@googlemail.com> Message-ID: <1116.1189184113@brightstareng.com> > On Thursday 06 September 2007 22:49, Tapojoy chatterjee wrote: > > hi > > whenever we press ESC in vi there is flashing of the terminal..is there a way around it > > I'm not using vi myself, but looking at vi.c, there is some obscure way > to toggle bell/flash notification. > > grep for "bell" in vi.c :set noflash =--------------------- paul fox, pgf at brightstareng.com From liangcw at netzero.com Fri Sep 7 10:59:21 2007 From: liangcw at netzero.com (Phillip Liang) Date: Fri, 7 Sep 2007 17:59:21 GMT Subject: NFS Support Message-ID: <20070907.105921.7811.0@webmail18.dca.untd.com> Hi, I have the same issue. Here is the result as vda suggested. Thanks for your help. (1) mount: mounting 192.168.10.33:/scratch on /mnt/test failed: Invalid argument (2) # cat nfs.log execve("/bin/mount", ["mount", "-t", "nfs", "192.168.10.33:/scratch", "/mnt/test"], [/* 16 vars */]) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 getuid32() = 0 brk(0) = 0xe6000 brk(0xe7000) = 0xe7000 getuid32() = 0 brk(0xe8000) = 0xe8000 getcwd("/mnt", 4098) = 5 brk(0xe9000) = 0xe9000 ioctl(2147483647, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbeaa7b5c) = -1 EBADF (Bad file descriptor) brk(0xea000) = 0xea000 stat64(0xbeaa7e92, 0xbeaa7b94) = -1 ENOENT (No such file or directory) mount("192.168.10.33:/scratch", "/mnt/test", "nfs", MS_SILENT, "") = -1 EINVAL (Invalid argument) write(2, "mount", 5) = 5 write(2, ": ", 2) = 2 write(2, "mounting ", 9) = 9 write(2, "192.168.10.33:/scratch", 22) = 22 write(2, " on ", 4) = 4 write(2, "/mnt/test", 9) = 9 write(2, " failed", 7) = 7 write(2, ": ", 2) = 2 write(2, "Invalid argument", 16) = 16 write(2, "\n", 1) = 1 exit(-1) = ? On Thursday 02 August 2007 09:25, Devinim Ş?LEN wrote: > Hi; > > I am using BusyBox version 1.6.1 and have a NFS mounting problem. When I try > to mount NFS external point getting this error; > > mount -t nfs 192.168.10.64:/ /mnt > mount: mounting 192.168.10.64:/ on /mnt failed > > can anybody help ? * Please find the following line in mount.c: bb_error_msg("mounting %s on %s failed", mp->mnt_fsname, mp->mnt_dir); and replace "_error_" with "_perror_". What does it print now? * Do "strace -o mnt.log mount -t nfs 192.168.10.64:/ /mnt" and post log * Do "tcpdump -nl -iethN -s0 -vvv host 192.168.10.64 and host " and post log here (bzip2 it if it's big) -- vda From kannappan at tesbv.com Fri Sep 7 11:17:13 2007 From: kannappan at tesbv.com (kannappan at tesbv.com) Date: Fri, 07 Sep 2007 23:47:13 +0530 Subject: booting fails after "init free memory" Message-ID: <20070907234713.w9dhgswl4wkc0s8w@bangalore.tesbv.com> I am using buildroot / uclibc to make initrd image. uclibc version is 0.9.29 , binutils 2.17, gcc 4.1.2 and busybox version 1.6.1. buildroot and busybox is compiled with shared lib options. when i load the initrd image to the target (arm926ejs), i am getting the following message: RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem) Freeing init memory: 72K when i google'd for this freeze operation, lists opted to enable the NWFPE in the kernel. even after that there is a freeze. with gcc4.1.2, binutils 2.17, newlib and busybox 1.6.1, after enabling NWFPE in kernel, initrd works fine. can anyone throw some pointers ? -- kans. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From vda.linux at googlemail.com Fri Sep 7 12:08:24 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 7 Sep 2007 20:08:24 +0100 Subject: NFS Support In-Reply-To: <20070907.105921.7811.0@webmail18.dca.untd.com> References: <20070907.105921.7811.0@webmail18.dca.untd.com> Message-ID: <200709072008.25004.vda.linux@googlemail.com> On Friday 07 September 2007 18:59, Phillip Liang wrote: > > Hi, > > I have the same issue. > Here is the result as vda suggested. > Thanks for your help. > > (1) > mount: mounting 192.168.10.33:/scratch on /mnt/test failed: Invalid argument > > (2) > # cat nfs.log > execve("/bin/mount", ["mount", "-t", "nfs", "192.168.10.33:/scratch", "/mnt/test"], [/* 16 vars */]) = 0 > ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 > ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0 > getuid32() = 0 > brk(0) = 0xe6000 > brk(0xe7000) = 0xe7000 > getuid32() = 0 > brk(0xe8000) = 0xe8000 > getcwd("/mnt", 4098) = 5 > brk(0xe9000) = 0xe9000 > ioctl(2147483647, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbeaa7b5c) = -1 EBADF (Bad file descriptor) ^^^^^^^^^^ This is indeed not a valid file descriptor. ioctl call like the above is typically done by stdio.h functions (like fopen, fprintf, etc). I need your help in identifying the problem. Message is definitely coming from here: report_error: if (ENABLE_FEATURE_CLEAN_UP) free(filteropts); if (rc && errno == EBUSY && ignore_busy) rc = 0; if (rc < 0) bb_perror_msg("mounting %s on %s failed", mp->mnt_fsname, mp->mnt_dir); at the end of singlemount() function. Can you edit singlemount() and add debug prints approximately like this: static int singlemount(struct mntent *mp, int ignore_busy) { int rc = -1, vfsflags; char *loopFile = 0, *filteropts = 0; llist_t *fl = 0; struct stat st; printf("HERE 1\n"); vfsflags = parse_mount_options(mp->mnt_opts, &filteropts); printf("HERE 2\n"); // Treat fstype "auto" as unspecified. if (mp->mnt_type && strcmp(mp->mnt_type,"auto") == 0) mp->mnt_type = 0; // Might this be an CIFS filesystem? if (ENABLE_FEATURE_MOUNT_CIFS && (!mp->mnt_type || strcmp(mp->mnt_type,"cifs") == 0) && (mp->mnt_fsname[0]=='/' || mp->mnt_fsname[0]=='\\') && mp->mnt_fsname[0]==mp->mnt_fsname[1] ) { len_and_sockaddr *lsa; char *ip, *dotted; char *s; printf("HERE 3\n"); rc = 1; and so on, then recompile busybox and rerun the same mount command? -- vda From vda.linux at googlemail.com Fri Sep 7 12:15:02 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 7 Sep 2007 20:15:02 +0100 Subject: patch: allow default PATH extension at build time In-Reply-To: <31600.1189179340@brightstareng.com> References: <31600.1189179340@brightstareng.com> Message-ID: <200709072015.03250.vda.linux@googlemail.com> On Friday 07 September 2007 16:35, Paul Fox wrote: > this is a pretty non-intrusive patch. no code change, no > additional bytes! :-) > > on our product(s), we try and keep locally developed executables > in a bin directory that is separate from the things that > traditionally come with a linux distribution. this is for our > own convenience, and sanity. but we want all system programs, > daemons, etc, to be able to get at those local executables > easily -- this is an embedded system, after all. it's > inconvenient to externally augment the PATH of things started > directly from init, or at boot time, etc, so this patch allows > appending extra text to the default system PATH that's provided > by init (and by the shell). (this patch is a lot smaller than it > used to be, because all instances of the default PATH have > recently been consolidated to messages.c -- thanks, vda.) Applied already, thanks! -- vda From vda.linux at googlemail.com Fri Sep 7 12:19:29 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 7 Sep 2007 20:19:29 +0100 Subject: patch: short form for unzip archive listing In-Reply-To: <12175.1189106242@brightstareng.com> References: <12175.1189106242@brightstareng.com> Message-ID: <200709072019.29922.vda.linux@googlemail.com> On Thursday 06 September 2007 20:17, Paul Fox wrote: > if you're dealing with zip archives in a script, it's useful to > be able to get a script-friendly listing. the current '-l' > command is more like 'ls -l', i.e. lots of information, but not > script-friendly. > > this patch overloads the existing '-q' flag so that if '-l' and > '-q' are used together, a "short form" listing (just pathnames) > is generated. (without this patch, the options make no sense to > use together.) > > i don't quite understand the bloatcheck, since i actually added a > few characters to the usage message, but i guess overall it now > compresses better? odd. > > function old new delta > unzip_main 1807 1858 +51 > packed_usage 23173 23151 -22 > .rodata 122070 122038 -32 > ------------------------------------------------------------------------------ > (add/remove: 0/0 grow/shrink: 1/2 up/down: 51/-54) Total: -3 bytes > > > i can commit in a day or two if no one objects. > - enum {v_silent, v_normal, v_list} verbosity = v_normal; > + int verbose = 1; > + int listing = 0; I think smallint will give you some small additional win in bloatcheck. -- vda From pgf at brightstareng.com Fri Sep 7 13:10:16 2007 From: pgf at brightstareng.com (Paul Fox) Date: Fri, 07 Sep 2007 16:10:16 -0400 Subject: patch: short form for unzip archive listing In-Reply-To: vda.linux's message of Fri, 07 Sep 2007 20:19:29 +0100. <200709072019.29922.vda.linux@googlemail.com> Message-ID: <12450.1189195816@brightstareng.com> > > > > i can commit in a day or two if no one objects. > > > - enum {v_silent, v_normal, v_list} verbosity = v_normal; > > + int verbose = 1; > > + int listing = 0; > > I think smallint will give you some small additional win in bloatcheck. committed. i changed these and a couple of other flag vars to smallint, and saved another 30 bytes. paul =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Sat Sep 8 08:09:46 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 8 Sep 2007 16:09:46 +0100 Subject: NFS Support In-Reply-To: <20070907.170947.1690.0@webmail19.dca.untd.com> References: <20070907.170947.1690.0@webmail19.dca.untd.com> Message-ID: <200709081609.46612.vda.linux@googlemail.com> On Saturday 08 September 2007 01:09, Phillip Liang wrote: > Hi, > > This lead to CONFIG_FEATURE_MOUNT_NFS was not set. > It is working now. > Thanks for help. > > Phillip > -- "Phillip Liang" wrote: > The output indicates the program skip this part, > > // Might this be an NFS filesystem? > > printf(" HERE 8\n"); > if (ENABLE_FEATURE_MOUNT_NFS > && (!mp->mnt_type || !strcmp(mp->mnt_type,"nfs")) > && strchr(mp->mnt_fsname, ':') != NULL > ) { > rc = nfsmount(mp, vfsflags, filteropts); > printf(" HERE 9\n"); > goto report_error; > } > > And goes to > > > printf(" HERE 14\n"); > // If mount failed, clean up loop file (if any). > > if (ENABLE_FEATURE_MOUNT_LOOP && rc && loopFile) { > del_loop(mp->mnt_fsname); > if (ENABLE_FEATURE_CLEAN_UP) { > free(loopFile); > free(mp->mnt_fsname); > } > } Wait a second here. As your earlier strace shows, with !ENABLE_FEATURE_MOUNT_NFS we are using uninitialized file descriptor somewhere. It's a bug, and it still should be fixed. Can you do the strace again, with printfs added and FEATURE_MOUNT_NFS not set (so that it will show "Bad file descriptor" again), and send me strace log and your modified mount.c with printfs? -- vda From landau_alex at yahoo.com Sat Sep 8 22:33:54 2007 From: landau_alex at yahoo.com (Alex Landau) Date: Sat, 8 Sep 2007 22:33:54 -0700 (PDT) Subject: [PATCH] Tar with transformer (gzip, bzip2, ...) on NOMMU In-Reply-To: <68903.25151.qm@web62510.mail.re1.yahoo.com> Message-ID: <773633.84076.qm@web62512.mail.re1.yahoo.com> --- Alex Landau wrote: > --- Denys Vlasenko wrote: > > > On Wednesday 05 September 2007 12:12, Alex Landau wrote: > > [snip] > > Applied with very minor changes, many thanks! > > > > (bloatcheck says 0 bytes difference for MMU) > > Thanks. > Small question: in open_transformer() you changed perror() and _exit() to > bb_perror_and_die() which is not defined. Forgot to svn add? Also, you removed the > comment saying that we should use _exit() and not exit(), so I guess bb_perror_and_die > is > not just a mistyped bb_perror_msg_and_die... > > Alex > Bumping.... ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC From vda.linux at googlemail.com Sun Sep 9 06:54:04 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 9 Sep 2007 14:54:04 +0100 Subject: [PATCH] Tar with transformer (gzip, bzip2, ...) on NOMMU In-Reply-To: <773633.84076.qm@web62512.mail.re1.yahoo.com> References: <773633.84076.qm@web62512.mail.re1.yahoo.com> Message-ID: <200709091454.04371.vda.linux@googlemail.com> On Sunday 09 September 2007 06:33, Alex Landau wrote: > > --- Alex Landau wrote: > > > --- Denys Vlasenko wrote: > > > > > On Wednesday 05 September 2007 12:12, Alex Landau wrote: > > > [snip] > > > Applied with very minor changes, many thanks! > > > > > > (bloatcheck says 0 bytes difference for MMU) > > > > Thanks. > > Small question: in open_transformer() you changed perror() and _exit() to > > bb_perror_and_die() which is not defined. Forgot to svn add? Also, you removed the > > comment saying that we should use _exit() and not exit(), so I guess bb_perror_and_die > > is > > not just a mistyped bb_perror_msg_and_die... > > > > Alex > > > > Bumping.... Sorry, I should have tested NOMMU build... I fixed it in svn now. It is in fact mistyped bb_perror_msg_and_die(). I think we can call it here, because we do not use atexit, and it flushes stdio internally, so exit inside bb_perror_msg_and_die() will actually work as intended. Another thing: currentl all unpackers have the same command line. Attached patch uses this and reduces size by 70 bytes by giving up the ability to run arbitrary command line. What do you think? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: zz.diff Type: text/x-diff Size: 6148 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20070909/2a73f7e7/attachment.bin From landau_alex at yahoo.com Sun Sep 9 23:53:58 2007 From: landau_alex at yahoo.com (Alex Landau) Date: Sun, 9 Sep 2007 23:53:58 -0700 (PDT) Subject: [PATCH] Tar with transformer (gzip, bzip2, ...) on NOMMU In-Reply-To: <200709091454.04371.vda.linux@googlemail.com> Message-ID: <493509.30302.qm@web62501.mail.re1.yahoo.com> --- Denys Vlasenko wrote: > On Sunday 09 September 2007 06:33, Alex Landau wrote: > > > > --- Alex Landau wrote: > > > > > --- Denys Vlasenko wrote: > > > > > > > On Wednesday 05 September 2007 12:12, Alex Landau wrote: > > > > [snip] > > > > Applied with very minor changes, many thanks! > > > > > > > > (bloatcheck says 0 bytes difference for MMU) > > > > > > Thanks. > > > Small question: in open_transformer() you changed perror() and _exit() to > > > bb_perror_and_die() which is not defined. Forgot to svn add? Also, you removed the > > > comment saying that we should use _exit() and not exit(), so I guess > bb_perror_and_die > > > is > > > not just a mistyped bb_perror_msg_and_die... > > > > > > Alex > > > > > > > Bumping.... > > Sorry, I should have tested NOMMU build... > > I fixed it in svn now. Compiles now, thanks. > > It is in fact mistyped bb_perror_msg_and_die(). I think we can call it here, > because we do not use atexit, and it flushes stdio internally, so exit > inside bb_perror_msg_and_die() will actually work as intended. I hope... Anyway that perror will only happen if exec has failed, which should (hopefully) occur only during development, if at all. > > Another thing: currentl all unpackers have the same > command line. Attached patch uses this and reduces size by 70 bytes > by giving up the ability to run arbitrary command line. > What do you think? No problems on my side. Plus, since the full version is committed, if another incompatible unpacker is added, we can always return to that version (or adapt the unpacker, of course). > vda Alex ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ From nitalohia at yahoo.co.in Sun Sep 9 23:56:39 2007 From: nitalohia at yahoo.co.in (nita lohia) Date: Mon, 10 Sep 2007 07:56:39 +0100 (BST) Subject: strace command Message-ID: <148917.56431.qm@web7806.mail.in.yahoo.com> hello i want to use strace command but it is not available to me.... how can i use it........ i m having linux.. can copy be done ? how ? thanks --------------------------------- Get the freedom to save as many mails as you wish. Click here to know how. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20070910/cf3f221d/attachment.htm From nitalohia at yahoo.co.in Sun Sep 9 23:51:39 2007 From: nitalohia at yahoo.co.in (nita lohia) Date: Mon, 10 Sep 2007 07:51:39 +0100 (BST) Subject: failed to pawn cgi task Message-ID: <287105.10662.qm@web7812.mail.in.yahoo.com> hello, i m using go ahead web server in arm linux , busybox..... i always get an error failed to spawn cgi task... my cg-bin directory set to 777...... can anyone help me ? Thanks in advance....... --------------------------------- Get the freedom to save as many mails as you wish. Click here to know how. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20070910/9427b67f/attachment.htm From natanael.copa at gmail.com Mon Sep 10 02:58:17 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Mon, 10 Sep 2007 11:58:17 +0200 Subject: strace command In-Reply-To: <148917.56431.qm@web7806.mail.in.yahoo.com> References: <148917.56431.qm@web7806.mail.in.yahoo.com> Message-ID: <1189418297.1153.8.camel@nc.nor.wtbts.org> On Mon, 2007-09-10 at 07:56 +0100, nita lohia wrote: > hello > > i want to use strace command > > but it is not available to me.... > > how can i use it........ > > i m having linux.. > > can copy be done ? how ? > > thanks There are like 1000 different linux distributions and all off them have their way of installing packages. Since you don't tell what linux ditribution you use nor what architecture you use, its basicly impossible to give any answer to you question. Have a look at http://catb.org/~esr/faqs/smart-questions.html Also, this question is not related to busybox so it is wrong place to ask. Sorry. -nc From natanael.copa at gmail.com Mon Sep 10 03:40:33 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Mon, 10 Sep 2007 12:40:33 +0200 Subject: failed to pawn cgi task In-Reply-To: <287105.10662.qm@web7812.mail.in.yahoo.com> References: <287105.10662.qm@web7812.mail.in.yahoo.com> Message-ID: <1189420833.1153.12.camel@nc.nor.wtbts.org> On Mon, 2007-09-10 at 07:51 +0100, nita lohia wrote: > hello, > > i m using go ahead web server in arm linux , busybox..... > > i always get an error > > failed to spawn cgi task... > > my cg-bin directory set to 777...... > > can anyone help me ? > > Thanks in advance....... Its difficult for ppl here to help since go ahead web server is not a busybox product. Have you tried http://webserver.goahead.com/webserver/wssupport.htm -nc From vda.linux at googlemail.com Mon Sep 10 05:42:37 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 10 Sep 2007 13:42:37 +0100 Subject: run_shell and selinux Message-ID: <200709101342.37663.vda.linux@googlemail.com> Hi, void run_shell(const char *shell, int loginshell, const char *command, const char **additional_args) { const char **args; int argno = 1; int additional_args_cnt = 0; ... args[argno] = NULL; #if ENABLE_SELINUX if (current_sid && !setexeccon(current_sid)) { freecon(current_sid); execve(shell, (char **) args, environ); } else #endif execv(shell, (char **) args); bb_perror_msg_and_die("cannot run %s", shell); } I don't understand in full what is the intent of the above #if/#endif block. IIRC these are equivalent: execve(shell, (char **) args, environ); execv(shell, (char **) args); Can it be rewritten this way? #if ENABLE_SELINUX if (current_sid && !setexeccon(current_sid)) freecon(current_sid); #endif execv(shell, (char **) args); If not, we need to add a comment which explains why not. -- vda From vda.linux at googlemail.com Mon Sep 10 05:48:08 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 10 Sep 2007 13:48:08 +0100 Subject: run_shell and selinux In-Reply-To: <200709101342.37663.vda.linux@googlemail.com> References: <200709101342.37663.vda.linux@googlemail.com> Message-ID: <200709101348.08958.vda.linux@googlemail.com> On Monday 10 September 2007 13:42, Denys Vlasenko wrote: > I don't understand in full what is the intent of the above > #if/#endif block. IIRC these are equivalent: > execve(shell, (char **) args, environ); > execv(shell, (char **) args); > Can it be rewritten this way? > > #if ENABLE_SELINUX > if (current_sid && !setexeccon(current_sid)) > freecon(current_sid); > #endif > execv(shell, (char **) args); > > If not, we need to add a comment which explains why not. and, moreover, is freecon() needed at all? Maybe this is in order? if (ENABLE_FEATURE_CLEAN_UP) freecon(...) -- vda From himainu-ynakam at miomio.jp Mon Sep 10 06:30:39 2007 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 10 Sep 2007 22:30:39 +0900 Subject: run_shell and selinux In-Reply-To: <200709101342.37663.vda.linux@googlemail.com> References: <200709101342.37663.vda.linux@googlemail.com> Message-ID: <20070910223039.c0eb154b.himainu-ynakam@miomio.jp> Hi. On Mon, 10 Sep 2007 13:42:37 +0100 Denys Vlasenko wrote: > Hi, > > void run_shell(const char *shell, int loginshell, const char *command, const char **additional_args) > { > const char **args; > int argno = 1; > int additional_args_cnt = 0; > ... > args[argno] = NULL; > #if ENABLE_SELINUX > if (current_sid && !setexeccon(current_sid)) { > freecon(current_sid); > execve(shell, (char **) args, environ); > } else > #endif > execv(shell, (char **) args); > bb_perror_msg_and_die("cannot run %s", shell); > } > > > I don't understand in full what is the intent of the above > #if/#endif block. IIRC these are equivalent: > execve(shell, (char **) args, environ); > execv(shell, (char **) args); > Can it be rewritten this way? > > #if ENABLE_SELINUX > if (current_sid && !setexeccon(current_sid)) > freecon(current_sid); > #endif > execv(shell, (char **) args); I think you can do it. And as you said in n