diff --git a/blog/2025-12-02-ssh-freeze-mtu-mss-clamping.md b/blog/2025-12-02-ssh-freeze-mtu-mss-clamping.md
new file mode 100644
index 0000000..079bef5
--- /dev/null
+++ b/blog/2025-12-02-ssh-freeze-mtu-mss-clamping.md
@@ -0,0 +1,189 @@
+---
+slug: ssh-freeze-mtu-mss-clamping
+title: Freeze de session SSH, MTU et MSS clamping
+authors: [tellserv]
+tags: [openwrt, gretap, ssh, mtu, networking]
+image: /img/blog/2025-12-02-ssh-freeze-mtu/freeze_session_ssh.png
+---
+
+
+ 
+
+
+Après avoir déployé des tunnels GREtap pour étendre mes VLANs à travers mon mesh WiFi OpenWRT, j'ai rencontré un problème frustrant : mes sessions SSH se figeaient aléatoirement et nécessitaient un redémarrage complet. La cause ? Un problème classique de MTU et de fragmentation. Voici comment le MSS clamping a résolu le problème.
+
+
+
+## Le symptôme : sessions SSH qui gèlent
+
+Le problème était particulièrement gênant lors de l'administration à distance :
+
+- Les sessions SSH fonctionnaient normalement pendant quelques minutes
+- Puis soudainement, la session se figeait complètement
+- Aucun retour, aucune erreur, juste un terminal figé
+- Impossible de taper quoi que ce soit, même Ctrl+C ne fonctionnait pas
+- Seule solution : fermer le terminal et rouvrir une nouvelle connexion
+
+
+
+*Les sessions SSH se figeaient sans message d'erreur.*
+
+Ce comportement était intermittent mais systématique : toutes les sessions finissaient par geler après un certain temps d'utilisation.
+
+## Comprendre le MTU et son impact
+
+### Qu'est-ce que le MTU ?
+
+Le **MTU (Maximum Transmission Unit)** représente la taille maximale d'un paquet réseau qui peut être transmis sans fragmentation. Sur Ethernet classique, le MTU standard est de **1500 octets**.
+
+### Le problème avec les tunnels
+
+Les protocoles de tunneling comme GREtap ajoutent des en-têtes supplémentaires à chaque paquet :
+
+- **En-tête GRE** : 4 octets (protocole de tunnel)
+- **En-tête IP externe** : 20 octets (pour le routage du tunnel)
+- **En-tête Ethernet interne** : 14 octets (pour le trafic transporté)
+
+**Total de l'overhead GREtap** : environ **38 octets**
+
+Cela signifie que pour un paquet de **1500 octets** à transmettre :
+- Taille réelle après encapsulation : **1538 octets**
+- Dépassement du MTU Ethernet : **38 octets** de trop
+
+### Le WiFi mesh aggrave le problème
+
+Sur un backhaul WiFi mesh, le problème est encore plus marqué :
+
+- Le WiFi mesh ajoute ses propres en-têtes
+- La fragmentation WiFi est moins efficace que sur Ethernet filaire
+- Les paquets trop grands peuvent être silencieusement abandonnés
+- Résultat : connexions qui se figent sans message d'erreur
+
+## Le diagnostic : problème de MTU confirmé
+
+En utilisant `ping` avec l'option **Don't Fragment** (DF), on peut tester la taille maximale de paquet acceptée.
+
+Sur l'interface GREtap configurée avec un MTU par défaut de **1280 octets** :
+
+```bash
+# Test avec un paquet de 1253 octets
+ping -M do -s 1253 192.168.100.2
+# Résultat : FAILED (100% packet loss, "message too long, mtu=1280")
+
+# Test avec un paquet de 1252 octets
+ping -M do -s 1252 192.168.100.2
+# Résultat : SUCCESS (0% packet loss)
+```
+
+
+
+*Tests de ping montrant l'échec à 1253 octets et le succès à 1252 octets avec un MTU de 1280.*
+
+Le test révèle que le MTU par défaut de **1280 octets** est trop restrictif. Les paquets légèrement plus grands sont fragmentés ou abandonnés, causant les freezes SSH.
+
+## La solution : MSS clamping
+
+### Qu'est-ce que le MSS clamping ?
+
+Le **MSS (Maximum Segment Size)** est la taille maximale de données TCP dans un segment. Le **MSS clamping** est une technique qui modifie les paquets TCP SYN (établissement de connexion) pour annoncer une MSS plus petite.
+
+Cela force les deux extrémités de la connexion à :
+- Négocier une taille de segment TCP plus petite
+- Éviter la fragmentation en amont
+- Créer des paquets qui passent sans problème dans le tunnel
+
+### Configuration dans OpenWRT
+
+La configuration du MSS clamping se fait dans les paramètres avancés du firewall OpenWRT :
+
+1. Accédez à **Network → Firewall**
+2. Ouvrez l'onglet **Advanced Settings**
+3. Activez **MSS clamping** pour les zones concernées
+
+
+
+**Explication de l'option** :
+
+- **MSS clamping** : Active le recalcul automatique du MSS basé sur le MTU de l'interface
+- OpenWRT calculera automatiquement : `MSS = MTU - 40` (en-têtes TCP/IP)
+
+## Tests de validation
+
+Après avoir activé le MSS clamping et ajusté le MTU, j'ai effectué des tests pour confirmer que le problème est résolu.
+
+### Tests avec hping3 et tcpdump
+
+Pour valider le bon fonctionnement du MSS clamping, j'ai utilisé **hping3** pour envoyer des paquets TCP SYN et **tcpdump** pour capturer et vérifier que le MSS est bien modifié :
+
+```bash
+# Envoi de paquets TCP SYN avec hping3
+hping3 -S -p 80 192.168.100.2
+
+# Capture avec tcpdump pour vérifier le MSS clamping
+tcpdump -i gretap-gr -nn 'tcp[tcpflags] & tcp-syn != 0'
+```
+
+
+
+*Capture tcpdump montrant le MSS clamping en action : les paquets avec MSS 1500 sont automatiquement modifiés pour utiliser MSS 1240.*
+
+Les tests confirment que le MSS clamping fonctionne correctement et que les sessions SSH ne gèlent plus, même avec des transferts de données importants.
+
+## Configuration manuelle du MTU
+
+En complément du MSS clamping, j'ai aussi ajusté manuellement le MTU sur l'interface GREtap :
+
+**Sur les deux routeurs** :
+
+1. **Network → Interfaces → [Interface GREtap]**
+2. **Advanced Settings** :
+ - **Override MTU** : `1450` ou `1400`
+
+Pourquoi ne pas utiliser le MTU théorique optimal de 1462 ?
+- MTU WiFi mesh : 1500 octets
+- Overhead GREtap : 38 octets
+- MTU théorique optimal : 1500 - 38 = **1462 octets**
+
+Cependant, j'ai choisi un MTU de **1450 ou 1400** pour avoir une **marge de sécurité**, notamment pour assurer la stabilité du mesh WiFi qui peut ajouter des en-têtes supplémentaires variables.
+
+## Comprendre le MSS clamping en détail
+
+Le MSS clamping fonctionne en modifiant les paquets **TCP SYN** lors de l'établissement de connexion :
+
+1. **Client** envoie SYN avec MSS=1460 (valeur par défaut Ethernet)
+2. **Routeur avec MSS clamping** intercepte le paquet
+3. **Routeur** recalcule : MSS optimal = MTU interface - 40 = 1462 - 40 = **1422**
+4. **Routeur** modifie le paquet SYN pour annoncer MSS=1422
+5. **Serveur** répond avec MSS=1422 ou moins
+6. **Résultat** : toute la connexion TCP utilisera des segments de maximum 1422 octets
+
+Avec un MSS de 1422 octets :
+- Taille du segment TCP : 1422 octets
+- + En-tête TCP : 20 octets
+- + En-tête IP : 20 octets
+- **= Paquet IP total : 1462 octets**
+
+Ce paquet de 1462 octets :
+- Entre dans le tunnel GREtap
+- + Overhead GREtap : 38 octets
+- **= Paquet final : 1500 octets**
+
+Le paquet final de 1500 octets passe parfaitement dans le MTU Ethernet de 1500 octets. Aucune fragmentation nécessaire.
+
+## Conclusion
+
+Le MSS clamping est une solution élégante pour résoudre les problèmes de MTU sur les tunnels :
+
+- **Transparent** : fonctionne automatiquement sans configuration des clients
+- **Efficace** : évite complètement la fragmentation
+- **Performant** : aucun impact négatif sur les performances
+- **Standard** : supporté par tous les routeurs et pare-feux modernes
+
+Si vous déployez des tunnels GREtap (ou tout autre type de tunnel) sur votre infrastructure réseau, pensez à :
+1. Calculer le MTU optimal en soustrayant l'overhead du protocole
+2. Configurer le MTU manuellement sur les interfaces tunnel
+3. Activer le MSS clamping dans votre firewall
+
+Pour plus de détails sur la configuration complète des tunnels GREtap avec OpenWRT, consultez l'article complet : [Tunnels GREtap pour VLANs](/docs/openwrt/gretap-vlan).
+
+Les sessions SSH sont maintenant stables, même sous charge. Plus aucun freeze. Mission accomplie.
diff --git a/docs/openwrt/backhaul-wifi-mesh.md b/docs/openwrt/backhaul-wifi-mesh.md
new file mode 100644
index 0000000..0f17031
--- /dev/null
+++ b/docs/openwrt/backhaul-wifi-mesh.md
@@ -0,0 +1,122 @@
+---
+sidebar_position: 2
+title: Backhaul WiFi Mesh avec 802.11s
+---
+
+# Backhaul WiFi Mesh avec 802.11s
+
+Ce guide explique comment créer un backhaul WiFi entre deux routeurs sous OpenWRT en utilisant le protocole 802.11s (mesh point).
+
+## Objectif
+
+Créer un lien WiFi mesh entre deux routeurs OpenWRT pour étendre le réseau sans câble Ethernet. Le second routeur sera configuré en "Dumb AP" et communiquera avec le routeur principal via un backhaul mesh sécurisé.
+
+## Prérequis
+
+- Deux routeurs avec OpenWRT installé
+- Accès SSH ou interface web LuCI sur les deux routeurs
+- Un routeur principal configuré (avec DHCP et firewall actifs)
+
+## Étape 1 : Configuration du second routeur en Dumb AP
+
+Le second routeur doit être transformé en "Dumb AP" (Access Point basique sans services réseau). Il existe un script automatique pour cette configuration, mais nous allons détailler la méthode manuelle via l'interface LuCI.
+
+### Script automatique (optionnel)
+
+Pour une configuration automatique, vous pouvez utiliser le script de **OneMarcFifty** disponible sur [GitHub - onemarcfifty/openwrt-mesh](https://github.com/onemarcfifty/openwrt-mesh).
+
+### Configuration manuelle via LuCI
+
+Il faut **désactiver** les services suivants sur le second routeur :
+
+1. **Firewall** : **System → Startup** → Désactiver `firewall`
+2. **DNS** : **Network → DHCP and DNS** → Décocher "DNS server"
+3. **Serveur DHCP** : **Network → Interfaces → LAN → DHCP Server** → Cocher "Ignore interface"
+
+Ces services ne sont pas nécessaires car le routeur principal gère la sécurité, le DNS et la distribution d'adresses IP.
+
+### Configuration de l'interface LAN
+
+Configurez l'interface LAN du second routeur pour qu'elle soit sur le **même subnet** que le routeur principal :
+
+1. Accédez à **Network → Interfaces → LAN**
+2. Configurez les paramètres suivants :
+ - **Protocol** : DHCP client (recommandé) ou Static address
+ - Si Static : **IPv4 address** : `.2` sur le subnet (exemple : si le routeur principal est en `192.168.1.1`, mettre `192.168.1.2`)
+
+
+
+:::tip Sauvegarde de configuration
+Avant de modifier l'interface LAN, notez l'IP actuelle ou configurez une interface de secours pour pouvoir accéder au routeur en cas de problème.
+
+
+:::
+
+## Étape 2 : Configuration du réseau mesh 802.11s
+
+Le protocole 802.11s permet de créer un réseau mesh WiFi natif. Les deux routeurs utiliseront ce protocole pour établir le backhaul.
+
+### Paramètres du mesh
+
+Les deux routeurs doivent avoir **exactement les mêmes paramètres** suivants :
+
+1. **Mode WiFi** : Mesh Point
+2. **Mesh ID** : identifiant unique pour votre mesh (même valeur sur les deux routeurs)
+3. **Interface réseau** : créer une interface dédiée au mesh (exemple : `mesh0`)
+4. **Sécurité** : WPA3-SAE (Personal) recommandé
+5. **Mot de passe** : mot de passe fort et aléatoire
+
+### Génération d'un mot de passe sécurisé
+
+Utilisez cette commande pour générer un mot de passe fort aléatoire :
+
+```bash
+openssl rand -base64 32
+```
+
+Ou depuis OpenWRT :
+
+```bash
+dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64
+```
+
+### Configuration via LuCI
+
+1. Accédez à **Network → Wireless**
+2. Sélectionnez l'interface WiFi à utiliser pour le mesh (généralement radio0 ou radio1)
+3. Configurez les paramètres suivants :
+
+
+
+**Paramètres essentiels** :
+- **Mode** : Mesh Point (802.11s)
+- **Mesh ID** : votre identifiant mesh (identique sur les deux routeurs)
+- **Network** : créer ou sélectionner une interface réseau dédiée au mesh
+- **Encryption** : WPA3-SAE
+- **Key** : le mot de passe généré précédemment
+
+:::warning Synchronisation des paramètres
+Les deux routeurs doivent avoir **exactement** le même Mesh ID et le même mot de passe, sinon ils ne pourront pas établir la connexion mesh.
+:::
+
+### Interface réseau pour le mesh
+
+Créez une interface réseau dédiée pour le mesh :
+1. **Network → Interfaces → Add new interface**
+2. **Name** : `mesh0` (ou tout autre nom descriptif)
+3. **Protocol** : Static address ou DHCP client
+4. **Device** : sélectionner le device mesh créé (généralement `mesh0`)
+
+Cette interface servira de base pour le tunnel GREtap dans la partie suivante.
+
+## Vérification
+
+Après configuration, vérifiez que :
+1. Le second routeur obtient une IP sur le même subnet que le routeur principal
+2. Les deux routeurs peuvent se pinguer mutuellement
+3. L'interface mesh est active et connectée (vérifiable dans **Network → Wireless**)
+4. Le backhaul mesh est établi et stable
+
+## Prochaine étape
+
+Une fois le backhaul mesh configuré, vous pouvez passer à la [configuration GREtap pour étendre les VLANs](./gretap-vlan.md) à travers ce lien mesh.
diff --git a/docs/openwrt/gretap-vlan.md b/docs/openwrt/gretap-vlan.md
new file mode 100644
index 0000000..44226d5
--- /dev/null
+++ b/docs/openwrt/gretap-vlan.md
@@ -0,0 +1,210 @@
+---
+sidebar_position: 3
+title: Tunnels GREtap pour VLANs
+---
+
+# Tunnels GREtap pour VLANs à travers le mesh
+
+Ce guide explique comment étendre des VLANs à travers le backhaul WiFi mesh en utilisant des tunnels GREtap.
+
+## Prérequis
+
+- Backhaul WiFi mesh configuré selon le [guide précédent](./backhaul-wifi-mesh.md)
+- Les deux routeurs doivent pouvoir communiquer via l'interface mesh
+- Accès à l'interface LuCI sur les deux routeurs
+
+## Pourquoi GREtap plutôt que BATMAN-adv ?
+
+Pour un réseau mesh composé de **seulement deux routeurs**, GREtap est préférable à BATMAN-adv pour plusieurs raisons :
+
+### Avantages de GREtap dans ce scénario
+
+1. **Point-à-point suffisant** : Avec deux routeurs, un tunnel point-à-point simple est suffisant. BATMAN-adv est conçu pour des topologies mesh complexes avec de nombreux nœuds et chemins redondants.
+
+2. **Moins d'overhead** : GREtap a un overhead de protocole plus faible que BATMAN-adv. Avec seulement deux nœuds, les fonctionnalités avancées de routage mesh de BATMAN ne sont pas nécessaires.
+
+3. **Simplicité de configuration** : GREtap est plus simple à configurer et à déboguer. Pas besoin de gérer les tables de routage mesh, les métriques de chemin, ou les algorithmes de sélection de route.
+
+4. **Prévisibilité** : Le trafic emprunte toujours le même chemin (le tunnel direct). Pas de changements dynamiques de route.
+
+5. **Support natif** : GREtap est largement supporté et documenté dans OpenWRT sans nécessiter de modules kernel additionnels complexes.
+
+:::info BATMAN-adv : quand l'utiliser ?
+BATMAN-adv devient intéressant quand vous avez :
+- 3 nœuds mesh ou plus
+- Plusieurs chemins possibles entre nœuds
+- Besoin de redondance et de basculement automatique
+- Topologie mesh dynamique avec nœuds mobiles
+:::
+
+## Installation des packages requis
+
+Installez le package nécessaire sur **les deux routeurs** :
+
+```bash
+opkg update
+opkg install luci-proto-gre
+```
+
+Ou via l'interface LuCI : **System → Software**, recherchez et installez `luci-proto-gre`.
+
+## Configuration du tunnel GREtap
+
+### Étape 1 : Créer l'interface GREtap
+
+Sur **les deux routeurs**, créez une nouvelle interface GREtap :
+
+1. Accédez à **Network → Interfaces → Add new interface**
+2. Configurez les paramètres de base
+
+**Paramètres de base** :
+- **Name** : nom court (exemple : `gr`)
+- **Protocol** : GRETAP (Ethernet over GRE)
+
+:::danger Limitation de longueur des noms d'interface
+OpenWRT créé automatiquement l'interface avec le préfixe `gretap-`. Par exemple, si vous nommez votre interface `trunk`, OpenWRT créera `gretap-trunk`.
+
+**Problème** : Pour faire passer des VLANs, la notation sera `gretap-trunk.100`, ce qui fait **16 caractères** et dépasse la limite !
+
+**Exemple problématique** :
+- Interface nommée `trunk` → Device créé : `gretap-trunk` (13 caractères)
+- VLAN 100 → `gretap-trunk.100` (16 caractères) ❌ **TROP LONG**
+
+**Solution** : Utilisez un nom **très court** comme `gr`, `t`, ou `g`.
+- Interface nommée `gr` → Device créé : `gretap-gr` (9 caractères)
+- VLAN 100 → `gretap-gr.100` (13 caractères) ✅ **OK**
+
+:::
+
+:::info Origine de cette limitation
+Les noms d'interface réseau sous Linux sont stockés dans une structure qui utilise un tableau de 16 octets. Ce tableau inclut le terminateur nul `\0`, donc la longueur maximale d'un nom d'interface réseau est de **15 caractères** (16 - 1 = 15).
+:::
+
+**Paramètres du tunnel (General Settings)** :
+- **Remote IPv4 address or FQDN** : IP de l'autre routeur sur l'interface mesh
+- **Local IPv4 address** : IP de ce routeur sur l'interface mesh
+
+
+
+**Options avancées (Advanced Settings)** :
+
+Il est important de configurer les options avancées correctement :
+
+- ⬜ **Use TTL on tunnel interface** : laisser décoché
+- ⬜ **Use PMTU discovery** : laisser décoché (équivalent à **Don't fragment**)
+- ⬜ **Default gateway** : DÉCOCHER cette option (important !)
+- **Bind interface** : sélectionner l'interface mesh (par exemple `lan`)
+
+
+
+:::tip Pourquoi décocher ces options ?
+- **PMTU discovery / Don't fragment** : Le trafic WiFi mesh peut nécessiter de la fragmentation. Autoriser la fragmentation évite les pertes de paquets.
+- **Default gateway** : Le tunnel GREtap ne doit pas devenir la passerelle par défaut du routeur.
+:::
+
+## Extension des VLANs à travers le tunnel
+
+### Principe
+
+Pour faire passer un VLAN à travers le tunnel GREtap, il faut créer un **bridge device** qui contient :
+- Le port physique ou l'interface VLAN locale
+- Le port GREtap VLAN correspondant
+
+La notation utilisée pour un port GREtap VLAN est : `@.`
+
+**Exemple** : Pour le VLAN 100 avec un tunnel nommé `gr` (device : `gretap-gr`) → `@gretap-gr.100`
+
+### Configuration sur le routeur principal
+
+#### Étape 1 : Créer le bridge device pour le VLAN
+
+1. Accédez à **Network → Interfaces → Devices → Add device configuration**
+2. Créez un **Bridge device** :
+
+**Configuration du bridge** :
+- **Device type** : Bridge device
+- **Device name** : `br-lab` (ou nom descriptif pour votre VLAN)
+- **Bridge ports** : Ajouter les ports suivants :
+ - Le port physique ou VLAN local (exemple : `lan3` pour un port physique)
+ - Le port GREtap VLAN : `@gretap-gr.100` (adapter selon votre device et numéro VLAN)
+
+
+
+#### Étape 2 : Créer l'interface réseau pour le VLAN
+
+1. **Network → Interfaces → Add new interface**
+2. Configurez l'interface :
+
+**Paramètres (General Settings)** :
+- **Name** : `LAB` (ou nom descriptif)
+- **Protocol** : Static address
+- **Device** : Sélectionner le bridge créé précédemment (`br-lab`)
+- **IPv4 address** : L'adresse IP de ce routeur sur le VLAN (exemple : `192.168.100.1`)
+- **IPv4 netmask** : Le masque du VLAN (exemple : `255.255.255.0`)
+
+
+
+**Serveur DHCP (DHCP Server)** :
+
+Configurez le serveur DHCP pour ce VLAN afin de distribuer des IPs aux clients :
+
+
+
+**Firewall Settings** :
+
+Assignez l'interface à une zone firewall appropriée (exemple : `homelab_zone` ou créer une nouvelle zone) :
+
+
+
+:::tip Static DHCP Leases
+Une fois que le Dumb AP récupère une IP via DHCP sur ce VLAN, vous pouvez configurer un **static DHCP lease** pour lui assigner une IP fixe.
+
+Exemple : mettre le Dumb AP à l'IP `.2` sur chaque VLAN pour une configuration cohérente (exemple : `192.168.100.2`).
+:::
+
+Répétez cette configuration pour chaque VLAN à étendre à travers le tunnel.
+
+### Configuration sur le Dumb AP
+
+Sur le second routeur (Dumb AP), les interfaces VLAN doivent être configurées en **DHCP client** pour récupérer automatiquement une IP sur chaque VLAN.
+
+1. **Network → Interfaces → Add new interface**
+2. Configurez l'interface :
+ - **Name** : `vlan100` (ou nom descriptif)
+ - **Protocol** : DHCP client
+ - **Device** : `@gretap-gr.100` (le port GREtap VLAN)
+
+Le Dumb AP récupérera automatiquement une adresse IP du serveur DHCP du routeur principal sur ce VLAN.
+
+### Exemple de configuration multi-VLAN
+
+**Configuration typique** :
+- VLAN 10 (Management) → `@gretap-gr.10`
+- VLAN 100 (Homelab) → `@gretap-gr.100`
+- VLAN 200 (IoT) → `@gretap-gr.200`
+
+Chaque VLAN traverse le tunnel GREtap de manière transparente et isolée.
+
+## Vérification et tests
+
+### Tests de connectivité
+
+Depuis le Dumb AP, testez la connectivité sur chaque VLAN :
+
+```bash
+# Ping vers la passerelle du VLAN 100
+ping -I vlan100 192.168.100.1
+
+# Vérifier l'obtention d'une IP via DHCP
+ip addr show dev gretap-gr.100
+```
+
+Depuis le routeur principal, vérifiez que le Dumb AP apparaît dans les baux DHCP :
+
+- **Network → Interfaces → LAB → DHCP Server → Active DHCP Leases**
+
+## Conclusion
+
+Avec GREtap, vous pouvez étendre efficacement vos VLANs à travers un backhaul WiFi mesh entre deux routeurs OpenWRT. Cette solution offre un bon compromis entre simplicité, performance et fonctionnalité pour des topologies point-à-point.
+
+Pour des réseaux mesh plus complexes avec 3 nœuds ou plus, considérez l'utilisation de BATMAN-adv qui offre des fonctionnalités de routage mesh plus avancées.
diff --git a/docs/openwrt/index.md b/docs/openwrt/index.md
new file mode 100644
index 0000000..a768d49
--- /dev/null
+++ b/docs/openwrt/index.md
@@ -0,0 +1,16 @@
+---
+sidebar_position: 1
+title: OpenWRT
+---
+
+# OpenWRT
+
+Le projet OpenWrt est un système d'exploitation basé sur Linux destiné aux matériels embarqués (routeurs principalement). Au lieu d'être un système d'exploitation figé et verrouillé, OpenWrt offre un système d'exploitation totalement modifiable grâce à un gestionnaire de paquets. Ceci vous permet de vous libérer des applications et de la configuration installées par le fabricant, afin de personnaliser votre appareil, grâce à l'ajout et l'utilisation de paquets apportant de nouvelles fonctions.
+
+Pour les développeurs, OpenWrt est l'environnement idéal pour construire une application sans avoir à construire tout un firmware autour. Pour les utilisateurs, OpenWrt permet une totale personnalisation, ainsi que la possibilité d'utiliser l'appareil à des fins qu'on n'avait jamais envisagées.
+
+## Ressources
+
+- [Site officiel OpenWRT](https://openwrt.org/fr/start)
+- [Documentation OpenWRT](https://openwrt.org/fr/docs/start)
+- [Wiki OpenWRT](https://openwrt.org/fr/start)
diff --git a/i18n/en/docusaurus-plugin-content-blog/2025-12-02-ssh-freeze-mtu-mss-clamping.md b/i18n/en/docusaurus-plugin-content-blog/2025-12-02-ssh-freeze-mtu-mss-clamping.md
new file mode 100644
index 0000000..14ad383
--- /dev/null
+++ b/i18n/en/docusaurus-plugin-content-blog/2025-12-02-ssh-freeze-mtu-mss-clamping.md
@@ -0,0 +1,189 @@
+---
+slug: ssh-freeze-mtu-mss-clamping
+title: SSH Session Freeze, MTU and MSS Clamping
+authors: [tellserv]
+tags: [openwrt, gretap, ssh, mtu, networking]
+image: /img/blog/2025-12-02-ssh-freeze-mtu/freeze_session_ssh.png
+---
+
+
+
+
+
+After deploying GREtap tunnels to extend my VLANs across my OpenWRT WiFi mesh, I encountered a frustrating issue: my SSH sessions would randomly freeze and require a complete restart. The cause? A classic MTU and fragmentation problem. Here's how MSS clamping solved the issue.
+
+
+
+## The Symptom: Freezing SSH Sessions
+
+The problem was particularly annoying during remote administration:
+
+- SSH sessions would work normally for a few minutes
+- Then suddenly, the session would freeze completely
+- No response, no error, just a frozen terminal
+- Unable to type anything, even Ctrl+C wouldn't work
+- Only solution: close the terminal and open a new connection
+
+
+
+*SSH sessions would freeze without any error message.*
+
+This behavior was intermittent but systematic: all sessions would eventually freeze after some time of use.
+
+## Understanding MTU and Its Impact
+
+### What is MTU?
+
+**MTU (Maximum Transmission Unit)** represents the maximum size of a network packet that can be transmitted without fragmentation. On standard Ethernet, the default MTU is **1500 bytes**.
+
+### The Problem with Tunnels
+
+Tunneling protocols like GREtap add additional headers to each packet:
+
+- **GRE header**: 4 bytes (tunnel protocol)
+- **Outer IP header**: 20 bytes (for tunnel routing)
+- **Inner Ethernet header**: 14 bytes (for transported traffic)
+
+**Total GREtap overhead**: approximately **38 bytes**
+
+This means for a **1500-byte** packet to transmit:
+- Actual size after encapsulation: **1538 bytes**
+- Ethernet MTU exceeded by: **38 bytes**
+
+### WiFi Mesh Aggravates the Problem
+
+On a WiFi mesh backhaul, the problem is even more pronounced:
+
+- WiFi mesh adds its own headers
+- WiFi fragmentation is less efficient than wired Ethernet
+- Oversized packets can be silently dropped
+- Result: connections that freeze without error messages
+
+## The Diagnosis: MTU Problem Confirmed
+
+Using `ping` with the **Don't Fragment** (DF) option, we can test the maximum accepted packet size.
+
+On the GREtap interface configured with a default MTU of **1280 bytes**:
+
+```bash
+# Test with a 1253-byte packet
+ping -M do -s 1253 192.168.100.2
+# Result: FAILED (100% packet loss, "message too long, mtu=1280")
+
+# Test with a 1252-byte packet
+ping -M do -s 1252 192.168.100.2
+# Result: SUCCESS (0% packet loss)
+```
+
+
+
+*Ping tests showing failure at 1253 bytes and success at 1252 bytes with MTU 1280.*
+
+The test reveals that the default MTU of **1280 bytes** is too restrictive. Slightly larger packets are fragmented or dropped, causing the SSH freezes.
+
+## The Solution: MSS Clamping
+
+### What is MSS Clamping?
+
+**MSS (Maximum Segment Size)** is the maximum size of TCP data in a segment. **MSS clamping** is a technique that modifies TCP SYN packets (connection establishment) to announce a smaller MSS.
+
+This forces both ends of the connection to:
+- Negotiate a smaller TCP segment size
+- Avoid fragmentation upstream
+- Create packets that pass through the tunnel without issues
+
+### Configuration in OpenWRT
+
+MSS clamping configuration is done in OpenWRT's advanced firewall settings:
+
+1. Navigate to **Network → Firewall**
+2. Open the **Advanced Settings** tab
+3. Enable **MSS clamping** for the relevant zones
+
+
+
+**Option explanation**:
+
+- **MSS clamping**: Enables automatic MSS recalculation based on interface MTU
+- OpenWRT will automatically calculate: `MSS = MTU - 40` (TCP/IP headers)
+
+## Validation Tests
+
+After enabling MSS clamping and adjusting the MTU, I performed tests to confirm the problem is resolved.
+
+### Tests with hping3 and tcpdump
+
+To validate that MSS clamping is working correctly, I used **hping3** to send TCP SYN packets and **tcpdump** to capture and verify that the MSS is being modified:
+
+```bash
+# Send TCP SYN packets with hping3
+hping3 -S -p 80 192.168.100.2
+
+# Capture with tcpdump to verify MSS clamping
+tcpdump -i gretap-gr -nn 'tcp[tcpflags] & tcp-syn != 0'
+```
+
+
+
+*Tcpdump capture showing MSS clamping in action: packets with MSS 1500 are automatically modified to use MSS 1240.*
+
+Tests confirm that MSS clamping is working correctly and that SSH sessions no longer freeze, even with large data transfers.
+
+## Manual MTU Configuration
+
+Additionally to MSS clamping, I also manually adjusted the MTU on the GREtap interface:
+
+**On both routers**:
+
+1. **Network → Interfaces → [GREtap Interface]**
+2. **Advanced Settings**:
+ - **Override MTU**: `1450` or `1400`
+
+Why not use the theoretical optimal MTU of 1462?
+- WiFi mesh MTU: 1500 bytes
+- GREtap overhead: 38 bytes
+- Theoretical optimal MTU: 1500 - 38 = **1462 bytes**
+
+However, I chose an MTU of **1450 or 1400** to have a **safety margin**, especially to ensure WiFi mesh stability which can add variable additional headers.
+
+## Understanding MSS Clamping in Detail
+
+MSS clamping works by modifying **TCP SYN** packets during connection establishment:
+
+1. **Client** sends SYN with MSS=1460 (default Ethernet value)
+2. **Router with MSS clamping** intercepts the packet
+3. **Router** recalculates: Optimal MSS = Interface MTU - 40 = 1462 - 40 = **1422**
+4. **Router** modifies the SYN packet to announce MSS=1422
+5. **Server** responds with MSS=1422 or less
+6. **Result**: the entire TCP connection will use segments of maximum 1422 bytes
+
+With an MSS of 1422 bytes:
+- TCP segment size: 1422 bytes
+- + TCP header: 20 bytes
+- + IP header: 20 bytes
+- **= Total IP packet: 1462 bytes**
+
+This 1462-byte packet:
+- Enters the GREtap tunnel
+- + GREtap overhead: 38 bytes
+- **= Final packet: 1500 bytes**
+
+The final 1500-byte packet fits perfectly within the 1500-byte Ethernet MTU. No fragmentation needed.
+
+## Conclusion
+
+MSS clamping is an elegant solution to resolve MTU issues on tunnels:
+
+- **Transparent**: works automatically without client configuration
+- **Effective**: completely avoids fragmentation
+- **Performant**: no negative performance impact
+- **Standard**: supported by all modern routers and firewalls
+
+If you deploy GREtap tunnels (or any other tunnel type) on your network infrastructure, remember to:
+1. Calculate the optimal MTU by subtracting the protocol overhead
+2. Manually configure the MTU on tunnel interfaces
+3. Enable MSS clamping in your firewall
+
+For more details on the complete configuration of GREtap tunnels with OpenWRT, see the full article: [GREtap Tunnels for VLANs](/docs/openwrt/gretap-vlan).
+
+SSH sessions are now stable, even under load. No more freezes. Mission accomplished.
diff --git a/i18n/en/docusaurus-plugin-content-docs/current/openwrt/backhaul-wifi-mesh.md b/i18n/en/docusaurus-plugin-content-docs/current/openwrt/backhaul-wifi-mesh.md
new file mode 100644
index 0000000..929cd6a
--- /dev/null
+++ b/i18n/en/docusaurus-plugin-content-docs/current/openwrt/backhaul-wifi-mesh.md
@@ -0,0 +1,122 @@
+---
+sidebar_position: 2
+title: WiFi Mesh Backhaul with 802.11s
+---
+
+# WiFi Mesh Backhaul with 802.11s
+
+This guide explains how to create a WiFi backhaul between two OpenWRT routers using the 802.11s (mesh point) protocol.
+
+## Objective
+
+Create a mesh WiFi link between two OpenWRT routers to extend the network without an Ethernet cable. The second router will be configured as a "Dumb AP" and will communicate with the main router via a secure mesh backhaul.
+
+## Prerequisites
+
+- Two routers with OpenWRT installed
+- SSH or LuCI web interface access on both routers
+- A configured main router (with active DHCP and firewall)
+
+## Step 1: Configuring the Second Router as a Dumb AP
+
+The second router must be transformed into a "Dumb AP" (basic Access Point without network services). There is an automatic script for this configuration, but we will detail the manual method via the LuCI interface.
+
+### Automatic Script (Optional)
+
+For automatic configuration, you can use **OneMarcFifty**'s script available on [GitHub - onemarcfifty/openwrt-mesh](https://github.com/onemarcfifty/openwrt-mesh).
+
+### Manual Configuration via LuCI
+
+You need to **disable** the following services on the second router:
+
+1. **Firewall**: **System → Startup** → Disable `firewall`
+2. **DNS**: **Network → DHCP and DNS** → Uncheck "DNS server"
+3. **DHCP Server**: **Network → Interfaces → LAN → DHCP Server** → Check "Ignore interface"
+
+These services are not necessary because the main router handles security, DNS, and IP address distribution.
+
+### LAN Interface Configuration
+
+Configure the second router's LAN interface to be on the **same subnet** as the main router:
+
+1. Go to **Network → Interfaces → LAN**
+2. Configure the following parameters:
+ - **Protocol**: DHCP client (recommended) or Static address
+ - If Static: **IPv4 address**: `.2` on the subnet (example: if the main router is at `192.168.1.1`, set `192.168.1.2`)
+
+
+
+:::tip Configuration Backup
+Before modifying the LAN interface, note the current IP or configure a backup interface to be able to access the router in case of problems.
+
+
+:::
+
+## Step 2: Configuring the 802.11s Mesh Network
+
+The 802.11s protocol allows creating a native WiFi mesh network. Both routers will use this protocol to establish the backhaul.
+
+### Mesh Parameters
+
+Both routers must have **exactly the same** following parameters:
+
+1. **WiFi Mode**: Mesh Point
+2. **Mesh ID**: unique identifier for your mesh (same value on both routers)
+3. **Network Interface**: create a dedicated interface for the mesh (example: `mesh0`)
+4. **Security**: WPA3-SAE (Personal) recommended
+5. **Password**: strong and random password
+
+### Generating a Secure Password
+
+Use this command to generate a strong random password:
+
+```bash
+openssl rand -base64 32
+```
+
+Or from OpenWRT:
+
+```bash
+dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64
+```
+
+### Configuration via LuCI
+
+1. Go to **Network → Wireless**
+2. Select the WiFi interface to use for the mesh (usually radio0 or radio1)
+3. Configure the following parameters:
+
+
+
+**Essential Parameters**:
+- **Mode**: Mesh Point (802.11s)
+- **Mesh ID**: your mesh identifier (identical on both routers)
+- **Network**: create or select a dedicated network interface for the mesh
+- **Encryption**: WPA3-SAE
+- **Key**: the previously generated password
+
+:::warning Parameter Synchronization
+Both routers must have **exactly** the same Mesh ID and the same password, otherwise they will not be able to establish the mesh connection.
+:::
+
+### Network Interface for the Mesh
+
+Create a dedicated network interface for the mesh:
+1. **Network → Interfaces → Add new interface**
+2. **Name**: `mesh0` (or any other descriptive name)
+3. **Protocol**: Static address or DHCP client
+4. **Device**: select the created mesh device (usually `mesh0`)
+
+This interface will serve as the basis for the GREtap tunnel in the next section.
+
+## Verification
+
+After configuration, verify that:
+1. The second router obtains an IP on the same subnet as the main router
+2. Both routers can ping each other
+3. The mesh interface is active and connected (verifiable in **Network → Wireless**)
+4. The mesh backhaul is established and stable
+
+## Next Step
+
+Once the mesh backhaul is configured, you can proceed to [GREtap configuration to extend VLANs](./gretap-vlan.md) through this mesh link.
diff --git a/i18n/en/docusaurus-plugin-content-docs/current/openwrt/gretap-vlan.md b/i18n/en/docusaurus-plugin-content-docs/current/openwrt/gretap-vlan.md
new file mode 100644
index 0000000..fb60d00
--- /dev/null
+++ b/i18n/en/docusaurus-plugin-content-docs/current/openwrt/gretap-vlan.md
@@ -0,0 +1,210 @@
+---
+sidebar_position: 3
+title: GREtap Tunnels for VLANs
+---
+
+# GREtap Tunnels for VLANs Across the Mesh
+
+This guide explains how to extend VLANs across the WiFi mesh backhaul using GREtap tunnels.
+
+## Prerequisites
+
+- WiFi mesh backhaul configured according to the [previous guide](./backhaul-wifi-mesh.md)
+- Both routers must be able to communicate via the mesh interface
+- Access to the LuCI interface on both routers
+
+## Why GREtap Instead of BATMAN-adv?
+
+For a mesh network consisting of **only two routers**, GREtap is preferable to BATMAN-adv for several reasons:
+
+### Advantages of GREtap in This Scenario
+
+1. **Point-to-Point Sufficient**: With two routers, a simple point-to-point tunnel is sufficient. BATMAN-adv is designed for complex mesh topologies with many nodes and redundant paths.
+
+2. **Less Overhead**: GREtap has lower protocol overhead than BATMAN-adv. With only two nodes, the advanced mesh routing features of BATMAN are not necessary.
+
+3. **Configuration Simplicity**: GREtap is simpler to configure and debug. No need to manage mesh routing tables, path metrics, or route selection algorithms.
+
+4. **Predictability**: Traffic always takes the same path (the direct tunnel). No dynamic route changes.
+
+5. **Native Support**: GREtap is widely supported and documented in OpenWRT without requiring complex additional kernel modules.
+
+:::info BATMAN-adv: When to Use It?
+BATMAN-adv becomes interesting when you have:
+- 3 or more mesh nodes
+- Multiple possible paths between nodes
+- Need for redundancy and automatic failover
+- Dynamic mesh topology with mobile nodes
+:::
+
+## Installing Required Packages
+
+Install the necessary package on **both routers**:
+
+```bash
+opkg update
+opkg install luci-proto-gre
+```
+
+Or via the LuCI interface: **System → Software**, search for and install `luci-proto-gre`.
+
+## Configuring the GREtap Tunnel
+
+### Step 1: Create the GREtap Interface
+
+On **both routers**, create a new GREtap interface:
+
+1. Go to **Network → Interfaces → Add new interface**
+2. Configure the basic parameters
+
+**Basic Parameters**:
+- **Name**: short name (example: `gr`)
+- **Protocol**: GRETAP (Ethernet over GRE)
+
+:::danger Interface Name Length Limitation
+OpenWRT automatically creates the interface with the `gretap-` prefix. For example, if you name your interface `trunk`, OpenWRT will create `gretap-trunk`.
+
+**Problem**: To pass VLANs, the notation will be `gretap-trunk.100`, which is **16 characters** and exceeds the limit!
+
+**Problematic Example**:
+- Interface named `trunk` → Device created: `gretap-trunk` (13 characters)
+- VLAN 100 → `gretap-trunk.100` (16 characters) ❌ **TOO LONG**
+
+**Solution**: Use a **very short** name like `gr`, `t`, or `g`.
+- Interface named `gr` → Device created: `gretap-gr` (9 characters)
+- VLAN 100 → `gretap-gr.100` (13 characters) ✅ **OK**
+
+:::
+
+:::info Origin of This Limitation
+Network interface names under Linux are stored in a structure that uses a 16-byte array. This array includes the null terminator `\0`, so the maximum length of a network interface name is **15 characters** (16 - 1 = 15).
+:::
+
+**Tunnel Parameters (General Settings)**:
+- **Remote IPv4 address or FQDN**: IP of the other router on the mesh interface
+- **Local IPv4 address**: IP of this router on the mesh interface
+
+
+
+**Advanced Options (Advanced Settings)**:
+
+It is important to configure the advanced options correctly:
+
+- ⬜ **Use TTL on tunnel interface**: leave unchecked
+- ⬜ **Use PMTU discovery**: leave unchecked (equivalent to **Don't fragment**)
+- ⬜ **Default gateway**: UNCHECK this option (important!)
+- **Bind interface**: select the mesh interface (for example `lan`)
+
+
+
+:::tip Why Uncheck These Options?
+- **PMTU discovery / Don't fragment**: WiFi mesh traffic may require fragmentation. Allowing fragmentation avoids packet loss.
+- **Default gateway**: The GREtap tunnel should not become the router's default gateway.
+:::
+
+## Extending VLANs Through the Tunnel
+
+### Principle
+
+To pass a VLAN through the GREtap tunnel, you need to create a **bridge device** that contains:
+- The local physical port or VLAN interface
+- The corresponding GREtap VLAN port
+
+The notation used for a GREtap VLAN port is: `@.`
+
+**Example**: For VLAN 100 with a tunnel named `gr` (device: `gretap-gr`) → `@gretap-gr.100`
+
+### Configuration on the Main Router
+
+#### Step 1: Create the Bridge Device for the VLAN
+
+1. Go to **Network → Interfaces → Devices → Add device configuration**
+2. Create a **Bridge device**:
+
+**Bridge Configuration**:
+- **Device type**: Bridge device
+- **Device name**: `br-lab` (or descriptive name for your VLAN)
+- **Bridge ports**: Add the following ports:
+ - The local physical port or VLAN (example: `lan3` for a physical port)
+ - The GREtap VLAN port: `@gretap-gr.100` (adapt according to your device and VLAN number)
+
+
+
+#### Step 2: Create the Network Interface for the VLAN
+
+1. **Network → Interfaces → Add new interface**
+2. Configure the interface:
+
+**Parameters (General Settings)**:
+- **Name**: `LAB` (or descriptive name)
+- **Protocol**: Static address
+- **Device**: Select the previously created bridge (`br-lab`)
+- **IPv4 address**: This router's IP address on the VLAN (example: `192.168.100.1`)
+- **IPv4 netmask**: The VLAN's netmask (example: `255.255.255.0`)
+
+
+
+**DHCP Server (DHCP Server)**:
+
+Configure the DHCP server for this VLAN to distribute IPs to clients:
+
+
+
+**Firewall Settings**:
+
+Assign the interface to an appropriate firewall zone (example: `homelab_zone` or create a new zone):
+
+
+
+:::tip Static DHCP Leases
+Once the Dumb AP retrieves an IP via DHCP on this VLAN, you can configure a **static DHCP lease** to assign it a fixed IP.
+
+Example: set the Dumb AP to IP `.2` on each VLAN for consistent configuration (example: `192.168.100.2`).
+:::
+
+Repeat this configuration for each VLAN to extend through the tunnel.
+
+### Configuration on the Dumb AP
+
+On the second router (Dumb AP), the VLAN interfaces must be configured as **DHCP clients** to automatically retrieve an IP on each VLAN.
+
+1. **Network → Interfaces → Add new interface**
+2. Configure the interface:
+ - **Name**: `vlan100` (or descriptive name)
+ - **Protocol**: DHCP client
+ - **Device**: `@gretap-gr.100` (the GREtap VLAN port)
+
+The Dumb AP will automatically retrieve an IP address from the main router's DHCP server on this VLAN.
+
+### Multi-VLAN Configuration Example
+
+**Typical Configuration**:
+- VLAN 10 (Management) → `@gretap-gr.10`
+- VLAN 100 (Homelab) → `@gretap-gr.100`
+- VLAN 200 (IoT) → `@gretap-gr.200`
+
+Each VLAN crosses the GREtap tunnel transparently and in isolation.
+
+## Verification and Testing
+
+### Connectivity Tests
+
+From the Dumb AP, test connectivity on each VLAN:
+
+```bash
+# Ping to VLAN 100 gateway
+ping -I vlan100 192.168.100.1
+
+# Verify obtaining an IP via DHCP
+ip addr show dev gretap-gr.100
+```
+
+From the main router, verify that the Dumb AP appears in the DHCP leases:
+
+- **Network → Interfaces → LAB → DHCP Server → Active DHCP Leases**
+
+## Conclusion
+
+With GREtap, you can effectively extend your VLANs across a WiFi mesh backhaul between two OpenWRT routers. This solution offers a good compromise between simplicity, performance, and functionality for point-to-point topologies.
+
+For more complex mesh networks with 3 or more nodes, consider using BATMAN-adv which offers more advanced mesh routing features.
diff --git a/i18n/en/docusaurus-plugin-content-docs/current/openwrt/index.md b/i18n/en/docusaurus-plugin-content-docs/current/openwrt/index.md
new file mode 100644
index 0000000..435732d
--- /dev/null
+++ b/i18n/en/docusaurus-plugin-content-docs/current/openwrt/index.md
@@ -0,0 +1,16 @@
+---
+sidebar_position: 1
+title: OpenWRT
+---
+
+# OpenWRT
+
+The OpenWrt Project is a Linux-based operating system designed for embedded devices (primarily routers). Instead of being a fixed and locked operating system, OpenWrt offers a fully customizable operating system through a package manager. This allows you to break free from the applications and configuration installed by the manufacturer, enabling you to customize your device through the addition and use of packages that bring new functionalities.
+
+For developers, OpenWrt is the ideal environment to build an application without having to build an entire firmware around it. For users, OpenWrt allows total customization, as well as the possibility of using the device for purposes never originally envisioned.
+
+## Resources
+
+- [Official OpenWRT Website](https://openwrt.org/start)
+- [OpenWRT Documentation](https://openwrt.org/docs/start)
+- [OpenWRT Wiki](https://openwrt.org/start)
diff --git a/sidebars.ts b/sidebars.ts
index f3b7504..bba6be3 100644
--- a/sidebars.ts
+++ b/sidebars.ts
@@ -25,6 +25,18 @@ const sidebars: SidebarsConfig = {
'projets-openclassrooms/p13-migration-cloud-aws',
],
},
+ {
+ type: 'category',
+ label: 'OpenWRT',
+ link: {
+ type: 'doc',
+ id: 'openwrt/index',
+ },
+ items: [
+ 'openwrt/backhaul-wifi-mesh',
+ 'openwrt/gretap-vlan',
+ ],
+ },
{
type: 'category',
label: 'Homelab actuel - Docker Compose & Ansible',
diff --git a/static/img/blog/2025-12-02-ssh-freeze-mtu/activer_mss_clamping.png b/static/img/blog/2025-12-02-ssh-freeze-mtu/activer_mss_clamping.png
new file mode 100644
index 0000000..f3dec19
Binary files /dev/null and b/static/img/blog/2025-12-02-ssh-freeze-mtu/activer_mss_clamping.png differ
diff --git a/static/img/blog/2025-12-02-ssh-freeze-mtu/freeze_session_ssh.png b/static/img/blog/2025-12-02-ssh-freeze-mtu/freeze_session_ssh.png
new file mode 100644
index 0000000..0e7db18
Binary files /dev/null and b/static/img/blog/2025-12-02-ssh-freeze-mtu/freeze_session_ssh.png differ
diff --git a/static/img/blog/2025-12-02-ssh-freeze-mtu/probleme_de_mtu.png b/static/img/blog/2025-12-02-ssh-freeze-mtu/probleme_de_mtu.png
new file mode 100644
index 0000000..c81fdaa
Binary files /dev/null and b/static/img/blog/2025-12-02-ssh-freeze-mtu/probleme_de_mtu.png differ
diff --git a/static/img/blog/2025-12-02-ssh-freeze-mtu/test_fonctionnel.png b/static/img/blog/2025-12-02-ssh-freeze-mtu/test_fonctionnel.png
new file mode 100644
index 0000000..8dd49d9
Binary files /dev/null and b/static/img/blog/2025-12-02-ssh-freeze-mtu/test_fonctionnel.png differ
diff --git a/static/img/openwrt/bridge_device_lab_avec_port_gretap.png b/static/img/openwrt/bridge_device_lab_avec_port_gretap.png
new file mode 100644
index 0000000..4c0be42
Binary files /dev/null and b/static/img/openwrt/bridge_device_lab_avec_port_gretap.png differ
diff --git a/static/img/openwrt/config_backhaul_wifi.png b/static/img/openwrt/config_backhaul_wifi.png
new file mode 100644
index 0000000..9c2396c
Binary files /dev/null and b/static/img/openwrt/config_backhaul_wifi.png differ
diff --git a/static/img/openwrt/interface-gretap.png b/static/img/openwrt/interface-gretap.png
new file mode 100644
index 0000000..49bfb3c
Binary files /dev/null and b/static/img/openwrt/interface-gretap.png differ
diff --git a/static/img/openwrt/interface_br-lan_dhcp.png b/static/img/openwrt/interface_br-lan_dhcp.png
new file mode 100644
index 0000000..c0752ef
Binary files /dev/null and b/static/img/openwrt/interface_br-lan_dhcp.png differ
diff --git a/static/img/openwrt/interface_gretap_parametresavance.png b/static/img/openwrt/interface_gretap_parametresavance.png
new file mode 100644
index 0000000..88d4736
Binary files /dev/null and b/static/img/openwrt/interface_gretap_parametresavance.png differ
diff --git a/static/img/openwrt/interface_vlan_lab_avec_bridge_en_device.png b/static/img/openwrt/interface_vlan_lab_avec_bridge_en_device.png
new file mode 100644
index 0000000..95784a7
Binary files /dev/null and b/static/img/openwrt/interface_vlan_lab_avec_bridge_en_device.png differ
diff --git a/static/img/openwrt/interface_vlan_lab_dhcp_sur_routeur_maitre.png b/static/img/openwrt/interface_vlan_lab_dhcp_sur_routeur_maitre.png
new file mode 100644
index 0000000..9e2efa4
Binary files /dev/null and b/static/img/openwrt/interface_vlan_lab_dhcp_sur_routeur_maitre.png differ
diff --git a/static/img/openwrt/interface_vlan_lab_firewallzone.png b/static/img/openwrt/interface_vlan_lab_firewallzone.png
new file mode 100644
index 0000000..8422bb5
Binary files /dev/null and b/static/img/openwrt/interface_vlan_lab_firewallzone.png differ
diff --git a/static/img/openwrt/sauvetage_interface.png b/static/img/openwrt/sauvetage_interface.png
new file mode 100644
index 0000000..dabfd7c
Binary files /dev/null and b/static/img/openwrt/sauvetage_interface.png differ