Searched hist:195026 (Results 1 - 6 of 6) sorted by relevance
| /freebsd-10.0-release/etc/rc.d/ | ||
| H A D | NETWORKING | diff 195026 Thu Jun 25 23:20:00 MDT 2009 dougb Reverse the effect of r193198 for pf and ipfw which will once again allow them to start after netif. There were too many problems reported with this change in the short period of time that it lived in HEAD, and we are too late in the release cycle to properly shake it out. IMO the issue of having the firewalls up before the network is still a valid concern, particularly for pf whose default state is wide open. However properly solving this issue is going to take some investment on the part of the people who actually use those tools. This is not a strict reversion of all the changes for r193198 since it also included some simplification of the BEFORE/REQUIRE logic which is still valid for ipfilter and ip6fw. |
| H A D | pflog | diff 195026 Thu Jun 25 23:20:00 MDT 2009 dougb Reverse the effect of r193198 for pf and ipfw which will once again allow them to start after netif. There were too many problems reported with this change in the short period of time that it lived in HEAD, and we are too late in the release cycle to properly shake it out. IMO the issue of having the firewalls up before the network is still a valid concern, particularly for pf whose default state is wide open. However properly solving this issue is going to take some investment on the part of the people who actually use those tools. This is not a strict reversion of all the changes for r193198 since it also included some simplification of the BEFORE/REQUIRE logic which is still valid for ipfilter and ip6fw. |
| H A D | pfsync | diff 195026 Thu Jun 25 23:20:00 MDT 2009 dougb Reverse the effect of r193198 for pf and ipfw which will once again allow them to start after netif. There were too many problems reported with this change in the short period of time that it lived in HEAD, and we are too late in the release cycle to properly shake it out. IMO the issue of having the firewalls up before the network is still a valid concern, particularly for pf whose default state is wide open. However properly solving this issue is going to take some investment on the part of the people who actually use those tools. This is not a strict reversion of all the changes for r193198 since it also included some simplification of the BEFORE/REQUIRE logic which is still valid for ipfilter and ip6fw. |
| H A D | ipfw | diff 195026 Thu Jun 25 23:20:00 MDT 2009 dougb Reverse the effect of r193198 for pf and ipfw which will once again allow them to start after netif. There were too many problems reported with this change in the short period of time that it lived in HEAD, and we are too late in the release cycle to properly shake it out. IMO the issue of having the firewalls up before the network is still a valid concern, particularly for pf whose default state is wide open. However properly solving this issue is going to take some investment on the part of the people who actually use those tools. This is not a strict reversion of all the changes for r193198 since it also included some simplification of the BEFORE/REQUIRE logic which is still valid for ipfilter and ip6fw. |
| H A D | pf | diff 195026 Thu Jun 25 23:20:00 MDT 2009 dougb Reverse the effect of r193198 for pf and ipfw which will once again allow them to start after netif. There were too many problems reported with this change in the short period of time that it lived in HEAD, and we are too late in the release cycle to properly shake it out. IMO the issue of having the firewalls up before the network is still a valid concern, particularly for pf whose default state is wide open. However properly solving this issue is going to take some investment on the part of the people who actually use those tools. This is not a strict reversion of all the changes for r193198 since it also included some simplification of the BEFORE/REQUIRE logic which is still valid for ipfilter and ip6fw. |
| H A D | netif | diff 195026 Thu Jun 25 23:20:00 MDT 2009 dougb Reverse the effect of r193198 for pf and ipfw which will once again allow them to start after netif. There were too many problems reported with this change in the short period of time that it lived in HEAD, and we are too late in the release cycle to properly shake it out. IMO the issue of having the firewalls up before the network is still a valid concern, particularly for pf whose default state is wide open. However properly solving this issue is going to take some investment on the part of the people who actually use those tools. This is not a strict reversion of all the changes for r193198 since it also included some simplification of the BEFORE/REQUIRE logic which is still valid for ipfilter and ip6fw. |
Completed in 76 milliseconds