arfneto

É claro que nada tem a ver o roteador com a conexão em si. Pode ser que o roteador tenha parado, que a fonte tenha queimado, qualquer coisa. Pode ser que a conexão tenha caído apenas. Então claro que um aparelho que fique testando sozinho a efetividade de cada conexão é algo bacana. Não faz balanceamento de carga, mesmo que os caras deem esse nome para ele, mas ok. Só que em muitos casos a gente não precisa disso. E com os dispositivos usando a internet toda hora leva minutos para alguém perceber que o provedor X parou. E aí um cara vai lá no armário e desliga ele por uns minutos. Em geral os provedores são bem estáveis hoje em dia. E um minúsculo script de umas 20 linhas faz a mesma coisa que esses algoritmos... Nem sempre a gente precisa mesmo comprar algo

@diogo99099 Sim, qualquer um. Apenas configure come eu disse.

Talvez seja útil ter algo assim aqui então vou deixar um exemplo bem ingênuo de uma aplicação C ou C++ que usa um edit box em Windows A documentação sobre essas coisas é extensa e completa. Sobre esse controle veja em português do Brasil em https://learn.microsoft.com/pt-br/windows/win32/controls/about-edit-controls por exemplo Essa é a janela da aplicação Tem 3 controles e ao apertar o botão copia o texto de um edit box para outro #include <windows.h> #define ID_EDIT1 1 #define ID_EDIT2 2 #define ID_BUTTON 3 LRESULT CALLBACK WindowProcedure( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) { static HWND hEdit1, hEdit2, hButton; switch (msg) { case WM_CREATE: // ao criar a janela da aplicacao cria os 3 controles hEdit1 = CreateWindow( TEXT("EDIT"), TEXT(""), WS_CHILD | WS_VISIBLE | WS_BORDER, 50, 50, 200, 20, hwnd, (HMENU)ID_EDIT1, NULL, NULL); hEdit2 = CreateWindow( TEXT("EDIT"), TEXT(""), WS_CHILD | WS_VISIBLE | WS_BORDER, 50, 100, 200, 20, hwnd, (HMENU)ID_EDIT2, NULL, NULL); hButton = CreateWindow( TEXT("BUTTON"), TEXT("Copia do primeiro para o segundo EditBox "), WS_CHILD | WS_VISIBLE, 50, 150, 300, 30, hwnd, (HMENU)ID_BUTTON, NULL, NULL); break; // um click no botao vai gerar a mensagem WM_COMMAND para // a janela do aplicativo com a indicacao de quem enviou // em wParam case WM_COMMAND: if (LOWORD(wParam) == ID_BUTTON) { wchar_t wtext[512]; LPWSTR ptr = wtext; GetWindowText(hEdit1, ptr, 512); SetWindowText(hEdit2, ptr); } break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hwnd, msg, wParam, lParam); } return 0; } int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { const char className[] = "MyWindowClass"; WNDCLASS wc = {}; wc.lpfnWndProc = WindowProcedure; wc.hInstance = hInstance; wchar_t wtext[512]; mbstowcs( wtext, className, strlen(className) + 1); // Plus null wc.lpszClassName = wtext; RegisterClass(&wc); HWND hwnd = CreateWindowEx( 0, // Optional window styles. wc.lpszClassName, // Window class L"Aperte o botão para copiar o texto de um edit " L"box para outro", // Window text WS_OVERLAPPEDWINDOW, // Window style // Size and position CW_USEDEFAULT, CW_USEDEFAULT, 400, 300, NULL, // Parent window NULL, // Menu hInstance, // Instance handle NULL // Additional application data ); if (hwnd == NULL) { return 0; } ShowWindow(hwnd, nCmdShow); MSG msg = {}; while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return 0; } Delphi apenas cria uma camada sobre isso, assim como se faz com Windows Forms ou MFC ou Qt ou wxWidgets ou ou qualquer outro framework. É só Windows e C afinal.

Mas, como eu expliquei, ele faz implicitamente esse lance de passar as conexões para outro provedor, como qualquer outro switch faria. Os protocolos acabam por fazer isso. E se os roteadores de seus provedores tiverem desempenho parecido até as conexões acabam sendo distribuídas entre eles E o tal load balancer não faz balanceamento de carga. Apenas de conexões. Isso é marketing só. EXEMPLO: se você tem 2 provedores e 4 conexões, 1,2,3 e 4 e seu aparelho distribui a carga por um algoritmo de alternância simples, tipo Round Robin, o mais comum, vai acabar com as conexões 1 e 3 no primeiro e 2 e 4 no segundo. Bem equilibrado! Só que não adianta nada. Se 1 e 3 começarem a gastar dezenas de mbps e os 2 e 4 só ficarem olhando para as telas nada nesse mundo vai balancear essa carga e passar uma das conexões do provedor A para o provedor B.

@diogo99099 Tl-sg108e não é um "load balancer". Talvez não tenha entendido o que eu expliquei. Esse é apenas um switch.

Note que esse é um switch nivel 2 comum.

@Kelt0n não disse a marca do aparelho nem o modelo... provavelmente não pode não. Prefira o trabalho e passe um cabo ou dois. Sempre compensa.

@diogo99099 não, não faz. Só que se cair uma conexão vai sobrar só a outra então o protocolo faz o resto. Note que aparelhos como esse tal LOAD BALANCE ER605 GIGABIT TP-LINK dizem fazer uma coisa que não é verdadeira. Eles não fazem balanceamento de carga. Apenas o balanceamento das conexões, distribuindo pelos provedores que estão ativos. As conexões e não a carga. EXEMPLO: suponha um provedor, tipo a VIVO em 192.168.15.1, DHCP entre 10 e 154 com Lease de 5 min outro provedor, como a NET em 192.168.15.2, DHCP entre 155 e 254 com Lease de 5 min esse switch de que falou em 192.168.15.3 uma rede com mascara comum 255.255.255.0 Tudo que você ligar nas outras portas do switch vai receber endereços de um dos dois provedores, o que responder primeiro. E eles tem performance parecida... Se um parar a conexão vai cair, e vai ser reestabelecida em seguida usando o outro provedor porque ele vai responder com os endereços certos d DNS IP e gateway. Quando o outro voltar vai passar a responder igualzinho e como o lease do DHCP é de 5 minutos ele vai começar a receber conexões de novo. Para a rede local não faz diferença, já que o que muda é apenas o gateway e os end de DNS Claro que um "load balancer" deixa tudo mais simples, mas nem faz balanceamento de carga, como eu disse. Tem casos em que a conexão cai mas o DHCP não então pode ser que o aparelho continue ativo com DHCP e gateway e tudo, mas não esteja de fato operando. Claro que pode ser que os tais load balancers também não percebam isso... Só atente para o que eu expliquei

@_FBO_ Entenda a diferença entre um aplicativo de console e um aplicativo desktop para Windows. Ou use o IDE da Borland para C++. Não existem eventos em C++ para associar com callbacks. O Windows por exemplo gera uma mensagem WM-KEYUP quando o usuário solta uma tecla em seu programa. E você precisa colocar uma callback para essa mensagem no seu programa C ou C++. Simples assim. Só que o Delphi esconde isso e é muito mais fácil programar assim, daí o sucesso desse ambiente. Fora o fato de poder usar o mesmo código em vários sistemas... Esse é o loop de mensagens do Windows, gerado automaticamente pelo IDE: LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_COMMAND: { int wmId = LOWORD(wParam); // Parse the menu selections: switch (wmId) { case IDM_ABOUT: DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About); break; case IDM_EXIT: DestroyWindow(hWnd); break; default: return DefWindowProc(hWnd, message, wParam, lParam); } } break; case WM_PAINT: { PAINTSTRUCT ps; HDC hdc = BeginPaint(hWnd, &ps); // TODO: Add any drawing code that uses hdc here... EndPaint(hWnd, &ps); } break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hWnd, message, wParam, lParam); } return 0; } Então já dá para você entender. Você inclui aí a mensagem WM_KEYUP e sua função de tratamento, a tal callback. Nada mais. Você trata todas as mensagens de que precisa e o Windows roda o programa junto com os outros. Estou simplificando as coisas, é só um exemplo. Os controles do Windows são como os componentes VCL do Delphi. E tem seus próprios eventos e mensagens. Mas o mecanismo é esse que eu expliquei, mas aplicados nesse caso a coisas como EditBox, ProgressBar, Menus e tal.

@_FBO_ Os eventos no Delphi são mapeados para eventos e mensagens do Windows, que foi escrito em C --- e C++ em alguma extensão nos últimos anos. Pode usar a API diretamente. Se quer vincular uma função a ser executada quando acontecer algo pode passar isso no construtor de classe, se não for sempre a mesma função. A noção de callback aqui não acho que se aplica: afinal os eventos aqui são síncronos, referentes às teclas pressionadas. Se você quer usar isso em Windows o mais simples para manter a familiaridade com o que usa é usar o RAD Studio e usar o C++ da Borland. Ou o C++ Bullder, que é o IDE C++ do RAD Studio mas acho que pode ser usado à parte. Direto do site de venda do produto: Delphi introduz uma abstração para a camada de mensagens e eventos do Windows (ou do Mac ou do linux ou Android). Delphi é um framework tipo RAD --- de Rapid Application Development. E essa é a razão do sucesso desse IDE. Você escreve mais ou menos como no Visual Basic no Windows, ou no JavaFX. Preenche simples formulários de propriedades e callbacks e o framework faz o resto para você. Por isso você pode escrever aplicativos em Delphi para 5 plataformas ao mesmo tempo. E o IDE ainda inclui um criador do programa de instalação, o tal setup. E assim é muito, mas muito mais simples escrever em Delphi usando Pascal. Porque o Delphi costura tudo pra você. É claro que em C ou C++ é perfeitamente possível. Delphi foi escrito em C, bem como o Windows. o Linux, o MacOS é linux, O Android é linux. De volta ao programa Se quer fazer isso em C++ deve usar uma aplicação desktop para Windows no seu caso. E não um simples programa de console, que roda tudo em uma thread só. E lá vai ver que é tudo igual ao Delphi: você associa mensagens a funções, o conceito de callback. Se quer associar algo a OnEditingDone ou OnKeyPress use variáveis. Aqui não são de fato callbacks. Trata-se de simples atribuições. Não precisa disso em C++. Nem new nem delete nem o ponteiro this. Não é java. E mesmo a existência de uma classe Edit associada ao teclado é algo curioso. Só tem um teclado e está usando a API do Windows. Nem se pode garantir que uma tecla vá de fato para seu programa, e se vai iria para qual de várias instâncias de Edit, se as tivesse? Se vai usar uma série de microcontroladores então imagino que nada disso se aplica e vai usar comunicação serial ou USB para ler direto do dispositivo. Bem, nem é assim um caso de lógica. Só faz pouco sentido. Esse trecho if ((GetAsyncKeyState(48) < 0) && (lastKey != '0')) { buff += '0'; lastKey = '0'; } if ((GetAsyncKeyState(49) < 0) && (lastKey != '1')) { buff += '1'; lastKey = '1'; } if ((GetAsyncKeyState(50) < 0) && (lastKey != '2')) { buff += '2'; lastKey = '2'; } if ((GetAsyncKeyState(51) < 0) && (lastKey != '3')) { buff += '3'; lastKey = '3'; } if ((GetAsyncKeyState(52) < 0) && (lastKey != '4')) { buff += '4'; lastKey = '4'; } if ((GetAsyncKeyState(53) < 0) && (lastKey != '5')) { buff += '5'; lastKey = '5'; } if ((GetAsyncKeyState(54) < 0) && (lastKey != '6')) { buff += '6'; lastKey = '6'; } if ((GetAsyncKeyState(55) < 0) && (lastKey != '7')) { buff += '7'; lastKey = '7'; } if ((GetAsyncKeyState(56) < 0) && (lastKey != '8')) { buff += '8'; lastKey = '8'; } if ((GetAsyncKeyState(57) < 0) && (lastKey != '9')) { buff += '9'; lastKey = '9'; } É equivalente a esse: for (int ch = '0'; ch <= '9'; ch += 1) if ((GetAsyncKeyState(ch) < 0)) { buff += ch; lastKey = (char)ch; return; } E provavelmente é melhor tratar ENTER em outra chamada Se leu o que escrevi até aqui já deve ter entendido que num programa de console você vai ter que executar a ação dentro da sua lógica. Se quer um evento associado a algo vai ter que usar uma aplicação desktop e o loop de mensagens. Vou te mostrar um exemplo de todo modo. Em C++ porque foi a linguagem que tentou usar. E X E M P L O Vou usar essa classe cEdit A classe cEdit #pragma once #include <windows.h> #include <iostream> using namespace std; using On_KeyPress = void (*)(char); using Notify_event = void (*)(); class cEdit { private: char lastKey; string text; string buff; public: On_KeyPress OnKeyPress; Notify_event OnEditingDone; cEdit(); cEdit(On_KeyPress, Notify_event); virtual ~cEdit(); void checkK(); }; Uma possível implementação #include "cEdit.h" cEdit::cEdit() { lastKey = 0; text.clear(); buff.clear(); OnKeyPress = nullptr; OnEditingDone = nullptr; } cEdit::cEdit(On_KeyPress kp, Notify_event ne) { lastKey = 0; text.clear(); buff.clear(); OnKeyPress = kp; OnEditingDone = ne; } cEdit::~cEdit() { std::cout << "Destruindo instancia de cEdit\n"; }; void cEdit::checkK() { for (int ch = '0'; ch <= '9'; ch += 1) if ((GetAsyncKeyState(ch) < 0)) { buff += ch; lastKey = (char)ch; return; } if (GetAsyncKeyState(VK_RETURN) < 0) { lastKey = 0; text = buff; buff.clear(); if (OnEditingDone != nullptr) OnEditingDone(); return; } if (OnKeyPress != nullptr) { OnKeyPress(lastKey); } } Um exemplo que usa isso #include <Windows.h> #include <format> #include <iostream> #include "cEdit.h" using namespace std; void f_kp1(char); void f_kp2(char); int main(void) { { cEdit teste; teste.OnKeyPress = f_kp1; teste.OnKeyPress(17); } cEdit outra(f_kp2, nullptr); outra.OnKeyPress(42); return 0; } void f_kp1(char ch) { std::print( cout, "Callback #1. Codigo da tecla = {}\n", (int) ch); return; } void f_kp2(char ch) { std::print( cout, "Callback #2. Codigo da tecla = {}\n", (int) ch); return; } Pode ver duas maneiras de usar isso, no construtor ou via atribuição. Em geral se usa o nome das callbacks como private. A saida do programa Callback #1. Codigo da tecla = 17 Destruindo instancia de cEdit Callback #2. Codigo da tecla = 42 Destruindo instancia de cEdit Entenda que não existem eventos no programa. De nada adianta o nome. E nesse contexto as funções também não são callbacks, ao menos não no estilo javascript por exemplo.

Esse aparelho faz o que você quer. Não há interferência com os telefones. é outro protocolo --- SIP em TCP/IP. No fundo podia usar um simples switch para isso.

Dá pra imaginar o que eu acho disso. Mesmo que possa funcionar. Não recomendo e vai encontrar aqui dezenas de posts meus explicando porque não fazer isso. Claro para AP que acaso sejam tipo de bar ou loja que oferece wifi para clientes é perfeitamente possível e até recomendável segmentar a rede IP e isolar os dispositivos. Fora isso é bobagem. seu roteador vai centralizar o tráfego dessas conexões. Se ligar 150 dispositivos via wifi e se o tráfego for só para a internet então essa é a realidade. Deve conhecer seu tráfego. 16 conexões é muito pouco. De onde tirou esse número? que mascara de rede está usando? qual o modelo desse aparelho? como está ligado isso? De nada adianta isso. Vai ficar até pior. Se tem 200mbps para 200 clientes vai ter isso pra considerar: Precisa ter uma ideia do trafego e saber quantos clientes estão ativos num dado momento em média. Essa banda vai ser dividida entre todos. É a realidade. De nada adianta os AP para 100 dispositivos (exagerado isso) se o roteador suportar só 10. Ou a banda for pequena para o tipo de uso dos 10 ou 100 usuários.

Seu problema parece estar localizado a esse micro onde andou colocando configurações de DNS por exemplo... Precisa saber se outro micro conectado nesse cabo funciona ok, porque te daria a convicção de que tem algo errado no micro apenas... Rede em Windows depende de uns 3 ou 4 componentes associados à sua placa de rede só. Do padrão não precisa mudar nada. Nas propriedades da placa de rede precisa do mínimo - cliente para redes microsoft - compartilhamento de arquivos e impressoras - protocolo TCP/IP v4 algo como no desenho acima no protocolo IP v4 deixe tudo no automatico e não precisa de videos na internet para configurar isso. deixe tudo no padrão

Isso é algo que pode mesmo considerar para o futuro. ao julgar como identificar um problema ou mesmo como conseguir suporte. Seus computadores ligados ao switch que chamou de hub não tinham uma configuração de IP válida. Só isso. Se nenhum aparelho ligado ao tal "hub" tinha --- e não tinha --- já sabia que tinha um problema ali. Podia ter colocado esse aparelho em uma mesa ligado a um computador de teste e usado um cabo de rede que já sabia que funcionava, e testado a partir daí, sem sair mais da mesa até ter o aparelho conectado. Ao mesmo tempo podia ter usado qualquer computador ou AP que sabia estar funcionando e ligado naquele cabo onde estava o switch... E teria entendido que mais um aparelho não funcionava ali e assim o sinal de rede provavelmente não estava chegando...

Em C+ é igualzinho. E o sistema é o mesmo Windows nesse caso. Pode usar bind ou lambdas mas pode também simplesmente colocar o nome da função de callback como argumento. lambda é só uma (prática) notação compacta onde você pode salvar a função numa variável. bind tem o mesmo sentido em todas linguagens. Como um alias para uma chamada de função. Não precisa nem de um nem de outro. Seu programa na versão C++ não compila por ter erros de sintaxe. A lógica em si não entendi. Callbacks estariam mais para o caso de escrever isso em C, falando das linguagens desse forum. e typedef não é usado em C++ na prática. E CheckKeys em Pascal ou Delphi ou C ou C++ parece ter muitos testes sem sentido. Todos aqueles if devem ser mutualmente exclusivos. Mesmo que o sistema reporte várias teclas pressionadas sua lógica admite apenas um buff e um lastKey então só vai considerar o último.... E se não tem nenhuma tecla pressionada para que testar tantas vezes? Veja esse trecho if ((GetAsyncKeyState(50) < 0) && (lastKey != '2')) { buff += '2'; lastKey = '2'; } Se a função retornar <0 então lastKey vai ficar com '2' de qualquer maneira.... e o valor de buff é o mesmo que o de lastKey ao final.... E não seria o caso de apenas retornar depois disso ao invés de testar por mais teclas?

Isso porque é um limite e não uma configuração. Você não "coloca ela" como um parâmetro e sim como um limite mínimo. Conexões via cabo acontecem em 10 100 ou 1000 para sua placa. Se FIXAR o mínimo como 1000 FD como fez não vai se conectar em 1000 half duplex por exemplo. Foi sua escolha, Pode achar que mesmo 10mbps seja uma conexão melhor que nenhuma conexão... Conexões a gigabit usam todos os 8 fios do cabo. A 10 ou 100 usa apenas os pinos 1 2 3 e 6. Isso quer dizer que se você tem um problema em um ou mais dos outros fios, 4 5 7 e 8, e teve a ideia de marcar lá os 1000 FD não vai se conectar de jeito nenhum. Não sei quem começou a dizer que isso é uma configuração mas está em toda parte em fórums e tutoriais e conversas de bar Internet nada tem a ver com a rede local. Se desligar o cabo da internet a rede continua funcionando igualzinha. Tanto faz o plano que contrate. De onde concluiu que a placa está limitando algo?

Você não disse qual modelo de AP está usando. Só que eles são redondos. Alguns modelos podem rodar DHCP mesmo em modo AP. E eles não "pegam DHCP". DHCP é um serviço iniciado pelos dispositivos de rede. Nada tem a ver com o AP em si. Um dispositivo IP ao se conectar na rede ethernet --- sim, wifi é ethernet também --- e não tendo um endereço fixo de rede vai enviar mensagens pela rede em busca de algum servidor DHCP que possa oferecer configuração de rede. Essas mensagens chegam ao roteador do provedor e esse pode oferecer endereços. E pode claro ter outros servidores em sua rede. Servidor DHCP é só um programa de computador e pode rodar em qualquer micro. A conexão dos AP é ethernet e não IP. IP é outra camada. Em geral os roteadores vêm configurados para servir 254 endereços via DHCP e não 16. Veja por exemplo o padrão da VIVO de usar 192.168.15.0 para a rede e 255.255.255.0 para a máscara de rede indica exatamente isso. Mesmo caso da NET com a rede padrão 192.168.0.0 com a máscara 255.255.255.0. Fora os dois endereços já em uso restam 254 dispositivos na rede e é o máximo que o DHCP pode fornecer na configuração padrão. Esses AP não "transmitem internet". São dispositivos de rede apenas. O que existe é o aparelho do provedor configurado como gateway padrão. O protocolo TCP/IP faz o resto. Não os AP. A menos que use os aparelhos como roteadores e ligue na porta WAN segmentando a rede inicial --- e em geral é má ideia, com perda de performance e multiplo NAT e muitos outros problemas --- todas as conexões em todos os AP vão contar no limite. Não do DHCP em si mas da rede como um todo. Como eu disse o normal é 254 hosts. Pode claro usar uma máscara de rede para mais dispositivos...

foi o que eu disse. você apaga e, claro, fica sem rede. Reinicia a máquina e o sistema reinstala a placa na configuração padrão, desfazendo coisas que possa ter feito pelo caminho tentando "resolver" o problema. Se ainda não funciona é porque o problema não estava ai.... O padrão é suficiente para funcionar isso. E qualquer mudança sem saber o que é também é suficiente para não funcionar mais, como essa ideia de usar 127.0.0.1 como servidor DNS Agora deve ver item a item até achar o problema. Tem outros aparelhos ligados na rede e com acesso ok a internet?

"internet" não é configurável. Seu computador sequer está ligado à internet. Apenas ligada na rede local, a tal LAN wifi nada tem a ver com a internet. wifi é parte da rede local, uma rede ethernet que nesse caso trafega os dados via ondas de rádio. A operadora pouco ou nada pode fazer pelo wifi. Por uma questão de marketing e fidelização passaram a oferecer "sem custo" pontos de acesso wifi integrados aos aparelhos que eles fornecem, anos e anos atrás. Acha mesmo que o padrão seria algo destrutivo? Não é.

Abra o gerenciador de dispositivos, use as setas para selecionar a placa de rede, aperte a tecla delete, confirme. Reinicie a máquina. O gerenciador de dispositivos fica no painel de controle. Aperte a tecla do Windows e depois P A I ... quando ver lá na lista o painel de controle selecione e tecle ENTER. Vai ver a lista de aplicativos do painel de controles. Um deles é o gerenciador de dispositivos... nada mais pode usar Windows e R ao mesmo tempo e digitar compmgmt.msc, o nome dele. E teclar ENTER. Sempre tem muitas maneiras de fazer a mesma coisa.

Internet nada tem a ver com wifi. Se desligar o cabo da internet vai reparar que o wifi continua igualzinho. wifi é uma conexão local, do seu computador ou celular para o ponto de acesso, seu roteador com wifi nesse caso Se você tem um roteador e não um AP então usar como repetidor nunca vai dar o melhor resultado. Simplesmente passe um cabo para o andar de cima e ligue na porta LAN do outro roteador e configure de acordo. É o simples e que vai dar menor latência e menos perda de banda. Quase nada na verdade.

@Andre luis souza carvalho apenas exclua a placa de rede no gerenciador de dispositivos e reinicie a maquina. em geral quando se experimenta muito com essas coisas é o caminho mais curto. Volta tudo para o padrão. E quase sempre é como deve ficar

Automático em geral é melhor do que ter que fazer algo sugiro manter sempre assim Ninguém quer ir de máquina me máquina fixar endereços de servidores DNS a menos de coisas bem específicas. Muitas vezes não é prático e muitas vezes nem é possível fazer isso. O servidor DHCP que atender seu computador já vai fornecer esses endereços e só precisa fixar em um lugar. Ou nenhum, porque em geral os DNS do provedor são mais rápidos (muito mais rápidos em alguns casos) do que os servidores de Google ou CloudFare ou OpenDNS que tod mundo recomenda. Na dúvida meça com algo tipo DNSBench. O cache de DNS fica em memória então raramente faz diferença. Um /renew implica em um /release e um release vai zerar o cahce de DNS de qualquer forma... Então o último comando executa os outros dois. Pode ser mais simples só desativar e ativar a placa de rede no gerenciador de dispositivos --- compmgmt.msc --- porque vai fazer isso e algo mais, recarregando o driver de rede e toda a camada de protocolos associada ao dispositivo.

Não deve ser o IP de sua máquina, que é local em sua rede, mas sim o IP público de sua rede na internet, isso que o modem recebe ao se conectar. O IP de usa máquina na LAN pode ser fixado usando uma configuração no DHCP ou mesmo um endereço fixo. Mas um endereço fixo para seu modem precisa ser contratado junto ao provedor. E atenderia só uma rede. Não poderia fazer o simples que é usar em viagem por exemplo. Como eu expliquei antes, essa é uma ideia infeliz e não vai funcionar nunca. A própria internet foi criada já com mecanismos para permitir essa mudança de endereços de redes, usando DNS e registros...

@larissa oliveira pode enviar o aparelho para essa oficina LefTec em São Bernardo do Campo - SP por exemplo.