networking settings in sysctl.conf not applyed or overwritten

[jjletho]

@gogalthorp

Don’t know why you are trying to change the settings where you are. Can’t you just set the network up as you want in Yast? Though it is unclear what you are really trying to actually do.

I need to change the log_martians settings on a couple of device because they are on a network where physiologically they see “martian” packets. So i need to set value “0” to those sysctl (dafult is “1”).

Those are the lines i added in my sysctl.conf, but they are ignored and, after the boot, values are always set to default.

net.ipv4.conf.eth0.log_martians = 0
net.ipv4.conf.br0.log_martians = 0

Trying to do those changes I discovered that it’s impossible to set at boot time every sysctl network related settings. So the problem is general and not limited to log_martians. There are tons of reasons to change those parameters, it’s unacceptable that you are forced to use default values! it’s simply absurd!

[jjletho]

@tsu2

Then you missed it because it’s all there.

Read the first sentence on this page, then everything else, particularly how the multi-line config is created towards the bottom of this page

Http://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection/tcp-buffer-re-sizing/persisting-tcp-buffer-and-congestion-control-algorithm-changes

It’s the standard cross-distro method using sysctl (systemV), will work for any distro and version using systemV including 12.2. I haven’t tested how well it might work in more fully systemd systems like 12.3 although theoretically it <should> still work.

TSU

Hi Tsu,
the link you posted describes exactly what i’m trying to do! Modifications to sysctl.conf are ignored or overwritten, this is the real problem! I suspect systemd is involved in the problem.

[arvidjaar]

@jjletho

I suspect systemd is involved in the problem.

systemd is of course involved here - it sets up configured sysctl values. I already told you the first step to debug it - use shell wrapper to verify that systemd-sysctl is called and sets correct values.

[jjletho]

@arvidjaar

systemd is of course involved here - it sets up configured sysctl values. I already told you the first step to debug it - use shell wrapper to verify that systemd-sysctl is called and sets correct values.

Hi arvidjaar,
unfortunately I’m unable to use a “shell wrapper”, could you please help me o could you give me an hint or a link to some documents about it?
This is also my very first experience with systemd.

[arvidjaar]

cd /lib/systemd
mv systemd-sysctl systemd-sysctl.bin
cat > systemd-sysctl << EOF
#!/bin/sh
/lib/systemd/systemd-sysctl.bin "$@"
date >> /tmp/systemd-sysctl.log
printf '%s
' "$*" >> /tmp/systemd-sysctl.log
sysctl -a >> /tmp/systemd-sysctl.log
EOF
chmod +x systemd-sysctl
reboot

And examine /tmp/systemd-sysctl.log after reboot. If it does not exist, systemd-sysctl does is not called at all. If it exists, check values of interest. Are they set correctly?

[jjletho]

@arvidjaar

cd /lib/systemd
mv systemd-sysctl systemd-sysctl.bin
cat > systemd-sysctl << EOF
#!/bin/sh
/lib/systemd/systemd-sysctl.bin "$@"
date >> /tmp/systemd-sysctl.log
printf '%s
' "$*" >> /tmp/systemd-sysctl.log
sysctl -a >> /tmp/systemd-sysctl.log
EOF
chmod +x systemd-sysctl
reboot

And examine /tmp/systemd-sysctl.log after reboot. If it does not exist, systemd-sysctl does is not called at all. If it exists, check values of interest. Are they set correctly?

Thank you very much! I made the wrapper (now it’s clear what a shell wrapper is ) and rebooted the system, the file systemd-sysctl.log contains only the date!
So systemd-sysctl is called but for sure it does not do what is supposed to do! It’s also very strange that sysctl -a does not produce any output at all.

[tsu2]

@jjletho

Hi Tsu,
the link you posted describes exactly what i’m trying to do! Modifications to sysctl.conf are ignored or overwritten, this is the real problem! I suspect systemd is involved in the problem.

You should be able to verify the method described in my paper works, easily and without much time involved.

1. Run this command to see current tcp/ip buffer settings

# tcpdump _ni eth0

2. Make the sysctl.conf settings exactly as described in my paper.
3. Reboot
4. Re-run the above command to view the new buffer values
5. View the changed (current) congestion control algorithm. Current Linux default is cubic, my script changes to veno

# cat /proc/sys/net/ipv4/tcp_congestion_control

When you’re done and want to undo the changes in this test, just remove the lines of code at the end of sysctl.conf (or if you previously just copied and renamed a backup of your original, restore accordingly).

Should take only slightly longer than a reboot to do this. As I described, this still works for 12.2, haven’t tested but should still work for future systemd systems although no guarantee. At some point native systemd commands should likely be preferred.

TSU

[tsu2]

If it ends up that you <really> can’t make sysctl.conf work for (I doubt) you can try writing/converting your calls to a custom systemd service unit.

There is a long, excellent series in a blog by one of the systemd authors, although you might need to read other blog entries for foundation info, the specific ones you likely would want to concentrate on are

Http://0pointer.de/blog/projects/inetd.html
Http://0pointer.de/blog/projects/socket-activated-containers.html
Http://0pointer.de/blog/projects/instances.html

HTH,
TSU

[arvidjaar]

@jjletho

It’s also very strange that sysctl -a does not produce any output at all.

It’s simply PATH problem, sorry, had to be more careful but I was writing from memory and could not check where commands are located anyway. As I had to reboot after kernel update anyway, I tested this and guess what - it of course works.

bor@opensuse:~> fgrep eth1.rp_ /tmp/systemd-sysctl.log 
net.ipv4.conf.eth1.rp_filter = 1
bor@opensuse:~> sudo /sbin/sysctl -a | fgrep eth1.rp_
net.ipv4.conf.eth1.rp_filter = 1
bor@opensuse:~> cat /lib/systemd/systemd-sysctl
#!/bin/sh

/lib/systemd/systemd-sysctl.bin "$@"
/usr/bin/date >> /tmp/systemd-sysctl.log
/usr/bin/printf '%s
' "$*" >> /tmp/systemd-sysctl.log
/sbin/sysctl -a >> /tmp/systemd-sysctl.log
bor@opensuse:~> 

[jjletho]

You were right i’m sorry, it was a simple path problem that I should have guessed on my own!
So i did the test and the result is that systemd-sysctl is regularly called, and sysctl.conf are applied! When the boot is finished however sysctl values are at their default again. So something in the boot sequence is changing them. I have already excluded vmware and xen.

I continue my investigation

Thank you very much for your help!

[jjletho]

I discovered it!!!

The SuSeFirewall service overwrites network related sysctl settings. I suppose this is a bug. Do you know if there is a way to tell the firewall scripts to leave untouched sysctl parameters ?
I had a look to SuSeFirewall yast graphic configuration mask and to /etc/sysconfig/SuSEFirewall* files, without any success.

Is someone of you so kind to do a very simple test just to double check if this behavior is common to all 12.2 installations and it’s not related someway with my particular configuration. ?

The test could be very simple:

1. modify something network related using /etc/sysctl.conf, for example add some lines like this:
   net.ipv4.conf.default.log_martians = 0
   net.ipv4.conf.all.log_martians = 0
   net.ipv4.conf.br0.log_martians = 0
   net.ipv4.conf.eth0.log_martians = 0
   Please note that the value you are modifying must be different from kernel default
2. enable SuSEFirewall service
3. reboot
4. verify that your modifications are reverted to default

cat /proc/sys/net/ipv4/conf/eth0/log_martians
1

5. disable SuSEFirewall service
6. reboot
7. verify taht your modifications are in place

cat /proc/sys/net/ipv4/conf/eth0/log_martians
0

Thank you all!

[tsu2]

Are you trying to specifically modify logfiles?

And, just changing <anything> in syslog.conf is shotgun scatter without necessary revance, eg the settings in my link <will> persist non-default values but have nothing to do with the firewall. Small wonder then that the settings I describe should be unaffected.

TSU

[jjletho]

@tsu2

Are you trying to specifically modify logfiles?

TSU

I’m in a situation where physiologically there are “martian” packets on the network and this flood my log file with useless information. So I would like to disable martian packets notification. The problem i discovered is, by the way, more general and involves all network related and device specific parameters

[jjletho]

I opened a bug

https://bugzilla.novell.com/show_bug.cgi?id=807257

[tsu2]

FYI
Curious about your findings,

I re-visited what is on my machine(12.2) and to my amazement the entire /proc/net/ipv4/ branch is missing (I would swear it existed a year ago).

This leads me to speculate that the currently installed systemd on my system (version 44) may have re-written and “acquired” control of the ipv4 network stack, leaving behind for the moment only ipv6, fw configs and some deprecated commands like netstat.

Or, it may be related to the fact I’m currently connected to the Internet using IPv6. If this is the case when I change my network connection <maybe> my ipv4 branch may re-appear.

So, am suggesting that you also check the existence of the ipv4 branch on your system. If it doesn’t exist, then it may exist only as a volatile setting.

Ah, systemd. During this transition a lot of strange things may happen…

TSU

[robin_listas]

On 2013-03-05 17:36, tsu2 wrote:
>
> FYI
> Curious about your findings,
>
> I re-visited what is on my machine(12.2) and to my amazement the entire
> /proc/net/ipv4/ branch is missing (I would swear it existed a year ago).

It does not exist in my 11.4, and this version predates systemd.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

[arvidjaar]

@tsu2

I re-visited what is on my machine(12.2) and to my amazement the entire /proc/net/ipv4/ branch is missing

This is /proc/sys/net/…

[tsu2]

@arvidjaar

This is /proc/sys/net/…

Yup, always helps to look in the right place…

TSU

[jjletho]

SOLVED
thank to bugzilla guys, the problem is solved. It was not a bug! the FW_KERNEL_SECURITY parameter in /etc/sysconfig/ allows you to stop SuSeFirewall from automatically setting several sysctl network related parameters.

See the bug for further details