Re: grep: bug or feature ?

On Thursday 19 February 2009 03:45:04 pm walter harms wrote:
> Hi list,
> i was porting a script to an embedded box with bb and found the
> following effect:
> 
> ./busybox grep "[a-Z]" /etc/hosts
> grep: bad regex '[a-Z]': Invalid range end
> 
> while
>  grep "[a-Z]" /etc/hosts
> 
> works with no problem.
> 
> bug or feature ?

Use CONFIG_EXTRA_COMPAT=y. I just tested, with this option
off I am getting "Invalid range end", with it on I dont.

This options makes grep use GNU regex matching.

I bet GNU grep uses GNU regex matching routines, not POSIX.
The differense has to be only on C API level -
GNU regex can match NULs, POSIX cannot.

But apparently in reality the differences run deeper.
--
vda

Re: bug in tr ?

On Friday 20 February 2009 04:06:30 pm walter harms wrote:
> Hi List,
> i was traceing a bug and found that tr (bb 13.0) seems to have a bug:
> 
> 
> echo "19AFH" |./tr -cd "[0-9]"
> 19
> 
>  echo "19AFH" |./tr -cd "[0-9A-F]"
> bash: echo: write error: Datenübergabe unterbrochen (broken pipe)

You do not show that tr complains about bad command format
(by showing usage screen). Is it a test in telepathy,
or do you compigured out help text? (that't why
attaching your .config isn't such a bad idea).

> ./tr -cd "[0-9A-F]" <xx
> echo $?
> 1
> reading from a file seems to indicate an error ?

I see this:

# ./busybox tr -cd "[0-9A-F]" <AUTHORS; echo $?
BusyBox v1.14.0.svn (2009-03-01 04:13:26 CET) multi-call binary

Usage: tr [-cds] STRING1 [STRING2]

Translate, squeeze, and/or delete characters from
standard input, writing to standard output

[PATCH] wget --post-data support

Hello, 

The attached patch adds --post-data option to the wget applet.

Additionally   
+  "tries\0"            Required_argument "t"
+  "timeout\0"          Required_argument "T"
must be added to wget_longopts[] otherwise WGET_OPT_HEADER dose not match to the bits of the return value
of getopt32().

Best regards
Harald

--- wget.c.orig 2008-11-09 18:27:59.000000000 +0100
+++ wget.c 2009-02-28 21:28:47.000000000 +0100
 <at>  <at>  -384,6 +384,24  <at>  <at> 
  return hdrval;
 }

+#if ENABLE_FEATURE_WGET_LONG_OPTIONS
+static unsigned char URL_escape_char(unsigned char c)
+{
+ /* URL encode, see RFC 2396 */ 
+ if ( (c >= '0' && c <= '9') ||
+  (c >= 'a' && c <= 'z') ||
+  (c >= 'A' && c <= 'Z') ||
+  c == '-'  || c == '_' ||
+  c == '.'  || c == '!' ||
+  c == '~'  || c == '*' ||
+  c == '\'' || c == '(' ||

permissions on /var/log/messages

I'd like /var/log/messages to be readable by non-root users. syslogd.c
uses device_open to open the file though and it has the permissions
hardcoded to 0600.

I can't really see why it uses device_open... nor a good solution.

Hamish
--

-- 
Hamish Moffatt VK3SB <hamish <at> debian.org> <hamish <at> cloud.net.au>

WPA Keys can cause Router to reset to factory default

_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: WPA Keys can cause Router to reset to factory default

Hi Chris,
i do not think this is a busybox problem.
It is obvious the "user-interface" to "configfile" code that is
not working correctly.

Busybox provides some basic tools e.g. a "vi" that allows you to
edit the configfile by hand.

i am afraid we can not help you, please contact the company responsible
for the router.

re,
 wh

Chris Rigg-Milner schrieb:
>  
> 
> Hi,
> 
>  
> 
> This problem has been annoying me for a couple of years now, so I finally
> got around to doing some investigation after installing an upgrade to my
> Belkin f5d7633uk router which uses Busybox V1.00.
> 
> I will admit that I am not 100% sure the problem is down to the busybox
> software but as I cannot get Belkin to do anything about it I am trying this
> so here goes anyway.
> 
>  
> 
> I have just installed f5d7633-4a_v1uk_1.00.25.bin a firmware upgrade for the
> router from F5D7633-4Av1_UK_1.00.17_AnnexA.bin which was itself an
> ineffectual fix for similar issues on the v10 release.
> 
>  
> 
> When I set up WPA security for wireless connections I like to use the
> www.grc.com/password generator to get a "63 random printable ASCII
> character" password.
> 
>  
> 
> THE PROBLEM:
> 
>  
> 
> Some characters cause major problems to the router/router software.
> 
> Specifically 2 main issues:
> 
> If a " (double quote) appears in the string (valid according to the spec for
> WPA Keys) this causes the key to become useless as the router saves the key
> in the config file as a double quote delimited string. Becoming useless in
> fact means that should you reload the config file it will truncate the key
> and therefore make a shorter string. In other words it changes the key and
> clients cannot logon as they have the correct Original key.
> 
> Now this one I feel is VERY SERIOUS.
> 
> Some characters that appear in the generated key cause the router to reset
> to what I assume is a factory default setting.
> 
> This happens when you make the changes on the admin panel supplied, in my
> case by Belkin.
> 
> When you save the changes to the security setting the router reboots, as I
> suppose one would expect. The result of that reboot does not give any
> indication of a problems but you now have a router with NO SECURITY AT ALL.
> The admin password is reset to "" (blank, nothing, nada). The wireless
> security is set to OFF, and  in many cases the ISP userid/password is lost
> and the router must be re-configured from scratch.
> 
> This leaves your router completely open to the universe, unless it is
> rendered useless by the loss of u/p to connect to the ISP.
> 
>  
> 
> Now this has happened to me using various WPA keys but this one is the last
> one that caused it to happen, obviously not my current key.
> 
> wpakey="c/S/4Sc`oLTM <at> r_\?rJa$~Lu82Tr!^IA HXPQD9\P2RpJvz(+<:Lzk^2A#x{^c4"
> 
>  
> 
> I had already removed any " (double quote) character and added something in
> its place but still, total mayhem on saving it to the router from the admin
> panel security page.
> 
>  
> 
>  
> 
> I hope this is not your problem and if not, please let me know and I will
> have another attempt at getting Belkin to fix the problem.
> 
> This is a great pity as the mix of their hardware and your software make a
> perfectly adequate package apart from this issue.
> 
>  
> 
>  
> 
> Regards
> 
> Chris Rigg-Milner
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> busybox mailing list
> busybox <at> busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox

Re: WPA Keys can cause Router to reset to factory default

On Monday 02 March 2009 12:51:33 pm Chris Rigg-Milner wrote:
> This problem has been annoying me for a couple of years now, so I finally
> got around to doing some investigation after installing an upgrade to my
> Belkin f5d7633uk router which uses Busybox V1.00.
> 
> I will admit that I am not 100% sure the problem is down to the busybox
> software but as I cannot get Belkin to do anything about it I am trying this
> so here goes anyway.

This can be helped only if you have a way to log in the router
and modify files on its filesystem(s), including scripts.

> THE PROBLEM:
> 
> Some characters cause major problems to the router/router software.
> 
> Specifically 2 main issues:
> 
> If a " (double quote) appears in the string (valid according to the spec for
> WPA Keys) this causes the key to become useless as the router saves the key
> in the config file as a double quote delimited string.
...
> Some characters that appear in the generated key cause the router to reset 
> to what I assume is a factory default setting.
> 
> This happens when you make the changes on the admin panel supplied, in my
> case by Belkin.
> 
> When you save the changes to the security setting the router reboots, as I
> suppose one would expect. The result of that reboot does not give any
> indication of a problems but you now have a router with NO SECURITY AT ALL.
> The admin password is reset to "" (blank, nothing, nada). The wireless
> security is set to OFF, and  in many cases the ISP userid/password is lost
> and the router must be re-configured from scratch.
... 
> Now this has happened to me using various WPA keys but this one is the last
> one that caused it to happen, obviously not my current key.
> 
> wpakey="c/S/4Sc`oLTM <at> r_\?rJa$~Lu82Tr!^IA HXPQD9\P2RpJvz(+<:Lzk^2A#x{^c4"

Well duh, with characters like ` this may invoke shell's command substitution,
and this can be very bad. $ and \ are bad also.

> I had already removed any " (double quote) character and added something in
> its place but still, total mayhem on saving it to the router from the admin
> panel security page.

> I hope this is not your problem and if not, please let me know and I will
> have another attempt at getting Belkin to fix the problem.

Basically, what needs to be fixed is that the script which saves the key
in the form of wpakey=... must be fixed.

I suggest discarding any control characters first (with codes less than 32),
maybe also discarding all non-ascii chars (codes >= 127).

Piping the key through tr -cd ' -~' command will do it.

Then store the key with SINGLE quotes. They are more restrictive for shells:
only single quote has special meaning inside. Thus you need to escape only
single quote.

Sed command s/'/'"'"'/g would do it, but we need to massage it so
that shell itself would not be confused by "s and 's:

dq='"'
echo "any 'junk'" | tr -cd ' -~' | sed "s/'/'$dq'$dq'/g"

> This is a great pity as the mix of their hardware and your software make a
> perfectly adequate package apart from this issue.

If you can identify part of the script which does that, and replace it
with something like this:

wpakey=`dq='"'; echo "any 'junk'" | tr -cd ' -~' | sed "s/'/'$dq'$dq'/g"`
echo "wpakey='$wpakey'" >>some_configfile

it should do the trick. In this example, it should end up
writing the string wpakey='any '"'"'junk'"'"''
to some_configfile. Which is correct.

With your example string:

# raw='c/S/4Sc`oLTM <at> r_\?rJa$~Lu82Tr!^IA HXPQD9\P2RpJvz(+<:Lzk^2A#x{^c4'
# wpakey=`dq='"'; echo "$raw" | tr -cd ' -~' | sed "s/'/'$dq'$dq'/g"`
# echo "wpakey='$wpakey'"
wpakey='c/S/4Sc`oLTM <at> r_\?rJa$~Lu82Tr!^IA HXPQD9\P2RpJvz(+<:Lzk^2A#x{^c4'

it still seems to work correctly.
--
vda

Re: permissions on /var/log/messages

On Monday 02 March 2009 07:03:53 am Hamish Moffatt wrote:
> I'd like /var/log/messages to be readable by non-root users. syslogd.c
> uses device_open to open the file though and it has the permissions
> hardcoded to 0600.
> 
> I can't really see why it uses device_open... nor a good solution.

I propose this patch.
--
vda

_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] wget --post-data support

On Sunday 01 March 2009 04:39:06 pm Harald Kuethe wrote:
> Hello, 
> 
> The attached patch adds --post-data option to the wget applet.

# patch -p0 </tmp/z.patch --dry-run
patching file wget.c               
Hunk #1 succeeded at 387 with fuzz 1 (offset 3 lines).
Hunk #2 FAILED at 420.                                
Hunk #3 FAILED at 446.                                
Hunk #4 FAILED at 462.                                
Hunk #5 FAILED at 477.                                
Hunk #6 FAILED at 509.                                
Hunk #7 FAILED at 595.                                
Hunk #8 FAILED at 622.                                
7 out of 8 hunks FAILED -- saving rejects to file wget.c.rej

Please resend as attachment. (rediff against current svn first).

> Additionally   
> +  "tries\0"            Required_argument "t"
> +  "timeout\0"          Required_argument "T"
> must be added to wget_longopts[] otherwise WGET_OPT_HEADER dose not match to the bits of the return value
of getopt32().

Thanks for catching this. I will adjust constants now.
--
vda

Re: sendmail help

On Wednesday 25 February 2009 07:18:23 am Vladimir Dronnikov wrote:
> Hi, Frank!
> 
> 2009/2/25 Frank Ianella <fjianella <at> gmail.com>:
> > i am trying to use the sendmail applet to relay to smtp.gmail.com but
> > cannot figure out the neccessary command syntax.
> >
> 
> You can try working:
> $ sendmail -H "exec openssl s_client -quiet -connect smtp.gmail.com:25
> -tls1 -starttls smtp" -f user <at> gmail.com -F "Your real name here (pure
> optional)"

Is it possible to use port 465? Port 25 sometimes is blocked by ISPs.

> You'll be prompted for password, or you can pass you credentials (two
> lines file: username, password) to fd 4 like:
> $ sendmail -H "exec openssl s_client -quiet -connect smtp.gmail.com:25
> -tls1 -starttls smtp" -f user <at> gmail.com -F "Your real name here (pure
> optional)" 4<.your_cred_file
> 
> Notice "exec, -quiet, no -crlf and -tls1".

Why username/password is passed through fd 4? I don't see where that happens.
Is it a openssl's feature? I tried to google for that but so far failed.
--
vda