RE: Adding port range option to `--bind-address'?
I had a similar situation some weeks ago with a machine passing through a firewall, only a select range of outgoing ports allowed. I think this could be usefull for a handfull of people. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax > -Original Message- > From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 26, 2003 5:12 PM > To: [EMAIL PROTECTED] > Subject: Adding port range option to `--bind-address'? > > > Does anyone think it would be useful to add the ability to specify > port ranges with `--bind-address'? I received a patch that adds that > feature by extending the `--bind-address' syntax to allow things like > `--bind-address=1.2.3.4:704' and `--bind-address=1.2.3.4:700-1000'. > > I have no use for this functionality, but I'd like to know if someone > else might find this useful. Since the patch does require additional > work to be applied, and since it might interfere with Mauro's IPv6 > work, I'd like to check how useful it is first. > > The submitter, Turi Peter, says: > > Well, a normal user has nothing to do with this patch, but in a > few cases, it's required to do operations from the lower ports. > Here at ELTE I've run into this poblem: I wanted to fetch http(s) > data form a server, where the connections are allowed only from > privilegized ports. Messing with netcat and openssl is quite > messy and I wanted an "elegant" solution, this is why I wrote this > patch. > > What do you think? Mauro, could you comment on this? >
dual-family (IPv4+IPv6) support for wget 1.9
I've submitted a patch to the wget-patches list, but in the meantime, if you would like dual-family support for wget 1.9 (as opposed to an exclusive choice of either IPv4 or IPv6), you may find my patch, along with a small blurb about it, at: http://www.episec.com/people/edelkind/patches/ ari
RE: wget 1.9 for windows: no debug support?
Confirmed, missed that. Updated binary available at the usual place.
This does the trick for the 1.9 tree.
Changelog: rename DEBUG to ENABLE_DEBUG in windows\config.h.{ms,bor}
diff -ubBr wget-1.9/windows/config.h.bor wget-1.9+debug/windows/config.h.bor
--- wget-1.9/windows/config.h.bor Mon Oct 13 15:20:52 2003
+++ wget-1.9+debug/windows/config.h.bor Mon Oct 27 09:47:08 2003
@@ -76,7 +76,7 @@
#define USE_DIGEST 1
/* Define if you want the debug output support compiled in. */
-#define DEBUG
+#define ENABLE_DEBUG
/* Define if you have sys/time.h header. */
#undef HAVE_SYS_TIME_H
diff -ubBr wget-1.9/windows/config.h.ms wget-1.9+debug/windows/config.h.ms
--- wget-1.9/windows/config.h.msMon Oct 13 15:20:52 2003
+++ wget-1.9+debug/windows/config.h.ms Mon Oct 27 09:36:44 2003
@@ -55,7 +55,7 @@
#define USE_DIGEST 1
/* Define if you want the debug output support compiled in. */
-#define DEBUG
+#define ENABLE_DEBUG
/* Define if you have sys/time.h header. */
#undef HAVE_SYS_TIME_H
Heiko
--
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL PROTECTED]
-- +39-041-5907073 ph
-- +39-041-5907472 fax
> -Original Message-
> From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
> Sent: Sunday, October 26, 2003 9:16 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: wget 1.9 for windows: no debug support?
>
>
> [EMAIL PROTECTED] writes:
>
> > Well, to find out what was happening, I specified -d for the debug
> > output. The message was: debug support not compiled in
> [...]
> > Is this an oversight or does it serve a purpose?
>
> Heiko will know for sure, but it's most likely an oversight. The
> Windows config.h.* files still enabled debugging with #define DEBUG,
> which has in the meantime been renamed to ENABLE_DEBUG.
>
Re: Naughty make install.info, naugthy, bad boy...
Hi Hrvoje :)
* Hrvoje Niksic <[EMAIL PROTECTED]> dixit:
> > connect_timeout=60
> > dns_timeout=0
> > read_timeout=600
> > timeout=0
> >
> > Notice the last line. Will does that mean that *all* timeouts are
> > disabled,
> Yes. The "timeout" option is a shortcut for specifying all the other
> options.
What I mean is: if I don't specify 'timeout' in my wgetrc it has
the default value ('900', AFAIK), but it is ignored? It shouldn't,
IMHO, it's a weird behaviour, that way I cannot specify commands in
my wgetrc with their default values and have the default behaviour
(if I put timeout=900 then *all* timeouts are 900, no matter if I set
dns_timeout to '0' in wgetrc). I'm afraid I'm missing something...
> > This links with my other question: I want to put *all* wgetrc
> > commands in my wgetrc file, with their defaults if I haven't change
> > them, just for reference (is easier for me). The problem is that I
> > don't know what are the defaults of some entries, or even if I can
> > put things like 'accept=', without a value, in the rc file. Could
> > you help me on this?
> I think you should be able to use `accept='. As for the defaults,
> take a look at the defaults() function in src/init.c.
Thanks a lot :)))
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
Re: Adding port range option to `--bind-address'?
Hi Hrvoje :) * Hrvoje Niksic <[EMAIL PROTECTED]> dixit: > Does anyone think it would be useful to add the ability to specify > port ranges with `--bind-address'? Reading the explanation from Turi it seems reasonable, and I don't think that such a feature impose any burden on wget :? Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 http://www.pleyades.net & http://raul.pleyades.net/
Re: Naughty make install.info, naugthy, bad boy...
DervishD <[EMAIL PROTECTED]> writes:
>> Yes. The "timeout" option is a shortcut for specifying all the
>> other options.
>
> What I mean is: if I don't specify 'timeout' in my wgetrc it has the
> default value ('900', AFAIK), but it is ignored?
I'm afraid I don't understand this question. Is what ignored? You
say you don't specify it -- how can it be ignored then?
> it's a weird behaviour, that way I cannot specify commands in my
> wgetrc with their default values and have the default behaviour
Sure you can, just don't use "timeout". It's meant as a simple way to
set (or unset) all timeouts.
> (if I put timeout=900 then *all* timeouts are 900, no matter if I
> set dns_timeout to '0' in wgetrc).
I think this is a case of
"Doctor, doctor, it hurts when I do that."
"Don't do that, then."
:-)
Seriously, if you don't want to change dns_timeout, then don't use the
timeout option.
Re: Naughty make install.info, naugthy, bad boy...
Hi Hrvoje :)
* Hrvoje Niksic <[EMAIL PROTECTED]> dixit:
> >> Yes. The "timeout" option is a shortcut for specifying all the
> >> other options.
> > What I mean is: if I don't specify 'timeout' in my wgetrc it has the
> > default value ('900', AFAIK), but it is ignored?
> I'm afraid I don't understand this question. Is what ignored? You
> say you don't specify it -- how can it be ignored then?
Sorry, I'm afraid my english is somewhat poor :((( What I mean is
that the option 'timeout' has a default value if it is not specified
in wgetrc, true?. But if you specify any *_timeout option, then that
default is not used for the options you specify, true again? Then
that value is being ignored, isn't it?. But if you specify
'timeout=900' in the wgetrc, then any other *_timeout option is
ignored. The fact is that I'm using 'timeout' with its default value
but the behaviour of wget is not the same as if I was not using
'timeout'. I hope I've explained correctly this time O:))
> > it's a weird behaviour, that way I cannot specify commands in my
> > wgetrc with their default values and have the default behaviour
> Sure you can, just don't use "timeout". It's meant as a simple way to
> set (or unset) all timeouts.
OK. I don't like that behaviour, but I understand the use of
'timeout', thanks :))
> > (if I put timeout=900 then *all* timeouts are 900, no matter if I
> > set dns_timeout to '0' in wgetrc).
> I think this is a case of
> "Doctor, doctor, it hurts when I do that."
> "Don't do that, then."
X''
> Seriously, if you don't want to change dns_timeout, then don't use the
> timeout option.
OK, I take note ;)
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
Re: Adding port range option to `--bind-address'?
On Sun, 26 Oct 2003, Hrvoje Niksic wrote: > Does anyone think it would be useful to add the ability to specify > port ranges with `--bind-address'? I received a patch that adds that > feature by extending the `--bind-address' syntax to allow things like > `--bind-address=1.2.3.4:704' and `--bind-address=1.2.3.4:700-1000'. > > I have no use for this functionality, but I'd like to know if someone > else might find this useful. Since the patch does require additional > work to be applied, and since it might interfere with Mauro's IPv6 > work, I'd like to check how useful it is first. > > The submitter, Turi Peter, says: > > Well, a normal user has nothing to do with this patch, but in a > few cases, it's required to do operations from the lower ports. > Here at ELTE I've run into this poblem: I wanted to fetch http(s) > data form a server, where the connections are allowed only from > privilegized ports. Messing with netcat and openssl is quite > messy and I wanted an "elegant" solution, this is why I wrote this > patch. > > What do you think? Mauro, could you comment on this? i think that the port range restriction is useful and since adding this functionality to wget is not very difficult (and if correctly done, it does not break IPv6 support), we should definitely do it. however, i am not very happy with turi's code, since the parsing of the --bind-address argument should not be done in resolve_bind_address but in the getopt loop and it should not use sscanf. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Deep Space 6 - IPv6 with Linux http://www.deepspace6.net Ferrara Linux User Grouphttp://www.ferrara.linux.it
Re: Adding port range option to `--bind-address'?
Mauro Tortonesi <[EMAIL PROTECTED]> writes: > however, i am not very happy with turi's code, since the parsing of > the --bind-address argument should not be done in > resolve_bind_address but in the getopt loop and it should not use > sscanf. I agree on both points. I guess the feature will go in, but not necessarily in its current implementation.
Re: Naughty make install.info, naugthy, bad boy...
DervishD <[EMAIL PROTECTED]> writes:
> * Hrvoje Niksic <[EMAIL PROTECTED]> dixit:
>> >> Yes. The "timeout" option is a shortcut for specifying all the
>> >> other options.
>> > What I mean is: if I don't specify 'timeout' in my wgetrc it has the
>> > default value ('900', AFAIK), but it is ignored?
>> I'm afraid I don't understand this question. Is what ignored? You
>> say you don't specify it -- how can it be ignored then?
>
> Sorry, I'm afraid my english is somewhat poor :((( What I mean is
> that the option 'timeout' has a default value if it is not specified
> in wgetrc, true?.
Not entirely. The "timeout" does not translate to a single variable,
but to three variables. Changing "timeout" modifies all three.
If you insist on thinking in terms of the default values, you can set
them like this:
# Defaults:
connect_timeout = 0
dns_timeout = 0
read_timeout = 900
# You can change any of the above by modifying the respective
# variables. Using "timeout" changes them all at once, to a single
# value. If that is not desired, simply do not use "timeout".
> The fact is that I'm using 'timeout' with its default value but the
> behaviour of wget is not the same as if I was not using 'timeout'.
That is correct, but that is by design -- see above. Simply stop
thinking of "timeout" as of a single variable, and the problem will (I
hope) go away. It worked for me. :-)
[...]
> OK. I don't like that behaviour, but I understand the use of
> 'timeout', thanks :))
How would you have it behave?
