Uma conexão de rede pode apresentar um dos problemas mais frustrantes para quem trabalha com suporte técnico: a perda de pacotes. A Internet parece funcionar, os sites abrem na maior parte do tempo e o computador continua conectado ao Wi-Fi ou ao cabo de rede. Mesmo assim, uma impressora falha ocasionalmente, uma chamada apresenta interrupções, um sistema demora para responder ou determinado serviço simplesmente perde a comunicação.
O primeiro teste normalmente executado é o conhecido Ping.
Ele pode responder uma pergunta importante: existe comunicação com determinado endereço e, durante o período do teste, houve respostas ICMP ausentes?
Mas existe outra pergunta muito mais difícil:
se um pacote foi perdido, onde exatamente isso aconteceu?
O problema pode estar fora do computador: Wi-Fi, roteador, switch, provedor, equipamento remoto ou algum ponto existente entre origem e destino.
Entretanto, também existe outra possibilidade.
O pacote pode chegar ao computador e ser descartado dentro da própria pilha de rede do Windows.
É justamente nesse ponto que uma ferramenta pouco conhecida do Windows se torna extremamente interessante: o Pktmon, abreviação de Packet Monitor.
O Pktmon é uma ferramenta nativa de diagnóstico de rede da Microsoft. Ele está disponível no Windows 11 e consegue trabalhar com captura, filtragem, contadores e detecção de descartes de pacotes dentro dos componentes de rede do sistema operacional.
Isso muda bastante a investigação.
Em vez de perguntar apenas:
“Existe perda de pacotes?”
podemos começar a investigar:
“O Windows recebeu esse tráfego?”
“Por quais componentes ele passou?”
“O próprio computador descartou algum pacote?”
“Existe um motivo registrado para esse descarte?”
E tudo isso pode ser investigado sem instalar inicialmente um analisador externo de pacotes.
Neste artigo da VMIA, vamos conhecer o Pktmon desde os conceitos básicos até situações práticas de diagnóstico no Windows 11.
O que é o Pktmon?
O Pktmon, ou Packet Monitor, é uma ferramenta de diagnóstico de rede incluída no Windows.
Ela funciona através do executável:
pktmon.exe
A ferramenta consegue observar o tráfego enquanto ele atravessa diferentes componentes da pilha de rede do Windows.
Isso é importante porque a comunicação de rede não acontece simplesmente desta maneira:
Internet → placa de rede → programa
Entre a interface física ou virtual e o aplicativo existem diferentes componentes responsáveis pelo processamento dos pacotes.
O Windows precisa interpretar protocolos, encaminhar tráfego, aplicar filtros, entregar dados aos componentes apropriados e executar várias outras operações antes que determinado aplicativo receba as informações.
O Pktmon oferece visibilidade sobre parte desse caminho.
Segundo a documentação técnica da Microsoft, ele pode executar quatro funções particularmente importantes:
- captura de pacotes;
- detecção de descarte de pacotes;
- filtragem;
- contagem de pacotes.
Por isso, pensar no Pktmon simplesmente como um substituto do Ping seria um erro.
São ferramentas diferentes.
Ping e Pktmon não fazem o mesmo trabalho
O comando Ping é extremamente útil e continua sendo uma das primeiras ferramentas que devemos considerar durante determinados diagnósticos.
Por exemplo:
ping 192.168.1.1
Pode ajudar a verificar a comunicação ICMP com o roteador.
Outro exemplo:
ping 8.8.8.8
Pode ajudar em determinados testes de conectividade IP externa.
E:
ping google.com
adiciona outro elemento à investigação, pois antes de enviar o teste para o endereço correspondente, o nome precisa ser resolvido.
Entretanto, o resultado do Ping não deve ser interpretado como um diagnóstico completo da rede.
Imagine a seguinte situação:
Disparando 192.168.1.50 com 32 bytes de dados:
Resposta de 192.168.1.50: bytes=32 tempo=2ms TTL=64
Resposta de 192.168.1.50: bytes=32 tempo=3ms TTL=64
Esgotado o tempo limite do pedido.
Resposta de 192.168.1.50: bytes=32 tempo=2ms TTL=64Existe um indício de perda durante o teste.
Mas onde ocorreu essa perda?
O Ping sozinho não responde.
O pacote poderia ter sido perdido:
- antes de sair do computador;
- na interface Wi-Fi;
- durante a comunicação sem fio;
- no roteador;
- em algum equipamento intermediário;
- no dispositivo de destino;
- no caminho da resposta;
- ou em determinado componente local.
Portanto:
detectar uma ausência de resposta não significa automaticamente identificar sua causa.
Essa distinção será fundamental durante todo este artigo.
O conceito mais importante: o caminho do pacote dentro do Windows
Para entender por que o Pktmon é tão interessante, precisamos abandonar por alguns minutos a visão simplificada de uma rede.
Quando você abre um navegador e acessa um site, os dados não simplesmente aparecem na placa de rede e imediatamente surgem no Chrome, Edge ou Firefox.
Existe uma pilha de rede entre essas duas extremidades.
De maneira simplificada, podemos imaginar:
Aplicativo
↓
TCP/UDP
↓
IP
↓
Componentes e filtros de rede
↓
Driver
↓
Adaptador de rede
↓
RedeEssa representação não pretende mostrar todos os detalhes internos da arquitetura de rede do Windows. Seu objetivo é apenas demonstrar que existem diferentes etapas entre um programa e a interface física.
E aqui aparece uma característica muito importante do Pktmon.
Ele pode observar pacotes em diferentes pontos da pilha de rede.
Consequentemente, podemos obter informações que uma captura realizada somente em um único ponto talvez não forneça da mesma maneira.
Essa característica também explica por que a Microsoft destaca o Pktmon em ambientes com virtualização, containers e redes definidas por software.
Mas isso não significa que ele seja útil somente em servidores ou grandes datacenters.
Há bastante utilidade em diagnósticos de computadores comuns.
O Pktmon já está instalado no Windows 11?
Sim.
Em versões suportadas do Windows 11, o Pktmon faz parte do próprio sistema operacional.
Você pode verificar rapidamente abrindo o Terminal, PowerShell ou Prompt de Comando e executando:
pktmonou:
pktmon helpDependendo da operação executada, privilégios administrativos serão necessários. Para os exemplos de captura deste artigo, o ideal é abrir o Terminal do Windows como administrador.
Não precisamos baixar um executável de um site desconhecido.
Também não precisamos instalar um pacote de ferramentas apenas para verificar se o recurso existe.
Conhecendo os principais comandos do Pktmon
Ao consultar a sintaxe atual da ferramenta encontramos comandos como:
pktmon filter
pktmon list
pktmon start
pktmon stop
pktmon status
pktmon unload
pktmon counters
pktmon reset
pktmon etl2txt
pktmon etl2pcap
pktmon hex2pkt
pktmon helpCada um desempenha uma função diferente.
Vamos começar pelos mais importantes para entender o fluxo de trabalho.
pktmon start
Inicia a coleta.
Um exemplo simples é:
pktmon start -cO parâmetro -c habilita a captura de pacotes.
A partir desse momento, precisamos reproduzir o problema que queremos investigar.
Se uma aplicação falha ao estabelecer determinada comunicação, por exemplo, iniciamos a captura, reproduzimos a falha e depois encerramos a coleta.
pktmon stop
Para interromper a captura:
pktmon stopO processo parece simples, mas existe uma regra extremamente importante:
não capture tráfego desnecessário.
Um computador moderno pode gerar uma quantidade enorme de comunicação de rede.
Navegadores, sincronização em nuvem, antivírus, Windows Update, mensageiros, serviços do Windows e vários programas podem conversar com a rede simultaneamente.
Quanto mais tráfego irrelevante capturamos, mais difícil fica encontrar o evento que realmente interessa.
É por isso que os filtros terão tanta importância mais adiante.
Primeiro teste prático com Pktmon
Podemos começar com uma captura genérica apenas para entender o funcionamento.
Abra o Terminal como administrador.
Execute:
pktmon start -cAgora reproduza rapidamente a comunicação que deseja observar.
Depois execute:
pktmon stopO Pktmon trabalha com arquivos de rastreamento ETL.
Para transformar a captura em um formato textual, podemos utilizar:
pktmon etl2txt PktMon.etlEsse processo gera uma representação que pode ser analisada em texto.
A própria Microsoft utiliza esse fluxo básico em sua documentação de diagnóstico de perda de pacotes:
pktmon.exe start -c
pktmon.exe stop
pktmon.exe etl2txt PktMon.etlEntretanto, simplesmente capturar tudo não representa a melhor estratégia para um diagnóstico real.
O próximo passo é aprender a procurar apenas aquilo que interessa.
Os filtros transformam o Pktmon em uma ferramenta muito mais útil
Imagine que queremos investigar a comunicação entre o computador e um dispositivo com endereço:
192.168.1.50
Não queremos necessariamente analisar toda a Internet utilizada pelo computador.
Queremos investigar aquele endereço.
O Pktmon possui comandos específicos para gerenciar filtros:
pktmon filter listlista os filtros existentes.
Podemos adicionar filtros com:
pktmon filter adde removê-los quando não forem mais necessários.
A sintaxe permite filtrar elementos como:
- endereço MAC;
- VLAN;
- IPv4 ou IPv6;
- TCP;
- UDP;
- ICMP;
- endereço IP;
- portas.
A possibilidade de combinar critérios é extremamente importante.
Em vez de procurar um pacote entre milhares de comunicações diferentes, podemos reduzir a captura ao cenário que estamos investigando.
Limpando filtros antigos antes de começar
Existe um detalhe simples que pode evitar muita confusão.
Antes de iniciar um novo diagnóstico, verifique os filtros ativos:
pktmon filter listSe houver filtros de testes anteriores, eles podem alterar aquilo que será capturado.
Quando necessário, podemos remover os filtros configurados:
pktmon filter removeDepois configuramos apenas os critérios necessários para o novo teste.
Esse pequeno cuidado evita uma situação bastante comum em ferramentas de captura:
achar que determinado tráfego não existe quando, na realidade, ele apenas ficou fora do filtro configurado.
Podemos filtrar por endereço IP
Suponha novamente que estamos investigando:
192.168.1.50
Podemos criar um filtro relacionado ao endereço IP.
A lógica seria:
pktmon filter add NomeDoFiltro -i 192.168.1.50Depois iniciamos a captura.
pktmon start -cReproduzimos o problema.
Em seguida:
pktmon stopAgora o volume de dados tende a ser muito mais relevante para aquela investigação.
Podemos filtrar por protocolo
Outra possibilidade interessante é selecionar protocolos.
O Pktmon permite trabalhar, entre outros, com:
TCP
UDP
ICMP
ICMPv6Isso abre possibilidades interessantes.
Queremos estudar somente determinados testes ICMP?
Podemos configurar um filtro correspondente.
Queremos investigar uma aplicação que utiliza TCP?
Podemos limitar o tráfego.
Queremos estudar um serviço UDP específico?
Também podemos.
A documentação atual permite inclusive aplicar filtros TCP considerando flags como:
FIN
SYN
RST
PSH
ACK
URG
ECE
CWREsse nível de filtragem já mostra que estamos muito além de simplesmente executar Ping repetidamente.
Podemos filtrar por porta
Agora imagine um problema clássico de suporte:
o dispositivo responde ao Ping, mas o serviço não funciona.
Essa situação é perfeitamente possível.
ICMP funcionar não garante que determinado serviço TCP esteja disponível.
Um equipamento pode responder:
ping 192.168.1.50e, mesmo assim, determinada comunicação TCP falhar.
O Pktmon permite utilizar portas como parte dos filtros.
Isso possibilita investigar somente o tráfego relacionado ao serviço que realmente interessa.
É uma diferença conceitual importante:
testar o equipamento não é necessariamente testar o serviço.
O equipamento pode estar acessível pela rede enquanto determinada porta, aplicação ou protocolo apresenta problema.
Pktmon Counters: antes de analisar milhares de linhas, conte os pacotes
Uma das funções mais interessantes do Pktmon é:
pktmon countersOs contadores oferecem uma visão de alto nível sobre o fluxo de pacotes pelos componentes monitorados.
Isso é útil porque nem sempre precisamos começar abrindo uma enorme captura.
Primeiro podemos perguntar:
o tráfego esperado apareceu?
Depois:
existem descartes?
E somente então aprofundar a investigação.
A sintaxe atual do comando permite selecionar tipos de contador, inclusive:
all
flow
dropTambém existe a possibilidade de solicitar informações relacionadas ao motivo de descarte.
Por exemplo, a ferramenta oferece a opção:
--drop-reasone um modo de atualização contínua:
--liveEssa abordagem muda completamente a maneira de investigar uma rede.
Pacote perdido na rede não é a mesma coisa que pacote descartado pelo Windows
Essa provavelmente é a distinção mais importante deste artigo.
Imagine que executamos um teste e determinada resposta nunca chega ao computador.
O Windows não pode explicar algo que nunca recebeu.
Nesse cenário, precisamos investigar outros pontos:
- Wi-Fi;
- cabeamento;
- switch;
- roteador;
- provedor;
- caminho externo;
- servidor remoto;
- equipamento de destino.
Agora considere outro cenário.
O pacote chega ao computador, entra na pilha de rede e depois algum componente local o descarta.
Nesse caso, temos um fenômeno completamente diferente.
É justamente nesse tipo de investigação que o Pktmon pode oferecer informações muito interessantes.
A Microsoft documenta que a ferramenta consegue atribuir determinados descartes locais a razões específicas e locais dentro da pilha.
Portanto, precisamos evitar a conclusão:
“perdeu pacote = problema no roteador.”
Assim como devemos evitar:
“perdeu pacote = problema no Windows.”
O objetivo de um diagnóstico técnico é reunir evidências para separar essas possibilidades.
DropReason: quando o Windows consegue explicar por que descartou um pacote
Quando um descarte ocorre em um componente suportado, o Pktmon pode registrar informações associadas ao evento.
Entre elas existe um campo particularmente interessante:
DropReason
Ou seja:
motivo do descarte.
A documentação da Microsoft apresenta exemplos de motivos relacionados a situações como incompatibilidade de MTU ou filtragem de VLAN, além de outros motivos específicos da pilha.
Isso não significa que todo problema de rede produzirá automaticamente uma explicação perfeita.
Mas significa que, em determinadas situações, podemos deixar de trabalhar apenas com:
“alguma coisa deu errado.”
e passar para uma informação muito mais específica sobre onde ou por que o Windows descartou determinado tráfego.
Um exemplo importante: pacote chega, mas não existe serviço esperando por ele
A documentação de diagnóstico da Microsoft apresenta um exemplo muito didático.
Um pacote UDP entra no computador destinado a determinada porta.
O Pktmon registra o descarte e informa um motivo indicando que não existe um endpoint de transporte correspondente.
Em termos mais simples:
o pacote chegou ao computador, mas não havia um socket local associado àquela porta para recebê-lo.
Observe como isso muda completamente a investigação.
Sem essa informação, alguém poderia culpar:
- roteador;
- Wi-Fi;
- firewall externo;
- cabo;
- operadora.
Mas o pacote efetivamente chegou à máquina.
O problema estava em outra etapa.
Esse exemplo mostra por que precisamos investigar o caminho do pacote, e não apenas verificar se o endereço IP responde.
Pktmon substitui o Wireshark?
Não.
Esse ponto precisa ficar muito claro.
O Pktmon e o Wireshark podem inclusive trabalhar de maneira complementar.
O Wireshark é extremamente poderoso para análise detalhada de protocolos e conteúdo de capturas.
Já o Pktmon possui uma vantagem particularmente interessante dentro do Windows:
visibilidade sobre componentes internos da pilha e determinados descartes locais.
A própria documentação atual da Microsoft cita a combinação das informações do Pktmon com análise no Wireshark como uma estratégia capaz de identificar a causa de muitos casos de perda de pacotes.
Portanto, o título deste artigo fala em diagnosticar sem instalar o Wireshark porque podemos começar uma investigação com uma ferramenta que já existe no Windows.
Isso não significa que ferramentas externas deixaram de ser úteis.
E existe outra surpresa: o Pktmon pode gerar PCAPNG
O Pktmon possui o comando:
pktmon etl2pcapEle permite converter um log ETL do Pktmon para o formato PCAPNG.
Isso cria uma ponte muito interessante.
Podemos:
- realizar a captura com o Pktmon;
- aproveitar informações oferecidas pelo Windows;
- converter o arquivo;
- quando necessário, analisar posteriormente a captura em uma ferramenta compatível com PCAPNG.
Ou seja, não precisamos pensar em:
Pktmon OU Wireshark.
Em muitos diagnósticos mais avançados podemos pensar em:
Pktmon + análise de protocolo.
Um diagnóstico melhor começa com uma pergunta melhor
Ferramentas de rede não substituem raciocínio técnico.
Antes de iniciar uma captura, devemos definir exatamente o que queremos descobrir.
Perguntas ruins:
“Minha Internet está ruim. Vou capturar tudo.”
“Minha impressora não funciona. Vou monitorar todos os pacotes.”
“Meu Wi-Fi cai. Vou deixar uma captura enorme rodando.”
Perguntas melhores:
“Quando tento abrir este serviço, o computador envia uma tentativa TCP para o endereço correto?”
“A resposta chega ao computador?”
“Existe algum descarte local?”
“O descarte aparece sempre no mesmo componente?”
“O problema acontece somente com determinado protocolo?”
“Existe diferença entre o momento em que funciona e o momento em que falha?”
Quanto mais específica for a pergunta, melhor podemos configurar os filtros e menor será o ruído da captura.
Não interprete qualquer descarte como defeito
Existe ainda outra armadilha.
Encontrar pacotes descartados não significa automaticamente encontrar a causa do problema percebido pelo usuário.
Sistemas operacionais recebem tráfego que pode ser descartado legitimamente.
Além disso, a própria Microsoft observa que alguma perda de pacotes pode ocorrer sem necessariamente causar um problema perceptível em camadas superiores.
Portanto, o diagnóstico correto exige correlação.
Precisamos relacionar:
horário da falha + comunicação investigada + pacote correspondente + componente + motivo do descarte + comportamento do aplicativo.
É isso que transforma uma captura de pacotes em evidência técnica.
O fluxo correto de investigação com Pktmon
Até aqui já conseguimos construir um método inicial.
Podemos resumir assim:
1. Identificar exatamente o problema
↓
2. Descobrir IP, protocolo ou porta envolvidos
↓
3. Limpar filtros antigos
↓
4. Criar filtros específicos
↓
5. Iniciar o Pktmon
↓
6. Reproduzir a falha
↓
7. Consultar contadores
↓
8. Parar imediatamente a captura
↓
9. Analisar descartes
↓
10. Converter o ETL quando necessárioEssa sequência é muito mais eficiente do que capturar indiscriminadamente vários minutos de tráfego.
E ainda estamos apenas começando.
Na próxima parte vamos entrar no lado mais interessante do Pktmon: montar diagnósticos práticos, interpretar contadores e descartes, trabalhar com filtros por IP, protocolo e porta e entender como diferenciar indícios de um problema local daqueles que apontam para algo fora do Windows.
Fontes técnicas desta parte
A base técnica utilizada foi a documentação oficial da Microsoft sobre o Packet Monitor, sintaxe atual do pktmon, filtros, contadores e o guia de diagnóstico de perda de pacotes do Windows. O texto, exemplos explicativos e organização do artigo foram produzidos originalmente para este post; a documentação foi utilizada para confirmar funcionamento, parâmetros e limitações da ferramenta.
Pktmon na prática: filtros, contadores e diagnóstico de perda de pacotes
Na primeira parte entendemos uma diferença fundamental: detectar que uma comunicação falhou não significa descobrir onde ocorreu a falha.
O Ping pode indicar ausência de determinadas respostas. Porém, isoladamente, ele não consegue afirmar se um pacote desapareceu no Wi-Fi, no roteador, em algum equipamento intermediário, no destino ou se determinado tráfego foi descartado localmente pelo Windows.
Agora podemos avançar para uma investigação mais estruturada.
O objetivo não será simplesmente executar comandos do Pktmon e observar várias linhas aparecendo na tela. Vamos utilizá-lo para responder perguntas específicas.
Uma sequência típica pode ser:
Sintoma
↓
Teste básico
↓
Identificação do IP/protocolo/porta
↓
Filtro
↓
Captura
↓
Reprodução da falha
↓
Contadores
↓
DropReason
↓
InterpretaçãoEssa metodologia é mais importante do que decorar comandos.
Cenário 1: o Ping apresenta perda de pacotes
Imagine um dispositivo da rede local com o endereço:
192.168.1.50Pode ser um computador, servidor, equipamento de rede ou outro dispositivo que aceite ICMP.
Executamos:
ping 192.168.1.50 -tDurante alguns minutos aparecem respostas normais:
Resposta de 192.168.1.50: bytes=32 tempo=2ms TTL=64
Resposta de 192.168.1.50: bytes=32 tempo=3ms TTL=64
Resposta de 192.168.1.50: bytes=32 tempo=2ms TTL=64De repente:
Esgotado o tempo limite do pedido.Logo depois, as respostas voltam.
Essa informação é útil.
Existe uma interrupção ou, pelo menos, uma ausência de resposta ICMP durante aquele momento.
Mas ainda não podemos afirmar:
“o Wi-Fi perdeu o pacote.”
Também não podemos concluir:
“o roteador está com defeito.”
Muito menos:
“o Windows bloqueou o pacote.”
Precisamos de mais evidências.
Primeiro passo: reduza o problema
Antes de abrir qualquer captura, responda:
Qual equipamento estamos investigando?
Neste exemplo:
192.168.1.50Qual protocolo estamos utilizando no teste inicial?
ICMP.
O problema acontece constantemente ou de forma intermitente?
Neste exemplo, intermitentemente.
Essas três informações já permitem criar uma investigação muito mais limpa.
Verifique os filtros existentes
Antes de adicionar qualquer filtro:
pktmon filter listSe existirem filtros antigos que não pertencem ao diagnóstico atual, remova-os:
pktmon filter removeEsse passo parece simples, mas evita um erro bastante perigoso.
Imagine que ontem você tenha criado um filtro para:
192.168.1.100Hoje está investigando:
192.168.1.50Se esquecer a configuração anterior, pode iniciar a captura e concluir:
“O Pktmon não está vendo os pacotes.”
Na realidade, você simplesmente pediu para ele observar outra coisa.
Por isso, desenvolva o hábito:
pktmon filter listantes de cada nova investigação.
Criando um filtro para um endereço IP
Agora podemos adicionar um filtro para o endereço investigado:
pktmon filter add DispositivoTeste -i 192.168.1.50Depois confirme:
pktmon filter listO objetivo é simples: reduzir o volume de tráfego irrelevante.
Sem filtro, o computador pode estar simultaneamente conversando com:
- serviços da Microsoft;
- navegador;
- OneDrive;
- antivírus;
- mensageiros;
- serviços de atualização;
- servidores DNS;
- outros computadores;
- dispositivos da rede local;
- serviços em nuvem.
Nada disso necessariamente interessa ao problema.
Quanto melhor o filtro, mais fácil será analisar o resultado.
Agora iniciamos a captura
Execute:
pktmon start -cDepois reproduza o problema.
No nosso exemplo:
ping 192.168.1.50 -tAguarde até ocorrer o comportamento que queremos investigar.
Assim que ele acontecer, interrompa o Ping com:
Ctrl + Ce finalize a captura:
pktmon stopNão deixe a coleta rodando desnecessariamente.
Capturas pequenas e direcionadas são muito mais fáceis de interpretar.
O que queremos descobrir?
Neste ponto precisamos resistir à tentação de abrir o arquivo e procurar aleatoriamente por alguma linha que pareça suspeita.
A pergunta continua sendo:
o Windows observou algum descarte relacionado à comunicação investigada?
Essa pergunta é diferente de:
“O Ping falhou?”
Já sabemos que ele falhou.
Agora estamos procurando evidências adicionais.
Conhecendo pktmon counters
O comando:
pktmon counterspermite consultar os contadores mantidos pelo Packet Monitor.
Esses contadores podem mostrar informações sobre pacotes processados pelos componentes monitorados.
Entre as possibilidades atuais existem contadores relacionados ao fluxo e aos descartes.
Podemos consultar ajuda específica:
pktmon counters helpou:
pktmon help countersEssa prática é importante porque parâmetros podem evoluir entre versões do Windows.
Em um artigo técnico, decorar um comando é menos importante do que saber consultar a sintaxe efetivamente disponível no sistema.
Contadores de descarte
Quando o objetivo é investigar perdas locais, os contadores de descarte merecem atenção especial.
A sintaxe atual permite trabalhar com o tipo:
dropAlém disso, existe a possibilidade de exibir informações relacionadas aos motivos dos descartes.
Isso cria uma investigação em duas etapas.
Primeiro:
existem descartes registrados?
Depois:
qual motivo foi associado a eles?
Essa ordem evita analisar profundamente uma hipótese que nem sequer apareceu na captura.
O que significa DropReason?
O termo pode ser traduzido literalmente como:
motivo do descarte.
Quando o Pktmon observa determinados descartes dentro dos componentes monitorados, ele pode associar uma razão ao evento.
Isso é extremamente interessante.
Imagine encontrar apenas:
DroppedSabemos que algo foi descartado.
Agora imagine encontrar:
Dropped
DropReason: ...Temos uma pista sobre por que aquilo aconteceu.
A documentação da Microsoft mantém uma lista extensa de razões de descarte utilizadas pela plataforma.
Existem motivos associados a diferentes componentes e condições da pilha de rede.
Por isso, não devemos decorar todos eles.
O procedimento correto é:
Encontrar o DropReason
↓
Identificar o código/nome
↓
Consultar seu significado
↓
Relacionar com o tráfego capturado
↓
Comparar com o sintoma observadoCuidado: DropReason não é uma sentença automática
Suponha que encontramos um descarte.
Isso não significa automaticamente:
“Achamos o defeito.”
O Windows pode descartar tráfego que não deveria ser entregue a uma aplicação.
Pacotes inesperados, tráfego sem destino local válido e várias outras situações podem produzir descartes perfeitamente legítimos.
Portanto, precisamos verificar quatro coisas:
- O descarte ocorreu exatamente no horário da falha?
- O pacote pertence ao endereço que estamos investigando?
- O protocolo e a porta correspondem ao serviço com problema?
- O motivo do descarte é compatível com o sintoma?
Se as quatro respostas apontarem para a mesma direção, nossa evidência fica muito mais forte.
Um exemplo: UDP chega ao computador, mas ninguém está esperando por ele
Esse é um excelente exemplo para compreender a diferença entre problema de rede e problema de serviço.
Imagine que um equipamento envie um datagrama UDP para:
192.168.1.20:5000O pacote atravessa a rede.
Chega à placa de rede.
Entra na pilha do Windows.
Porém, naquele momento, nenhum programa possui um socket UDP correspondente esperando aquela comunicação.
O Windows pode descartar o pacote.
Observe a diferença.
A comunicação:
chegou ao computador.
Portanto, seria incorreto concluir imediatamente:
“o roteador não está entregando os pacotes.”
O roteador entregou.
O problema ocorreu posteriormente.
Talvez o programa responsável pelo serviço:
- não esteja iniciado;
- tenha fechado;
- esteja ouvindo outra porta;
- esteja vinculado a outro endereço;
- tenha falhado;
- esteja configurado incorretamente.
Esse tipo de conclusão é muito mais útil do que simplesmente dizer:
“a rede está com problema.”
Agora pense no cenário contrário
Imagine que estamos esperando uma resposta de:
192.168.1.50Mas não encontramos evidência de que ela tenha chegado ao computador.
Isso também é informação.
Nesse caso, a investigação precisa avançar para fora da máquina.
Podemos começar a considerar:
Computador
↓
Adaptador
↓
Cabo / Wi-Fi
↓
Switch / Access Point
↓
Roteador
↓
Rede intermediária
↓
DestinoSe o pacote nunca entrou no ponto que estamos monitorando, procurar indefinidamente por uma configuração do navegador provavelmente não será produtivo.
O conceito de localização da perda
Uma das melhores formas de pensar em diagnóstico de pacotes é imaginar uma estrada com vários pedágios.
Temos:
A → B → C → D → EO pacote deveria passar por todos.
Se conseguimos demonstrar que ele passou por:
A
B
Cmas não aparece em:
Dreduzimos muito a região provável do problema.
É exatamente esse princípio que torna capturas em múltiplos pontos tão poderosas.
O Pktmon pode observar pacotes em diferentes componentes da pilha do Windows.
Isso permite obter informações que uma captura realizada somente em uma interface pode não mostrar da mesma maneira.
pktmon list: conhecendo os componentes
Execute:
pktmon listEsse comando lista componentes de rede que o Packet Monitor consegue reconhecer.
Dependendo do computador, podemos encontrar diferentes elementos relacionados à infraestrutura de rede.
Essa lista pode variar porque cada máquina possui:
- hardware diferente;
- drivers diferentes;
- adaptadores virtuais diferentes;
- VPNs diferentes;
- recursos do Windows diferentes;
- softwares de terceiros diferentes.
Por isso, não espere que dois computadores apresentem exatamente a mesma estrutura.
Esse é outro motivo para evitar tutoriais que dizem:
“se a linha número 4 estiver diferente, existe defeito.”
Diagnóstico de rede não funciona dessa maneira.
Adaptadores virtuais tornam tudo mais interessante
Um Windows moderno pode ter muito mais interfaces do que o usuário imagina.
Além da placa Ethernet e do Wi-Fi, podem existir interfaces relacionadas a:
- VPN;
- Hyper-V;
- WSL;
- Wi-Fi Direct;
- máquinas virtuais;
- softwares de segurança;
- virtualização;
- containers;
- outros componentes.
Quando um usuário olha apenas para:
Configurações → Rede e Internet
ele pode ter a impressão de que existem somente duas interfaces.
Internamente, a situação pode ser bem mais complexa.
O Pktmon ajuda justamente porque trabalha próximo dessa arquitetura.
Cenário 2: Ping funciona, mas determinada porta não
Agora chegamos a um diagnóstico muito comum.
Imagine:
ping 192.168.1.50Resultado:
Resposta de 192.168.1.50: bytes=32 tempo=1ms TTL=64
Resposta de 192.168.1.50: bytes=32 tempo=1ms TTL=64
Resposta de 192.168.1.50: bytes=32 tempo=2ms TTL=64
Resposta de 192.168.1.50: bytes=32 tempo=1ms TTL=64Alguém conclui:
“A rede está perfeita.”
Não necessariamente.
O único fato demonstrado é que houve resposta ao teste ICMP executado.
Agora imagine que o programa precise acessar uma porta TCP específica.
O equipamento pode responder perfeitamente ao ICMP e o serviço TCP continuar inacessível.
São testes diferentes.
Testando primeiro a porta
Antes de capturar pacotes, podemos utilizar outra ferramenta nativa do Windows:
Test-NetConnection 192.168.1.50 -Port 443Um resultado possível:
ComputerName : 192.168.1.50
RemoteAddress : 192.168.1.50
RemotePort : 443
InterfaceAlias : Wi-Fi
SourceAddress : 192.168.1.20
TcpTestSucceeded : FalseAgora temos uma informação interessante.
O dispositivo pode responder ao Ping, mas o teste TCP para a porta 443 falhou.
A próxima pergunta é:
por quê?
É nesse momento que a captura pode fazer sentido.
Filtrando uma porta TCP
Podemos limpar os filtros:
pktmon filter removeDepois criar um filtro relacionado ao protocolo e à porta que realmente interessa.
A sintaxe exata deve ser conferida no sistema com:
pktmon filter add helpEssa verificação é especialmente importante quando utilizamos filtros mais específicos.
Depois iniciamos a captura:
pktmon start -cExecutamos novamente:
Test-NetConnection 192.168.1.50 -Port 443e encerramos:
pktmon stopAgora a captura está relacionada a uma tentativa concreta.
O handshake TCP ajuda a explicar muita coisa
Para entender esse diagnóstico, precisamos conhecer o princípio básico de estabelecimento de uma conexão TCP.
Simplificando:
Cliente Servidor
SYN ------------------------>
<---------------- SYN/ACK
ACK ------------------------>Esse processo é conhecido como three-way handshake.
Agora imagine:
Cliente Servidor
SYN ------------------------>
SYN ------------------------>
SYN ------------------------>
Nenhuma resposta retorna.
Isso aponta para um tipo de investigação.
Agora:
SYN ------------------------>
<---------------- RST
Temos outro comportamento.
E:
SYN ------------------------>
<---------------- SYN/ACK
ACK ------------------------>
mostra outro cenário completamente diferente.
Perceba como simplesmente dizer:
“a porta não funciona”
esconde informações valiosas.
SYN enviado e nenhuma resposta
Quando observamos tentativas SYN saindo, mas nenhuma resposta retornando, algumas hipóteses possíveis incluem:
- filtragem no caminho;
- firewall;
- serviço remoto inacessível;
- equipamento remoto indisponível;
- problema de roteamento;
- perda de comunicação;
- resposta tomando outro caminho;
- problema intermediário.
Não podemos escolher uma dessas hipóteses apenas olhando um único pacote.
Mas já sabemos algo:
houve uma tentativa de conexão.
SYN seguido de RST
Agora imagine:
SYN →
← RSTIsso é muito diferente de silêncio absoluto.
Existe uma resposta.
Em muitos cenários, isso indica que o destino foi alcançado, mas a conexão foi rejeitada.
Uma hipótese comum seria não existir serviço ouvindo naquela porta.
Novamente:
chegar ao computador não significa que o serviço esteja disponível.
SYN, SYN/ACK e ACK
Se encontramos:
SYN
SYN/ACK
ACKo estabelecimento TCP ocorreu.
Se o aplicativo continua dizendo:
“não foi possível conectar”
precisamos investigar etapas posteriores.
Talvez o problema esteja em:
- TLS;
- autenticação;
- protocolo da aplicação;
- certificado;
- timeout posterior;
- resposta inválida;
- aplicação.
Isso evita perder horas procurando defeito no cabo quando a conexão TCP já foi estabelecida corretamente.
Cenário 3: problema intermitente
Agora imagine um problema ainda mais interessante:
funciona nove vezes e falha na décima.
Esse tipo de falha costuma ser difícil porque quando o técnico executa o teste:
funciona.
Quando vai embora:
falha.
O Pktmon pode ajudar porque conseguimos iniciar uma captura direcionada e reproduzir repetidamente a operação até o problema aparecer.
O segredo novamente é filtrar.
Se deixarmos uma captura completa durante uma hora, teremos uma enorme quantidade de tráfego.
Se capturarmos apenas:
IP específico
+
protocolo específico
+
porta específicao resultado se torna muito mais administrável.
Compare funcionamento e falha
Uma técnica extremamente eficiente consiste em capturar dois momentos.
Captura A — quando funciona
Execute a operação normalmente e registre o tráfego.
Captura B — quando falha
Repita exatamente a mesma operação até ocorrer o problema.
Depois compare.
Por exemplo:
FUNCIONOU
SYN
SYN/ACK
ACK
Dados
RespostaContra:
FALHOU
SYN
SYN
SYNEssa comparação pode valer mais do que dezenas de comandos executados aleatoriamente.
Temos uma referência do comportamento normal e outra do comportamento defeituoso.
Captura sem contexto não resolve diagnóstico
Um arquivo com milhares de pacotes não possui muito valor se não sabemos:
- que horas o problema aconteceu;
- qual operação estava sendo executada;
- qual IP estava envolvido;
- qual porta deveria funcionar;
- qual aplicativo apresentou falha.
Durante um diagnóstico profissional, anote essas informações.
Por exemplo:
14:32:10 — iniciado teste
14:32:18 — serviço respondeu normalmente
14:32:26 — segunda tentativa normal
14:32:41 — aplicação apresentou timeout
14:32:44 — captura encerradaAgora podemos procurar o comportamento existente por volta de:
14:32:41Isso é muito mais eficiente.
pktmon status: confira antes de continuar
Durante a investigação podemos consultar:
pktmon statusEsse comando ajuda a verificar o estado atual do Packet Monitor.
É útil principalmente quando estamos realizando vários testes e não lembramos se determinada coleta ainda está ativa.
Novamente, parece um detalhe.
Mas ferramentas de diagnóstico ficam perigosas quando esquecemos o estado em que foram deixadas.
Resetando os contadores
Entre diferentes testes pode ser interessante zerar os contadores para evitar misturar dados de cenários diferentes.
O Pktmon disponibiliza:
pktmon resetA ideia é começar determinada medição com uma base limpa.
Isso é especialmente importante ao comparar:
teste normal
versus
teste com falhaSe os contadores acumularem eventos anteriores, a comparação fica menos clara.
Transformando ETL em texto
Depois da captura:
pktmon stoppodemos converter o arquivo:
pktmon etl2txt PktMon.etlA conversão produz uma representação textual dos eventos.
Isso permite procurar elementos específicos e estudar a sequência da comunicação.
Mas existe uma limitação prática.
Quanto maior a captura, maior será o arquivo e mais difícil será interpretar tudo manualmente.
Mais uma vez:
filtrar antes é melhor do que procurar depois.
Transformando ETL em PCAPNG
Quando precisamos de uma análise de protocolo mais detalhada, podemos converter a captura:
pktmon etl2pcap PktMon.etlO resultado pode ser utilizado em ferramentas compatíveis com PCAPNG.
Esse recurso é particularmente interessante porque podemos aproveitar duas perspectivas:
Pktmon
↓
Componentes e descartes do Windows
PCAPNG
↓
Análise detalhada dos protocolosNão existe necessidade de escolher apenas uma abordagem.
Onde entra o Wireshark?
Em diagnósticos mais avançados, o Wireshark continua sendo uma ferramenta extremamente poderosa.
Ele pode facilitar a análise de:
- handshake TCP;
- retransmissões;
- DNS;
- TLS;
- HTTP;
- SMB;
- protocolos específicos;
- tempos entre pacotes;
- conversações.
O Pktmon possui outra vantagem:
ele pode fornecer informações relacionadas ao caminho do pacote dentro da pilha do Windows e a determinados descartes locais.
Portanto, um técnico pode começar com:
Ping
↓
Test-NetConnection
↓
Pktmon
↓
DropReasone, quando necessário:
ETL
↓
PCAPNG
↓
WiresharkEssa é uma progressão muito mais racional do que instalar várias ferramentas antes mesmo de saber qual pergunta queremos responder.
Como diferenciar perda externa de descarte local?
Não existe um único comando mágico que responda isso em todos os cenários.
Precisamos combinar evidências.
Considere três situações simplificadas.
Situação A
O computador envia o pacote.
Nenhuma resposta aparece.
Não encontramos um descarte local correspondente.
A investigação deve considerar fortemente elementos externos ao ponto monitorado.
Situação B
O pacote chega ao computador.
O Pktmon registra um descarte local e fornece um DropReason compatível com o problema.
Agora existe evidência para investigar a pilha local, configuração, serviço ou componente relacionado.
Situação C
O pacote chega, atravessa os componentes esperados e alcança a aplicação.
Mesmo assim, o programa apresenta erro.
Talvez o problema esteja acima da camada de transporte.
Podemos precisar investigar:
- protocolo da aplicação;
- autenticação;
- certificado;
- dados;
- configuração;
- servidor.
Observe como cada cenário leva a um caminho diferente.
Não use Pktmon como caça a erros
Existe uma tendência comum quando descobrimos uma ferramenta avançada.
Começamos a executá-la em um computador funcionando normalmente e procuramos qualquer coisa que pareça erro.
Isso pode gerar diagnósticos falsos.
O procedimento deve ser o contrário.
Primeiro:
existe um sintoma concreto.
Depois:
criamos uma hipótese.
Então:
coletamos evidências.
Por fim:
confirmamos ou descartamos a hipótese.
A ferramenta serve ao diagnóstico.
O diagnóstico não deve existir apenas porque encontramos uma linha estranha na ferramenta.
Um método VMIA para investigar perda de pacotes
Podemos organizar o processo em etapas.
Etapa 1 — Defina o sintoma
Não use:
“Internet ruim.”
Prefira:
“O sistema perde comunicação aproximadamente três vezes por hora durante alguns segundos.”
Quanto mais específico, melhor.
Etapa 2 — Identifique o destino
Descubra:
IP
hostname
porta
protocoloquando aplicável.
Etapa 3 — Execute testes simples
Podemos começar com:
pinge, para determinados serviços TCP:
Test-NetConnectionEtapa 4 — Configure filtros
Remova filtros antigos:
pktmon filter removeAdicione somente os necessários.
Etapa 5 — Inicie a captura
pktmon start -cEtapa 6 — Reproduza o problema
Faça exatamente aquilo que costuma falhar.
Etapa 7 — Registre o horário
Anote o momento exato da falha.
Etapa 8 — Encerre rapidamente
pktmon stopEtapa 9 — Analise contadores e descartes
Procure evidências relacionadas ao tráfego investigado.
Etapa 10 — Compare com uma operação normal
Quando possível, capture também uma tentativa bem-sucedida.
O erro mais comum: confundir correlação com causa
Imagine:
14:00 — usuário abre sistema
14:01 — Pktmon registra descarte
14:02 — sistema travaIsso não demonstra automaticamente que aquele descarte causou a falha.
Agora:
Tentativa 1 — funciona — fluxo normal
Tentativa 2 — funciona — fluxo normal
Tentativa 3 — falha — descarte específico
Tentativa 4 — funciona — fluxo normal
Tentativa 5 — falha — mesmo descarte específicoA evidência ficou muito mais interessante.
Repetibilidade importa.
E se o Pktmon não encontrar nada?
Isso também faz parte do diagnóstico.
Não encontrar o descarte esperado pode significar várias coisas:
- o problema ocorreu fora do ponto observado;
- o filtro estava incorreto;
- o tráfego não passou pelo componente esperado;
- a captura começou tarde;
- a captura terminou cedo;
- o problema não aconteceu durante o teste;
- a falha ocorreu em outra camada;
- precisamos utilizar outra ferramenta.
O pior erro seria interpretar:
“Pktmon não mostrou nada”
como:
“a rede está perfeita.”
Uma ferramenta nunca enxerga tudo.
O Pktmon não elimina a necessidade de entender redes
Na realidade, acontece o contrário.
Quanto mais detalhada é a ferramenta, mais importante fica compreender:
- IP;
- TCP;
- UDP;
- ICMP;
- portas;
- interfaces;
- roteamento;
- MTU;
- firewall;
- DNS;
- aplicações.
Sem esses conceitos, uma captura pode parecer apenas um enorme conjunto de números.
Com os conceitos corretos, cada sequência começa a contar uma história.
A pergunta deixou de ser “tem Internet?”
Chegamos a um ponto importante do nosso diagnóstico.
No início, tínhamos perguntas simples:
O Ping responde?
Depois:
Existe perda?
Agora conseguimos fazer perguntas melhores:
A tentativa realmente saiu do computador?
A resposta retornou?
Ela chegou à pilha do Windows?
Algum componente a descartou?
Existe DropReason?
A conexão TCP chegou a ser estabelecida?
O problema aconteceu antes ou depois do handshake?
Esse é o verdadeiro ganho proporcionado por ferramentas como o Pktmon.
Não é simplesmente enxergar mais pacotes.
É conseguir fazer perguntas melhores sobre aquilo que está acontecendo com a comunicação.
Casos reais com Pktmon no Windows 11: Wi-Fi, impressoras, MTU, firewall e VPN
Até aqui, construímos a base.
Já sabemos que o Pktmon pode capturar tráfego, aplicar filtros, registrar contadores e ajudar a identificar determinados descartes dentro da pilha de rede do Windows.
Agora chegamos à parte mais útil para quem trabalha com suporte técnico: aplicar essa ferramenta a problemas concretos.
Porque, na prática, ninguém abre o Terminal pensando:
“Hoje vou estudar o comportamento interno da pilha TCP/IP.”
O que normalmente acontece é algo bem diferente:
“A impressora responde ao Ping, mas não imprime.”
“O Wi-Fi funciona, mas cai várias vezes por dia.”
“No cabo funciona, no Wi-Fi não.”
“A VPN conecta e a Internet para.”
“Alguns sites abrem, outros ficam carregando.”
“O programa diz que não consegue conectar, mas o navegador funciona normalmente.”
É justamente nesses cenários que uma captura bem planejada pode economizar muito tempo.
Caso 1 — A impressora responde ao Ping, mas não imprime
Esse é um dos exemplos mais interessantes porque demonstra perfeitamente a diferença entre:
conectividade com o equipamento
e
funcionamento do serviço.
Imagine uma impressora configurada no endereço:
192.168.1.80Executamos:
ping 192.168.1.80e recebemos respostas normais.
Alguém pode concluir:
“A impressora está funcionando na rede.”
Mas isso é uma conclusão incompleta.
O Ping apenas confirma que existe resposta ICMP.
A impressão depende de outro protocolo e de outra porta.
Dependendo da configuração, podemos encontrar cenários envolvendo RAW TCP, LPR, WSD ou outros mecanismos.
Se a fila estiver configurada para impressão RAW, por exemplo, a porta TCP 9100 é muito comum.
Podemos começar com:
Test-NetConnection 192.168.1.80 -Port 9100Se encontrarmos:
TcpTestSucceeded : Trueisso indica que uma conexão TCP naquela porta conseguiu ser estabelecida durante o teste.
Se encontrarmos:
TcpTestSucceeded : Falsejá sabemos que o problema não pode ser resumido a:
“a impressora está online porque responde ao Ping.”
Agora existe uma diferença clara:
ICMP funciona
TCP 9100 falhaÉ justamente aí que o Pktmon pode ajudar.
Capturando somente a comunicação com a impressora
Podemos começar limpando filtros antigos:
pktmon filter removeDepois adicionamos um filtro relacionado ao IP da impressora:
pktmon filter add Impressora -i 192.168.1.80Em seguida:
pktmon start -cAgora mandamos uma página de teste para a impressora.
Assim que a falha ocorrer:
pktmon stopA captura pode nos ajudar a entender algumas possibilidades.
Possibilidade A — O computador tenta abrir a conexão
Se encontramos tentativas TCP saindo em direção à impressora, sabemos que o Windows tentou iniciar a comunicação.
Isso já elimina algumas hipóteses.
Por exemplo, não estamos mais investigando um caso em que o software simplesmente nunca tentou falar com o equipamento.
A próxima pergunta é:
a impressora respondeu?
Possibilidade B — O SYN sai, mas nada retorna
Podemos encontrar algo equivalente a:
PC → Impressora : SYN
PC → Impressora : SYN
PC → Impressora : SYNsem resposta.
Isso pode apontar para diferentes hipóteses:
- porta não acessível;
- filtragem;
- problema no equipamento;
- Wi-Fi instável;
- comunicação interrompida;
- serviço da impressora indisponível;
- caminho incorreto;
- outro problema entre origem e destino.
Ainda não temos a causa final.
Mas reduzimos bastante o campo de investigação.
Possibilidade C — A impressora responde com RST
Outro cenário:
PC → Impressora : SYN
Impressora → PC : RSTAgora sabemos que o destino respondeu.
Isso é muito diferente de silêncio.
Uma resposta RST pode indicar que a porta não está aceitando conexões naquele momento.
Nesse caso, culpar imediatamente o Wi-Fi provavelmente seria precipitado.
Possibilidade D — O TCP conecta, mas a impressão ainda falha
Agora imagine:
SYN
SYN/ACK
ACKO handshake ocorre.
Mesmo assim, o trabalho de impressão falha.
Nesse ponto precisamos avançar para outras hipóteses:
- spooler;
- driver;
- protocolo utilizado pela fila;
- dados enviados;
- porta configurada incorretamente;
- falha posterior da sessão;
- aplicação;
- firmware do equipamento.
Essa distinção é poderosa porque evita substituir roteador, cabo ou placa de rede sem necessidade.
Caso 2 — A impressora funciona por cabo, mas falha pelo Wi-Fi
Esse cenário permite utilizar comparação controlada.
Imagine um notebook que consegue imprimir normalmente quando conectado por Ethernet.
No Wi-Fi, a impressão apresenta:
- demora;
- interrupções;
- trabalhos presos;
- falhas aleatórias.
O primeiro erro seria concluir:
“O driver está corrompido.”
Se o mesmo computador, mesma fila e mesma impressora funcionam corretamente pelo cabo, existe uma informação muito relevante.
O caminho de rede mudou.
Podemos comparar:
Teste A — Ethernet
Teste B — Wi-FiFaça a mesma operação nos dois cenários.
Capture o tráfego.
Compare:
- tempo de estabelecimento;
- retransmissões;
- ausência de respostas;
- interrupções;
- descartes locais;
- comportamento do fluxo.
Essa comparação pode revelar muito mais do que um teste isolado.
Caso 3 — Internet funciona no cabo e falha no Wi-Fi
Aqui temos outro excelente cenário comparativo.
Conecte o computador por Ethernet.
Execute os testes.
Depois repita pelo Wi-Fi.
Se o comportamento muda apenas ao mudar a interface, começamos a reduzir o número de variáveis.
Podemos investigar:
- driver Wi-Fi;
- interferência;
- potência;
- roaming;
- economia de energia;
- adaptador;
- roteador;
- access point;
- retransmissões;
- congestionamento do canal.
O Pktmon sozinho não mede todos esses fatores de rádio.
Isso é importante.
Ele não substitui ferramentas de análise de espectro ou diagnóstico de sinal.
Mas pode mostrar o comportamento dos pacotes no Windows enquanto o problema ocorre.
Não confunda problema de rádio com problema TCP
Imagine:
Sinal Wi-Fi: excelentee mesmo assim:
retransmissões
timeouts
atrasosO sinal forte não elimina interferência, congestionamento ou outros problemas da camada sem fio.
Da mesma maneira, uma captura TCP com retransmissões não prova automaticamente que o roteador está defeituoso.
Retransmissão significa que algum dado esperado não foi confirmado adequadamente.
Precisamos descobrir por quê.
Caso 4 — O programa perde conexão, mas o navegador continua funcionando
Esse é um dos sintomas mais enganadores.
O usuário diz:
“Minha Internet não caiu porque o YouTube continuou funcionando.”
Ao mesmo tempo, determinado software perdeu a conexão.
Isso é perfeitamente possível.
Diferentes aplicações podem usar:
- servidores diferentes;
- portas diferentes;
- protocolos diferentes;
- tempos de timeout diferentes;
- DNS diferente;
- rotas diferentes;
- conexões persistentes diferentes.
Portanto:
navegador funcionando não significa que todas as comunicações de rede estejam funcionando.
Filtre somente o serviço com problema
Se soubermos o servidor utilizado pelo programa, podemos capturar apenas esse destino.
Por exemplo:
203.0.113.25Podemos filtrar:
pktmon filter add Sistema -i 203.0.113.25Depois:
pktmon start -cReproduzimos a falha e encerramos:
pktmon stopAgora podemos procurar diferenças entre:
conexão normale:
conexão com falhaCaso 5 — MTU incorreta
MTU significa Maximum Transmission Unit.
De forma simplificada, representa o tamanho máximo de um pacote que pode atravessar determinada interface ou caminho sem exigir outro tratamento.
Problemas relacionados à MTU podem gerar sintomas curiosos.
Por exemplo:
- Ping pequeno funciona;
- determinados sites abrem;
- VPN apresenta falha;
- páginas ficam parcialmente carregadas;
- uploads travam;
- alguns serviços funcionam e outros não.
Isso acontece porque tamanhos diferentes de pacote podem se comportar de maneiras diferentes pelo caminho.
Ping pode ajudar a investigar MTU
No Windows, podemos utilizar:
ping destino -f -l tamanhoO parâmetro:
-fsolicita não fragmentar em IPv4.
E:
-ldefine o tamanho da carga útil ICMP.
Por exemplo:
ping 8.8.8.8 -f -l 1472Se o caminho não suportar aquele tamanho, podemos receber uma mensagem indicando necessidade de fragmentação.
Mas cuidado.
O valor do payload não representa sozinho o tamanho total do pacote IP.
Existem cabeçalhos adicionais.
Por isso, o teste precisa ser interpretado corretamente.
Onde o Pktmon entra em um problema de MTU?
A documentação da Microsoft inclui razões de descarte relacionadas a tamanhos ou condições incompatíveis em determinados componentes.
Se o Windows estiver descartando determinado tráfego por um motivo associado à MTU, o Pktmon pode fornecer uma pista importante.
Nesse cenário, não estamos apenas vendo:
“o site não abriu.”
Podemos encontrar evidência de um descarte local.
Isso muda a investigação.
MTU também aparece muito em VPN
VPN adiciona encapsulamento.
Isso significa que o pacote original pode ganhar cabeçalhos adicionais.
Consequentemente, um tamanho que funcionava perfeitamente fora da VPN pode enfrentar limitações depois do encapsulamento.
Daí surgem sintomas como:
VPN conecta
Ping funciona
alguns sistemas abrem
outros travamAntes de culpar DNS, firewall ou aplicação, vale investigar MTU e o caminho dos pacotes.
Caso 6 — VPN conecta e a Internet para
Esse é outro problema clássico.
O usuário ativa a VPN.
O túnel conecta.
Mas:
- Internet deixa de funcionar;
- sites param de abrir;
- somente recursos internos funcionam;
- DNS falha;
- determinado programa perde conectividade.
Esse problema pode envolver:
- rota padrão;
- métricas;
- DNS;
- split tunneling;
- firewall;
- adaptador virtual;
- IPv6;
- política da própria VPN.
Primeiro observe as rotas
No PowerShell:
Get-NetRouteTambém podemos utilizar:
route printCompare antes e depois de conectar a VPN.
Procure alterações na rota padrão.
Por exemplo:
0.0.0.0/0Uma VPN full tunnel pode redirecionar praticamente todo o tráfego através do túnel.
Isso pode ser esperado.
Já em outro cenário, a rota alterada pode gerar conflito.
Pktmon ajuda a responder: por qual interface o tráfego está passando?
Quando existem adaptadores físicos e virtuais, o caminho pode ficar menos óbvio.
Podemos capturar o tráfego relevante e observar os componentes envolvidos.
Isso ajuda a investigar se determinado pacote está seguindo:
Wi-Fi → Internetou:
Wi-Fi → Adaptador VPN → TúnelDependendo da configuração.
Essa informação pode ser crucial.
Caso 7 — Firewall bloqueando uma comunicação
Firewalls podem bloquear tráfego de várias maneiras.
Mas existe uma diferença importante entre:
destino não respondeue:
tráfego foi descartado localmenteSe o pacote chega ao computador e um componente de filtragem o descarta, o Pktmon pode ajudar a fornecer evidências sobre essa etapa.
Isso não significa que qualquer DropReason relacionado a filtragem seja automaticamente culpa do Windows Defender Firewall.
Podem existir outros filtros.
Softwares de segurança, VPNs e aplicações podem instalar componentes próprios na pilha de rede.
Por isso, novamente, precisamos correlacionar o componente e o motivo.
Caso 8 — Antivírus ou software de segurança interfere na conexão
Softwares de segurança modernos podem analisar tráfego de rede.
Alguns utilizam filtros dentro da pilha do Windows.
Se determinado problema começa após instalação ou atualização de um software de segurança, essa hipótese precisa ser testada com cuidado.
O procedimento correto não é simplesmente:
“desative o antivírus.”
Isso pode reduzir a segurança e ainda não produzir uma conclusão confiável.
Melhor:
- identifique o tráfego;
- capture a falha;
- procure descartes;
- identifique componentes envolvidos;
- compare comportamento;
- só então teste alterações controladas.
Caso 9 — Um site específico não abre
Suponha:
Google funciona
Bing funciona
YouTube funciona
site X não funcionaA frase:
“a Internet está funcionando”
é verdadeira apenas em parte.
Existe conectividade geral.
Mas determinado destino apresenta problema.
Antes do Pktmon, podemos testar:
Resolve-DnsName exemplo.comDepois:
Test-NetConnection exemplo.com -Port 443Se DNS funciona, mas TCP 443 falha, já reduzimos o problema.
Agora podemos capturar somente aquele destino.
E se o TCP 443 conecta?
Então o problema pode estar acima dessa camada.
Talvez exista:
- falha TLS;
- certificado;
- proxy;
- navegador;
- aplicação;
- bloqueio por conteúdo;
- problema HTTP;
- servidor remoto.
Mais uma vez, a captura serve para eliminar hipóteses.
Caso 10 — Internet funciona, mas upload trava
Essa situação também pode indicar problemas diferentes de um simples “sem Internet”.
Downloads pequenos podem funcionar.
Navegação pode funcionar.
Mas envio de arquivos grandes falha.
Nesse cenário, pense em:
- MTU;
- perda de pacotes;
- upstream;
- QoS;
- bufferbloat;
- Wi-Fi;
- VPN;
- firewall;
- servidor remoto.
Capturar a sessão pode mostrar retransmissões e interrupções.
Caso 11 — Somente um computador apresenta problema
Imagine três computadores conectados ao mesmo roteador.
Dois funcionam perfeitamente.
Um apresenta falhas.
Esse dado é muito valioso.
Não elimina completamente o roteador, mas muda a probabilidade das hipóteses.
Agora devemos investigar mais atentamente:
- driver;
- adaptador;
- firewall;
- VPN;
- filtro de terceiros;
- configuração IP;
- rota;
- software local.
O Pktmon é especialmente útil nesse tipo de cenário porque permite olhar para dentro da pilha daquele computador específico.
Caso 12 — Todos os computadores apresentam o mesmo problema
Agora o cenário muda.
Se vários dispositivos diferentes falham ao mesmo tempo, existe maior possibilidade de um elemento compartilhado estar envolvido:
- roteador;
- switch;
- access point;
- provedor;
- serviço remoto;
- DNS externo.
O Pktmon de apenas um computador ainda pode ajudar.
Mas não devemos limitar a investigação ao Windows.
Esse ponto é fundamental: o Pktmon não enxerga a rede inteira
O Pktmon enxerga aquilo que passa pelos componentes monitorados daquele Windows.
Ele não consegue magicamente observar:
- interior do roteador;
- rádio do access point;
- switch remoto;
- infraestrutura da operadora;
- servidor externo;
- computador de destino.
Por isso, quando necessário, precisamos combinar outras ferramentas.
Ping
Útil para:
- disponibilidade ICMP;
- latência;
- variações;
- perda aparente;
- testes contínuos.
Exemplo:
ping 192.168.1.1 -tPathPing
Pode combinar informações de rota com medições ao longo do caminho.
Exemplo:
pathping exemplo.comÉ útil principalmente para investigação de caminhos com múltiplos saltos.
Mas seus resultados também precisam ser interpretados com cuidado, pois roteadores podem limitar ou priorizar respostas ICMP de maneira diferente do tráfego encaminhado.
Tracert
Ajuda a visualizar o caminho lógico até determinado destino.
tracert exemplo.comNão é uma ferramenta de captura.
Mas ajuda a contextualizar onde a comunicação está indo.
Test-NetConnection
Excelente para combinar diferentes verificações.
Test-NetConnection exemplo.com -Port 443Pode responder rapidamente se determinada porta TCP consegue ser alcançada.
Wireshark
Muito poderoso quando precisamos analisar profundamente protocolos.
Especialmente:
- TCP;
- TLS;
- DNS;
- HTTP;
- SMB;
- DHCP;
- retransmissões;
- sequência temporal.
Pktmon
O diferencial é observar o tráfego através dos componentes de rede do próprio Windows e fornecer informações sobre determinados descartes locais.
Cada ferramenta responde perguntas diferentes.
Nunca escolha a ferramenta antes da pergunta
Essa regra vale ouro.
Não faça:
“Vou usar Wireshark.”antes de saber qual é o problema.
Nem:
“Vou usar Pktmon.”apenas porque ele parece mais avançado.
Primeiro defina:
o que exatamente eu quero provar ou descartar?
Depois escolha a ferramenta.
Um exemplo completo de diagnóstico
Imagine o seguinte chamado:
“Minha impressora Wi-Fi falha várias vezes por dia. Às vezes imprime e às vezes fica parada.”
Vamos construir uma investigação.
Etapa 1 — Identificar o IP
Exemplo:
192.168.1.80Etapa 2 — Ping contínuo
ping 192.168.1.80 -tObserve se existe perda no mesmo momento da falha.
Etapa 3 — Testar a porta
Se utilizar RAW:
Test-NetConnection 192.168.1.80 -Port 9100Etapa 4 — Verificar filtros
pktmon filter listEtapa 5 — Limpar filtros antigos
pktmon filter removeEtapa 6 — Criar filtro
pktmon filter add Impressora -i 192.168.1.80Etapa 7 — Iniciar captura
pktmon start -cEtapa 8 — Mandar imprimir
Reproduza exatamente o cenário real.
Etapa 9 — Anotar a hora da falha
Por exemplo:
16:48:32Etapa 10 — Encerrar
pktmon stopEtapa 11 — Converter
pktmon etl2txt PktMon.etlEtapa 12 — Interpretar
Agora compare:
- houve tentativa TCP?
- a impressora respondeu?
- houve retransmissão?
- ocorreu descarte local?
- existe DropReason?
- o handshake chegou a completar?
Essa sequência gera evidência técnica.
Não altere cinco coisas ao mesmo tempo
Esse é outro erro clássico de suporte.
O técnico:
- troca DNS;
- redefine Winsock;
- atualiza driver;
- reinicia roteador;
- altera MTU;
- desativa IPv6;
- troca porta.
Depois o problema desaparece.
Mas ninguém sabe por quê.
Isso resolve o chamado?
Talvez.
Mas produz pouco conhecimento.
E se o problema voltar, todo o processo precisará ser repetido.
O diagnóstico correto tenta alterar uma variável por vez.
Capture antes de corrigir quando o problema é intermitente
Quando possível, essa é uma prática muito valiosa.
Se você reiniciar o roteador antes da captura, talvez o problema desapareça.
Então você perde a oportunidade de observar o estado defeituoso.
Em problemas intermitentes, a ordem ideal pode ser:
Problema acontecendo
↓
Captura
↓
Registro
↓
Hipótese
↓
Alteração
↓
Novo testeAssim conseguimos comparar antes e depois.
Privacidade e segurança durante capturas
Capturas de rede podem conter informações sensíveis.
Dependendo do protocolo e do ambiente, um arquivo pode registrar:
- endereços IP;
- nomes de máquinas;
- nomes de servidores;
- consultas DNS;
- metadados de comunicação;
- eventualmente dados de protocolos não criptografados.
Portanto:
não publique capturas completas na Internet sem revisar seu conteúdo.
Também não envie arquivos de captura para desconhecidos sem entender o que eles contêm.
Esse cuidado vale para Pktmon, Wireshark e outras ferramentas semelhantes.
Evite capturas enormes
Uma captura de dez segundos reproduzindo exatamente a falha pode ser muito melhor que uma captura de oito horas.
Quanto maior a coleta:
- mais espaço ocupa;
- mais tráfego irrelevante contém;
- maior a dificuldade de análise;
- maior o risco de registrar dados desnecessários.
Filtros são parte do diagnóstico, não apenas um recurso de desempenho.
O melhor cenário para Pktmon
O Pktmon se torna especialmente interessante quando a pergunta é:
“O pacote chegou ao Windows e foi descartado dentro dele?”
Ou:
“Por quais componentes locais essa comunicação passou?”
Nesses casos, ele oferece uma perspectiva muito útil.
Quando talvez não valha começar pelo Pktmon
Existem problemas em que ferramentas mais simples resolvem mais rapidamente.
Se a máquina recebeu:
169.254.x.xtalvez a primeira pergunta seja sobre DHCP.
Se:
ping 127.0.0.1funciona, mas não existe endereço válido na interface, precisamos investigar configuração IP.
Se DNS é a única suspeita, talvez:
Resolve-DnsNameseja mais útil inicialmente.
Se queremos somente saber se a porta TCP está acessível:
Test-NetConnectioné muito mais rápido.
Comece simples.
Aprofunde quando necessário.
O Pktmon é uma ferramenta de segunda camada de diagnóstico
Podemos imaginar três níveis.
Nível 1 — Testes rápidos
ipconfig
ping
nslookup / Resolve-DnsName
Test-NetConnectionNível 2 — Investigação estruturada
route print
Get-NetRoute
netstat
Get-NetTCPConnection
PktmonNível 3 — Análise profunda
Wireshark
ETW
logs de aplicação
capturas em múltiplos pontos
análise de infraestruturaEssa classificação não é oficial da Microsoft.
É apenas uma forma prática de organizar o diagnóstico.
Por que o Pktmon merece ser conhecido?
Porque ele ocupa um espaço interessante.
Não é tão simples quanto Ping.
Também não exige necessariamente começar por uma ferramenta externa completa de análise de protocolos.
Ele oferece acesso direto a informações internas da pilha de rede do Windows e pode registrar determinados descartes com motivos associados.
Para suporte técnico, isso significa sair de frases genéricas como:
“deve ser o Wi-Fi.”
“deve ser o Windows.”
“deve ser o roteador.”
e tentar responder:
“onde está a evidência?”
Essa mudança de mentalidade é mais importante do que qualquer comando apresentado neste artigo.
O verdadeiro objetivo não é encontrar mais erros
O objetivo é reduzir incerteza.
Um bom diagnóstico deve transformar:
“não funciona”em algo como:
“O computador envia a tentativa TCP, mas não recebe resposta.”Depois:
“A falha acontece apenas pelo Wi-Fi.”Depois:
“No cabo, o mesmo fluxo completa normalmente.”Agora temos uma direção muito mais clara.
Ou:
“O pacote chega ao Windows, mas é descartado localmente.”Isso leva a outra direção.
Diagnóstico é justamente esse processo de transformar um problema amplo em uma causa cada vez mais específica.
Pktmon não é mágico — e isso é uma vantagem
Ferramentas que parecem oferecer uma resposta automática muitas vezes incentivam conclusões automáticas.
O Pktmon exige interpretação.
Isso pode parecer mais difícil.
Mas também obriga o técnico a pensar em:
- origem;
- destino;
- protocolo;
- porta;
- fluxo;
- componente;
- contexto;
- horário;
- comparação.
Esse raciocínio produz diagnósticos melhores.
Depois de entender como capturar tráfego, aplicar filtros, consultar contadores e interpretar descartes, falta uma última etapa: saber quando confiar no Pktmon, quando ele não é suficiente e como encaixá-lo dentro de um diagnóstico maior.
Essa parte é importante porque nenhuma ferramenta resolve todos os cenários.
O Pktmon é poderoso, mas funciona melhor quando sabemos exatamente qual pergunta estamos tentando responder.
O que o Pktmon faz muito bem
O Pktmon é especialmente útil quando queremos observar:
- se determinado tráfego passou pelo Windows;
- quais componentes locais participaram do processamento;
- se houve descarte em algum ponto monitorado;
- qual motivo de descarte foi registrado;
- como determinado fluxo se comporta no momento da falha;
- diferenças entre uma tentativa bem-sucedida e uma tentativa com problema.
Ele se torna muito valioso em falhas intermitentes.
Quando o problema aparece apenas em determinados momentos, uma captura curta e direcionada pode revelar algo que um teste simples não consegue mostrar.
O que o Pktmon não faz sozinho
O Pktmon não deve ser confundido com uma ferramenta que enxerga toda a infraestrutura.
Ele não mostra automaticamente tudo o que acontece dentro de:
- roteadores;
- switches externos;
- access points;
- infraestrutura da operadora;
- servidores remotos;
- outros computadores.
Ele também não substitui uma análise detalhada de protocolos em todos os casos.
Em algumas situações, você pode precisar combinar o Pktmon com:
Ping
PathPing
Tracert
Test-NetConnection
Get-NetRoute
Get-NetTCPConnection
Wireshark
logs de aplicações
logs de firewallA melhor ferramenta depende da pergunta.
O Pktmon também não substitui conhecimento de rede
Isso precisa ficar claro.
Uma ferramenta avançada pode gerar muitos dados.
Mas, se não entendermos conceitos como:
- IP;
- TCP;
- UDP;
- ICMP;
- porta;
- socket;
- rota;
- gateway;
- MTU;
- firewall;
- DNS;
- handshake TCP;
será difícil transformar esses dados em diagnóstico.
O Pktmon não interpreta tudo sozinho.
Ele entrega evidências.
A interpretação continua sendo responsabilidade de quem está analisando.
Erro comum 1 — Capturar tudo
Esse é provavelmente o erro mais frequente.
Executar:
pktmon start -ce deixar o computador funcionando durante muito tempo pode gerar uma captura enorme.
Depois fica difícil descobrir onde está o problema.
O ideal é reduzir o cenário.
Se souber o IP:
filtre por IP.
Se souber a porta:
filtre por porta.
Se souber o protocolo:
filtre por protocolo.
Quanto mais específico o filtro, melhor.
Erro comum 2 — Esquecer filtros antigos
Antes de cada diagnóstico:
pktmon filter listSe necessário:
pktmon filter removeEssa rotina simples evita interpretações erradas.
Erro comum 3 — Achar que qualquer DropReason representa defeito
Encontrar um descarte não significa automaticamente encontrar a causa do problema.
É necessário verificar:
- horário;
- IP;
- protocolo;
- porta;
- fluxo;
- repetibilidade;
- relação com o sintoma.
Um descarte isolado pode não ter importância para o problema investigado.
Erro comum 4 — Concluir que perda de Ping significa defeito local
Se o Ping perdeu uma resposta, isso não prova que o Windows descartou o pacote.
O problema pode estar fora da máquina.
Use o Pktmon para procurar evidências locais.
Se não existir descarte correspondente, continue investigando o caminho externo.
Erro comum 5 — Concluir que Ping funcionando significa rede perfeita
Esse também é muito comum.
Considere:
ping 192.168.1.80funciona.
Mas:
Test-NetConnection 192.168.1.80 -Port 9100falha.
Nesse caso, ICMP e TCP apresentam comportamentos diferentes.
O Ping não testou o serviço utilizado pela aplicação.
Erro comum 6 — Alterar várias configurações de uma vez
Evite:
resetar Winsock
trocar DNS
desativar IPv6
alterar MTU
trocar driver
reiniciar roteadortudo ao mesmo tempo.
Se o problema desaparecer, você não saberá qual alteração resolveu.
Prefira testes controlados.
Uma variável por vez.
Erro comum 7 — Desativar recursos sem saber por quê
É comum encontrar tutoriais dizendo:
“desative IPv6”
“desative firewall”
“desative antivírus”
“mude o MTU”
sem nenhuma evidência.
Essas mudanças podem introduzir novos problemas.
O objetivo do diagnóstico é justamente evitar esse tipo de tentativa aleatória.
Erro comum 8 — Ignorar o horário da falha
Em problemas intermitentes, anote o momento exato em que o erro aconteceu.
Por exemplo:
15:42:18 — falha ocorreuDepois procure os eventos correspondentes.
Sem horário, uma captura grande perde muito valor.
Erro comum 9 — Não comparar com um cenário funcionando
Uma captura de falha é útil.
Mas uma captura normal pode ser ainda mais importante.
Compare:
FUNCIONA
versus
FALHAEssa diferença muitas vezes revela o ponto exato em que o fluxo se altera.
Erro comum 10 — Ignorar a aplicação
Nem todo problema está na rede.
Se o handshake TCP completa normalmente, mas o programa continua falhando, talvez a causa esteja em:
- autenticação;
- certificado;
- protocolo;
- aplicação;
- servidor;
- configuração.
A análise deve subir para a camada seguinte.
Guia rápido: qual ferramenta usar primeiro?
Podemos organizar alguns cenários.
Quero saber se o destino responde
Use:
ping destinoQuero saber se determinada porta TCP responde
Use:
Test-NetConnection destino -Port portaQuero descobrir qual rota o Windows está utilizando
Use:
route printou:
Get-NetRouteQuero saber quais conexões TCP estão abertas
Use:
Get-NetTCPConnectionou:
netstat -anoQuero investigar o caminho até um destino
Use:
tracert destinoQuero analisar perdas ao longo de um caminho
Use:
pathping destinoQuero investigar descartes dentro do Windows
Use:
pktmonQuero analisar protocolos profundamente
Considere:
WiresharkSequência recomendada de diagnóstico
Uma estratégia eficiente pode seguir esta ordem:
1. Identifique o sintoma
2. Descubra destino e serviço
3. Teste IP
4. Teste porta
5. Verifique rota
6. Compare interfaces
7. Capture com Pktmon
8. Procure DropReason
9. Compare normal x falha
10. Aprofunde com Wireshark se necessárioEssa ordem mantém o diagnóstico simples no início e complexo apenas quando necessário.
FAQ — Perguntas frequentes sobre Pktmon no Windows 11
O Pktmon já vem instalado no Windows 11?
Sim.
Ele faz parte do sistema e pode ser chamado diretamente pelo Terminal, PowerShell ou Prompt de Comando.
Teste:
pktmonou:
pktmon helpPreciso abrir o Terminal como administrador?
Para várias operações de captura e diagnóstico, sim.
O ideal é abrir o Terminal do Windows com privilégios administrativos.
O Pktmon funciona no PowerShell?
Sim.
Embora o Pktmon seja um executável do Windows, você pode chamá-lo normalmente dentro do PowerShell.
O Pktmon substitui o Ping?
Não.
O Ping testa comunicação ICMP.
O Pktmon observa tráfego dentro da pilha de rede do Windows e pode registrar descartes.
Eles respondem perguntas diferentes.
O Pktmon substitui o Wireshark?
Também não.
O Wireshark continua excelente para análise profunda de protocolos.
O diferencial do Pktmon está principalmente na integração com a pilha de rede do Windows e na possibilidade de registrar descartes locais.
Posso abrir a captura do Pktmon no Wireshark?
Sim.
Você pode converter ETL para PCAPNG.
Exemplo:
pktmon etl2pcap PktMon.etlDepois, o arquivo resultante pode ser aberto em ferramentas compatíveis.
Como transformar a captura em texto?
Use:
pktmon etl2txt PktMon.etlComo iniciar a captura?
Um exemplo simples:
pktmon start -cComo parar?
Use:
pktmon stopComo listar filtros?
Use:
pktmon filter listComo remover filtros antigos?
Use:
pktmon filter removeComo verificar o estado do Pktmon?
Use:
pktmon statusComo consultar contadores?
Use:
pktmon countersO que é DropReason?
É uma indicação do motivo pelo qual determinado pacote foi descartado em um componente monitorado.
Nem todo descarte representa um defeito.
Ele precisa ser analisado no contexto correto.
Pktmon consegue mostrar perda no roteador?
Não diretamente.
Ele observa o que acontece no Windows.
Para diagnosticar roteadores ou outros equipamentos, você precisará combinar outras ferramentas e medições.
Pktmon consegue diagnosticar Wi-Fi?
Ele pode ajudar a observar o comportamento dos pacotes no Windows durante uma falha Wi-Fi.
Mas não substitui ferramentas de análise de rádio, interferência, canais e sinal.
Pktmon serve para impressoras?
Sim.
Pode ser muito útil quando a impressora responde ao Ping, mas o serviço de impressão apresenta falhas.
Você pode combinar:
ping IP_DA_IMPRESSORAcom:
Test-NetConnection IP_DA_IMPRESSORA -Port 9100e, quando necessário, usar o Pktmon para capturar o fluxo.
Por que a impressora responde ao Ping, mas não imprime?
Porque Ping e impressão usam mecanismos diferentes.
O ICMP pode funcionar enquanto a porta de impressão, o driver, o spooler ou outro componente apresenta problema.
Pktmon ajuda em problemas com VPN?
Sim.
Principalmente quando queremos observar tráfego passando por adaptadores virtuais ou investigar mudanças no caminho da comunicação.
Também vale combinar com:
Get-NetRoutePktmon pode mostrar problemas de MTU?
Em alguns cenários, pode registrar descartes relacionados a tamanho de pacote ou características do caminho.
Mas o diagnóstico de MTU também pode exigir outros testes.
Posso deixar o Pktmon capturando o dia inteiro?
Tecnicamente é possível em determinados cenários, mas não é a melhor prática para um diagnóstico comum.
Capturas longas geram muito ruído.
Prefira filtros específicos e períodos curtos.
Existe risco de privacidade?
Sim.
Capturas de rede podem registrar metadados e, dependendo do protocolo, até conteúdo não criptografado.
Revise os arquivos antes de compartilhar.
Conclusão
O Pktmon é uma daquelas ferramentas que permanecem escondidas no Windows até o momento em que começamos a procurar respostas mais profundas.
O Ping consegue mostrar que determinada resposta não chegou.
O Test-NetConnection consegue verificar uma porta TCP.
O Tracert consegue mostrar parte do caminho.
O PathPing pode ajudar na análise de perdas ao longo da rota.
Mas o Pktmon acrescenta outra perspectiva:
o que aconteceu com o pacote dentro do próprio Windows?
Essa pergunta pode fazer enorme diferença.
Em vez de trocar roteador, resetar rede, alterar DNS ou reinstalar driver sem uma hipótese clara, podemos coletar evidências.
O pacote saiu?
A resposta chegou?
Algum componente local descartou?
Existe DropReason?
O handshake TCP completou?
A falha acontece apenas no Wi-Fi?
No cabo funciona?
O comportamento muda com a VPN?
Essas perguntas transformam um diagnóstico genérico em uma investigação técnica.
E esse é provavelmente o maior valor do Pktmon.
Ele não serve apenas para capturar pacotes.
Ele ajuda a abandonar o método de tentativa e erro e trabalhar com evidências.
CTA VMIA
Problemas de rede nem sempre aparecem como uma mensagem clara de erro.
Às vezes, a Internet funciona normalmente durante horas e falha apenas em determinados programas. Em outros casos, uma impressora responde ao Ping, mas não imprime. Também existem situações em que o Wi-Fi parece ter sinal forte, mas apresenta perdas, lentidão ou interrupções.
A VMIA realiza diagnóstico e configuração de computadores Windows, redes domésticas, Wi-Fi, roteadores, impressoras e problemas de conectividade.
O atendimento pode ser realizado por acesso remoto ou visita técnica, conforme o tipo de problema.
Se sua rede apresenta falhas difíceis de identificar, um diagnóstico baseado em testes e evidências pode evitar trocas desnecessárias de equipamentos e alterações aleatórias no Windows.
VMIA — Manutenção e Configuração
Site: https://vmia.site
Blog: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Avaliações: https://avaliacao.vmia.com.br
Telefone / WhatsApp: (11) 99779-7772
Atendimento com agendamento.
Faça um comentário