Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já
pode ser atualizado à partir da árvore releng/10.1 através do svn. :)
[]´s
Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já
pode ser atualizado à partir da árvore releng/10.1 através do svn. :)
[]´s
Gondim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da
Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil
paulo.rd...@bsd.com.br escreveu:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode
ser atualizado à partir da árvore releng/10.1 através do svn. :)
[]´s
Em 11/11/2014, à(s) 11:13, Tiago Ribeiro sha...@gmail.com escreveu:
Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil
paulo.rd...@bsd.com.br escreveu:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode
ser
Bom dia pessoal, devido a um problema com Pipe + MAC Address no FreeBSD 10
para controle de upload (thread antiga aqui), estou fazendo testes na
versão 9.2 do Nat do IPFW usando libalias.
Pois bem, independentemente das demais regras (testei somente com as de
NAT) o comportamento no FreeBSD 9.2
On 11/11/2014 11:13, Tiago Ribeiro wrote:
Em 11/11/2014, à(s) 11:07, Paulo Henrique - BSDs Brasil
paulo.rd...@bsd.com.br escreveu:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode ser
atualizado à partir da árvore
On 11/11/2014 11:07, Paulo Henrique - BSDs Brasil wrote:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já
pode ser atualizado à partir da árvore releng/10.1 através do svn. :)
[]´s
Gondim
-
Histórico:
Talvez o divert natd seja o q esteja funcionando no seu script
add divert natd all from 192.168.0.0/16 to any via wan0
eu costumava usar assim, inclusive com pipes.
mas o seu one_pass está me fazendo refletir se deveria ser setado em 1 ou nao...
[ ]'s
Fabricio Lima
When your hammer is C++,
Em 11/11/2014, à(s) 12:05, Marcelo Gondim gon...@bsdinfo.com.br escreveu:
On 11/11/2014 11:07, Paulo Henrique - BSDs Brasil wrote:
Em 11/11/2014 10:42, Marcelo Gondim escreveu:
Ainda não é oficial mas se nada absurdo acontecer rsrsrsr o 10.1R já pode
ser atualizado à partir da árvore
Fabricio, eu uso o divert em alguns cases (mais de 20), só que o consumo de
cpu e a latência conforme a banda consumida e o número de sub-redes com
alias na placa interna aumenta está ficando inviável.
A tentativa de utilizar essa forma de NAT é reduzir esse consumo de CPU e
também manter uma
Testes que eu fiz com a versão 10.1-RC4, se alguem puder fazer algo
semelhante no PRERELEASE pra ver se o resultado é o mesmo.
Options no Kernel:
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options
Entendi...
seu objetivo (q estaria causando o kernel panic) é o MAC + pipes
Duvida:
-sem as regras de mac address, está tudo carregando normal ne? (pipes por
IP) e baixa cpu?
-pra estar gerando tanta carga na cpu assim, qual o throughput q estamos
falando? (pra saber se a alta demanda de cpu é
Entendi...
seu objetivo (q estaria causando o kernel panic) é o MAC + pipes
Não dá Kernel Panic no 9.2, somente no 10.1, no 10 simplesmente não há
navegação, nem com MAC nem com IP direto.
Sobre PPPoE é meu futuro, estou caminhando para isso mais são muitos
clientes e tenho muitos
faz o pipe apenas pelo IP...
e a regra do accept faça atraves de AND do ip e mac.
assim vc 'nao complicou' o seu script de fw fazendo regra dummynet em
layer2...
e liberou apenas os clientes com MAC previamente cadastrados
o mal intencionado teria q saber q vc faz isso, e clonar o mac de
14 matches
Mail list logo
