Project

General

Profile

Actions

Bug #4199

closed

2.1.5 to 2.2 system tunable default value issue

Added by Bipin Chandra over 9 years ago. Updated over 8 years ago.

Status:
Rejected
Priority:
High
Category:
-
Target version:
-
Start date:
01/11/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:

Description

i noticed when u have a config which u have been upgrading since long and now from 2.1.5 to 2.2, the system tunable entries stored in config file are stored with value as default if u havent changed anything and as soon as u upgrade it tries to apply those with value as default and that causes a bunch of errors in console and to overcome this u need to goto same section in web gui and delete those entries so the default entries get removed from the config file after which all is good.
There needs to be a way to upgrade the config file during upgrade and remove entries with values as default

sample config file before upgrade
<item>
<tunable>net.inet.tcp.blackhole</tunable>
<value>default</value>
<descr><![CDATA[Drop packets to closed TCP ports without returning a RST]]></descr>
</item>
<item>
<tunable>net.inet.udp.blackhole</tunable>
<value>default</value>
<descr><![CDATA[Do not send ICMP port unreachable messages for closed UDP ports]]></descr>
</item>
<item>
<tunable>net.inet.ip.random_id</tunable>
<value>default</value>
<descr><![CDATA[Randomize the ID field in IP packets (default is 0: sequential IP IDs)]]></descr>
</item>
<item>
<tunable>net.inet.tcp.drop_synfin</tunable>
<value>default</value>
<descr><![CDATA[Drop SYN-FIN packets (breaks RFC1379, but nobody uses it anyway)]]></descr>
</item>


Files

conf.xml (4.48 KB) conf.xml Bipin Chandra, 01/11/2015 11:21 PM
Actions #1

Updated by Chris Buechler over 9 years ago

  • Status changed from New to Feedback

this isn't true, most all configs have the sysctl items and the code that sets them reads their default value and sets it accordingly.

            if($tunable['value'] == "default")
                $value = get_default_sysctl_value($tunable['tunable']);

which works as it should. I enabled logging of all sysctl commands on a system with an upgraded config containing all the sysctl items and it never once used "default" as the sysctl value.

Pretty sure this is bunk, but there could be some edge case I'm not seeing. You have a way to replicate this?

Actions #2

Updated by Jim Thompson over 9 years ago

  • Assignee set to Chris Buechler
Actions #3

Updated by Bipin Chandra over 9 years ago

to replicate this, first copy the sysctl section from the attached config file to a 2.1.5 config file and then upgrade that machine to 2.2 and keep a close watch in the console window as the system tries to apply the value as default and the errors come in console but not for all but a few of the entries, so better use as is the section i provided in the config file.

secondly if the value is default, 2.1.5 would actually show the default value whereas 2.2 doesnt but i guess u patched it soon after i opened the bug report.

the system i tried this on was a alix, nanobsd but i guess it would be same for all systems.

Actions #4

Updated by Chris Buechler over 9 years ago

  • Status changed from Feedback to Rejected

I loaded that on nano and full, 32 and 64 bit, both on 2.2 and on 2.1.5 then upgraded to 2.2, and it never tries to set a sysctl to "default". The only thing from that config snippet that triggers an error is hw.bce.tso_enable which must be set in loader.conf(.local), and is harmless. I also can't find any release version we've ever put out that included that tunable, guessing it was there temporarily in a snapshot at some point maybe. Regardless, it's harmless. The issue as described doesn't exist.

Actions #5

Updated by Chris Buechler over 8 years ago

  • Target version deleted (2.2)
Actions

Also available in: Atom PDF