version 1.203, 2017/04/26 20:21:29 |
version 1.204, 2017/06/26 17:18:57 |
|
|
<p> |
<p> |
Take Adaptec for instance. Before the 3.7 release we disabled support |
Take Adaptec for instance. Before the 3.7 release we disabled support |
for the |
for the |
<a href="http://man.openbsd.org/?query=aac&sektion=4">aac(4)</a> |
<a href="https://man.openbsd.org/?query=aac&sektion=4">aac(4)</a> |
Adaptec RAID driver because negotiations with the Adaptec had failed. |
Adaptec RAID driver because negotiations with the Adaptec had failed. |
They refused to give us documentation. Without documentation, support |
They refused to give us documentation. Without documentation, support |
for their controller had always been poor. The driver had bugs (which |
for their controller had always been poor. The driver had bugs (which |
|
|
ever) we will get around to writing that support for Adaptec RAID |
ever) we will get around to writing that support for Adaptec RAID |
controllers now. And Adaptec has gone and bought ICP Vortex, which |
controllers now. And Adaptec has gone and bought ICP Vortex, which |
may mean we can never get documentation for the |
may mean we can never get documentation for the |
<a href="http://man.openbsd.org/?query=gdt&sektion=4">gdt(4)</a> |
<a href="https://man.openbsd.org/?query=gdt&sektion=4">gdt(4)</a> |
controllers. |
controllers. |
The "Open Source Friendly liar" IBM owns Mylex, and Mylex has told us we |
The "Open Source Friendly liar" IBM owns Mylex, and Mylex has told us we |
would not get documentation, either. |
would not get documentation, either. |
|
|
<br> |
<br> |
|
|
Want to help us? Avoid |
Want to help us? Avoid |
<a href="http://man.openbsd.org/?query=ipw">Intel Centrino</a>, |
<a href="https://man.openbsd.org/?query=ipw">Intel Centrino</a>, |
Broadcom, TI, or Connexant PrismGT chipsets. |
Broadcom, TI, or Connexant PrismGT chipsets. |
Heck, avoid buying even regular |
Heck, avoid buying even regular |
<a href="http://man.openbsd.org/?query=wi">old pre-G Prism products</a>, |
<a href="https://man.openbsd.org/?query=wi">old pre-G Prism products</a>, |
to send a message. |
to send a message. |
If you can, buy 802.11 products using chips by |
If you can, buy 802.11 products using chips by |
<a href="http://man.openbsd.org/?query=rtw">Realtek</a>, |
<a href="https://man.openbsd.org/?query=rtw">Realtek</a>, |
<a href="http://man.openbsd.org/?query=ral">Ralink</a>, |
<a href="https://man.openbsd.org/?query=ral">Ralink</a>, |
<a href="http://man.openbsd.org/?query=atu">Atmel</a>, |
<a href="https://man.openbsd.org/?query=atu">Atmel</a>, |
<a href="http://man.openbsd.org/?query=awi">ADMTek</a>, |
<a href="https://man.openbsd.org/?query=awi">ADMTek</a>, |
<a href="http://man.openbsd.org/?query=ath">Atheros</a>. |
<a href="https://man.openbsd.org/?query=ath">Atheros</a>. |
Our manual pages attempt to explain which vendors (ie. D-Link) box |
Our manual pages attempt to explain which vendors (ie. D-Link) box |
which chipsets into which product. |
which chipsets into which product. |
<br> |
<br> |
|
|
Cisco lawyers and IETF policy. |
Cisco lawyers and IETF policy. |
<p> |
<p> |
We've been working a few years now on our packet filtering software |
We've been working a few years now on our packet filtering software |
<a href="http://man.openbsd.org/?query=pf&sektion=4">pf(4)</a> |
<a href="https://man.openbsd.org/?query=pf&sektion=4">pf(4)</a> |
and it became time to add failover. We want to be able to set up pf |
and it became time to add failover. We want to be able to set up pf |
firewalls side by side, and exchange the stateful information between |
firewalls side by side, and exchange the stateful information between |
them, so that in case of failure another could take over 'keep state' |
them, so that in case of failure another could take over 'keep state' |
sessions. Our |
sessions. Our |
<a href="http://man.openbsd.org/?query=pfsync&sektion=4">pfsync(4)</a> |
<a href="https://man.openbsd.org/?query=pfsync&sektion=4">pfsync(4)</a> |
protocol solves this problem. However, on both sides of the firewall, |
protocol solves this problem. However, on both sides of the firewall, |
it is also necessary to have all the regular hosts not see a |
it is also necessary to have all the regular hosts not see a |
network failure. The only reliable way to do this is for both |
network failure. The only reliable way to do this is for both |
|
|
it to use cryptography. |
it to use cryptography. |
<p> |
<p> |
The combination of |
The combination of |
<a href="http://man.openbsd.org/?query=pf&sektion=4">pf(4)</a>, |
<a href="https://man.openbsd.org/?query=pf&sektion=4">pf(4)</a>, |
<a href="http://man.openbsd.org/?query=pfsync&sektion=4">pfsync(4)</a>, and |
<a href="https://man.openbsd.org/?query=pfsync&sektion=4">pfsync(4)</a>, and |
<a href="http://man.openbsd.org/?query=carp&sektion=4">carp(4)</a> |
<a href="https://man.openbsd.org/?query=carp&sektion=4">carp(4)</a> |
has permitted us to build highly redundant firewalls. To date, we |
has permitted us to build highly redundant firewalls. To date, we |
have built a few networks that include as many as 4 firewalls, all |
have built a few networks that include as many as 4 firewalls, all |
running random reboot cycles. As long as one firewall is alive in a |
running random reboot cycles. As long as one firewall is alive in a |