Difference between revisions of "Talk:Sysctl"

From ArchWiki
Jump to: navigation, search
m ('sysctl -p' does not work: Remove closed discussion.)
(net.ipv4.tcp_rfc1337: re)
 
(22 intermediate revisions by 7 users not shown)
Line 1: Line 1:
I can't imagine this being a very long article, but I do find it useful.  I didn't have a clue what this command did until I came across it now.  I recall it from my first time installing Arch, with regard to storing the volume levels in alsamixer. --[[User:Mustard|Mustard]] 10:31, 22 October 2010 (EDT)
 
 
error: permission denied on key 'net.ipv4.conf.all.mc_forwarding'
 
error: permission denied on key 'net.ipv4.conf.default.mc_forwarding'
 
 
Are these not used any-more?
 
 
:it's read only which might mean that it has to be changed while compiling the kernel, I'm not sure (it used to work), it is disabled by default anyway [[User:Thestinger|thestinger]] 16:39, 26 October 2010 (EDT)
 
 
 
== net.ipv4.tcp_rfc1337 ==
 
== net.ipv4.tcp_rfc1337 ==
  
Line 21: Line 12:
  
 
So, isn't {{ic|0}} the safe value? Our wiki says otherwise. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:56, 17 September 2013 (UTC)
 
So, isn't {{ic|0}} the safe value? Our wiki says otherwise. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:56, 17 September 2013 (UTC)
:With setting {{ic|0}} the system would 'assassinate' a socket in time_wait prematurely upon receiving a RST. While this might sound like a good idea (it frees up a socket quicker), it opens the door for tcp sequence problems/syn replay. Those problems were described in RFC1337 and enabling the setting {{ic|1}} is one way to deal with them (letting TIME_WAIT packets idle out even if a reset is received, so that the sequence number cannot be reused meanwhile). The wiki is correct in my view. Kernel doc is wrong here - "prevent" should read "enable".  --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:12, 17 September 2013 (UTC)
+
:With setting {{ic|0}} the system would 'assassinate' a socket in time_wait prematurely upon receiving a RST. While this might sound like a good idea (it frees up a socket quicker), it opens the door for tcp sequence problems/syn replay. Those problems were described in RFC1337 and enabling the setting {{ic|1}} is one way to deal with them (letting TIME_WAIT packets idle out even if a reset is received, so that the sequence number cannot be reused meanwhile). The wiki is correct in my view. <s>Kernel doc is wrong here - "prevent" should read "enable".</s> --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:12, 17 September 2013 (UTC)
 +
 
 +
:Since this discussion is still open: An interesting attack to the kernels implementation of the related RFC5961 was published yesterday under [https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/cao cve2016-5696]. I have not looked into it enough to form an opinion whether leaving default {{ic|0}} or {{ic|1}} for this setting makes any difference to that, but it is exactly the kind of sequencing attack I was referring to three years back. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:38, 11 August 2016 (UTC)
 +
 
 +
== Virtual memory ==
 +
 
 +
The official documentation states that these two variables "Contain[s], as a percentage of total available memory that contains free pages
 +
and reclaimable pages,..." and that "The total available memory is not equal to total system memory.". However the comment underneath talks about them as if they were a percentage of ''system'' memory, making it quite confusing, e.g. I have 6GiB of system memory but only 1-2GiB available.
 +
 
 +
Also the defaults seem to have changed, I have {{ic|1=dirty_ratio=50}} and {{ic|1=dirty_background_ratio=20}}.
 +
 
 +
-- [[User:DoctorJellyface|DoctorJellyface]] ([[User talk:DoctorJellyface|talk]]) 08:27, 8 August 2016 (UTC)
 +
 
 +
:Yes, I agree. When I changed the section a little with [https://wiki.archlinux.org/index.php?title=Sysctl&type=revision&diff=435336&oldid=422169], I left the comment. The reason was that while it simplifies in current form, expanding it to show the difference between system memory and available memory first and only then calculate the percentages makes it cumbersome/complicated to follow. If you have an idea how to do it, please go ahead. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:07, 8 August 2016 (UTC)
 +
 
 +
::The problem is that the kernel docs don't explain what does "available memory" really mean. Assuming that it changes similarly to what {{ic|free}} shows, taking the system memory instead is still useful to prepare for the worst case. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:11, 8 August 2016 (UTC)
 +
 
 +
:::Yes, worst case also because "available" should grow disproportionately, because some slices, like system memory reserved for the bios or GPU will not change, regardless of total installed ram. I've had my go with [https://wiki.archlinux.org/index.php?title=Sysctl&type=revision&diff=445976&oldid=445672]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:54, 9 August 2016 (UTC)

Latest revision as of 08:38, 11 August 2016

net.ipv4.tcp_rfc1337

From kernel doc:

tcp_rfc1337 - BOOLEAN
	If set, the TCP stack behaves conforming to RFC1337. If unset,
	we are not conforming to RFC, but prevent TCP TIME_WAIT
	assassination.
	Default: 0

So, isn't 0 the safe value? Our wiki says otherwise. -- Lahwaacz (talk) 08:56, 17 September 2013 (UTC)

With setting 0 the system would 'assassinate' a socket in time_wait prematurely upon receiving a RST. While this might sound like a good idea (it frees up a socket quicker), it opens the door for tcp sequence problems/syn replay. Those problems were described in RFC1337 and enabling the setting 1 is one way to deal with them (letting TIME_WAIT packets idle out even if a reset is received, so that the sequence number cannot be reused meanwhile). The wiki is correct in my view. Kernel doc is wrong here - "prevent" should read "enable". --Indigo (talk) 21:12, 17 September 2013 (UTC)
Since this discussion is still open: An interesting attack to the kernels implementation of the related RFC5961 was published yesterday under cve2016-5696. I have not looked into it enough to form an opinion whether leaving default 0 or 1 for this setting makes any difference to that, but it is exactly the kind of sequencing attack I was referring to three years back. --Indigo (talk) 08:38, 11 August 2016 (UTC)

Virtual memory

The official documentation states that these two variables "Contain[s], as a percentage of total available memory that contains free pages and reclaimable pages,..." and that "The total available memory is not equal to total system memory.". However the comment underneath talks about them as if they were a percentage of system memory, making it quite confusing, e.g. I have 6GiB of system memory but only 1-2GiB available.

Also the defaults seem to have changed, I have dirty_ratio=50 and dirty_background_ratio=20.

-- DoctorJellyface (talk) 08:27, 8 August 2016 (UTC)

Yes, I agree. When I changed the section a little with [1], I left the comment. The reason was that while it simplifies in current form, expanding it to show the difference between system memory and available memory first and only then calculate the percentages makes it cumbersome/complicated to follow. If you have an idea how to do it, please go ahead. --Indigo (talk) 09:07, 8 August 2016 (UTC)
The problem is that the kernel docs don't explain what does "available memory" really mean. Assuming that it changes similarly to what free shows, taking the system memory instead is still useful to prepare for the worst case. -- Lahwaacz (talk) 09:11, 8 August 2016 (UTC)
Yes, worst case also because "available" should grow disproportionately, because some slices, like system memory reserved for the bios or GPU will not change, regardless of total installed ram. I've had my go with [2]. --Indigo (talk) 07:54, 9 August 2016 (UTC)