Anúncio do HT Forum

Clube do DD-WRT / OpenWRT / Etc.

Discussão em 'Informática' iniciada por _dsouza_, 19 Mar 2017.

  1. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    Anúncio do HT Forum
    É o que estou sabendo também. Parece que as tentativas de se criar um "NAT6" viável não vingaram (ou não foi adotado na prática, não sei), ainda bem!

    Quanto ao endereço fe80, veja que se trata de um endereço de link local (não é o típico IP privado de rede interna, ULA, diga-se), aparentemente necessário para se realizar funções de comunicação entre roteadores ou nodos (????) e não para, efetivamente, transferir os dados. É a impressão que tenho depois de ler muito pouco sobre isso, mas não tenho certeza:

    https://en.m.wikipedia.org/wiki/Reserved_IP_addresses#IPv6

    Esses endereços fe80 também sempre são disponibilizados. Eu os tinha em todas as interfaces, mesmo quando estava sem conexão ipv6 e com a configuração toda errada. Aparentemente é uma exigência.

    Acho que o firewall não mudará muito (claro, exceto pelo fato que não há regras de tradução NAT). Também não vi, mas estou esperando apenas regras normais ACCEPT, REJECT, FORWARD etc., mandando de interface para interface e sem traduzir por NAT. Terminei tarde ontem, então não tive tempo, mas qualquer hora dessas dou uma olhada também.

    Vale lembrar que na página de administração, as regras de firewall continuam idênticas (DROP na wan, por exemplo), por isso que digo isso.

    Será interessante ver os arquivos de configuração, pois esses costumam ser bem mais detalhados e fornecem mais detalhes dá coisa toda. Comprometo-me a mais tarde dar uma olhada nisso e postar aqui.

    [']s!
     
    • 1
  2. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Bem, comecei minha leitura de IPv6 firewall. Até então confirmado meu entendimento, não tem NAT com IPv6 (óbvio) e o roteador é "apenas" um roteador.

    Dessa maneira é importante configurar um "stateful firewall" no roteador para IPv6, caso contrário os dispositivos serão expostos à internet pública com IPv6 (e aí depende do firewall de cada dispositivo). Nos *WRT da vida, normalmente o firewall utilizado é o "iptables" (padrão do Linux).

    O que me preocupou foi o comentário abaixo na Wiki do DD-WRT:

    Sinceramente acho que essa documentação está desatualizada, vou tentar confirmar. Na dúvida estou deixando o IPv6 desabilitado, pois não me sinto confortável em ter minha rede interna exposta à internet sem firewall.

    Sobre o OpenWRT, aparentemente as versões mais recentes (da "Barrier Breaker" em diante) já incluem por default um firewall IPv6:

     
    • 1
  3. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Como eu imaginava, a documentação do DD-WRT está desatualizada.

    Achei um post no fórum do DD-WRT que explica em mais detalhes.

    No próximo final de semana vou habilitar novamente o IPv6 e farei alguns testes adicionais via CLI para confirmar que as configurações do firewall da UI do DD-WRT estão sendo refletidas de fato no ip6tables:

     
    • 1
  4. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    Vou aproveitar e coloca as partes relevantes dos arquivos de config.

    De antemão, já vi algumas diferenças quanto ao tratamento adequado de alguns pacotes ICMP. Aparentemente, o melhor funcionamento do IPv6 passa pelos roteadores tratarem ativamente esses pacotes da melhor forma [1, 2 e 3].

    Corrijam-me se estiver errado, mas a ideia que estou tendo é que caminharemos, gradualmente, para uma prática de segurança aberta, em que a prática de ignorar requisições para tentar se manter silente ("STEALTH") será abandonada para se ignorar apenas chamadas desnecessárias (portas específicas deverão continuar silentes), mantendo o roteador vivo e visível na Internet para essas chamadas de manutenção (ICMPv6).

    A impressão que tenho é que, no IPv6, roteadores domésticos têm uma importância bem maior na composição de gateways do que possuem no IPv4 (até porque deixaram de ser meros roteadores de um computador apenas, como já foi no passado: hoje todos têm vários equipamentos em casa).

    Um dos efeitos mais visíveis disso é que, por exemplo, testes como o do Shields-Up talvez sejam atualizados para refletir essa nova proposta e não mais marcar como "falho" um teste em que tudo está silente mas o roteador responde requisições ICMP.

    Novamente, se minha ideia preliminar estiver correta, será bastante interessante ver como essa discussão caminhará junto à segurança do firmware dos roteadores, algo que já mencionamos. Não que eu defenda algum tipo de segurança por obscuridade (nem sei se a expressão é apropriada aqui), mas será algo interessante de acompanhar, NMHO.

    /etc/config/dhcp (omitida a parte de DHCP estático, "config host")
    Código:
    config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
    
    config dhcp 'lan'
        option interface 'lan'
        option leasetime '23h'
        option start '201'
        option limit '39'
        option ra 'server'
    
    config dhcp 'wan'
        option interface 'wan'
        option ignore '1'
    
    config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
    /etc/config/network
    Código:
    config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'
    
    config globals 'globals'
        option ula_prefix '<OMITIDO>'
    
    config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.0.254'
        option gateway '192.168.0.254'
        option broadcast '192.168.0.255'
        option ip6assign '60'
    
    config interface 'wan'
        option ifname 'eth0.2'
        option _orig_ifname 'eth0.2'
        option _orig_bridge 'false'
        option proto 'dhcp'
        option peerdns '0'
        option dns '208.67.220.220 208.67.222.222'
    
    config interface 'wan6'
        option ifname '@wan'
        option _orig_ifname '@wan'
        option _orig_bridge 'false'
        option proto 'dhcpv6'
        option reqprefix '64'
        option reqaddress 'try'
        option peerdns '0'
        option dns '2620:0:ccd::2 2620:0:ccc::2'
    
    config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'
    
    config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 5t'
    
    config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0 5t'
    /etc/config/firewall
    Código:
    config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'
    
    config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'
    
    config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fe80::/10'
        option src_port '547'
        option dest_ip 'fe80::/10'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'
    
    config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'
    
    config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'
    
    config defaults
        option syn_flood '1'
        option output 'ACCEPT'
        option drop_invalid '1'
        option input 'ACCEPT'
        option forward 'REJECT'
    
    config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
    
    config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option output 'ACCEPT'
        option masq '1'
        option mtu_fix '1'
        option input 'DROP'
        option forward 'DROP'
    
    config forwarding
        option src 'lan'
        option dest 'wan'
    
    config include
        option path '/etc/firewall.user'
    
    config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp udp'
        option src_dport '<OMITIDO>'
        option dest_ip '192.168.0.1'
        option dest_port '<OMITIDO>'
        option name 'bittorrent-1'
    
    config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp udp'
        option src_dport '<OMITIDO>'
        option dest_ip '192.168.0.4'
        option dest_port '<OMITIDO>'
        option name 'bittorrent-4'
     
    Última edição: 21 Mar 2017
    • 1
  5. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    @placard@placard, eu ainda defendo o uso de firewall, mesmo em IPv6. Ou seja, só entra na minha rede o que eu permitir. Já para as conexões de dentro para fora, aí tá valendo (é o famoso "stateful firewall").

    O que acontece normalmente em IPv4 é que normalmente se confunde NAT com Firewall. Num NAT, apenas o IP público do roteador é visível, já com IPv6 todos os IPs são públicos. Nesse aspecto concordo contigo que a "seguranço por obfuscação" implícita no NAT não funciona mais com IPv6 (justamente por não ter mais NAT).

    Por outro lado, mesmo IPv4 já usávamos o firewall, e entendo que esse deve continuar sendo usado com IPv6.

    A questão do ICMP é interessante, já que no IPv4 normalmente o mesmo era desabilitado para a Internet ("stealth" de fora para dentro), e para IPv6 parece ser norma deixar o mesmo habilitado, já que o correto funcionamento do IPv6 depende do ICMP (http://blogs.cisco.com/security/icmp-and-security-in-ipv6).

    Tem outro artigo antigo mas interessante e generalista sobre o assunto em https://arstechnica.com/gadgets/2007/05/ipv6-firewall-mixed-blessing/

    (y)
     
    • 1
  6. fcc

    fcc Powered by HK.


    Desde 18 Mai 2004
    ES - Vila Velha
    Pessoal,

    Sou totalmente noob nesses detalhes que vcs estão falando acima. Mas tentando entender.

    Uma dúvida. O firmware alternativo, além das muitas opções de controle da rede, melhoram o sinal e consequentemente a entrega da velocidade? Ou não?
     
  7. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    Isso é um assunto um pouco mais complexo para mim, mas suponho que sim, eu também jamais dispensaria o firewall (e sim, estou plenamente ciente da distinção em relação ao NAT). O artigo da CISCO foi exatamente o que citei acima. Já o do ARS sintetiza bem minha preocupação:

    Acho que uma boa resposta seria: deveriam, mas não funcionam sempre. Por exemplo, acho mais fácil (além de uma solução mais elegante) ter regras de firewall configuradas no roteador do que em cada aparelho interno separadamente. Isso sem falar que é muito comum nossos computadores terem vários serviços rodando, e nem sempre sabemos as potenciais falhas de segurança deles.

    Um exemplo que me ocorreu agora: o adb funciona na porta 5555/5554, abrindo-se para conexões de entrada. Sei lá se existe alguma falha a ser explorada? Suponho que seja bem mais seguro que as conexões sequer cheguem no meu computador, e parem no firewall do roteador, quando eu estou em casa usando o adb. Um exemplo apenas.

    Se fosse chutar, diria que é possível que as pessoas em geral possam estar confundindo ter "One and Only" Internet globalmente roteável em teoria, cuja prática estaria limitada apenas por decisões dos administradores e não por limitações técnicas (número de IPs, pra citar a mais óbvia), com a necessidade de se ter todo e cada aparelho conectado numa rede IP acessível globalmente, necessariamente, o que está longe de ser o caso do ipv6. É uma utilidade, mas não uma necessidade. Firewalls servem justamente quando não é desejável, ou não?

    Nem penso que as medidas de segurança já implementadas no próprio ipv6 neguem essa conclusão.

    Quanto ao meu ponto original, ainda o tenho: será interessante ver como falhas dos roteadores (um dos assuntos que deu origem ao tópico) irá impactar usuários uma vez que eles estarão acessíveis 24/7 numa Internet cujos riscos de segurança estão cada vez mais profissionalizados, onde cada vez mais serviços são usados e cada vez mais aparelhos igualmente frágeis (smartphone TVs, smart torradeiras...) estão conectados neles.

    Dito de outra forma: se até certo ponto era interessante ser 100% stealth e "voar baixo" no ipv4, é preciso ser mais robusto e seguro para "voar alto" numa realidade (ipv6) que exige maior publicidade (respostas e coordenação) para garantir um roteamento mais eficiente.

    Enfim, vou acompanhar mais...
     
    • 2
  8. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Esses firmware permitem em alguns casos aumentar a potência de transmissão, aumentando o alcance. Mas em termos de desempenho e velocidade no geral são similares aos originais de fábrica. Porém são mais sujeitos à bugs e instabilidades, portanto a troca do firmware na minha opinião vale à pena somente caso você estiver buscando funcionalidades mais avançadas...
     
    • 2
  9. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    @fcc@fcc

    A questão da potência de transmissão é algo bem complicado, pois além da discussão ser bastante técnica, e exigir demonstrações especializadas, ainda existe muito placebo.

    Há aqueles que não permitem nenhuma alteração. Há aqueles que são placebo, permitindo a configuração mas comportando-se internamente da mesma forma (pois a placa tem limites legislativos do país onde é vendida embutidos no firmware do rádio). Outros permitem alteração, mas apenas até certo limite, comportando-se como placebo acima disso.

    Mesmo que você aumente a potência, nem sempre terá um aumento de alcance útil, podendo até diminuir esse alcance. Se o rádio foi desenhado para uma faixa específica de potência (e há os baratos e caros), aumentar a potência pode aumentar bem mais proprocionalmente o nível de ruído, gerando um sinal de mais baixa qualidade (já vi gente nos fórums do OpenWrt fazendo essas medições). Além disso, aumentar a potência pode exigir uma melhor antena, e aí vai depender do hardware conseguir utilizar bem a antena (novamente, os resultados dependem via de regra da qualidade e 'força' do rádio). Finalmente, mesmo colocando uma antena melhor pode resultar numa captação maior de alguma rede de background, gerando mais sinal que deve ser filtrado (floor noise) e novamente depende do eequipamento.

    Certo é que aparelhos costumam ser testados tal como vendidos. Fora disso você está praticamente em um território virgem cheio de variáveis para se medir e controlar.

    Voltando ao assunto anterior, rapidamente, hoje de noite fiz o primeiro teste de uma funcionalidade bem "IPv6": abri um site de PING reverso e digitei o endereço IPv6 do meu celular, que está conectado atrás do meu roteador via WiFi. O celular respondeu a todas as requisições, ou seja, minha rede interna é globalmente roteável. Pacotes ICMP estão passando, IPs globais individuais, mas serviços de portas estão bloqueados via firewall.

    [']s!
     
    • 3
  10. fcc

    fcc Powered by HK.


    Desde 18 Mai 2004
    ES - Vila Velha
    Valeu @_dsouza_@_dsouza_ e @placard@placard.

    Já quase instalei uma vez mas deixei quieto.

    Como meu wifi andou caindo bastante e esse tópico surgiu, resolvi perguntar.

    Mudei canal para um menos usado e descobri que meu cabo estava ruim, intermitente, e isso gerava queda da Internet também.

    Consegui resolver os 2.
     
  11. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Abaixo as regras default do firewall de IPv6 do DD-WRT. Conheço apenas superficialmente a parametrização de linha de comando do iptables/ip6tables, preciso olhar a documentação para traduzir o que isso significa.

    Código:
    root@tplink-sala:~# ip6tables --list
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     0        anywhere             anywhere           state RELATED,ESTABLISHED
    ACCEPT     ipv6-icmp    anywhere             anywhere
    ACCEPT     0        fe80::/64            anywhere
    ACCEPT     0        anywhere             anywhere
    DROP       0        anywhere             anywhere
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     0        anywhere             anywhere           state RELATED,ESTABLISHED
    ACCEPT     0        anywhere             anywhere
    ACCEPT     ipv6-icmp    anywhere             anywhere           ipv6-icmp echo-request limit: avg 2/sec burst 5
    DROP       0        anywhere             anywhere
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    
     
    • 1
  12. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    @_dsouza_@_dsouza_ tente a flag de print ao invés de list. Para o propósito de apenas mostrar as regras ativas do sistema no momento é visualmente melhor, NMHO (e também acho mais fácil de entender, algumas ficam até autoexplicativas apenas de se ver). A listagem de chains é mais pra quem quer ver as categorias individualizadas para entendê-las e modificar seu funcionamento.
     
    • 1
  13. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Não achei a flag de "print", acho que não existe, pelo menos não no comando "ip6tables" do DD-WRT (ver abaixo).

    Em tempo: usei o SpeedTest com IPv6 habilitado. No servidor que costumo usar, tive uma queda drástica de performance. Acho que as rotas do IPv6 são diferentes (e mais longas?) do que o IPv4, até o ping foi bem mais demorado (é como se tivesse entrado numa rota internacional para depois voltar para o Brasil, onde está o servidor que uso). Até que eu consiga confirmar isso vou deixar o IPv6 desabilitado por enquanto...

    (y)

    Código:
    root@tplink-sala:~# ip6tables --help
    ip6tables v1.3.7
    
    Usage: ip6tables -[AD] chain rule-specification [options]
           ip6tables -[RI] chain rulenum rule-specification [options]
           ip6tables -D chain rulenum [options]
           ip6tables -[LFZ] [chain] [options]
           ip6tables -[NX] chain
           ip6tables -E old-chain-name new-chain-name
           ip6tables -P chain target [options]
           ip6tables -h (print this help information)
    
    Commands:
    Either long or short options are allowed.
      --append  -A chain            Append to chain
      --delete  -D chain            Delete matching rule from chain
      --delete  -D chain rulenum
                                    Delete rule rulenum (1 = first) from chain
      --insert  -I chain [rulenum]
                                    Insert in chain as rulenum (default 1=first)
      --replace -R chain rulenum
                                    Replace rule rulenum (1 = first) in chain
      --list    -L [chain]          List the rules in a chain or all chains
      --flush   -F [chain]          Delete all rules in  chain or all chains
      --zero    -Z [chain]          Zero counters in chain or all chains
      --new     -N chain            Create a new user-defined chain
      --delete-chain
                -X [chain]          Delete a user-defined chain
      --policy  -P chain target
                                    Change policy on chain to target
      --rename-chain
                -E old-chain new-chain
                                    Change chain name, (moving any references)
    Options:
      --proto       -p [!] proto    protocol: by number or name, eg. `tcp'
      --source      -s [!] address[/mask]
                                    source specification
      --destination -d [!] address[/mask]
                                    destination specification
      --in-interface -i [!] input name[+]
                                    network interface name ([+] for wildcard)
      --jump        -j target
                                    target for rule (may load target extension)
      --match       -m match
                                    extended match (may load extension)
      --numeric     -n              numeric output of addresses and ports
      --out-interface -o [!] output name[+]
                                    network interface name ([+] for wildcard)
      --table       -t table        table to manipulate (default: `filter')
      --verbose     -v              verbose mode
      --line-numbers                print line numbers when listing
      --exact       -x              expand numbers (display exact values)
      --modprobe=<command>          try to insert modules using this command
      --set-counters PKTS BYTES     set the counter during insert/append
    [!] --version   -V              print package version.
    root@tplink-sala:~#
    
     
    • 1
  14. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    Correto, deve ser alguma omissão do ip6tables do DD então (versão mais antiga talvez?).

    [']s!
     
  15. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Pois é, a versão do ip6tables do DD-WRT é a 1.3.7, que é bem antiga (de 2006?!?). A versão mais recente é a 1.6.1 (http://www.netfilter.org/projects/iptables/downloads.html).

    EDITADO: achei a manpage do ip6tables 1.6.0 aqui. A única oção diferente que achei foi a "--list-rules", é essa que vc usa?

    (y)
     
  16. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    Sim, sim, essa mesmo. (y)

    Quanto à versão muito antiga, talvez fosse apropriado dar uma olhada para ver se há muitas vulnerabilidades. Novamente, é uma das procurações centrais do tópico. Vou até ver qual é a minha.

    [']s!
     
    • 1
  17. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    A minha é a 1.4.21, afetada por uma vulnerabilidade que, pelo que vi superficialmente (não entendo de iptables, muito menos de sua segurança), tem seus efeitos mitigados caso se tenha um kernel > [3.0–3.13.2]. No caso tenho o 3.18.23.
     
    Última edição: 23 Mar 2017
  18. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Estou usando o build r30082 do DD-WRT no Archer C7 já faz tempo (bastante estável). Mas é um build já antigo, de Julho/2016.

    Tenho acompanhado o fórum do DD-WRT, e os builds desde então estão instáveis. Tiveram comentários que os últimos builds estariam mais estáveis, e resolvi atualizar e testar o build r31690 ontem. Depois do upgrade, resetei todas as configurações e configurei tudo do zero de novo.

    A princípio estava tudo OK, porém de início o Fire Stick TV teve alguns problemas na conexão via Wifi na banda de 5GHz. Refiz a configuração e funcionou.

    No entanto hoje meu laptop simplesmente não conecta mais o Wifi em 5GHz no Archer C7. Por default, acaba pegando sempre um sinal mais fraco de outro AP meu em outro cômodo. Testei várias coisas não resolveu.

    Voltei agora para o build antigo (r30082) e tudo voltou ao normal.

    Em resumo: é esse tipo de coisa que incomoda um pouco com os builds do DD-WRT. É sempre um desafio achar um build estável e confiável. O problema é que nos últimos meses todos os builds novos estão com problemas de estabiliadde no Wifi de 5GHz e acabo voltando para um build que já está meio antigo... :(
     
    • 1
  19. placard

    placard Usuário

    7.810 4.116 811

    Desde 29 Mai 2008
    SBJP
    Por que não pega algum tempo livre e tenta o OpenWrt? Vi aqui que a maior parte das versões do C7 são bem suportadas. Alguns ajustes, alguns pacotes que precisam ser instalados após instalar o firmware, mas nada demais ou difícil, muito menos para você.

    E qualquer coisa eu posso tentar ajudar, caso eu saiba claro.
     
    • 1
  20. _dsouza_

    _dsouza_ Lost in time

    9.340 3.221 811

    Desde 4 Set 2008
    Porto Alegre
    Depois da experiência de ontem pensei sim em experimentar o OpenWRT. Vou ler um pouco mais e ver se me aventuro... :) (y)
     
  1. Usamos cookies próprios e de terceiros para dar um melhor serviço e mostrar publicidade. Ao continuar, aceita o seu uso.
    Fechar Aviso