[WGET BUG] - Can not retreive image from cacti
Hello,
We are using version 1.10.2 of wget under Ubuntu and Debian. So we have
many
scripts that get some images from a cacti site. These scripts ran perfectly
with version 1.9 of wget but they can not get image with version 1.10.2 of
wget.
Here you can find an example of our scripts:
sub GetCactiGraph()
{
my ($node,$alt,$time,$filename)[EMAIL PROTECTED];
my $url = https://foo.bar/cacti/;;
my $b = WWW::Mechanize-new();
$b-get($url);
$b-field(login_username, user);
$b-field(login_password, user);
$b-click();
if ($b-content() =~ /, gFld\(.*$node, (.+)\)\)/g)
{
$b-get($url . $1);
if ($b-content() =~ /img
src='(graph_image\.php\?local_graph_id=\d+).+'
border='0' alt='\s*$alt\s*'/g)
{
my $period = ($time eq day ? rra_id=1 :
rra_id=3);
print WGET: $url$1$period -O $filename\n;
if (defined $filename)
{ `wget -q $url$1$period -O $filename`;
return $filename;}
else
{ `wget --no-check-certificate -q
$url$1$period -O $alt.png`;
return $alt.png ;}
}
}
}
File is created but it is empty.
Bye,
Thomas
Re: wget issues on Solaris
Kommineni, Devendra wrote: If invoked using the DNS alias for the test cluster, it fails after several retries. (we have two servers in the cluster) that's weird. it seems that the TCP connection is correctly established but is dropped after the HTTP request is sent. maybe there's something wrong at the HTTP level. perhaps you could turn on the -S option to examine HTTP requests and responses? The problem does not occur on the linux nodes ( with wget 1.10.1). what do you mean? are you saying that the problem arises only with a specific version of wget (possibly prior to 1.10.1) or with a specific non-linux platform? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
RE: wget issues on Solaris
Thanks Mauro for your reply. When we are using on Linux platform we are not getting this exception. We are getting this exception when we are using with Solaris. Thanks Devendra -Original Message- From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] Sent: Monday, June 19, 2006 12:09 PM To: Kommineni, Devendra Cc: [EMAIL PROTECTED] Subject: Re: wget issues on Solaris Kommineni, Devendra wrote: If invoked using the DNS alias for the test cluster, it fails after several retries. (we have two servers in the cluster) that's weird. it seems that the TCP connection is correctly established but is dropped after the HTTP request is sent. maybe there's something wrong at the HTTP level. perhaps you could turn on the -S option to examine HTTP requests and responses? The problem does not occur on the linux nodes ( with wget 1.10.1). what do you mean? are you saying that the problem arises only with a specific version of wget (possibly prior to 1.10.1) or with a specific non-linux platform? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it -- LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.
Re: Buffer overflow bug in base64_encode
[EMAIL PROTECTED] writes:
I discovered a buffer overflow bug in the base64_encode() function,
located at line 1905 in file src\utils.c. Note that this bug is in the
latest version of the program (version 1.10.2) The bug appears to be that
the function is assuming that the input data is a size that is an even
multiple of 3 bytes. No doubt this is due to the fact that the base 64
algorithm is converting data to base 64 three bytes at a time. The
problem here is that if the block of data is not an even multiple of 3
bytes, then the last group of bytes will be either 1 or 2 bytes long.
This means that the only the last 1 or 2 bytes should be used in the base
64 algorithm.
You're right; thanks for reporting this. I have now installed this fix:
2006-06-19 Hrvoje Niksic [EMAIL PROTECTED]
* utils.c (base64_encode): Would read past end of STR.
Reported by [EMAIL PROTECTED]
Index: src/utils.c
===
--- src/utils.c (revision 2151)
+++ src/utils.c (working copy)
@@ -1912,26 +1912,35 @@
'w','x','y','z','0','1','2','3',
'4','5','6','7','8','9','+','/'
};
- int i;
const unsigned char *s = (const unsigned char *) str;
+ const unsigned char *end = (const unsigned char *) str + length - 2;
char *p = b64store;
/* Transform the 3x8 bits to 4x6 bits, as required by base64. */
- for (i = 0; i length; i += 3)
+ for (; s end; s += 3)
{
*p++ = tbl[s[0] 2];
*p++ = tbl[((s[0] 3) 4) + (s[1] 4)];
*p++ = tbl[((s[1] 0xf) 2) + (s[2] 6)];
*p++ = tbl[s[2] 0x3f];
- s += 3;
}
/* Pad the result if necessary... */
- if (i == length + 1)
-*(p - 1) = '=';
- else if (i == length + 2)
-*(p - 1) = *(p - 2) = '=';
-
+ switch (length % 3)
+{
+case 1:
+ *p++ = tbl[s[0] 2];
+ *p++ = tbl[(s[0] 3) 4];
+ *p++ = '=';
+ *p++ = '=';
+ break;
+case 2:
+ *p++ = tbl[s[0] 2];
+ *p++ = tbl[((s[0] 3) 4) + (s[1] 4)];
+ *p++ = tbl[((s[1] 0xf) 2)];
+ *p++ = '=';
+ break;
+}
/* ...and zero-terminate it. */
*p = '\0';
