Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On Thu, Oct 25, 2012 at 10:29:51PM +0200, Andre Oppermann wrote: A On 25.10.2012 18:25, Andrey V. Elsukov wrote: A On 25.10.2012 19:54, Andre Oppermann wrote: A I still don't agree with naming the sysctl net.pfil.forward. This A type of forwarding is a property of IPv4 and IPv6 and thus should A be put there. Pfil hooking can be on layer 2, 2-bridging, 3 and A who knows where else in the future. Forwarding works only for IPv46. A A You haven't even replied to my comment on net@. Please change the A sysctl location and name to its appropriate place. A A Hi Andre, A A There were two replies related to this subject, you did not replied to A them and i thought that you became agree. A A I replied to your reply to mine. Other than that I didn't find A anything else from you. A A So, if not, what you think about the name net.pfil.ipforward? A A net.inet.ip.pfil_forward A net.inet6.ip6.pfil_forward A A or something like that. A A If you can show with your performance profiling that the sysctl A isn't even necessary, you could leave it completely away and have A pfil_forward enabled permanently. That would be even better for A everybody. I'd prefer to have the sysctl. Benchmarking will definitely show no regression, because in default case packets are tagless. But if packets would carry 1 or 2 tags each, which don't actually belong to PACKET_TAG_IPFORWARD, then processing would be pessimized. -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 26.10.2012 13:26, Gleb Smirnoff wrote: On Thu, Oct 25, 2012 at 10:29:51PM +0200, Andre Oppermann wrote: A On 25.10.2012 18:25, Andrey V. Elsukov wrote: A On 25.10.2012 19:54, Andre Oppermann wrote: A I still don't agree with naming the sysctl net.pfil.forward. This A type of forwarding is a property of IPv4 and IPv6 and thus should A be put there. Pfil hooking can be on layer 2, 2-bridging, 3 and A who knows where else in the future. Forwarding works only for IPv46. A A You haven't even replied to my comment on net@. Please change the A sysctl location and name to its appropriate place. A A Hi Andre, A A There were two replies related to this subject, you did not replied to A them and i thought that you became agree. A A I replied to your reply to mine. Other than that I didn't find A anything else from you. A A So, if not, what you think about the name net.pfil.ipforward? A A net.inet.ip.pfil_forward A net.inet6.ip6.pfil_forward A A or something like that. A A If you can show with your performance profiling that the sysctl A isn't even necessary, you could leave it completely away and have A pfil_forward enabled permanently. That would be even better for A everybody. I'd prefer to have the sysctl. Benchmarking will definitely show no regression, because in default case packets are tagless. But if packets would carry 1 or 2 tags each, which don't actually belong to PACKET_TAG_IPFORWARD, then processing would be pessimized. With M_FASTFWD_OURS I used an overlay of the protocol specific M_PROTO[1-5] mbuf flags. The same can be done with M_IPFORWARD. The ipfw code then will not only add the m_tag but also set M_IPFORWARD flag. That way no sysctl is required and the feature is always available. The overlay definition is in ip_var.h. -- Andre ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 26.10.2012 15:43, Andre Oppermann wrote: A If you can show with your performance profiling that the sysctl A isn't even necessary, you could leave it completely away and have A pfil_forward enabled permanently. That would be even better for A everybody. I'd prefer to have the sysctl. Benchmarking will definitely show no regression, because in default case packets are tagless. But if packets would carry 1 or 2 tags each, which don't actually belong to PACKET_TAG_IPFORWARD, then processing would be pessimized. With M_FASTFWD_OURS I used an overlay of the protocol specific M_PROTO[1-5] mbuf flags. The same can be done with M_IPFORWARD. The ipfw code then will not only add the m_tag but also set M_IPFORWARD flag. That way no sysctl is required and the feature is always available. The overlay definition is in ip_var.h. It seems we have only one bit in the m_flags that can be used, so, maybe we left it to some things that can appear in the future? -- WBR, Andrey V. Elsukov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 26.10.2012 14:29, Andrey V. Elsukov wrote: On 26.10.2012 15:43, Andre Oppermann wrote: A If you can show with your performance profiling that the sysctl A isn't even necessary, you could leave it completely away and have A pfil_forward enabled permanently. That would be even better for A everybody. I'd prefer to have the sysctl. Benchmarking will definitely show no regression, because in default case packets are tagless. But if packets would carry 1 or 2 tags each, which don't actually belong to PACKET_TAG_IPFORWARD, then processing would be pessimized. With M_FASTFWD_OURS I used an overlay of the protocol specific M_PROTO[1-5] mbuf flags. The same can be done with M_IPFORWARD. The ipfw code then will not only add the m_tag but also set M_IPFORWARD flag. That way no sysctl is required and the feature is always available. The overlay definition is in ip_var.h. It seems we have only one bit in the m_flags that can be used, so, maybe we left it to some things that can appear in the future? That's what the M_PROTO flags are for: #define M_IPFW_FORWARD M_PROTO2/* ip forwarding */ of course you have to do the same for ip6. The M_PROTO[1-5] flags are only valid within a protocol layer. For example they get cleared in ip_output() before the packet is handed to layer 2. -- Andre ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 26.10.2012 15:24, Andre Oppermann wrote: On 26.10.2012 14:29, Andrey V. Elsukov wrote: On 26.10.2012 15:43, Andre Oppermann wrote: A If you can show with your performance profiling that the sysctl A isn't even necessary, you could leave it completely away and have A pfil_forward enabled permanently. That would be even better for A everybody. I'd prefer to have the sysctl. Benchmarking will definitely show no regression, because in default case packets are tagless. But if packets would carry 1 or 2 tags each, which don't actually belong to PACKET_TAG_IPFORWARD, then processing would be pessimized. With M_FASTFWD_OURS I used an overlay of the protocol specific M_PROTO[1-5] mbuf flags. The same can be done with M_IPFORWARD. The ipfw code then will not only add the m_tag but also set M_IPFORWARD flag. That way no sysctl is required and the feature is always available. The overlay definition is in ip_var.h. It seems we have only one bit in the m_flags that can be used, so, maybe we left it to some things that can appear in the future? That's what the M_PROTO flags are for: #defineM_IPFW_FORWARDM_PROTO2/* ip forwarding */ Actually looking at it technically this isn't forwarding but specifying a different nexthop. Hence the #define and description should be more like #define M_IP_NEXTHOPM_PROTO2/* explicit ip nexthop */ Of course the userspace ipfw feature naming and usage doesn't change. But within the kernel it's really nexthop manipulation within the forwarding path. -- Andre of course you have to do the same for ip6. The M_PROTO[1-5] flags are only valid within a protocol layer. For example they get cleared in ip_output() before the packet is handed to layer 2. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
Author: ae Date: Thu Oct 25 09:39:14 2012 New Revision: 242079 URL: http://svn.freebsd.org/changeset/base/242079 Log: Remove the IPFIREWALL_FORWARD kernel option and make possible to turn on the related functionality in the runtime via the sysctl variable net.pfil.forward. It is turned off by default. Sponsored by: Yandex LLC Discussed with: net@ MFC after:2 weeks Modified: head/sbin/ipfw/ipfw.8 head/share/man/man4/ipfirewall.4 head/sys/conf/NOTES head/sys/conf/options head/sys/net/pfil.c head/sys/net/pfil.h head/sys/netinet/ip_fastfwd.c head/sys/netinet/ip_input.c head/sys/netinet/ip_output.c head/sys/netinet/tcp_input.c head/sys/netinet/udp_usrreq.c head/sys/netinet6/ip6_forward.c head/sys/netinet6/ip6_input.c head/sys/netinet6/ip6_output.c head/sys/netinet6/udp6_usrreq.c head/sys/netpfil/ipfw/ip_fw2.c head/sys/netpfil/ipfw/ip_fw_pfil.c head/sys/netpfil/ipfw/ip_fw_sockopt.c Modified: head/sbin/ipfw/ipfw.8 == --- head/sbin/ipfw/ipfw.8 Thu Oct 25 09:05:21 2012(r242078) +++ head/sbin/ipfw/ipfw.8 Thu Oct 25 09:39:14 2012(r242079) @@ -1,7 +1,7 @@ .\ .\ $FreeBSD$ .\ -.Dd July 16, 2012 +.Dd October 25, 2012 .Dt IPFW 8 .Os .Sh NAME @@ -777,8 +777,11 @@ use with transparent proxy servers. .Pp To enable .Cm fwd -a custom kernel needs to be compiled with the option -.Cd options IPFIREWALL_FORWARD . +the +.Xr sysctl 8 +variable +.Va net.pfil.forward +should be set to 1. .It Cm nat Ar nat_nr | tablearg Pass packet to a nat instance Modified: head/share/man/man4/ipfirewall.4 == --- head/share/man/man4/ipfirewall.4Thu Oct 25 09:05:21 2012 (r242078) +++ head/share/man/man4/ipfirewall.4Thu Oct 25 09:39:14 2012 (r242079) @@ -1,7 +1,7 @@ .\ .\ $FreeBSD$ .\ -.Dd September 1, 2006 +.Dd October 25, 2012 .Dt IPFW 4 .Os .Sh NAME @@ -20,7 +20,6 @@ Other related kernel options which may also be useful are: .Bd -ragged -offset indent .Cd options IPFIREWALL_DEFAULT_TO_ACCEPT -.Cd options IPFIREWALL_FORWARD .Cd options IPFIREWALL_VERBOSE .Cd options IPFIREWALL_VERBOSE_LIMIT=100 .Ed @@ -71,12 +70,6 @@ from flooding system logs or causing loc This option may be set to the number of packets which will be logged on a per-entry basis before the entry is rate-limited. .Pp -Policy routing and transparent forwarding features of -.Nm -can be enabled by -.Dv IPFIREWALL_FORWARD -kernel option. -.Pp The user interface for .Nm is implemented by the Modified: head/sys/conf/NOTES == --- head/sys/conf/NOTES Thu Oct 25 09:05:21 2012(r242078) +++ head/sys/conf/NOTES Thu Oct 25 09:39:14 2012(r242079) @@ -897,12 +897,6 @@ device lagg # IPDIVERT enables the divert IP sockets, used by ``ipfw divert''. It # depends on IPFIREWALL if compiled into the kernel. # -# IPFIREWALL_FORWARD enables changing of the packet destination either -# to do some sort of policy routing or transparent proxying. Used by -# ``ipfw forward''. All redirections apply to locally generated -# packets too. Because of this great care is required when -# crafting the ruleset. -# # IPFIREWALL_NAT adds support for in kernel nat in ipfw, and it requires # LIBALIAS. # @@ -923,7 +917,6 @@ options IPFIREWALL #firewall optionsIPFIREWALL_VERBOSE #enable logging to syslogd(8) optionsIPFIREWALL_VERBOSE_LIMIT=100#limit verbosity optionsIPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default -optionsIPFIREWALL_FORWARD #packet destination changes optionsIPFIREWALL_NAT #ipfw kernel nat support optionsIPDIVERT#divert sockets optionsIPFILTER#ipfilter support Modified: head/sys/conf/options == --- head/sys/conf/options Thu Oct 25 09:05:21 2012(r242078) +++ head/sys/conf/options Thu Oct 25 09:39:14 2012(r242079) @@ -398,7 +398,6 @@ IPFILTER_LOGopt_ipfilter.h IPFILTER_LOOKUPopt_ipfilter.h IPFIREWALL opt_ipfw.h IPFIREWALL_DEFAULT_TO_ACCEPT opt_ipfw.h -IPFIREWALL_FORWARD opt_ipfw.h IPFIREWALL_NAT opt_ipfw.h IPFIREWALL_VERBOSE opt_ipfw.h IPFIREWALL_VERBOSE_LIMIT opt_ipfw.h Modified: head/sys/net/pfil.c == --- head/sys/net/pfil.c Thu Oct 25 09:05:21 2012(r242078) +++ head/sys/net/pfil.c Thu Oct 25 09:39:14 2012(r242079) @@ -37,6 +37,7 @@ #include sys/rmlock.h #include sys/socket.h #include sys/socketvar.h +#include sys/sysctl.h #include sys/systm.h #include sys/condvar.h #include sys/lock.h
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On Thursday, October 25, 2012 5:39:15 am Andrey V. Elsukov wrote: Author: ae Date: Thu Oct 25 09:39:14 2012 New Revision: 242079 URL: http://svn.freebsd.org/changeset/base/242079 Log: Remove the IPFIREWALL_FORWARD kernel option and make possible to turn on the related functionality in the runtime via the sysctl variable net.pfil.forward. It is turned off by default. Certainly for MFC's I think it makes sense to retain the option, but make the option simply change the default from off to on. That avoids breaking existing kernel configurations. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 25.10.2012 17:28, John Baldwin wrote: Remove the IPFIREWALL_FORWARD kernel option and make possible to turn on the related functionality in the runtime via the sysctl variable net.pfil.forward. It is turned off by default. Certainly for MFC's I think it makes sense to retain the option, but make the option simply change the default from off to on. That avoids breaking existing kernel configurations. Yes, this is exactly what i plan to do. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 25.10.2012 11:39, Andrey V. Elsukov wrote: Author: ae Date: Thu Oct 25 09:39:14 2012 New Revision: 242079 URL: http://svn.freebsd.org/changeset/base/242079 Log: Remove the IPFIREWALL_FORWARD kernel option and make possible to turn on the related functionality in the runtime via the sysctl variable net.pfil.forward. It is turned off by default. Sponsored by:Yandex LLC Discussed with: net@ MFC after: 2 weeks I still don't agree with naming the sysctl net.pfil.forward. This type of forwarding is a property of IPv4 and IPv6 and thus should be put there. Pfil hooking can be on layer 2, 2-bridging, 3 and who knows where else in the future. Forwarding works only for IPv46. You haven't even replied to my comment on net@. Please change the sysctl location and name to its appropriate place. Also an MFC's after 2 weeks must ensure that compiling with IPFIREWALL_ FORWARD enabled the sysctl at the same time to keep kernel configs within 9-stable working. -- Andre ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 25.10.2012 19:54, Andre Oppermann wrote: I still don't agree with naming the sysctl net.pfil.forward. This type of forwarding is a property of IPv4 and IPv6 and thus should be put there. Pfil hooking can be on layer 2, 2-bridging, 3 and who knows where else in the future. Forwarding works only for IPv46. You haven't even replied to my comment on net@. Please change the sysctl location and name to its appropriate place. Hi Andre, There were two replies related to this subject, you did not replied to them and i thought that you became agree. So, if not, what you think about the name net.pfil.ipforward? Also an MFC's after 2 weeks must ensure that compiling with IPFIREWALL_ FORWARD enabled the sysctl at the same time to keep kernel configs within 9-stable working. Yes, it will work like that. -- WBR, Andrey V. Elsukov ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw
On 25.10.2012 18:25, Andrey V. Elsukov wrote: On 25.10.2012 19:54, Andre Oppermann wrote: I still don't agree with naming the sysctl net.pfil.forward. This type of forwarding is a property of IPv4 and IPv6 and thus should be put there. Pfil hooking can be on layer 2, 2-bridging, 3 and who knows where else in the future. Forwarding works only for IPv46. You haven't even replied to my comment on net@. Please change the sysctl location and name to its appropriate place. Hi Andre, There were two replies related to this subject, you did not replied to them and i thought that you became agree. I replied to your reply to mine. Other than that I didn't find anything else from you. So, if not, what you think about the name net.pfil.ipforward? net.inet.ip.pfil_forward net.inet6.ip6.pfil_forward or something like that. If you can show with your performance profiling that the sysctl isn't even necessary, you could leave it completely away and have pfil_forward enabled permanently. That would be even better for everybody. Also an MFC's after 2 weeks must ensure that compiling with IPFIREWALL_ FORWARD enabled the sysctl at the same time to keep kernel configs within 9-stable working. Yes, it will work like that. Excellent. Thank you. -- Andre ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
