[FUG-BR] Intencionalmente derrubando desempenho de CPU.

[Joao Rocha Braga Filho]

Dando uma pesquisada no powerd descobri algumas coisas interessantes.

Tem como diminuir o clock do processador à mão.

Com o seguinte comando vi o clock atual e as possibilidades:

root:[748] sysctl -a | grep dev.cpu...freq
dev.cpu.0.freq: 1093
dev.cpu.0.freq_levels: 2500/30940 2187/27072 1875/23205 1562/19337
1250/18480 1093/16170


Note que já reduzi ao mínimo. Como fiz isto? Assim:

root:[747] sysctl dev.cpu.0.freq=1093
dev.cpu.0.freq: 1093 -> 1093


Como verifiquei se funcionou? Pelo top, vendo o tempo de idle diminuir, pelo
barulho do ventilador de CPU diminuir, e pela temperatura do processador
cair
mais de 10 graus C.

root:[749] sysctl -a | grep dev.cpu...temperature:
dev.cpu.0.temperature: 47,0C
dev.cpu.1.temperature: 47,0C
dev.cpu.2.temperature: 47,0C
dev.cpu.3.temperature: 47,0C

Em geral o meu computador já tem desempenho mais do que o suficiente
para o meu dia a dia. Eu gostaria de ter mais memória.

O powerd parece fazer besteira, pois parece não entender que se tratam
de 4 núcleos.


Eu também brinquei um pouco de parar HDs:

root:[773] atacontrol spindown ad8 60
root:[774] atacontrol spindown ad8
ad8: spin down after 60 seconds idle



Bibliografia:

https://forums.freebsd.org/threads/howto-freebsd-cpu-scaling-and-power-saving.172/

man pages.


Será que vou baixar a conta de luz?


João Rocha.

-- 

http://jgoffredo.blogspot.com
goffr...@gmail.com
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Paulo Henrique - BSDs]

Em 05/11/2014 16:53, Fabricio Lima escreveu:

Edinilson, vc está certo...
eu tb mexia mais nisso na epoca do 6, 7, 8..

Hj eles ajustaram tanta coisa (9 e 10)
q talvez o default seja melhor q um 7 tunado...

(minha documentaçao caducou)

testar, testar, testar...

[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

2014-11-05 16:44 GMT-02:00 Edinilson - ATINET :


- Original Message - From: "Paulo Henrique - BSDs" <

paulo.rd...@bsd.com.br>
To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" <
freebsd@fug.com.br>
Sent: Wednesday, November 05, 2014 3:58 PM
Subject: [FUG-BR] Valor aconselhavel para variável HZ

Saudações,

Gostaria de saber se alguém trabalha com a variável HZ com o valor
superior a 2000, caso sim o ambiente fica estável, há uma melhora no
desempenho do sistema e da rede ?
Sei que a mesma interfere quanto ao uso da bateria em portáteis contudo a
duvida é restrita a servidores.
Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com
32Gbytes de ram melhorará o desempenho.
Abaixo tem os dados do sistema atualmente.
O HZ do sistema está em 2000.

uname -a
FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31
14:39:46 BRT 2014
netstat -m
yyy@x:/usr/obj/usr/src/sys/XXX amd64
11204/15571/26775 mbufs in use (current/cache/total)
1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
1023/9512 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/548/548/1018031 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
4847K/25734K/30581K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
9966280 requests for I/O initiated by sendfile

uptime
15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27


Alguns tunnings que já foi feito no sistema.

# $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
#
# This file is read when going to multi-user and its contents piped thru
# ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes
that
# are being run under another UID.
#security.bsd.see_other_uids=0

kern.maxfiles=100

# Otimizacoes de rede.
#kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou instavel
valor definido pelo sistema.
kern.ipc.maxsockbuf=33554432
net.inet.tcp.sendbuf_max=33554432
net.inet.tcp.recvbuf_max=33554432
net.inet.tcp.sendspace=1048576 # default 65536
net.inet.tcp.recvspace=1048576 # default 32768
net.inet.tcp.sendbuf_inc=1048576 # 8192 default
net.inet.tcp.recvbuf_inc=1048576 # 16384 default
kern.ipc.somaxconn=4096 # 128 default
net.inet.tcp.syncache.rexmtlimit=1
net.inet.tcp.syncookies=1

# COnfigura▒▒es de Seguran▒a
# General Security and DoS mitigation.
net.inet.ip.check_interface=1 # verify packet arrives on correct interface
net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
net.inet.ip.process_options=0 # IP options in the incoming packets will
be ignored
net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving
the system
net.inet.ip.redirect=0 # do not send IP redirects
net.inet.ip.accept_sourceroute=0 # drop source routed packets since they
can not be trusted
net.inet.ip.sourceroute=0 # if source routed packets are accepted the
route data is ignored
#net.inet.ip.stealth=1 # do not reduce the TTL by one(1) when a packets
goes through the firewall
net.inet.icmp.bmcastecho=0 # do not respond to ICMP packets sent to IP
broadcast addresses
net.inet.icmp.maskfake=0 # do not fake reply to ICMP Address Mask Request
packets
net.inet.icmp.maskrepl=0 # replies are not sent for ICMP address mask
requests
net.inet.icmp.log_redirect=0 # do not log redirected ICMP packet attempts
net.inet.icmp.drop_redirect=1 # no redirected ICMP packets
#net.inet.icmp.icmplim=50 # 50 ICMP packets per second. a reasonable
number for a small office.
#net.inet.tcp.delayed_ack=1 # always employ delayed ack, 6 packets get 1
ack to increase bandwidth
net.inet.tcp.drop_synfin=1 # SYN/FIN packets get dropped on initial
connection
net.inet.tcp.ecn.enable=1 # explicit congestion notification (ecn)
warning: some ISP routers abuse it
net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly
(helps against DoS, but may cause false RST)
net.inet.tcp.icmp_may_rst=0 # icmp may not send RST to avoid spoofed
icmp/udp floods
net.inet.tcp.maxtcptw=15000 # max number of tcp time_wait states for
closing connections
net.inet.tcp.msl=5000 # 5 second maximum segment life waiting for an ACK
in reply to a SYN-AC

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Fabricio Lima]

Edinilson, vc está certo...
eu tb mexia mais nisso na epoca do 6, 7, 8..

Hj eles ajustaram tanta coisa (9 e 10)
q talvez o default seja melhor q um 7 tunado...

(minha documentaçao caducou)

testar, testar, testar...

[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

2014-11-05 16:44 GMT-02:00 Edinilson - ATINET :

> - Original Message - From: "Paulo Henrique - BSDs" <
>> paulo.rd...@bsd.com.br>
>> To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" <
>> freebsd@fug.com.br>
>> Sent: Wednesday, November 05, 2014 3:58 PM
>> Subject: [FUG-BR] Valor aconselhavel para variável HZ
>>
>> Saudações,
>>
>> Gostaria de saber se alguém trabalha com a variável HZ com o valor
>> superior a 2000, caso sim o ambiente fica estável, há uma melhora no
>> desempenho do sistema e da rede ?
>> Sei que a mesma interfere quanto ao uso da bateria em portáteis contudo a
>> duvida é restrita a servidores.
>> Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com
>> 32Gbytes de ram melhorará o desempenho.
>> Abaixo tem os dados do sistema atualmente.
>> O HZ do sistema está em 2000.
>>
>> uname -a
>> FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31
>> 14:39:46 BRT 2014
>> netstat -m
>> yyy@x:/usr/obj/usr/src/sys/XXX amd64
>> 11204/15571/26775 mbufs in use (current/cache/total)
>> 1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
>> 1023/9512 mbuf+clusters out of packet secondary zone in use
>> (current/cache)
>> 0/548/548/1018031 4k (page size) jumbo clusters in use
>> (current/cache/total/max)
>> 0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
>> 0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
>> 4847K/25734K/30581K bytes allocated to network (current/cache/total)
>> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
>> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
>> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
>> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
>> 0 requests for sfbufs denied
>> 0 requests for sfbufs delayed
>> 9966280 requests for I/O initiated by sendfile
>>
>> uptime
>> 15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27
>>
>>
>> Alguns tunnings que já foi feito no sistema.
>>
>> # $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
>> #
>> # This file is read when going to multi-user and its contents piped thru
>> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
>> #
>>
>> # Uncomment this to prevent users from seeing information about processes
>> that
>> # are being run under another UID.
>> #security.bsd.see_other_uids=0
>>
>> kern.maxfiles=100
>>
>> # Otimizacoes de rede.
>> #kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou instavel
>> valor definido pelo sistema.
>> kern.ipc.maxsockbuf=33554432
>> net.inet.tcp.sendbuf_max=33554432
>> net.inet.tcp.recvbuf_max=33554432
>> net.inet.tcp.sendspace=1048576 # default 65536
>> net.inet.tcp.recvspace=1048576 # default 32768
>> net.inet.tcp.sendbuf_inc=1048576 # 8192 default
>> net.inet.tcp.recvbuf_inc=1048576 # 16384 default
>> kern.ipc.somaxconn=4096 # 128 default
>> net.inet.tcp.syncache.rexmtlimit=1
>> net.inet.tcp.syncookies=1
>>
>> # COnfigura▒▒es de Seguran▒a
>> # General Security and DoS mitigation.
>> net.inet.ip.check_interface=1 # verify packet arrives on correct interface
>> net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
>> net.inet.ip.process_options=0 # IP options in the incoming packets will
>> be ignored
>> net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving
>> the system
>> net.inet.ip.redirect=0 # do not send IP redirects
>> net.inet.ip.accept_sourceroute=0 # drop source routed packets since they
>> can not be trusted
>> net.inet.ip.sourceroute=0 # if source routed packets are accepted the
>> route data is ignored
>> #net.inet.ip.stealth=1 # do not reduce the TTL by one(1) when a packets
>> goes through the firewall
>> net.inet.icmp.bmcastecho=0 # do not respond to ICMP packets sent to IP
>> broadcast addresses
>> net.inet.icmp.maskfake=0 # do not fake reply to ICMP Address Mask Request
>> packets
>> net.inet.icmp.maskrepl=0 # replies are not sent for ICMP address mask
>> requests
>> net.inet.icmp.log_redirect=0 # do not log redirected ICMP packet attempts
>> net.inet.icmp.drop_redirect=1 # no redirected ICMP packets
>> #net.inet.icmp.icmplim=50 # 50 ICMP packets per second. a reasonable
>> number for a small office.
>> #net.inet.tcp.delayed_ack=1 # always employ delayed ack, 6 packets get 1
>> ack to increase bandwidth
>> net.inet.tcp.drop_synfin=1 # SYN/FIN packets get dropped on initial
>> connection
>> net.inet.tcp.ecn.enable=1 # explicit congestion notification (ecn)
>> warning: some ISP routers abuse it
>> net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly
>> (helps against DoS, but may cause false RST)
>> net.i

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[spiderslack]

Em 11/05/2014 03:10 PM, EnioRM escreveu:




Senhores!

apenas por curiosidade:
spiderslack, como está os options do seu pf.conf
set state-policy if-bound ou floating (que é o default)?

att



Ola Enio

Ja tentei as duas opções mas esta como default atualmente.

Att.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Edinilson - ATINET]

- Original Message - 
From: "Paulo Henrique - BSDs" 
To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" 


Sent: Wednesday, November 05, 2014 3:58 PM
Subject: [FUG-BR] Valor aconselhavel para variável HZ
Saudações,

Gostaria de saber se alguém trabalha com a variável HZ com o valor 
superior a 2000, caso sim o ambiente fica estável, há uma melhora no 
desempenho do sistema e da rede ?
Sei que a mesma interfere quanto ao uso da bateria em portáteis contudo a 
duvida é restrita a servidores.
Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com 
32Gbytes de ram melhorará o desempenho.

Abaixo tem os dados do sistema atualmente.
O HZ do sistema está em 2000.

uname -a
FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31 
14:39:46 BRT 2014

netstat -m
yyy@x:/usr/obj/usr/src/sys/XXX amd64
11204/15571/26775 mbufs in use (current/cache/total)
1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
1023/9512 mbuf+clusters out of packet secondary zone in use 
(current/cache)
0/548/548/1018031 4k (page size) jumbo clusters in use 
(current/cache/total/max)

0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
4847K/25734K/30581K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
9966280 requests for I/O initiated by sendfile

uptime
15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27


Alguns tunnings que já foi feito no sistema.

# $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
#
# This file is read when going to multi-user and its contents piped thru
# ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes 
that

# are being run under another UID.
#security.bsd.see_other_uids=0

kern.maxfiles=100

# Otimizacoes de rede.
#kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou instavel 
valor definido pelo sistema.

kern.ipc.maxsockbuf=33554432
net.inet.tcp.sendbuf_max=33554432
net.inet.tcp.recvbuf_max=33554432
net.inet.tcp.sendspace=1048576 # default 65536
net.inet.tcp.recvspace=1048576 # default 32768
net.inet.tcp.sendbuf_inc=1048576 # 8192 default
net.inet.tcp.recvbuf_inc=1048576 # 16384 default
kern.ipc.somaxconn=4096 # 128 default
net.inet.tcp.syncache.rexmtlimit=1
net.inet.tcp.syncookies=1

# COnfigura▒▒es de Seguran▒a
# General Security and DoS mitigation.
net.inet.ip.check_interface=1 # verify packet arrives on correct interface
net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
net.inet.ip.process_options=0 # IP options in the incoming packets will be 
ignored
net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving the 
system

net.inet.ip.redirect=0 # do not send IP redirects
net.inet.ip.accept_sourceroute=0 # drop source routed packets since they 
can not be trusted
net.inet.ip.sourceroute=0 # if source routed packets are accepted the 
route data is ignored
#net.inet.ip.stealth=1 # do not reduce the TTL by one(1) when a packets 
goes through the firewall
net.inet.icmp.bmcastecho=0 # do not respond to ICMP packets sent to IP 
broadcast addresses
net.inet.icmp.maskfake=0 # do not fake reply to ICMP Address Mask Request 
packets
net.inet.icmp.maskrepl=0 # replies are not sent for ICMP address mask 
requests

net.inet.icmp.log_redirect=0 # do not log redirected ICMP packet attempts
net.inet.icmp.drop_redirect=1 # no redirected ICMP packets
#net.inet.icmp.icmplim=50 # 50 ICMP packets per second. a reasonable 
number for a small office.
#net.inet.tcp.delayed_ack=1 # always employ delayed ack, 6 packets get 1 
ack to increase bandwidth
net.inet.tcp.drop_synfin=1 # SYN/FIN packets get dropped on initial 
connection
net.inet.tcp.ecn.enable=1 # explicit congestion notification (ecn) 
warning: some ISP routers abuse it
net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly 
(helps against DoS, but may cause false RST)
net.inet.tcp.icmp_may_rst=0 # icmp may not send RST to avoid spoofed 
icmp/udp floods
net.inet.tcp.maxtcptw=15000 # max number of tcp time_wait states for 
closing connections
net.inet.tcp.msl=5000 # 5 second maximum segment life waiting for an ACK 
in reply to a SYN-ACK or FIN-ACK
net.inet.tcp.path_mtu_discovery=0 # disable MTU discovery since most ICMP 
packets are dropped by others
net.inet.tcp.rfc3042=0 # disable the limited transmit mechanism which can 
slow burst transmissions
#net.inet.tcp.sack.enable=1 # sack disabled? 
http://www.ibm.com/developerworks/linux/library/l-tcp-sack/index.html

net.inet.udp.blackhole=1 # drop udp packets destined for closed sockets
net.inet.

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Fabricio Lima]

oi, eu novamente,

nao mexo com estes numeros ha uns anos, mas consultei meus backups, e eu
usava 65536 (64k) como maxfiles! (mas era banco de dados)

nas ultimas versoes coisas novas entraram, vi este link com umas sugestoes
legais:

http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel

nao digo pra aproveitar os numeros dele, mas analisar os parametros q ele
tb alterou.
comparado ao seus ajustes de sysctl, ele tem muita coisa a 'sugar'.

faça um bench no seu ambiente hj (usando ab e copia, ou algo mais evoluido)
e depois faça com as novas configuraçoes, e SEM nenhuma configuraçao.

se possivel poste aqui os resultados.


[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

2014-11-05 16:12 GMT-02:00 Fabricio Lima :

> Paulo,
>
> seus numeros estão um pouco agressivos... 1milhao de arquivos abertos, e
> ao mesmo tempo 32MB de buffers de rede.
>
> Isso é um file server ou banco ou servidor de trafego de rede (router)?
>
> observe q file server irá demandar muito arquivo aberto, ao contrario de
> banco de dados.
>
> Mas se for um servidor web, faz sentido muitos arquivos abertos, mas estou
> ainda em duvida se tantos!
>
> Acho que voce inflou em todos os sentidos, podendo ir so em uma direcao.
>
>
> [ ]'s
> Fabricio Lima
> When your hammer is C++, everything begins to look like a thumb.
>
> 2014-11-05 15:58 GMT-02:00 Paulo Henrique - BSDs :
>
> Saudações,
>>
>> Gostaria de saber se alguém trabalha com a variável HZ com o valor
>> superior a 2000, caso sim o ambiente fica estável, há uma melhora no
>> desempenho do sistema e da rede ?
>> Sei que a mesma interfere quanto ao uso da bateria em portáteis contudo a
>> duvida é restrita a servidores.
>> Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com
>> 32Gbytes de ram melhorará o desempenho.
>> Abaixo tem os dados do sistema atualmente.
>> O HZ do sistema está em 2000.
>>
>> uname -a
>> FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31
>> 14:39:46 BRT 2014
>> netstat -m
>> yyy@x:/usr/obj/usr/src/sys/XXX amd64
>> 11204/15571/26775 mbufs in use (current/cache/total)
>> 1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
>> 1023/9512 mbuf+clusters out of packet secondary zone in use
>> (current/cache)
>> 0/548/548/1018031 4k (page size) jumbo clusters in use
>> (current/cache/total/max)
>> 0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
>> 0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
>> 4847K/25734K/30581K bytes allocated to network (current/cache/total)
>> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
>> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
>> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
>> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
>> 0 requests for sfbufs denied
>> 0 requests for sfbufs delayed
>> 9966280 requests for I/O initiated by sendfile
>>
>> uptime
>> 15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27
>>
>>
>> Alguns tunnings que já foi feito no sistema.
>>
>> # $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
>> #
>> # This file is read when going to multi-user and its contents piped thru
>> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
>> #
>>
>> # Uncomment this to prevent users from seeing information about processes
>> that
>> # are being run under another UID.
>> #security.bsd.see_other_uids=0
>>
>> kern.maxfiles=100
>>
>> # Otimizacoes de rede.
>> #kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou instavel
>> valor definido pelo sistema.
>> kern.ipc.maxsockbuf=33554432
>> net.inet.tcp.sendbuf_max=33554432
>> net.inet.tcp.recvbuf_max=33554432
>> net.inet.tcp.sendspace=1048576 # default 65536
>> net.inet.tcp.recvspace=1048576 # default 32768
>> net.inet.tcp.sendbuf_inc=1048576 # 8192 default
>> net.inet.tcp.recvbuf_inc=1048576 # 16384 default
>> kern.ipc.somaxconn=4096 # 128 default
>> net.inet.tcp.syncache.rexmtlimit=1
>> net.inet.tcp.syncookies=1
>>
>> # COnfigura▒▒es de Seguran▒a
>> # General Security and DoS mitigation.
>> net.inet.ip.check_interface=1 # verify packet arrives on correct interface
>> net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
>> net.inet.ip.process_options=0 # IP options in the incoming packets will
>> be ignored
>> net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving
>> the system
>> net.inet.ip.redirect=0 # do not send IP redirects
>> net.inet.ip.accept_sourceroute=0 # drop source routed packets since they
>> can not be trusted
>> net.inet.ip.sourceroute=0 # if source routed packets are accepted the
>> route data is ignored
>> #net.inet.ip.stealth=1 # do not reduce the TTL by one(1) when a packets
>> goes through the firewall
>> net.inet.icmp.bmcastecho=0 # do not respond to ICMP packets sent to IP
>> broadcast addresses
>> net.inet.icmp.maskfake=0 # do not fake rep

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Fabricio Lima]

ipfw:

# Ativando Transparent Proxy
ipfw add fwd 200.1.1.1,8080 tcp from 192.168.0.0/16 to any 80

ainda nao acreditei 100% de q seu proxy precisa spoofar algo tipo o
websense com port mirror.

fluxo segue assim:
user1 pede a pagina www.uol.com.br:80
ao sair pelo fw1, ele redireciona pro proxy

o proxy recebe a conexao from user1, destino uol (um socket aberto aqui,
apos 3 way handshake)
ele inicia uma NOVA conexao para uol, usando como origem o IP dele.. (proxy)

ao receber de volta a pagina, ele devolve pela conexao com o usuario q
ainda estava aberta o socket (repara q nao houve o 2o redirect)

[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

Em 5 de novembro de 2014 16:12, spiderslack 
escreveu:

> Em 11/05/2014 02:20 PM, Fabricio Lima escreveu:
>
>> Repensando...
>>
>> voce NAO precisa do 2o redirect...
>>
>> quando um usuario na lan faz a requisiçao pra web, voce joga pro proxy.
>> ele agora vai receber, processar, e matar esta conexao
>> ele irá gerar uma nova conexao, a partir do IP dele, pra web...
>>
> Então segundo o suporte do proxy, ele não faz assim sai do proxy spoofado
> com meu ip(200.2.2.3 por exemplo), porque quando voltar, o pacote retorna
> em direção ao cliente ai preciso interceptar e jogar para o proxy.(isso
> para não sair com um único somente). O proxy é o mara cache.
>
>  e o fw vai rotear certinho.
>> Se voce bota um redirect nesta volta, pode induzir o reset.
>>
> Com o redirect ou sem o reset acontece
>
>>
>> Ou seja, use APENAS um redirect, e como meu email anterior, TRAVANDO a
>> origem:
>>
>> pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from $LOCAL_LAN
>> to
>> any port 80
>>
>> isso jogará pro proxy
>> e ele trata o resto, e devolve pra estação.
>>
>>  Estou estudando como o ipfw funciona para ver se é possivel fazer isso.
>
>
> Att.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Valor aconselhavel para variável HZ

[Fabricio Lima]

Paulo,

seus numeros estão um pouco agressivos... 1milhao de arquivos abertos, e ao
mesmo tempo 32MB de buffers de rede.

Isso é um file server ou banco ou servidor de trafego de rede (router)?

observe q file server irá demandar muito arquivo aberto, ao contrario de
banco de dados.

Mas se for um servidor web, faz sentido muitos arquivos abertos, mas estou
ainda em duvida se tantos!

Acho que voce inflou em todos os sentidos, podendo ir so em uma direcao.


[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

2014-11-05 15:58 GMT-02:00 Paulo Henrique - BSDs :

> Saudações,
>
> Gostaria de saber se alguém trabalha com a variável HZ com o valor
> superior a 2000, caso sim o ambiente fica estável, há uma melhora no
> desempenho do sistema e da rede ?
> Sei que a mesma interfere quanto ao uso da bateria em portáteis contudo a
> duvida é restrita a servidores.
> Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com
> 32Gbytes de ram melhorará o desempenho.
> Abaixo tem os dados do sistema atualmente.
> O HZ do sistema está em 2000.
>
> uname -a
> FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31
> 14:39:46 BRT 2014
> netstat -m
> yyy@x:/usr/obj/usr/src/sys/XXX amd64
> 11204/15571/26775 mbufs in use (current/cache/total)
> 1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
> 1023/9512 mbuf+clusters out of packet secondary zone in use (current/cache)
> 0/548/548/1018031 4k (page size) jumbo clusters in use
> (current/cache/total/max)
> 0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
> 0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
> 4847K/25734K/30581K bytes allocated to network (current/cache/total)
> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
> 0 requests for sfbufs denied
> 0 requests for sfbufs delayed
> 9966280 requests for I/O initiated by sendfile
>
> uptime
> 15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27
>
>
> Alguns tunnings que já foi feito no sistema.
>
> # $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
> #
> # This file is read when going to multi-user and its contents piped thru
> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
> #
>
> # Uncomment this to prevent users from seeing information about processes
> that
> # are being run under another UID.
> #security.bsd.see_other_uids=0
>
> kern.maxfiles=100
>
> # Otimizacoes de rede.
> #kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou instavel
> valor definido pelo sistema.
> kern.ipc.maxsockbuf=33554432
> net.inet.tcp.sendbuf_max=33554432
> net.inet.tcp.recvbuf_max=33554432
> net.inet.tcp.sendspace=1048576 # default 65536
> net.inet.tcp.recvspace=1048576 # default 32768
> net.inet.tcp.sendbuf_inc=1048576 # 8192 default
> net.inet.tcp.recvbuf_inc=1048576 # 16384 default
> kern.ipc.somaxconn=4096 # 128 default
> net.inet.tcp.syncache.rexmtlimit=1
> net.inet.tcp.syncookies=1
>
> # COnfigura▒▒es de Seguran▒a
> # General Security and DoS mitigation.
> net.inet.ip.check_interface=1 # verify packet arrives on correct interface
> net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
> net.inet.ip.process_options=0 # IP options in the incoming packets will be
> ignored
> net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving the
> system
> net.inet.ip.redirect=0 # do not send IP redirects
> net.inet.ip.accept_sourceroute=0 # drop source routed packets since they
> can not be trusted
> net.inet.ip.sourceroute=0 # if source routed packets are accepted the
> route data is ignored
> #net.inet.ip.stealth=1 # do not reduce the TTL by one(1) when a packets
> goes through the firewall
> net.inet.icmp.bmcastecho=0 # do not respond to ICMP packets sent to IP
> broadcast addresses
> net.inet.icmp.maskfake=0 # do not fake reply to ICMP Address Mask Request
> packets
> net.inet.icmp.maskrepl=0 # replies are not sent for ICMP address mask
> requests
> net.inet.icmp.log_redirect=0 # do not log redirected ICMP packet attempts
> net.inet.icmp.drop_redirect=1 # no redirected ICMP packets
> #net.inet.icmp.icmplim=50 # 50 ICMP packets per second. a reasonable
> number for a small office.
> #net.inet.tcp.delayed_ack=1 # always employ delayed ack, 6 packets get 1
> ack to increase bandwidth
> net.inet.tcp.drop_synfin=1 # SYN/FIN packets get dropped on initial
> connection
> net.inet.tcp.ecn.enable=1 # explicit congestion notification (ecn)
> warning: some ISP routers abuse it
> net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly
> (helps against DoS, but may cause false RST)
> net.inet.tcp.icmp_may_rst=0 # icmp may not send RST to avoid spoofed
> icmp/udp floods
> net.inet.tcp.maxtcptw=15000 # max number of tcp time_wait

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[spiderslack]

Em 11/05/2014 02:20 PM, Fabricio Lima escreveu:

Repensando...

voce NAO precisa do 2o redirect...

quando um usuario na lan faz a requisiçao pra web, voce joga pro proxy.
ele agora vai receber, processar, e matar esta conexao
ele irá gerar uma nova conexao, a partir do IP dele, pra web...
Então segundo o suporte do proxy, ele não faz assim sai do proxy 
spoofado com meu ip(200.2.2.3 por exemplo), porque quando voltar, o 
pacote retorna em direção ao cliente ai preciso interceptar e jogar para 
o proxy.(isso para não sair com um único somente). O proxy é o mara cache.



e o fw vai rotear certinho.
Se voce bota um redirect nesta volta, pode induzir o reset.

Com o redirect ou sem o reset acontece


Ou seja, use APENAS um redirect, e como meu email anterior, TRAVANDO a
origem:

pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from $LOCAL_LAN to
any port 80

isso jogará pro proxy
e ele trata o resto, e devolve pra estação.


Estou estudando como o ipfw funciona para ver se é possivel fazer isso.

Att.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[EnioRM]

2014-11-05 14:10 GMT-02:00 spiderslack :

> Ola pessoal.
>
> Se o assunto for off-topic me desculpe. Por nao se tratar especificamente
> de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um
> redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3
> interfaces.
>
> 1 re0 - wan
> 2 re1 - lan
> 3 alc0 - rede do proxy
>
> Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O
> endereço IP do proxy é 200.1.1.1(IP exemplo)
>
> pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any
> port 80
> pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80
> to any
>
> A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz
> testes tentando acessar o site da Cisco: 23.216.160.170):
>
> Desculpe pelo e-mail longo. Mas ja tentei de tudo. Tentei ao invés de
> route-to o reply-to sem sucesso tentei o divert-to tentei o rdr tambem sem
> sucesso o problema do RDR ele manda direto com destino ao proxy na verdade
> o destino e o site da cisco.
>
> Se alguem já passou por isso. Algum palpite que possa me ajuda desde já
> agradeço.
>
> Att.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



Senhores!

apenas por curiosidade:
spiderslack, como está os options do seu pf.conf
set state-policy if-bound ou floating (que é o default)?

att



-- 
*[]'*
*EnioRM *
*B**ackup na nuvem **com o Dropbox *
*Não perca suas anotações. Use o Evernote
*
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[spiderslack]

Em 11/05/2014 01:27 PM, Fabricio Lima escreveu:

Um tiro no escuro... Mas não uso regras assim com any any em proxy
transparente...
Sao perigosas...

Vamos travar sua origem da regra q intercepta as requisições pra jogar no
proxy.

Faz algo tipo:

Pass from $lan_NET to any 80
Obrigado por responder Fabricio, Mas o any any foi somente para teste o 
ultimo teste que fiz, na verdade estou redirecionando somente meu ip 
para não parar o resto da rede

Tenta fazer isso no outro redirect tb. Ou vê se um só resolve.

Não resolveu

Tenta migrar pra ipfw e vê se o bug se apresenta

hum ipfw?! nunca trabalhei com ele, vou pesquisar e ver como se comporta.


Vou ler seu tcpdump antes de falar o proximo teste

Ok, obrigado .
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] Valor aconselhavel para variável HZ

[Paulo Henrique - BSDs]

Saudações,

Gostaria de saber se alguém trabalha com a variável HZ com o valor 
superior a 2000, caso sim o ambiente fica estável, há uma melhora no 
desempenho do sistema e da rede ?
Sei que a mesma interfere quanto ao uso da bateria em portáteis contudo 
a duvida é restrita a servidores.
Aumentar o valor da mesma em um servidor com 12 Cores / 24 Threads com 
32Gbytes de ram melhorará o desempenho.

Abaixo tem os dados do sistema atualmente.
O HZ do sistema está em 2000.

uname -a
FreeBSD x 10.0-STABLE FreeBSD 10.0-STABLE #0 r269344: Thu Jul 31 
14:39:46 BRT 2014

netstat -m
yyy@x:/usr/obj/usr/src/sys/XXX amd64
11204/15571/26775 mbufs in use (current/cache/total)
1023/9825/10848/2036062 mbuf clusters in use (current/cache/total/max)
1023/9512 mbuf+clusters out of packet secondary zone in use (current/cache)
0/548/548/1018031 4k (page size) jumbo clusters in use 
(current/cache/total/max)

0/0/0/301638 9k jumbo clusters in use (current/cache/total/max)
0/0/0/169671 16k jumbo clusters in use (current/cache/total/max)
4847K/25734K/30581K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
9966280 requests for I/O initiated by sendfile

uptime
15:47 up 86 days, 19:40, 1 user, load averages: 8,15 8,86 9,27


Alguns tunnings que já foi feito no sistema.

# $FreeBSD: stable/10/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
#
# This file is read when going to multi-user and its contents piped thru
# ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about 
processes that

# are being run under another UID.
#security.bsd.see_other_uids=0

kern.maxfiles=100

# Otimizacoes de rede.
#kern.ipc.nmbclusters=131072 # 128Mb para buffer de rede - Ficou 
instavel valor definido pelo sistema.

kern.ipc.maxsockbuf=33554432
net.inet.tcp.sendbuf_max=33554432
net.inet.tcp.recvbuf_max=33554432
net.inet.tcp.sendspace=1048576 # default 65536
net.inet.tcp.recvspace=1048576 # default 32768
net.inet.tcp.sendbuf_inc=1048576 # 8192 default
net.inet.tcp.recvbuf_inc=1048576 # 16384 default
kern.ipc.somaxconn=4096 # 128 default
net.inet.tcp.syncache.rexmtlimit=1
net.inet.tcp.syncookies=1

# COnfigura▒▒es de Seguran▒a
# General Security and DoS mitigation.
net.inet.ip.check_interface=1 # verify packet arrives on correct interface
net.inet.ip.portrange.randomized=1 # randomize outgoing upper ports
net.inet.ip.process_options=0 # IP options in the incoming packets will 
be ignored
net.inet.ip.random_id=1 # assign a random IP_ID to each packet leaving 
the system

net.inet.ip.redirect=0 # do not send IP redirects
net.inet.ip.accept_sourceroute=0 # drop source routed packets since they 
can not be trusted
net.inet.ip.sourceroute=0 # if source routed packets are accepted the 
route data is ignored
#net.inet.ip.stealth=1 # do not reduce the TTL by one(1) when a packets 
goes through the firewall
net.inet.icmp.bmcastecho=0 # do not respond to ICMP packets sent to IP 
broadcast addresses
net.inet.icmp.maskfake=0 # do not fake reply to ICMP Address Mask 
Request packets
net.inet.icmp.maskrepl=0 # replies are not sent for ICMP address mask 
requests

net.inet.icmp.log_redirect=0 # do not log redirected ICMP packet attempts
net.inet.icmp.drop_redirect=1 # no redirected ICMP packets
#net.inet.icmp.icmplim=50 # 50 ICMP packets per second. a reasonable 
number for a small office.
#net.inet.tcp.delayed_ack=1 # always employ delayed ack, 6 packets get 1 
ack to increase bandwidth
net.inet.tcp.drop_synfin=1 # SYN/FIN packets get dropped on initial 
connection
net.inet.tcp.ecn.enable=1 # explicit congestion notification (ecn) 
warning: some ISP routers abuse it
net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly 
(helps against DoS, but may cause false RST)
net.inet.tcp.icmp_may_rst=0 # icmp may not send RST to avoid spoofed 
icmp/udp floods
net.inet.tcp.maxtcptw=15000 # max number of tcp time_wait states for 
closing connections
net.inet.tcp.msl=5000 # 5 second maximum segment life waiting for an ACK 
in reply to a SYN-ACK or FIN-ACK
net.inet.tcp.path_mtu_discovery=0 # disable MTU discovery since most 
ICMP packets are dropped by others
net.inet.tcp.rfc3042=0 # disable the limited transmit mechanism which 
can slow burst transmissions
#net.inet.tcp.sack.enable=1 # sack disabled? 
http://www.ibm.com/developerworks/linux/library/l-tcp-sack/index.html

net.inet.udp.blackhole=1 # drop udp packets destined for closed sockets
net.inet.tcp.blackhole=2 # drop tcp packets destined for closed ports
#net.route.netisr_maxqlen=4096 # route queue length defaults 4096 
(rtsock using "netstat -Q")

security.bsd.see_other_uids=0 # hide processes for root from user

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Fabricio Lima]

Repensando...

voce NAO precisa do 2o redirect...

quando um usuario na lan faz a requisiçao pra web, voce joga pro proxy.
ele agora vai receber, processar, e matar esta conexao
ele irá gerar uma nova conexao, a partir do IP dele, pra web...
e o fw vai rotear certinho.
Se voce bota um redirect nesta volta, pode induzir o reset.


Ou seja, use APENAS um redirect, e como meu email anterior, TRAVANDO a
origem:

pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from $LOCAL_LAN to
any port 80

isso jogará pro proxy
e ele trata o resto, e devolve pra estação.

[ ]'s
Fabricio Lima
When your hammer is C++, everything begins to look like a thumb.

Em 5 de novembro de 2014 14:27, Fabricio Lima 
escreveu:

> Um tiro no escuro... Mas não uso regras assim com any any em proxy
> transparente...
> Sao perigosas...
>
> Vamos travar sua origem da regra q intercepta as requisições pra jogar no
> proxy.
>
> Faz algo tipo:
>
> Pass from $lan_NET to any 80
>
> Tenta fazer isso no outro redirect tb. Ou vê se um só resolve.
> Tenta migrar pra ipfw e vê se o bug se apresenta
>
> Vou ler seu tcpdump antes de falar o proximo teste
>
> Fabricio
>
> Em quarta-feira, 5 de novembro de 2014, spiderslack <
> spidersl...@yahoo.com.br> escreveu:
>
> Ola pessoal.
>>
>> Se o assunto for off-topic me desculpe. Por nao se tratar especificamente
>> de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um
>> redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3
>> interfaces.
>>
>> 1 re0 - wan
>> 2 re1 - lan
>> 3 alc0 - rede do proxy
>>
>> Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O
>> endereço IP do proxy é 200.1.1.1(IP exemplo)
>>
>> pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any
>> port 80
>> pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80
>> to any
>>
>> A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz
>> testes tentando acessar o site da Cisco: 23.216.160.170):
>> *
>> **captura na re1**- LAN*
>>
>> 14:02:31.529558 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
>> (0x0800), length 74: 200.2.2.2.59297 > 23.216.160.170.80: Flags [S], seq
>> 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr
>> 0,nop,wscale 7], length 0
>> 14:02:31.529733 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
>> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.59297: Flags [S.], seq
>> 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val
>> 50571790 ecr 8945318,nop,wscale 7], length 0
>> 14:02:31.533785 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
>> (0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [.], ack 1,
>> win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0
>>
>> *Three way handshake feito*
>>
>> 14:02:32.181023 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
>> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], seq
>> 1894693316, ack 299551138, win 14480, options [mss 1460,sackOK,TS val
>> 2263835919 ecr 50571844,nop,wscale 5], length 0
>> 14:02:32.182614 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
>> (0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
>> 299551138, win 0, length 0
>> *
>> **Quando o site da cisco responde com SYN/ACK o cliente responde com um
>> Reset, ou seja não esta encaminhando a volta para o proxy minha regra de
>> volta não esta funcionando**. O que não entendo porque o cliente envia o
>> RST. Sera que ele considera uma nova conexão? e como nao tem three way
>> handshake feito ele reseta? E o processo ocorre algumas vezes enquanto o
>> cliente tenta*.
>>
>> 14:02:33.324284 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
>> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], seq
>> 1910248059, ack 299551138, win 14480, options [mss 1460,sackOK,TS val
>> 2263836914 ecr 50571944,nop,wscale 5], length 0
>> 14:02:33.325800 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
>> (0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
>> 299551138, win 0, length 0
>> 14:02:35.215487 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
>> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], seq
>> 28856710, ack 299551138, win 14480, options [mss 1460,sackOK,TS val
>> 2227668864 ecr 50572144,nop,wscale 5], length 0
>> 14:02:35.216626 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
>> (0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
>> 299551138, win 0, length 0
>> 14:02:35.668511 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
>> (0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [F.], seq
>> 112, ack 1, win 115, options [nop,nop,TS val 8949456 ecr 50571790], length 0
>> 14:02:35.668802 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
>> (0x0800), length 66: 23.216.160.170.80 > 200.2.2.2.59297: Flags [F.], seq
>> 1, ack 113, win 227, options [nop,nop,TS val 50572204 ecr 89

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Fabricio Lima]

Um tiro no escuro... Mas não uso regras assim com any any em proxy
transparente...
Sao perigosas...

Vamos travar sua origem da regra q intercepta as requisições pra jogar no
proxy.

Faz algo tipo:

Pass from $lan_NET to any 80

Tenta fazer isso no outro redirect tb. Ou vê se um só resolve.
Tenta migrar pra ipfw e vê se o bug se apresenta

Vou ler seu tcpdump antes de falar o proximo teste

Fabricio

Em quarta-feira, 5 de novembro de 2014, spiderslack <
spidersl...@yahoo.com.br> escreveu:

> Ola pessoal.
>
> Se o assunto for off-topic me desculpe. Por nao se tratar especificamente
> de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um
> redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3
> interfaces.
>
> 1 re0 - wan
> 2 re1 - lan
> 3 alc0 - rede do proxy
>
> Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O
> endereço IP do proxy é 200.1.1.1(IP exemplo)
>
> pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any
> port 80
> pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80
> to any
>
> A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz
> testes tentando acessar o site da Cisco: 23.216.160.170):
> *
> **captura na re1**- LAN*
>
> 14:02:31.529558 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
> (0x0800), length 74: 200.2.2.2.59297 > 23.216.160.170.80: Flags [S], seq
> 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr
> 0,nop,wscale 7], length 0
> 14:02:31.529733 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.59297: Flags [S.], seq
> 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val
> 50571790 ecr 8945318,nop,wscale 7], length 0
> 14:02:31.533785 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
> (0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [.], ack 1,
> win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0
>
> *Three way handshake feito*
>
> 14:02:32.181023 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], seq
> 1894693316, ack 299551138, win 14480, options [mss 1460,sackOK,TS val
> 2263835919 ecr 50571844,nop,wscale 5], length 0
> 14:02:32.182614 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
> (0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
> 299551138, win 0, length 0
> *
> **Quando o site da cisco responde com SYN/ACK o cliente responde com um
> Reset, ou seja não esta encaminhando a volta para o proxy minha regra de
> volta não esta funcionando**. O que não entendo porque o cliente envia o
> RST. Sera que ele considera uma nova conexão? e como nao tem three way
> handshake feito ele reseta? E o processo ocorre algumas vezes enquanto o
> cliente tenta*.
>
> 14:02:33.324284 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], seq
> 1910248059, ack 299551138, win 14480, options [mss 1460,sackOK,TS val
> 2263836914 ecr 50571944,nop,wscale 5], length 0
> 14:02:33.325800 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
> (0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
> 299551138, win 0, length 0
> 14:02:35.215487 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], seq
> 28856710, ack 299551138, win 14480, options [mss 1460,sackOK,TS val
> 2227668864 ecr 50572144,nop,wscale 5], length 0
> 14:02:35.216626 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
> (0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
> 299551138, win 0, length 0
> 14:02:35.668511 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
> (0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [F.], seq
> 112, ack 1, win 115, options [nop,nop,TS val 8949456 ecr 50571790], length 0
> 14:02:35.668802 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4
> (0x0800), length 66: 23.216.160.170.80 > 200.2.2.2.59297: Flags [F.], seq
> 1, ack 113, win 227, options [nop,nop,TS val 50572204 ecr 8949456], length 0
> 14:02:35.709774 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4
> (0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [.], ack 2,
> win 115, options [nop,nop,TS val 8949498 ecr 50572204], length 0
>
>
> *captura na alc0**- Interface onde o proxy esta conectado
> *
> 14:02:31.529573 00:1a:3f:b1:51:05 > 40:f2:e9:db:6b:23, ethertype IPv4
> (0x0800), length 74: 200.2.2.2.59297 > 23.216.160.170.80: Flags [S], seq
> 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr
> 0,nop,wscale 7], length 0
> 14:02:31.529726 40:f2:e9:db:6b:23 > 00:00:5e:00:01:0f, ethertype IPv4
> (0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.59297: Flags [S.], seq
> 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val
> 50571790 ecr 8945318,nop,wscale 7], length 0
> 14

[FUG-BR] [Off-topic] pf não redireciona com route-to

[spiderslack]

Ola pessoal.

Se o assunto for off-topic me desculpe. Por nao se tratar 
especificamente de FreeBSD. Mas axo já tentei de tudo. Estou tentando 
fazer um redirecionamento de porta 80 para um proxy. Tenho um FreeBSD 
com 3 interfaces.


1 re0 - wan
2 re1 - lan
3 alc0 - rede do proxy

Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O 
endereço IP do proxy é 200.1.1.1(IP exemplo)


pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any 
port 80
pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 
80 to any


A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz 
testes tentando acessar o site da Cisco: 23.216.160.170):

*
**captura na re1**- LAN*

14:02:31.529558 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4 
(0x0800), length 74: 200.2.2.2.59297 > 23.216.160.170.80: Flags [S], seq 
2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr 
0,nop,wscale 7], length 0
14:02:31.529733 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4 
(0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.59297: Flags [S.], 
seq 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS 
val 50571790 ecr 8945318,nop,wscale 7], length 0
14:02:31.533785 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4 
(0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [.], ack 
1, win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0


*Three way handshake feito*

14:02:32.181023 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4 
(0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], 
seq 1894693316, ack 299551138, win 14480, options [mss 1460,sackOK,TS 
val 2263835919 ecr 50571844,nop,wscale 5], length 0
14:02:32.182614 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4 
(0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq 
299551138, win 0, length 0

*
**Quando o site da cisco responde com SYN/ACK o cliente responde com um 
Reset, ou seja não esta encaminhando a volta para o proxy minha regra de 
volta não esta funcionando**. O que não entendo porque o cliente envia o 
RST. Sera que ele considera uma nova conexão? e como nao tem three way 
handshake feito ele reseta? E o processo ocorre algumas vezes enquanto o 
cliente tenta*.


14:02:33.324284 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4 
(0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], 
seq 1910248059, ack 299551138, win 14480, options [mss 1460,sackOK,TS 
val 2263836914 ecr 50571944,nop,wscale 5], length 0
14:02:33.325800 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4 
(0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq 
299551138, win 0, length 0
14:02:35.215487 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4 
(0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.24450: Flags [S.], 
seq 28856710, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 
2227668864 ecr 50572144,nop,wscale 5], length 0
14:02:35.216626 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4 
(0x0800), length 60: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq 
299551138, win 0, length 0
14:02:35.668511 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4 
(0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [F.], 
seq 112, ack 1, win 115, options [nop,nop,TS val 8949456 ecr 50571790], 
length 0
14:02:35.668802 00:1a:3f:b1:51:05 > 00:22:57:64:08:c5, ethertype IPv4 
(0x0800), length 66: 23.216.160.170.80 > 200.2.2.2.59297: Flags [F.], 
seq 1, ack 113, win 227, options [nop,nop,TS val 50572204 ecr 8949456], 
length 0
14:02:35.709774 00:22:57:64:08:c5 > 00:00:5e:00:01:0c, ethertype IPv4 
(0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [.], ack 
2, win 115, options [nop,nop,TS val 8949498 ecr 50572204], length 0



*captura na alc0**- Interface onde o proxy esta conectado
*
14:02:31.529573 00:1a:3f:b1:51:05 > 40:f2:e9:db:6b:23, ethertype IPv4 
(0x0800), length 74: 200.2.2.2.59297 > 23.216.160.170.80: Flags [S], seq 
2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr 
0,nop,wscale 7], length 0
14:02:31.529726 40:f2:e9:db:6b:23 > 00:00:5e:00:01:0f, ethertype IPv4 
(0x0800), length 74: 23.216.160.170.80 > 200.2.2.2.59297: Flags [S.], 
seq 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS 
val 50571790 ecr 8945318,nop,wscale 7], length 0
14:02:31.533789 00:1a:3f:b1:51:05 > 40:f2:e9:db:6b:23, ethertype IPv4 
(0x0800), length 66: 200.2.2.2.59297 > 23.216.160.170.80: Flags [.], ack 
1, win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0


*Three way handshake feito**
**Aqui noto que o proxy tenta sair creio que ele abre 2 conexão uma para 
o cliente outra para o server tipo como o modulo tproxy do linux/squid 
faz.**

*
14:02:32.070663 40:f2:e9:db:6b:23 > 00:00:5e:00:01:0f, ethertype IPv4 
(0x0800), length 74: 200.2.2.2.24450 > 23.216.160.170.80: Flags [S], seq 
299551137, win 29200, options [mss 1460,sackOK,TS val 5057184

Re: [FUG-BR] Hangout Entrevista com Renato Botelho: O futuro do pfSense!

[Jack]

Buenas!

>-Original Message-
>From: Neerlan Amorim
>
>Acabei de ouvir enquanto trabalhava.
>Show, precisamos mais disso ai!
>
>2014-11-05 11:48 GMT-04:00 mantunes :
>> Show.
>>

Legal Galera... Gracias pelos elogios e que com que gostaram!

A ideia básica é exatamente aproveitar um bate-papo informal e descontraído
para tratar de dúvidas comuns e genéricas sobre os projetos e tecnologias
que muita gente usa.

O Garga realmente se mostrou muito 'fotogênico'! :D



Abraços!

Jack
http://jack.eti.br
http://sys-squad.com
http://conexti.com.br

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Hangout Entrevista com Renato Botelho: O futuro do pfSense!

[Neerlan Amorim]

Acabei de ouvir enquanto trabalhava.
Show, precisamos mais disso ai!

2014-11-05 11:48 GMT-04:00 mantunes :
> Show.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd



-- 
Neerlan Amorim
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Hangout Entrevista com Renato Botelho: O futuro do pfSense!

[mantunes]

Show.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] Hangout Entrevista com Renato Botelho: O futuro do pfSense!

[Jack]

Buenas Lista!

Nesta terça-feira (04/11), a convite do Sys Squad, o amigo Renato Botelho
que é Engenheiro de Software na ESF (Electric Sheep Fencing LLC®) e,
portanto, faz parte do core team que desenvolve o pfSense®, participou de um
bate-papo descontraído e muito informativo.

Durante a conversa que durou um pouco mais de 1h30min, Garga (como também é
conhecido nas listas de discussões, fóruns e afins), falou sobre a evolução
do projeto pfSense® ao longo destes 10 anos, sobre a versão 2.2 que está às
vésperas de se tornar uma RC e o que esperar a médio e longo prazo da
ferramenta.

Para continuar lendo e acessar a gravação do hangout, basta seguir:
http://sys-squad.tumblr.com/post/101838224567/hangout-entrevista-com-renato-
botelho-o-futuro-do



Abraços!

Jack
http://jack.eti.br
http://sys-squad.com
http://conexti.com.br



-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd