Re: sysctl, argument parsing, possible bug

[Massimo Sala]

I make another test with kernel 4.9.32-15.41

sysctl procps version 3.2.8

sysctl net.ipv4.conf.eth0.100.forwarding
error: "net.ipv4.conf.eth0.100.forwarding" is an unknown key


so I install busybox :

BusyBox v1.19.3

busybox sysctl net.ipv4.conf.eth0.100.forwarding
net.ipv4.conf.eth0.100.forwarding = 0

It is working, as I expect reading busybox source sysctl.c



Stephen, I test
sysctl net/ipv4/conf/eth0.100/forwarding
I confirm it  works.


What is the problem ?

As sysctl, also automation tools and scripts cannot be "netdev names
aware", and so they fail using the usual dot notation.


I don't pretend to change sysctl to read from the /proc/sys/
directory, as busybox does.

I suggest to add a  remark to the man page of sysctl, reporting the
difference between the two tools and an example of the alternate
syntax :
sysctl net/ipv4/conf/eth0.100/forwarding


Thank you for your attention.
Best regards, Massimo

Re: sysctl, argument parsing, possible bug

[Massimo Sala]

Do you confirm it is a sysctl parsing bug ?

Bosybox handles these cases, so I think also standalone sysctl have to.

Or at least someone must update sysctl docs / MAN about this.

Best regards, Sala


On 01/08/2017, Cong Wang  wrote:
> On Tue, Aug 1, 2017 at 1:47 PM, Massimo Sala 
> wrote:
>> cat /proc/sys/net/ipv4/conf/eth0.100/forwarding
>> 0
>>
>> sysctl net.ipv4.conf.eth0.100.forwarding
>> error: "net.ipv4.conf.eth0.100.forwarding" is an unknown key
>>
>
> Use echo instead, sysctl doesn't understand eth0.100
> is a netdev name, sigh.
>

new sysctl tunable knob : tcp_retries2_time

[Massimo Sala]

I wish to suggest to developers to add this new knob :

tcp_retries2_time - INTEGER
This value influences the timeout (seconds) of an alive TCP connection,
when RTO retransmissions remain unacknowledged.
RFC 1122 recommends at least 100 seconds for the timeout,
which corresponds to a value of at least 8.


Rationale :
* I see a lot of misuse of tcp_retries2, because even if you check the
RTO, it will change with different connections, routing, etc... and so
tcp_retries2 timeout will change.

* An absolute value will be friendly and better ton read and document.
See other parameters with two knobs ( example : dirty_ratio,
dirty_ratio_bytes ).

Best regards, Sala