Horrível? Acho que falta conhecimento seu sobre o assunto. Mikrotik é excelente, tanto é que no meu appliance eu troquei o confuso OPNsense pelo simples e rápido routerOS.
Firewall dele é horrível? É praticamente uma versão gráfica de um iptables da vida.
E mais, a maioria aqui não precisa de muita coisa de um firewall em uso doméstico, no máximo uma nat para algum equipamento interno e bloquear acesso externo indesejado.
Horrível? Acho que falta conhecimento seu sobre o assunto. Mikrotik é excelente, tanto é que no meu appliance eu troquei o confuso OPNsense pelo simples e rápido routerOS.
Firewall dele é horrível? É praticamente uma versão gráfica de um iptables da vida.
E mais, a maioria aqui não precisa de muita coisa de um firewall em uso doméstico, no máximo uma nat para algum equipamento interno e bloquear acesso externo indesejado.
Conheço muito bem o mk, e repito ele como firewall é horrível.
Propósito do routeros é ser um roteador de rede não um firewall.
Idem pfsense/opensense, eles são concebidos para serem firewall de rede e não roteadores.
A propósitos diferentes e cada um se sai melhor no seu propósito.
E falar que o pfsense é confuso de se configurar mas que o mk é mais fácil, realmente cada pessoa acha uma coisa, n vou entrar nessa discussão pq rapaz mexo com coisa pior pra configurar de vez em quando que se chama openwrt
SQM desligado, e Hardware e Software offloading ligado
Deu uma melhoradinha, bateu seus 650 a 700mbps...
Fiz o teste pelo Iperf entre rede, e não passa mais que 700 mbps... ,
Tem alguma coisa errada aí com a confiuguração do teu OpenWrt. Com SQM desligado deveria bater quase 1Gbps.
Tenho um R5S "sobrando" aqui, e só por curiosidade fiz um teste no final de semana. Coloquei o mesmo em "duplo NAT", ou seja, liguei a WAN dele na minha rede local, e liguei um laptop via ethernet Gigabit no R5S.
Com o servidor iperf3 na minha rede local (ou seja, atrás da WAN do R5S), abaixo os resultados do meu teste:
Tem alguma coisa errada aí com a confiuguração do teu OpenWrt. Com SQM desligado deveria bater quase 1Gbps.
Tenho um R5S "sobrando" aqui, e só por curiosidade fiz um teste no final de semana. Coloquei o mesmo em "duplo NAT", ou seja, liguei a WAN dele na minha rede local, e liguei um laptop via ethernet Gigabit no R5S.
Com o servidor iperf3 na minha rede local (ou seja, atrás da WAN do R5S), abaixo os resultados do meu teste:
Não fiz screencap, mas usei o HTOP para acompanhar. Algumas observações *com SQM*:
1. Com o "software offloading" desligado, fica tudo num core só (vai a 100%) e a velocidade de download cai para ˜450Mbps
2. Com o "software offloading" ligado, alguns outros cores passam a mostrar alguma carga agora, ainda assim a maior carga continua num core só (que vai a 100%) e a velocidade de download sobe um pouco para ˜540-590Mbps.
Mesmo assim, com o "software offloading" ligado, em alguns testes vi que a velocidade caia para ˜400Mbps. Acompanhando no htop, notei que nesses casos o SQM estava usando um LITTLE core ao invés de um BIG core (o core que vai a 100% durante o teste). Não sei dizer o motivo disso, já que os 4 cores do R5S são A55 (não é big.LITTLE).
Ou seja, teria que fazer algum tipo de finetuning no scheduler de CPU do OpenWrt para priorizar sempre o uso dos BIG cores para o SQM.
Não fiz screencap, mas usei o HTOP para acompanhar. Algumas observações *com SQM*:
1. Com o "software offloading" desligado, fica tudo num core só (vai a 100%) e a velocidade de download cai para ˜450Mbps
2. Com o "software offloading" ligado, alguns outros cores passam a mostrar alguma carga agora, ainda assim a maior carga continua num core só (que vai a 100%) e a velocidade de download sobe um pouco para ˜540-590Mbps.
Mesmo assim, com o "software offloading" ligado, em alguns testes vi que a velocidade caia para ˜400Mbps. Acompanhando no htop, notei que nesses casos o SQM estava usando um LITTLE core ao invés de um BIG core (o core que vai a 100% durante o teste).
Ou seja, teria que fazer algum tipo de finetuning no scheduler de CPU do OpenWrt para priorizar sempre o uso dos BIG cores para o SQM.
já ativou o packet steering? Esqueci onde exatamente fica essa opção
Há tempos atrás o @xShARkx postou tutorial de mexer com o IRQ do nano 4s pra melhorar o balanço de carga entre os núcleos.
Acho que pode ter sido a config de sqm que vc fez. Lembro que eu tinha realizado uma config com outros scripts que conseguia bater até 700 e poucos mb com SQM.
Acho que pode ter sido a config de sqm que vc fez. Lembro que eu tinha realizado uma config com outros scripts que conseguia bater até 700 e poucos mb com SQM.
Conheço muito bem o mk, e repito ele como firewall é horrível.
Propósito do routeros é ser um roteador de rede não um firewall.
Idem pfsense/opensense, eles são concebidos para serem firewall de rede e não roteadores.
A propósitos diferentes e cada um se sai melhor no seu propósito.
E falar que o pfsense é confuso de se configurar mas que o mk é mais fácil, realmente cada pessoa acha uma coisa, n vou entrar nessa discussão pq rapaz mexo com coisa pior pra configurar de vez em quando que se chama openwrt
Engraçado que nunca mexi em opn sense ou mikrotik, só mexi em openwrt, e sempre via os videos e achava mikrotik e opn sense e etc bem mais complicado.
:3
Eu não tenho bufferbloat significativo aqui (tanto Claro Fibra quanto Vivo Fibra), então não uso SQM (grade "A+" sem SQM na Claro Fibra).
No passado, com Claro HFC, o bufferbloat era tão ruim que quando um smartphone começava a fazer upload do rolo de câmera a internet caia aqui em casa (literalmente o download parava). Foi nessa época que eu usei o SQM. Mas mesmo assim nos últimos anos a Claro HFC melhorou bastante. Ainda tinha bufferbloat, mas pelo menos a internet não parava mais quando enchia o upload. Como não jogo, uns 50ms a mais ou a menos não fazia diferença na época do HFC, então foi quando desativei o SQM por aqui.
Mas se vc for usar SQM, recomendo o R4S, que tem uma CPU superior ao R5S (eu uso o R4S aqui, o R5S está sem uso). Ou então o R6S se teu orçamento permitir!
Então, fiz o teste, ativei novamente SQM, Deixei na opção cake/simplest_tbf.qos
E a velocidade dos 700mbps da internet, começou a chegar no meu pc, Voila!
1. SQM ativo (Setei em Download 710000kbps e Upload 105000kbps)
2. "Software Flow Offloading" Habilitado
3. "Packet Steering" Desabilitado
Devo desabilitar o Software Flow Offloading?
Tentei habilitar o Packet Steering não notei diferença alguma..
Muito obrigado por enquanto, me ajudou muito já.
Então, fiz o teste, ativei novamente SQM, Deixei na opção cake/simplest_tbf.qos
E a velocidade dos 700mbps da internet, começou a chegar no meu pc, Voila!
1. SQM ativo (Setei em Download 710000kbps e Upload 105000kbps)
2. "Software Flow Offloading" Habilitado
3. "Packet Steering" Desabilitado
Devo desabilitar o Software Flow Offloading?
Tentei habilitar o Packet Steering não notei diferença alguma..
Muito obrigado por enquanto, me ajudou muito já.
Então, fiz o teste, ativei novamente SQM, Deixei na opção cake/simplest_tbf.qos
E a velocidade dos 700mbps da internet, começou a chegar no meu pc, Voila!
1. SQM ativo (Setei em Download 710000kbps e Upload 105000kbps)
2. "Software Flow Offloading" Habilitado
3. "Packet Steering" Desabilitado
Devo desabilitar o Software Flow Offloading?
Tentei habilitar o Packet Steering não notei diferença alguma..
Muito obrigado por enquanto, me ajudou muito já.
Com o Flow Offloading habilitado pode desabilitar o SQM, pelo menos aqui o sqm perde total controle sobre a velocidade, tem até um aviso na aba firewall: Experimental feature. Not fully compatible with QoS/SQM.
Com o Flow Offloading habilitado pode desabilitar o SQM, pelo menos aqui o sqm perde total controle sobre a velocidade, tem até um aviso na aba firewall: Experimental feature. Not fully compatible with QoS/SQM.
Confirmo, testei na versão "snapshot" e o SQM funcionou de boa.
--- Post duplo é unido automaticamente: ---
Curiosidade (ou dica para quem usa Debian com ARM): tenho um OrangePi 5 (mesma CPU do R6S) que uso para coisas aleatórias que precisam Linux - o mesmo está rodando DietPi (derivado do Armbian/Debian) bootando direto de um SSD NVMe).
Costumo usar o speedtest CLI no Orange PI para testes de velocidade. Com a Vivo (600/300) sempre bateu o máximo (~630/315), mas como mudei para Claro (plano 500/250 mas recebo 700/350), o speedtest CLI no Orange PI não estava chegando nos 700Mbps (no R4S com OpenWrt que uso como roteador chega aos 700Mpbs):
Código:
root@opi5:~ # speedtest -s 24878
Speedtest by Ookla
Server: RSnetPOA - Porto Alegre (id: 24878)
ISP: Claro NET
Idle Latency: 2.45 ms (jitter: 0.15ms, low: 2.42ms, high: 2.97ms)
Download: 629.52 Mbps (data used: 638.5 MB)
3.76 ms (jitter: 1.35ms, low: 2.07ms, high: 8.62ms)
Upload: 352.90 Mbps (data used: 244.4 MB)
5.24 ms (jitter: 3.19ms, low: 2.40ms, high: 20.89ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/7c8a39d6-758e-4633-9860-e85e0b5d6131
Depois de muito quebrar a cabeça, finalmente descobri que o culpado é o "CPU governor" do DietPi, que por default vem como "schedutil":
Bastou eu mudar o "CPU Governor" para "ondemand" com algumas customizações adicionais que resolveu o problema:
Código:
root@opi5:~ # speedtest -s 24878
Speedtest by Ookla
Server: RSnetPOA - Porto Alegre (id: 24878)
ISP: Claro NET
Idle Latency: 2.93 ms (jitter: 0.21ms, low: 2.66ms, high: 3.10ms)
Download: 701.58 Mbps (data used: 534.0 MB)
2.69 ms (jitter: 0.49ms, low: 1.87ms, high: 8.04ms)
Upload: 353.32 Mbps (data used: 177.7 MB)
2.67 ms (jitter: 0.70ms, low: 1.68ms, high: 9.49ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/9a6faae0-c1ac-4f23-b3ba-2b281aeffe44
Confirmo, testei na versão "snapshot" e o SQM funcionou de boa.
--- Post duplo é unido automaticamente: ---
Curiosidade (ou dica para quem usa Debian com ARM): tenho um OrangePi 5 (mesma CPU do R6S) que uso para coisas aleatórias que precisam Linux - o mesmo está rodando DietPi (derivado do Armbian/Debian) bootando direto de um SSD NVMe).
Costumo usar o speedtest CLI no Orange PI para testes de velocidade. Com a Vivo (600/300) sempre bateu o máximo (~630/315), mas como mudei para Claro (plano 500/250 mas recebo 700/350), o speedtest CLI no Orange PI não estava chegando nos 700Mbps (no R4S com OpenWrt que uso como roteador chega aos 700Mpbs):
Código:
root@opi5:~ # speedtest -s 24878
Speedtest by Ookla
Server: RSnetPOA - Porto Alegre (id: 24878)
ISP: Claro NET
Idle Latency: 2.45 ms (jitter: 0.15ms, low: 2.42ms, high: 2.97ms)
Download: 629.52 Mbps (data used: 638.5 MB)
3.76 ms (jitter: 1.35ms, low: 2.07ms, high: 8.62ms)
Upload: 352.90 Mbps (data used: 244.4 MB)
5.24 ms (jitter: 3.19ms, low: 2.40ms, high: 20.89ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/7c8a39d6-758e-4633-9860-e85e0b5d6131
Depois de muito quebrar a cabeça, finalmente descobri que o culpado é o "CPU governor" do DietPi, que por default vem como "schedutil":
Bastou eu mudar o "CPU Governor" para "ondemand" com algumas customizações adicionais que resolveu o problema:
Código:
root@opi5:~ # speedtest -s 24878
Speedtest by Ookla
Server: RSnetPOA - Porto Alegre (id: 24878)
ISP: Claro NET
Idle Latency: 2.93 ms (jitter: 0.21ms, low: 2.66ms, high: 3.10ms)
Download: 701.58 Mbps (data used: 534.0 MB)
2.69 ms (jitter: 0.49ms, low: 1.87ms, high: 8.04ms)
Upload: 353.32 Mbps (data used: 177.7 MB)
2.67 ms (jitter: 0.70ms, low: 1.68ms, high: 9.49ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/9a6faae0-c1ac-4f23-b3ba-2b281aeffe44
Meu R5S com Openwrt só tem as opções de powersave, performance e schedutil, vou lembrar de habilitar os outros governos quando for fazer upgrade, obg por lembrar disso.
Meu R5S com Openwrt só tem as opções de powersave, performance e schedutil, vou lembrar de habilitar os outros governos quando for fazer upgrade, obg por lembrar disso.
Acredito que isso seja específico do Debian/Armbian rodando em ARM. No R4S com OpenWrt chegou nos 700Mbps sem nenhuma configuração adicional, vou ver se descubro qual o default.
EDITADO: no OpenWrt o "schedutil" é o CPU Governor default. Porém diferentemente do DietPi, o OpenWrt atinge 700Mbps no speedtest mesmo com esse governor. Provavelmente o OpenWrt está mais "tunado" para performance de rede:
Código:
BusyBox v1.35.0 (2023-04-09 12:27:46 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 22.03.4, r20123-38ccc47687
-----------------------------------------------------
root@router:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
schedutil
root@router:~# speedtest
Speedtest by Ookla
Server: Claro net vírtua - Porto Alegre (id: 14143)
ISP: Claro NET
Idle Latency: 1.10 ms (jitter: 0.22ms, low: 0.72ms, high: 1.34ms)
Download: 699.46 Mbps (data used: 457.1 MB)
1.52 ms (jitter: 0.58ms, low: 0.88ms, high: 3.00ms)
Upload: 352.45 Mbps (data used: 278.9 MB)
1.77 ms (jitter: 4.37ms, low: 1.06ms, high: 220.76ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/683b1086-eeaa-4605-8e05-c2375aab633b
root@router:~#
Acredito que isso seja específico do Debian/Armbian rodando em ARM. No R4S com OpenWrt chegou nos 700Mbps sem nenhuma configuração adicional, vou ver se descubro qual o default.
EDITADO: no OpenWrt o "schedutil" é o CPU Governor default. Porém diferentemente do DietPi, o OpenWrt atinge 700Mbps no speedtest mesmo com esse governor. Provavelmente o OpenWrt está mais "tunado" para performance de rede:
Código:
BusyBox v1.35.0 (2023-04-09 12:27:46 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 22.03.4, r20123-38ccc47687
-----------------------------------------------------
root@router:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
schedutil
root@router:~# speedtest
Speedtest by Ookla
Server: Claro net vírtua - Porto Alegre (id: 14143)
ISP: Claro NET
Idle Latency: 1.10 ms (jitter: 0.22ms, low: 0.72ms, high: 1.34ms)
Download: 699.46 Mbps (data used: 457.1 MB)
1.52 ms (jitter: 0.58ms, low: 0.88ms, high: 3.00ms)
Upload: 352.45 Mbps (data used: 278.9 MB)
1.77 ms (jitter: 4.37ms, low: 1.06ms, high: 220.76ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/683b1086-eeaa-4605-8e05-c2375aab633b
root@router:~#
Não fiz screencap, mas usei o HTOP para acompanhar. Algumas observações *com SQM*:
1. Com o "software offloading" desligado, fica tudo num core só (vai a 100%) e a velocidade de download cai para ˜450Mbps
2. Com o "software offloading" ligado, alguns outros cores passam a mostrar alguma carga agora, ainda assim a maior carga continua num core só (que vai a 100%) e a velocidade de download sobe um pouco para ˜540-590Mbps.
Mesmo assim, com o "software offloading" ligado, em alguns testes vi que a velocidade caia para ˜400Mbps. Acompanhando no htop, notei que nesses casos o SQM estava usando um LITTLE core ao invés de um BIG core (o core que vai a 100% durante o teste). Não sei dizer o motivo disso, já que os 4 cores do R5S são A55 (não é big.LITTLE).
Ou seja, teria que fazer algum tipo de finetuning no scheduler de CPU do OpenWrt para priorizar sempre o uso dos BIG cores para o SQM.
Eu não tenho bufferbloat significativo aqui (tanto Claro Fibra quanto Vivo Fibra), então não uso SQM (grade "A+" sem SQM na Claro Fibra).
No passado, com Claro HFC, o bufferbloat era tão ruim que quando um smartphone começava a fazer upload do rolo de câmera a internet caia aqui em casa (literalmente o download parava). Foi nessa época que eu usei o SQM. Mas mesmo assim nos últimos anos a Claro HFC melhorou bastante. Ainda tinha bufferbloat, mas pelo menos a internet não parava mais quando enchia o upload. Como não jogo, uns 50ms a mais ou a menos não fazia diferença na época do HFC, então foi quando desativei o SQM por aqui.
Mas se vc for usar SQM, recomendo o R4S, que tem uma CPU superior ao R5S (eu uso o R4S aqui, o R5S está sem uso). Ou então o R6S se teu orçamento permitir!
--- Post duplo é unido automaticamente: ---
Eu só tenho o Redmi AX6S, mas uso só como access point...
tenho claro hfc, até que a internet é boa e já sofri muito com a vivo. O jeito é esperar o r4s chegar e dar uma chance, o meu roteador wdr4300 tem 10 anos.
testes em carga:
arris:
Estatísticas do Ping para 8.8.8.8:
Pacotes: Enviados = 17, Recebidos = 17, Perdidos = 0 (0% de
perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 20ms, Máximo = 118ms, Média = 63ms
wdr4300
Estatísticas do Ping para 8.8.8.8:
Pacotes: Enviados = 18, Recebidos = 18, Perdidos = 0 (0% de
perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 21ms, Máximo = 263ms, Média = 96ms
