Calculer Girl
  1. Calculer Girl
  3. wireshark et tcpdump -r: tailles de fenêtres tcp étranges
Intereting Posts
Passer des parameters wParam / lParam supplémentaires? npm install échouant Problème d’écriture sur PHP Meilleure façon de communiquer entre .NET et l’application C ++ native Puis-je demander à Nginx de consigner différemment certains types de requêtes? Chaîne vide analysant le résultat de la commande ntpq Comment installer wraith sur Windows 7 Copier le fichier du dossier d’installation de l’application vers le stockage local Django – Fin de la sortie du script avant les en-têtes Quelle est la solution de contournement pour “sortinger” la limitation de la commande à 65535 caractères par ligne? htaccess fonctionne dans localhost mais ne fonctionne pas dans l’instance EC2 Garder une trace des processus enfants dans Unix Une erreur s’est produite lors de l’installation de sqlite3 (1.3.7), et Bundler ne peut pas continuer Impossible de créer des applications rail Accédez à la directive apache errordocument de PHP Ports Gitlab 80 et 8080 pris par une instance Gitlab distincte?

wireshark et tcpdump -r: tailles de fenêtres tcp étranges

Je saisis le trafic http avec tcpdump et je m’intéresse au démarrage lent de TCP et à la manière dont les tailles de fenêtre augmentent: 

$ sudo tcpdump -i eth1 -w wget++.tcpdump tcp and port 80

Lorsque je visualise le fichier de vidage avec Wireshark, la progression des tailles de fenêtre semble normale, à savoir 5840, 5888, 5888, 8576, 11264, etc.

Mais quand je regarde le fichier de vidage via 

 $ tcpdump -r wget++.tcpdump -tnN | less

Je reçois ce qui semble être des tailles de fenêtres insensées (adresses IP omises pour des raisons de concision): 

 : S 1069713761:1069713761(0) win 5840  : S 1198053215:1198053215(0) ack 1069713762 win 5672  : . ack 1 win 46  : . 1:1419(1418) ack 1 win 46  : P 1419:2002(583) ack 1 win 46  : . ack 1419 win 133  : . ack 2002 win 178

Est-il possible d’obtenir des tailles de fenêtre normales / absolues sur la ligne de commande?

Les dimensions des fenêtres sont correctes – elles ne sont pas calibrées.

L’initiateur de la connexion a défini un wscale (facteur d’échelle de la fenêtre) de 7, de sorte que ses valeurs de win suivantes doivent être multipliées par 128 pour obtenir la taille de la fenêtre en octets. Ainsi, le win 46 indique une fenêtre de 5888 octets.

Le destinataire de la connexion a défini une wscale de 6, de sorte que ses valeurs de win doivent être multipliées par 64. Ainsi, le win 133 indique une fenêtre de 8512 octets et le win 178 indique 11392 octets.

De plus, si l’outil (wireshark ou tcpdump, ça n’a pas d’importance) ne voit pas le syn, il doit imprimer la valeur non calibrée, ce qui peut vous tromper