On 24/12/2023 13:12, Stéphane Rivière wrote:
[...]
Pour confirmer la forme de l'installation :
* On a des cartes industrielles (C) (basées sur microprocesseur PIC)
raccordées à un modem 4G. Ces cartes ont un client HTTP.
* On a un serveur HTTP (S) codé en Ada (ailleurs que sur les cartes).
* On a un reverse-proxy HTTP (P) Nginx (ailleurs que sur les cartes).
* On a une machine (H) quelque-part sur le VPN, qui est capable de faire
tourner tshark.
* Tout ce beau monde communique sur un VPN basé sur OpenVPN.
Le client HTTP sur les cartes réalisent des requêtes HTTP vers le
reverse-proxy HTTP, on a donc le schéma "réseau" suivant :
|=[ Tunnel OpenVPN ]=|
[Client HTTP] ---------------------------> [Reverse-proxy HTTP]
|====================|
Ta première capture tshark a été réalisée sur la machine H avec Firefox
en guise de client, et a écouté l'interface OpenVPN.
Ta deuxième capture tshark a aussi été réalisée sur la machine H, mais
en écoute seulement, aussi sur l'interface OpenVPN.
J'ai extrapolé des trucs, est-ce que c'est quand même bon ?
Pour moi, sans pouvoir voir les données, la deuxième capture ne révèle
pas de problème au niveau TCP, si ce n'est l'étrange fragmentation, mais
ce n'est pas si surprenant pour de l'embarqué. À ce stade, je dirais que
le problème se trouve au niveau du payload TCP, il faudrait que tu
affiches les données pour en savoir plus. En tous cas, du SYN au FIN, la
communication semble normale.
Je ne connais pas tshark, et je ne comprend pas d'où vient l'affichage
du début de requête GET. Est-ce qu'il affiche ça parce que le serveur a
ACK ce morceau ? Ce n'est pas cohérent avec la quantité de données
acknowledged par le serveur de toute façon. J'imagine que s'il ne
l'affiche pas comme étant une requête HTTP, c'est que le flux est mal formé.
- Léo
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
