Mailing List Archive

On Fri, Jul 27, 2001 at 01:43:44PM -0500, Alex Stevens wrote:

> Many times (check the archives). You can change the timeout values and
> recompile. 12 minutes works pretty well for me (I think the default is 5), but

I wonder why this is (still) not configurable via /proc/sys/net interface...

/Al

On Sat, Jul 28, 2001 at 03:48:08AM +0200, Alexander Demenshin wrote:
> On Fri, Jul 27, 2001 at 01:43:44PM -0500, Alex Stevens wrote:
>
> > Many times (check the archives). You can change the timeout values and
> > recompile. 12 minutes works pretty well for me (I think the default is 5), but
>
> I wonder why this is (still) not configurable via /proc/sys/net interface...

The usual reason is "don't confuse the user with too many buttons", and
"don't confuse us by making bug reports even more unreliable".

Personally, I don't find these two arguments sufficiently strong to
accept frustrating the knowledgeable-but-not-a-code-hacker person.

regards
Patrick

On Sat, Jul 28, 2001 at 08:16:54AM +0200, Patrick Schaaf wrote:
> On Sat, Jul 28, 2001 at 03:48:08AM +0200, Alexander Demenshin wrote:
> > On Fri, Jul 27, 2001 at 01:43:44PM -0500, Alex Stevens wrote:
> >
> > > Many times (check the archives). You can change the timeout values and
> > > recompile. 12 minutes works pretty well for me (I think the default is 5), but
> >
> > I wonder why this is (still) not configurable via /proc/sys/net interface...
>
> The usual reason is "don't confuse the user with too many buttons", and
> "don't confuse us by making bug reports even more unreliable".

I'd like to see some explanation of the problem in the documentation. It might
save a lot of queries to the list.

-Alex

>
> regards
> Patrick

--
__________________
alex@graylight.net
sidewinder@usa.net
------------------

"Yeah, I'm drunk all right, and you're crazy. Tomorrow I'll
be sober, but you'll still be crazy for the rest of your life."
-W.C. Fields

> > Many times (check the archives). You can change the timeout values and
> > recompile. 12 minutes works pretty well for me (I think the default is
5), but

Problem is that I'm seeing this when the entire connection is < 1 minute -
in fact a lot less than that. I'm off work for a week, but when I get back
I'll try and get some reliable log info.

Cheers
Nigel

On Sat, 28 Jul 2001, Nigel Morse wrote:

> > > Many times (check the archives). You can change the timeout values and
> > > recompile. 12 minutes works pretty well for me (I think the default is
> 5), but
>
> Problem is that I'm seeing this when the entire connection is < 1 minute -
> in fact a lot less than that. I'm off work for a week, but when I get back
> I'll try and get some reliable log info.

Probably because the packet with the FIN flag arrives early like I write
before. The timeout from the FIN packet to the next packet is only 10s.

-Peter

http://oss.one2one-networks.com

On Sat, Jul 28, 2001 at 08:16:54AM +0200, Patrick Schaaf wrote:

> > I wonder why this is (still) not configurable via /proc/sys/net interface...
>
> The usual reason is "don't confuse the user with too many buttons", and
> "don't confuse us by making bug reports even more unreliable".

This is clear, but this discussion was over long time ago, I believe...

/proc/sys/* is _not_ like button, it is visible only to those who look.

Sure, often those who look _may_ recompile the kernel, but sometimes
this is inconvenient... Anyway, in /proc/sys/net/ipv4/* you can find
lot of options which (even) may broke the standards (well, RFCs),
but those are still there. In ideal world, it would be a good idea
"not to confuse", but we are in _real_ world :)

iptables' syntax and packet flow in kernel is also something that
can confuse even advanced users, not only casual users, so two more
"buttons"... ip_conntrack_max is included, for instance, so...

Really, I would like to know where is the problem to include this
in sysctl - is it politics or just absense of time. So far there was
no clear explanation (except for "extra button" one, which is, IMHO,
very bad analogy).

I would like to note - this is _not_ something that might be considered
"new feature", so I see no reason why it cannot be accepted in core code.

Core team: any comments?

Regards,
/Al

On Sat, 28 Jul 2001 08:16:54 +0200, Patrick Schaaf <bof@bof.de> wrote:

>On Sat, Jul 28, 2001 at 03:48:08AM +0200, Alexander Demenshin wrote:
>> On Fri, Jul 27, 2001 at 01:43:44PM -0500, Alex Stevens wrote:
>>
>> > Many times (check the archives). You can change the timeout values and
>> > recompile. 12 minutes works pretty well for me (I think the default is 5), but
>>
>> I wonder why this is (still) not configurable via /proc/sys/net interface...
>
>The usual reason is "don't confuse the user with too many buttons", and
>"don't confuse us by making bug reports even more unreliable".

But even if that argument were valid in this case (which I personally do not
believe it to be) surely the timeout value should be chosen so that those same
easily-confused users are not confused by seeing an endless stream of strange
messages in their logs.

These messages result in a real risk that important netfilter log messages are
overlooked. Even with as little traffic as my home network (the Linux
firewall + one Windows box) produces, they are quite irritating.

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

Am Samstag, 28. Juli 2001 08:16 schrieb Patrick Schaaf:
> On Sat, Jul 28, 2001 at 03:48:08AM +0200, Alexander Demenshin wrote:
> > I wonder why this is (still) not configurable via /proc/sys/net
> > interface...
>
> The usual reason is "don't confuse the user with too many buttons", and
> "don't confuse us by making bug reports even more unreliable".
>
> Personally, I don't find these two arguments sufficiently strong to
> accept frustrating the knowledgeable-but-not-a-code-hacker person.

For the "too many button" argument you only have to look at /proc/sys/net...
at this moment i have 190 files their, a few more usefull wouldn't hurt.

On my home firewall i have installed a drop rule in the log chain for those
packets. But from the security viewpoint i'm not happy with this.
And i'm afraid that many people will install such "unsecure" rules to prevent
very big log files.

Greetings
Nils