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"
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: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 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 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 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"
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 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 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 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"
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 #include #include +#include #include #include #include @@ -64,6 +65,11 @@ VNET_DEFINE(struct pfilheadhead, pfil_he VNET_DEFIN
