Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
Bon, le client a trouvé vers 19h, ça venait de chez lui et c'était assez étrange en fait... Une trame GET mal formée avec un espace au lieu d'un %20 entre la fin de l'URL et le http/1.1 aurait suffit à pourrir la chose ainsi... Je n'ai pas d'opinion mais je vous remercie beaucoup de m'avoir aidé à affiner le truc et à déterminer que, vraisemblablement, le pb ne venait pas de notre coté... L'essentiel étant d'aller de l'avant ! Bonne fêtes renouvelées... -- Stéphane Rivière Ile d'Oléron - France --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
Hello Richard (et tous) ! Tu peux remplacer les urls par les IP? Au cas ou… Déjà fait. Aucun changement. Réduit ton MTU à 1300 . Chez Bouygues il y avait des problèmes de fragmentation sur les VPN et un client avait pas mal joué sur la MTU Fait ce matin. Coté serveur et client. Aucun changement. tun-mtu 1340 mssfix 1300 Ici c'est du SFR... Si je connecte un FF au routeur 4G la (toute petite) trame de test passe crème, donc j'ai du mal à taper sur le routeur 4G/VPN et le réseau associé (mais bon, j'affirme rien). FF : 172.31.0.2 - - [26/Dec/2023:12:50:24 +0100] "GET /231224111955085123030004062C3031323353616C7574206C657320706F7465733738396342? HTTP/1.1" 404 6 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0" Carte indus : Émision, gros timeout puis 172.31.0.2 - - [26/Dec/2023:12:50:35 +0100] "GET /23122612495008512303000F062C3031323353616C7574206C657320706F746573373839AF62? HTTP/1.1" 408 0 "-" "-" La balle est dans le camp du client ;> *MERCI à tous ceux qui m'ont aidé, en public ou privé !!!* *Et bonnes fêtes à toutes et tous :)* -- Stéphane Rivière Ile d'Oléron - France --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
Bonjour, Bonne fêtes à tous. Tu peux remplacer les urls par les IP? Au cas ou… Réduit ton MTU à 1300 . Chez Bouygues il y avait des problèmes de fragmentation sur les VPN et un client avait pas mal joué sur la MTU Richard Envoyé de mon iPhone > Le 25 déc. 2023 à 11:50, Stéphane Rivière a écrit : > > Bonjour Thomas, > Entre temps, sur la suggestion de Xavier, qui avait vu comme toi d'aller > creuser dans les coins, j'ai bien vérifié les MTU partout (qui sont tous à > 1500 sauf un à 1460) et connecté un FF sur le routeur 4G pour envoyer une > trame et vérifier que tout allait bien. > Donc il est probable que le pb se situe sur la carte indus. J'ai maté (en > diagonale et à coup de Ctrl-F) les 800 pages de doc de la stack TCP/IP > Microchip et pêché quelques indications au client, qu'il lira demain, afin de > vérifier certains #defines... >> 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. > > Ah je l'avais pas vu ça, tu as raison... > >> C'est peut-être une piste... > > Certainement ! > > Merci pour ton aide aussi :) > > -- > Stéphane Rivière > Ile d'Oléron - France > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
Bonjour Thomas, Entre temps, sur la suggestion de Xavier, qui avait vu comme toi d'aller creuser dans les coins, j'ai bien vérifié les MTU partout (qui sont tous à 1500 sauf un à 1460) et connecté un FF sur le routeur 4G pour envoyer une trame et vérifier que tout allait bien. Donc il est probable que le pb se situe sur la carte indus. J'ai maté (en diagonale et à coup de Ctrl-F) les 800 pages de doc de la stack TCP/IP Microchip et pêché quelques indications au client, qu'il lira demain, afin de vérifier certains #defines... 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. Ah je l'avais pas vu ça, tu as raison... C'est peut-être une piste... Certainement ! Merci pour ton aide aussi :) -- Stéphane Rivière Ile d'Oléron - France --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] [FRnOG] [MISC] Erreur HTTP 408
Bonjour Léo, 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. oui * On a un serveur HTTP (S) codé en Ada (ailleurs que sur les cartes). Sur l'instance de test H * On a un reverse-proxy HTTP (P) Nginx (ailleurs que sur les cartes). Sur l'instance de test H * On a une machine (H) quelque-part sur le VPN, qui est capable de faire tourner tshark. Sur l'instance de test H * Tout ce beau monde communique sur un VPN basé sur OpenVPN. oui 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]*> Serveur HTTP basique GET/POST* || 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. oui Ta deuxième capture tshark a aussi été réalisée sur la machine H, mais en écoute seulement, aussi sur l'interface OpenVPN. oui J'ai extrapolé des trucs, est-ce que c'est quand même bon ? T'as tout compris 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é. Oui, il semble. J'ai même changé le câble ethernet entre la carte indus et le routeur 4G pour dire... Donc je vois demain avec le client... Merci pour ton aide :) -- Stéphane Rivière Ile d'Oléron - France --- Liste de diffusion du FRnOG http://www.frnog.org/
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
