Linio Alan

Mega eu acho que no caso dela a Oi é bem complicada nessas questões, como eles são os únicos com um tipo de serviço em uma região, o assédio moral pra cima dos clientes na hora de 'desmembrar' serviços como você propõe se torna um verdadeiro calvário, isso acontece até aqui em SP quiçá no RJ, bom mas aí só a Jacqueline pra confirmar melhor. No caso da Cloud, entendo que é mais vantajoso do ponto de vista de acessibilidade, o SLA de uptime (disponibilidade) na Cloud costuma ser 99,999% no mínimo e isso contratualmente, então seria algo mais atrativo, dificilmente alguma operadora conseguiria implicar nesse sentido, pois o IP público na Cloud pertence ao datacenter e não à operadora. Desculpe não entendi a parte do "...considere um proxy ou uma VPN" seria no sentido de usar isso no anúncio do servidor de emails? Se for isso então não se aplica, o IP público vinculado ao servidor à princípio não pode ter mascaramento, não neste cenário.

Se você usa Exchange Server ou qualquer outro servidor de email vale mais a pena então considerar alocar esse servidor na Cloud mesmo (Azure, AWS) você ganha em desempenho, provável redução de custo e não fica mais refém de nenhuma operadora, e ainda pode manter a Oi pra telefonia. Considere fortemente migrar seu servidor de email pra nuvem.

Se for apenas por apenas por causa dos telefones então é como o @Mega Blaster disse, portabilidade está aí pra isso, é direito seu e dever da operadora mesmo em se tratando de linha fixa já que atualmente a telefonia das operadoras é tudo baseado em redes SDN e rede comutada por pacotes e não mais por circuito, isso flexibilizou enormemente as possibilidades ao consumidor final. Bem mais fácil conseguir um novo IPv4 público migrando inclusive sua telefonia do que dar murro em ponta de faca com operadora. Outra coisa é que se a saída da OI é algo impensável pelo menos no curto prazo então ainda te resta a contratação de outro link ou ainda dependendo do tipo de serviço atrás desse IP público, começar em migrar para a Cloud.

Olá Jacqueline Como diz o ditado popular: "o buraco é mais embaixo": Você vai precisar fazer alguns contatos com provedores e autoridades pra sanar o problema, não é um processo simples e é o único até onde consigo compreender. Obs.: talvez você queira omitir lá no seu print o IP blacklisted, ainda está aparecendo no description.

Ah então o caso é mais complexo, vi ali que você mencionou que usa o Omada TP-Link, ou seja, provavelmente você possui uma malha de APs sincronizados e os usuários todos conectados nesses APs, certo? Aí é caso até pra consultoria pra ser honesto já que se trata de uma solução empresarial, digo não minha mas da própria TP-Link pois se trata de sistema corporativo com garantia. Mas em linhas gerais, o ideal é que você tenha a mais absoluta certeza de que a 'uplink' do switch que conecta os APs seja Giga-Ethernet e de que não há gargalo nem na sua rede interna, desde gargalo de interface de rede ou do seu link de saída pra internet, garantindo isso, é necessário que você acompanhe se não está havendo gargalo de hardware dos equipamentos como: processamento alto, consumo de memória ou armazenamento alto (alguns devices tem armazenamento dependendo). Enfim é um trabalho amplo e complexo que demanda tempo de investigação preferencialmente in loco. Mas como o amigo @claudineybm mencionou ali, pode sim ser um algo consumo devido backups automaticos, mas eu acredito particularmente se fosse isso, a lentidão da rede diminuiria muito antes das 13hs que é o horário que você mencionou, e "coincidentemente" é o horário de almoço do pessoal lembrando que mesmo funcionários muitas vezes usam bastante banda com mídias e videos online de diversas fontes, por razões pessoais ou mesmo profissionais.

Entendi, poste qual erro de conexão está ocorrendo, bem como a saída para cada um dos comandos abaixo: iptables --list | grep port 1883 iptables -L Só para termos certeza de que não se trata de algum problema realmente de bloqueio. Em tempo: dê uma olhada NESTE outro tutorial aqui, ele ainda tem pacotes Linux de instalação do MQTT Explorer, em não se tratando de falha de conexão eu lhe recomendaria remover tudo e reinstalar os pacotes e as configs. iptables -I INPUT -p tcp --dport 1883 -j ACCEPT iptables -I OUTPUT -p tcp --sport 1883 -j ACCEPT service iptables save E não menos importante, checar o status do firewall nativo do Linux: sudo systemctl status firewalld Poste em sua próxima mensagem a saída para todos esses comandos.

Provavelmente algo nas configurações sim, até onde entendi a conexão entre eles se dá pelo IP de localhost (127.0.0.1) então à menos que algum firewall ou outro bloqueio esteja impedindo conexões no localhost (muito difícil) então é algo ou nas configurações dos dois programas ou o próprio. Você seguiu qual tutorial pra instalar isso? Já havia feito funcionar em algum outro momento?

@Eduardo_Braz quantos usuários no total ficam online ao mesmo tempo na sua rede? Equipamentos de rede tem um limite quanto à quantidade de usuários para funcionar de forma adequada, no seu caso aparentemente o equipamento de rede está sobrecarregando e, como tal, o desempenho geral fica prejudicado, fazendo subir a latência e aumentando perda de pacotes (sobrecarga significa processador operando muito acima do seu limiar de trabalho, maior uso de memória e consumo energético). Em se confirmando o cenário acima, significa que é hora para alguns upgrades de hardware/equipamento.

Percebi que as funções voltaram hoje, creio que está resolvido agora

No Reclame Aqui teve usuário que afirmou categoricamente que a NordVPN só tem servidores em SP, a empresa não desmentiu o usuário, veja reclamação AQUI. Mas de fato, não me recordo de nenhum provedor de VPN oferecendo essa granularidade com relação à servidores em território brasileiro, isso ocorre apenas com servidores nos EUA com o Kaspersky VPN e mesmo assim para um número limitado de estados. No seu caso, em havendo necessidade de realmente ter um servidor especificamente dentro da WWAN no RJ, então eu te sugiro subir um servidor com OpenVPN numa instância/VM da Azure ou AWS e escolher o RJ como local para deployment, assim você tem total controle tanto do seu tráfego quanto do próprio servidor: https://datacenters.microsoft.com/globe/explore?info=pop_RIO02 Este Vídeo aqui ensina a subir o seu servidor OpenVPN (embora ensine baseado na cloud da AWS você ainda assim transfere os conceitos para Azure e o principal, como realizar as configurações do servidor OpenVPN:

Creio que ainda não estava claro que se tratavam de duas operadoras diferentes, então neste caso o que você precisa é instalar um equipamento chamado loadbalance, existem vários no mercado uns mais caros outros baratos vai depender do seu orçamento.

@tmmsantos como pôde acompanhar muitos bons e valiosos insights técnicos que você pode explorar, grandes são as chances de você resolver o seu problema em definitivo seguindo um ou outro, compartilhe conosco os resultados do seu trabalho, irá enriquecer ainda mais o seu tópico e o fórum como um todo. Uma outra coisa que me ocorreu agora, pois já tive o mesmo problema que você passando cabos em dutos/passagens sem mais muito espaço, é usar um dos cabos já passados como "cabo-guia" para passar outro cabo, tendo claro o cuidado de fixar nas pontas um passador de cabos para sobrar mesmo, apenas para não correr o risco de perder o cabo já passado na tentativa. Aqui no meu caso funcionou em um duto de prédio entupido de terra da chuva, com outros cabos grossos já passados tipo coaxial no 2º andar, o porém fica para a necessidade de você precisar de +1 pessoa/amigo para lhe ajudar do outro lado.

Boa noite Equipe CdH! Uma honra estar voltando à este canto da internet tão caro à mim. Se o assunto for repetido por favor sintam-se à vontade em trancar ou apagar o tópico, irei entender Mas para minha surpresa hoje, ao responder em alguns tópicos percebi a ausência de algumas opções de formatação na barra, vejam: Agora mesmo neste exato tópico vejo que a barra esta completa, então me parece estar ausente apenas para respostas à tópicos/mensagens comuns. Houve alguma atualização ou mod nesse sentido ou estou "viajando" Obrigado pela atenção e um grande abraço!

É em se tratando de notebook você vai precisar aí de um adaptador Wireless USB ou pesquisar ainda mais até encontrar outra placa WiFi compatível com o seu Acer para substituir essa Atheros aí. Adaptador Wireless USB "de responsa" que já vi sendo usado até em tutoriais internet afora são os da linha ALFA, dá uma pesquisada. Eu mesmo quando tiver a oportunidade irei adquirir um dessa linha também .

@tmmsantos Entendi, que abacaxi. No lugar do conector, que é um atenuador de sinal, talvez lhe caísse melhor ter um pequeno switch, que seria um repetidor/regenerador do sinal, a perda se converteria em ganho: Seria a solução mais viável do ponto de vista "custo-benefício" para tentar contornar o problema, mas se você tem orçamento para bancar um kit de roteadores Mesh, é melhor ainda. Edit.: o post do @arfneto também trás uma solução muito inteligente, excelente amigo. Realmente faltou eu mencionar quanto à questão do cabo crimpado fora do padrão, é importante tê-los crimpados no padrão porque dessa forma a diafonia (relação sinal-ruído) que os próprios pares metálicos geram são anulados com maior eficiência (par Tx anulando a interferência eletromagnética do par Rx e vice-versa) 30 e tantos metros, com adaptador e ainda fora do padrão podem ser de fato a causa-raiz do problema, mas caso não sejam creio que a inserção de um "repetidor/regenerador" de sinal tal qual o switch é poderá vir bem à calhar.

Cabo crimpado pra passar velocidade abaixo da contratada é de chorar bixo, imagina quem é cliente leigo nunca vai perceber, paga uma coisa e recebe outra. Lamentável. Bom com relação ao outro problema, tenta ver quem está respondendo às requisições de DNS com o comando: nslookup www.uol.com.br Esse é um exemplo aí vai te mostrar se é o Intelbras ou a ONU, o correto aí eu diria que o IP de DNS deva ser algum interno da Claro caso não seja providencie que seja algum conhecido direto nas configurações da placa de rede

Isso o roteador principal sendo Mesh e os demais da mesma forma, Mesh também: de Mesh pra Mesh. Mas caso queira aportar algum outro router nessa rede WiFi pode porém os devices atrás do "roteador comum" estarão limitados e não usufruirão das capacidades da rede Mesh (não enquanto estiverem próximos/conectados ao "roteador comum". Correto essa é a premissa, a de não haver percepção de perdas ou interrupções dentro do alcance dos roteadores Mesh nos cômodos com cobertura. Correto independente do tipo de internet que chega à sua casa, porém sabemos que atualmente os provedores por entregarem velocidades cada vez mais altas, para maior aproveitamento de suas redes eles mesmo ofertarem kits Mesh para instalação, então é indiferente o tipo de internet do provedor (cable modem ou FTTH) Sim garante desde que, claro, seu provedor esteja entregando toda a largura de banda contratada, sem maquiagens.

Perfeita colocação do @El Dorado sobre a limitação na porta Giga ou do Huawei ou do Intelbras, mais provavelmente do Huawei porque se o limite máximo do throughput (taxa de transferência) fica limitada exatamente à 100 Mbps em um barramento que comporta 10x essa velocidade, fica clara uma limitação na comutação, caso contrário oscilaria para muito mais algo na casa de 200 Mbps. Infelizmente é praxe dos provedores de acesso internet limitarem ao máximo o total aproveitamento das portas GigaEthernet nas ONUs, tanto por questão de projeto (IPTV ou VoIP) tanto por questão de overhead mesmo impedindo o consumidor final de "pendurar" muitos dispositivos. Pra testar isso, se é limitação da porta Giga do seu Huawei, coloca notebook por cabo e faça o teste.

Entendo a sua precaução sobretudo se for para aproveitar o "Mi Turbo Charge" do Redmi Note 9, aí então meu amigo melhor partir para o original que, diga-se de passagem, é bem barato (se original MESMO) vai ter porém que garimpar um pouco lendo os comentários para ver se o vendedor realmente está vendendo original e não comprar gato por lebre.

Olá @Henry007 dá uma olhada nesse review, trás alguns modelos que podem te interessar:

Opa e ai @MatheusBRK se te ajuda dá uma olhada nesse review, pode te interessar:

A opção " alternativa"fora a rede mesh usando roteadores comuns é o WDS, existindo a interoperabilidade entre equipamentos diferentes caso tenha suporte ao WDS em seu firmware (configure apenas no Archer C6 se o Xiaomi for o roteador principal já que é mesh):

Entendi agora, bom nesses casos os próprios provedores tem em sua página de Cliente a opção de gerenciar tanto o SSID do WiFi quanto a senha deste, mas a senha de acesso ao gerenciamento do equipamento realmente somente eles quem detém essa informação e praticamente nunca à divulgam mesmo que à pedido, então de certa forma está segura essa informação se é esta sua preocupação, sem problemas.

Como o amigo arfneto bem disse: Você esta usando esse conector para estender o cabo de rede? Principalmente se o conector que você está passando na sua caixa de passagem, o Tx/Rx quem "manda" é a porta Ethernet, então como você disse que o TP-Link Archer C6 não está transmitindo Tx/Rx nos mesmos pares/padrão que conectando direto no computador o que explica funcionar neste último e não funcionar no roteador, isso se esse cabo no total não estiver passando por muitas dezenas de metros, o conector é um atenuador e diminui consideravelmente o alcance do sinal desde o modem VIVO passando pelo conector até chegar na ponta do outro cabo conectado do outro lado do conector, ou seja, ao invés dos 100 metros padrão do cabo Ethernet CAT5 (supondo que seja esse) com o conector existe uma perda e essa metragem cai fácil para bem menos à depender da qualidade do conector. O melhor cenário é acabar com a gambiarra de conector e repassar um cabo inteiro sem derivações, e tchau problema.

Aparentemente não é nenhum bicho de 7 cabeças, assista à ESTE VÍDEO o autor detalha muito bem os detalhes de configuração: Uma coisa que você porém deve ficar atento é com a diferença nas características do sinal óptico -- PON -- de cada equipamento: ZTE GPON F601: Comprimento de onda de transmissão: - Recebendo: 1.490 nm - Transmitindo: 1.310 nm - Sensibilidade de Recebimento: Melhor que -29dBm - Transmitindo potência ótica: 1 ~ 5dBm - Sobrecarga de potência ótica: -5dBm FONTE: https://www.nrstore.com.br/f601.html Já o NOKIA G-140W não encontrei muitas informações da PON dele, mas por se tratar de uma interface SC / UPC em ambos, a compatibilidade é provável porém caso não seja ou a ONT Nokia não consiga compensar eventuais degradações tal qual o da ZTE, então a PON não irá sincronizar assim fique atento à isso.