Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
Bonjour, Ce qui est bizarre c'est que la requête HTTP est envoyée à moitié dans le paquet 6 (81 octets) et à moitié dans le paquet 8 (44 octets) alors que la carte indus annonce un MSS de 536. La carte aurait pu mettre toutes les données dans un seul paquet. C'est peut-être une piste... Cordialement, Thomas 24 déc. 2023 13:14:04 Stéphane Rivière : > Boujour et bon courage à celles et ceux de permanence ou d'astreinte :) > > > Si quelqu'un a une idée ou a déjà rencontré un cas similaire... j'avoue être > en manque d'inspiration... > > C'est pour une application avec des cartes industrielles (PIC 32 bits, codage > en C, utilisation des stacks et libs MICROCHIP) reliées à des routeurs 4G (la > même manip que le message sur les QRC). > > Rien d'extravaguant. Tout étant implémenté, avec OpenVPN, un proxy Nginx en > frontal et un serveur HTTP GET/POST basique implémenté en Ada par mes soins. > > Je me retrouve avec des erreurs 408 (timout au niveau du proxy Nginx) > *uniquement avec la carte indus* (qui envoie juste une URL GET similaire à > celle ci-dessous). > > *Aucune erreur si j'envoie par FF une URL similaire : > *172.31.0.1:8081/231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342?* > * > > 172.31.0.3 - - [24/Dec/2023:11:19:37 +0100] "GET > /231224111843085123030003062C3031323353616C7574206C657320706F7465733738391F5C? > HTTP/1.1" *408* 0 "-" "-" < la *carte indus* > 172.31.0.3 - - [24/Dec/2023:11:20:48 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" *408* 0 "-" "-"< *la carte indus* > 172.31.0.2 - - [24/Dec/2023:11:36:58 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) > Gecko/20100101 Firefox/103.0" > 172.31.0.2 - - [24/Dec/2023:11:37:10 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) > Gecko/20100101 Firefox/103.0" > 172.31.0.2 - - [24/Dec/2023:11:37:12 +0100] "GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) > Gecko/20100101 Firefox/103.0" > > > En utilisant Tshark pour se brancher sur le VPN, filtrer les paquets TCP sur > le port 8081 pour des trames HTTP uniquement. > > *Essai avec FF : OK - *avec l'URL > 172.31.0.1:8081/231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342?* > * > > Tshark *détecte le trafic comme étant bien des trames HTTP* : voir en gras > ci-dessous* > * > > root@* /etc/openvpn >tshark -i tun0 -d tcp.port==8081,http -f "port 8081" > Running as user "root" and group "root". This could be dangerous. > Capturing on 'tun0' > 1 0.0 172.31.0.2 ? 172.31.0.1 TCP 52 55372 ? 8081 [ACK] Seq=1 > Ack=1 Win=501 Len=0 TSval=2641523022 TSecr=3450216110 > 2 0.47455 172.31.0.1 ? 172.31.0.2 TCP 52 [TCP ACKed unseen > segment] 8081 ? 55372 [ACK] Seq=1 Ack=2 Win=66 Len=0 TSval=3450226350 > TSecr=2641492368 > 3 0.807369694 172.31.0.2 ? 172.31.0.1 *HTTP* 489 [TCP Previous segment > not captured] GET > /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? > HTTP/1.1 > 4 0.814896905 172.31.0.1 ? 172.31.0.2 *HTTP* 205 [TCP ACKed unseen > segment] HTTP/1.1 404 Not Found (text/plain) > > La transaction se limite à 4 lignes. *RAS... > * > > * > * > > *Essai avec la carte indus : KO* - on dirait que la pile TCP/IP pose problème > mais ce ne sont que des suppositions, je ne peux pas déverminer coté carte. > > Tshark*ne détecte pas de trame HTTP* > > J'ai rayé le trafic concernant le PC portable > > root@* /etc/openvpn >tshark -i tun0 -d tcp.port==8081,http -f "port 8081" > Running as user "root" and group "root". This could be dangerous. > Capturing on 'tun0' > 1 0.0 172.31.0.2 ? 172.31.0.1 TCP 52 55372 ? 8081 [ACK] Seq=1 > Ack=1 Win=501 Len=0 TSval=2641574990 TSecr=3450268108 > 2 0.48117 172.31.0.1 ? 172.31.0.2 TCP 52 [TCP ACKed unseen > segment] 8081 ? 55372 [ACK] Seq=1 Ack=2 Win=67 Len=0 TSval=3450278328 > TSecr=2641523888 > / 3 1.486198007 172.31.0.3 ? 172.31.0.1 TCP 44 1032 ? 8081 [SYN] Seq=0 > Win=1200 Len=0 MSS=536 > 4 1.486247826 172.31.0.1 ? 172.31.0.3 TCP 44 8081 ? 1032 [SYN, ACK] > Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 > 5 1.526477917 172.31.0.3 ? 172.31.0.1 TCP 40 1032 ? 8081 [ACK] Seq=1 > Ack=1 Win=1200 Len=0 > 6 1.534424273 172.31.0.3 ? 172.31.0.1 TCP 121 1032 ? 8081 [PSH, ACK] > Seq=1 Ack=1 Win=1200 Len=81 [TCP segment of a reassembled PDU] > 7 1.534506612 172.31.0.1 ? 172.31.0.3 TCP 40 8081 ? 1032 [ACK] Seq=1 > Ack=82 Win=65535 Len=0/ > 8 1.534556251 172.31.0.3 ? 172.31.0.1 *TCP* 84 GET > /231224121420085123030006062C3031323353616C7574206C657320706F746573373839C50E? >
Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
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/
[TECH] [FRnOG] [MISC] Erreur HTTP 408
Boujour et bon courage à celles et ceux de permanence ou d'astreinte :) Si quelqu'un a une idée ou a déjà rencontré un cas similaire... j'avoue être en manque d'inspiration... C'est pour une application avec des cartes industrielles (PIC 32 bits, codage en C, utilisation des stacks et libs MICROCHIP) reliées à des routeurs 4G (la même manip que le message sur les QRC). Rien d'extravaguant. Tout étant implémenté, avec OpenVPN, un proxy Nginx en frontal et un serveur HTTP GET/POST basique implémenté en Ada par mes soins. Je me retrouve avec des erreurs 408 (timout au niveau du proxy Nginx) *uniquement avec la carte indus* (qui envoie juste une URL GET similaire à celle ci-dessous). *Aucune erreur si j'envoie par FF une URL similaire : *172.31.0.1:8081/231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342?* * 172.31.0.3 - - [24/Dec/2023:11:19:37 +0100] "GET /231224111843085123030003062C3031323353616C7574206C657320706F7465733738391F5C? HTTP/1.1" *408* 0 "-" "-" < la *carte indus* 172.31.0.3 - - [24/Dec/2023:11:20:48 +0100] "GET /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? HTTP/1.1" *408* 0 "-" "-"< *la carte indus* 172.31.0.2 - - [24/Dec/2023:11:36:58 +0100] "GET /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0" 172.31.0.2 - - [24/Dec/2023:11:37:10 +0100] "GET /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0" 172.31.0.2 - - [24/Dec/2023:11:37:12 +0100] "GET /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0" En utilisant Tshark pour se brancher sur le VPN, filtrer les paquets TCP sur le port 8081 pour des trames HTTP uniquement. *Essai avec FF : OK - *avec l'URL 172.31.0.1:8081/231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342?* * Tshark *détecte le trafic comme étant bien des trames HTTP* : voir en gras ci-dessous* * root@* /etc/openvpn >tshark -i tun0 -d tcp.port==8081,http -f "port 8081" Running as user "root" and group "root". This could be dangerous. Capturing on 'tun0' 1 0.0 172.31.0.2 ? 172.31.0.1 TCP 52 55372 ? 8081 [ACK] Seq=1 Ack=1 Win=501 Len=0 TSval=2641523022 TSecr=3450216110 2 0.47455 172.31.0.1 ? 172.31.0.2 TCP 52 [TCP ACKed unseen segment] 8081 ? 55372 [ACK] Seq=1 Ack=2 Win=66 Len=0 TSval=3450226350 TSecr=2641492368 3 0.807369694 172.31.0.2 ? 172.31.0.1 *HTTP* 489 [TCP Previous segment not captured] GET /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? HTTP/1.1 4 0.814896905 172.31.0.1 ? 172.31.0.2 *HTTP* 205 [TCP ACKed unseen segment] HTTP/1.1 404 Not Found (text/plain) La transaction se limite à 4 lignes. *RAS... * * * *Essai avec la carte indus : KO* - on dirait que la pile TCP/IP pose problème mais ce ne sont que des suppositions, je ne peux pas déverminer coté carte. Tshark*ne détecte pas de trame HTTP* J'ai rayé le trafic concernant le PC portable root@* /etc/openvpn >tshark -i tun0 -d tcp.port==8081,http -f "port 8081" Running as user "root" and group "root". This could be dangerous. Capturing on 'tun0' 1 0.0 172.31.0.2 ? 172.31.0.1 TCP 52 55372 ? 8081 [ACK] Seq=1 Ack=1 Win=501 Len=0 TSval=2641574990 TSecr=3450268108 2 0.48117 172.31.0.1 ? 172.31.0.2 TCP 52 [TCP ACKed unseen segment] 8081 ? 55372 [ACK] Seq=1 Ack=2 Win=67 Len=0 TSval=3450278328 TSecr=2641523888 / 3 1.486198007 172.31.0.3 ? 172.31.0.1 TCP 44 1032 ? 8081 [SYN] Seq=0 Win=1200 Len=0 MSS=536 4 1.486247826 172.31.0.1 ? 172.31.0.3 TCP 44 8081 ? 1032 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 5 1.526477917 172.31.0.3 ? 172.31.0.1 TCP 40 1032 ? 8081 [ACK] Seq=1 Ack=1 Win=1200 Len=0 6 1.534424273 172.31.0.3 ? 172.31.0.1 TCP 121 1032 ? 8081 [PSH, ACK] Seq=1 Ack=1 Win=1200 Len=81 [TCP segment of a reassembled PDU] 7 1.534506612 172.31.0.1 ? 172.31.0.3 TCP 40 8081 ? 1032 [ACK] Seq=1 Ack=82 Win=65535 Len=0/ 8 1.534556251 172.31.0.3 ? 172.31.0.1 *TCP* 84 GET /231224121420085123030006062C3031323353616C7574206C657320706F746573373839C50E? HTTP/1.1 [TCP segment of a reassembled PDU] 9 1.534571758 172.31.0.1 ? 172.31.0.3 TCP 40 8081 ? 1032 [ACK] Seq=1 Ack=126 Win=65535 Len=0 10 6.586207028 172.31.0.3 ? 172.31.0.1 TCP 46 [TCP Keep-Alive] 1032 ? 8081 [ACK] Seq=125 Ack=1 Win=1200 Len=1 [TCP segment of a reassembled PDU] 11 6.586259191 172.31.0.1 ? 172.31.0.3 TCP 40 [TCP Keep-Alive ACK] 8081 ? 1032 [ACK] Seq=1 Ack=126 Win=65535 Len=0 12 10.259594542 172.31.0.2 ? 172.31.0.1 TCP 52 [TCP Dup ACK 1#1] 55372 ? 8081 [ACK] Seq=1 Ack=1 Win=501 Len=0
