EXP C09 — Quand le serveur fonctionne… mais qu’on ne lui fait plus tout à fait confiance.

EXP C09 — Quand le serveur fonctionne… mais qu’on ne lui fait plus tout à fait confiance.

À première vue, notre serveur d’impression fonctionnait.

La Canon LBP-810 imprimait.

CUPS fonctionnait.

Avahi fonctionnait.

Windows savait trouver l’imprimante.

Kubuntu savait l’utiliser en IPP.

Le vieux pilote CAPT avait repris vie sur le Raspberry.

Et pourtant, quelque chose nous gênait.

Le réseau.

Le serveur pouvait fonctionner correctement pendant un certain temps, puis devenir beaucoup moins coopératif lorsque l’activité réseau diminuait.

Nous avions donc un problème assez particulier :

le serveur d’impression pouvait imprimer, mais nous n’avions pas encore la certitude qu’il pouvait rester disponible de manière fiable.

Bookworm fonctionnait… mais la stabilité devenait la vraie question.

Il faut être précis sur ce point.

Raspberry Pi OS Bookworm n’était pas un échec complet.

Nous avions réussi à construire dessus une grande partie de notre serveur d’impression et les expériences précédentes avaient apporté des résultats parfaitement réels.

Le problème était ailleurs : la stabilité du Wi-Fi sur la durée.

Au cours de nos recherches, nous avons également trouvé plusieurs retours d’utilisateurs concernant des problèmes de connexion ou de stabilité Wi-Fi sur des Raspberry Pi Zero 2 W sous Bookworm.

Certains témoignages décrivaient des pertes de connexion ou des déconnexions SSH, parfois alors qu’une autre distribution fonctionnait correctement sur le même Raspberry Pi. D’autres signalaient des problèmes persistants de Wi-Fi avec Bookworm sur la Zero 2 W.

Nous avons également trouvé des retours faisant état de différences de comportement selon les versions d’images, les outils de configuration et les générations de Raspberry Pi OS.

Cela ne prouvait absolument pas que Bookworm était responsable de notre problème.

Mais cela rendait notre observation suffisamment crédible pour mériter une véritable investigation.

Nous avons testé… beaucoup de choses.

Nous n’allions évidemment pas changer immédiatement de système.

Avant de jeter Bookworm à la poubelle, nous avons essayé de comprendre ce qui se passait.

Nous avons notamment examiné la gestion du Wi-Fi, le comportement de NetworkManager et le power saving.

Nous avons vérifié l’état effectif de la gestion d’énergie Wi-Fi :

iw dev wlan0 get power_save

Le résultat était :

Power save: off

Autrement dit, le power saving était déjà désactivé. Cette piste ne suffisait donc pas à expliquer à elle seule tout ce que nous observions.

Nous avons également étudié les possibilités offertes par raspi-config, NetworkManager et les réglages du pilote Wi-Fi.

Mais plus nous avancions, plus une conclusion s’imposait :

nous pouvions modifier des paramètres, mais nous n’avions toujours pas identifié avec certitude la cause du problème.

Le symptôme était pourtant très réel.

Les journaux nous avaient déjà donné des indices particulièrement intéressants.

Nous avions observé des séquences de ce type :

completed
   ↓
disconnected
   ↓
scanning
   ↓
associating
   ↓
disconnected
   ↓
link timed out
   ↓
supplicant-timeout

Ce n’était donc pas simplement un navigateur qui avait du mal à joindre le serveur.

Nous avions des événements réseau réels montrant que la connexion Wi-Fi quittait son état normal.

Le problème devenait particulièrement curieux lorsque nous constations qu’une activité réseau régulière semblait parfois empêcher ou retarder l’apparition du phénomène.

Autrement dit :

network activity
      ↓
   stability

no activity
      ↓
freeze / connection loss

Ce comportement était suffisamment étrange pour que nous ne voulions surtout pas transformer une simple corrélation en diagnostic.

Et si le problème n’était pas celui que nous pensions ?

Une autre possibilité devait rester ouverte :

Et si notre Raspberry Pi avait simplement un problème matériel intermittent ?

C’était une hypothèse parfaitement légitime.

Une alimentation, le module radio, la température, la mémoire flash ou un composant matériel pouvaient théoriquement provoquer des comportements intermittents.

Nous avions cependant un élément de comparaison intéressant : le même Raspberry Pi avait déjà servi auparavant dans d’autres usages sans présenter ce comportement réseau de manière évidente.

Il fallait donc éviter de conclure trop vite.

Le vrai problème : nous changions trop de variables pour identifier le coupable.

À ce stade, plusieurs éléments entraient dans l’équation :

Raspberry Pi Zero 2 W
│
├── Raspberry Pi OS Bookworm
├── armv7l
├── kernel 6.12.96
├── NetworkManager
├── wpa_supplicant
├── Wi-Fi driver / firmware
└── Livebox

Nous pouvions continuer à modifier un paramètre après l’autre.

Mais nous risquions de transformer notre expérience en laboratoire de bricolage :

modification
↓
reboot
↓
test
↓
wait
↓
new modification
↓
new test
↓
???

Nous avons donc décidé de faire quelque chose de beaucoup plus propre :

changer de système sans changer de Raspberry Pi.

Un test comparatif.

La règle était simple.

Nous ne toucherions pas à notre installation Bookworm.

La carte micro-SD existante resterait intacte.

À la place, nous allions utiliser une deuxième micro-SD.

La comparaison pouvait alors devenir intéressante :

                 SAME Pi Zero 2 W
                         │
              ┌──────────┴───────────┐
              │                      │
         Bookworm               another OS
         armv7l                 new test
         6.12.96
              │                      │
        unstable Wi-Fi           ??????
              │                      │
              └────── comparison ────┘

Le Raspberry Pi restait le même.

L’alimentation restait la même.

La position du Raspberry Pi restait la même.

Le routeur Wi-Fi du réseau local restait la même.

Le réseau Wi-Fi restait le même.

Et, autant que possible, nous pouvions conserver la même adresse IP :

192.168.1.40

Nous allions donc principalement changer la couche logicielle.

Pourquoi regarder du côté d’Armbian ?

En cherchant des images compatibles avec la Raspberry Pi Zero 2 W, nous avons découvert qu’Armbian proposait explicitement des images pour cette carte.

Plusieurs variantes étaient intéressantes, notamment Armbian Debian 13 Minimal et Armbian Ubuntu 26.04 Minimal.

Le principe nous plaisait immédiatement :

une distribution légère, orientée serveur, adaptée à une petite carte et suffisamment différente de Raspberry Pi OS pour constituer une comparaison intéressante.

Et surtout, nous n’étions pas obligés de partir sur un environnement graphique.

Notre serveur n’avait toujours besoin que de quelques services :

Wi-Fi
SSH
CUPS
Avahi
CAPT

Un bureau complet n’aurait donc apporté aucune valeur à notre expérience.

Quel Armbian choisir ?

Nous avons envisagé plusieurs possibilités.

Armbian Debian 13 était très logique pour un système destiné à héberger CUPS.

Mais nous avons finalement décidé de commencer par :

Armbian Ubuntu 26.04 Minimal / CLI

Le choix était intéressant pour une raison simple : nous changions suffisamment de choses pour obtenir une véritable comparaison, tout en restant dans un environnement Linux très classique.

Et nous pouvions ensuite, si nécessaire, tester une autre variante d’Armbian.

Première règle : ne rien installer.

Nous voulions éviter une erreur classique : installer immédiatement tout le serveur d’impression, puis découvrir que la nouvelle distribution fonctionne mal au niveau réseau.

Nous avons donc séparé les expériences.

Premier test :

Armbian
   ↓
Wi-Fi
   ↓
SSH
   ↓
stability

Pas encore de CUPS.

Pas encore de CAPT.

Pas encore d’Avahi.

Pas encore d’imprimante.

Et surtout :

pas de ping continu pour maintenir artificiellement le Raspberry actif.

Nous voulions reproduire exactement la situation qui nous intéressait.

Le premier démarrage.

Et là, quelque chose de très intéressant s’est produit.

La Raspberry Pi Zero 2 W démarrait parfaitement avec :

Armbian 26.8.3
Ubuntu 26.04
aarch64

Le Wi-Fi était immédiatement opérationnel :

wlan0
192.168.1.40/24

Et un changement d’architecture apparaissait immédiatement :

Bookworm
   → armv7l

Armbian
   → aarch64

Le Raspberry Pi utilisait également une pile réseau différente, basée sur systemd-networkd dans notre installation.

Nous avions donc volontairement changé plusieurs variables.

Mais cette fois, c’était précisément ce que nous cherchions à comparer.

Et maintenant… on attend.

La tentation était grande d’installer immédiatement CUPS et de recommencer toute l’expérience d’impression.

Nous avons résisté.

Le plus intéressant était désormais de laisser le Raspberry Pi fonctionner.

Pas de réglage Wi-Fi.

Pas de tweak.

Pas de modification du power saving.

Pas de reboot inutile.

Pas de ping permanent.

Simplement :

Armbian
   +
Wi-Fi
   +
time

Et pour notre expérience, le temps était précisément ce qui manquait à Bookworm.

Puis vint la vraie question : est-ce que l’impression fonctionnerait aussi ?

Une meilleure stabilité réseau n’aurait pas beaucoup de valeur si nous perdions tout le travail accompli avec CUPS et CAPT.

Il fallait donc reconstruire notre serveur.

Mais cette fois, le chemin était beaucoup plus clair.

Nous savions déjà exactement ce qu’il nous fallait :

Armbian
   ↓
CUPS
   ↓
Avahi
   ↓
CAPT 0.1
   ↓
/dev/usb/lp0
   ↓
Canon LBP-810

La configuration fonctionnelle découverte lors des expériences précédentes pouvait être réutilisée.

Notamment notre choix particulier de conserver :

device-uri=file:///dev/null

Le pilote CAPT restait chargé de communiquer directement avec /dev/usb/lp0.

Le changement de distribution ne remettait donc pas en cause toute l’architecture.

Armbian reprend la totalité du parcours.

Très rapidement, le test devint beaucoup plus intéressant qu’un simple test réseau.

Nous avions maintenant :

Windows
   │
   │ IPP / WSD
   ▼
rpizero2w
Armbian Ubuntu 26.04
   │
   ├── systemd-networkd
   ├── wpa_supplicant
   ├── CUPS
   ├── Avahi
   └── CAPT 0.1
         │
         ▼
       USB /dev/usb/lp0
         │
         ▼
      Canon LBP-810

Et la Canon imprimait.

La page de test Windows est sortie impeccablement.

Windows utilisait le serveur en IPP, sans avoir besoin du pilote Canon CAPT sur le poste client.

De son côté, Kubuntu pouvait également continuer à utiliser la file IPP existante.

Autrement dit, le changement de système était transparent pour les clients.

Le moment décisif.

Nous avions maintenant une situation particulièrement intéressante.

Bookworm :

armv7l
kernel 6.12.96
NetworkManager

→ Wi-Fi losses
→ disconnection sequences
→ supplicant-timeout

Armbian :

aarch64
kernel 6.18.44
systemd-networkd

→ stable Wi-Fi
→ working CUPS
→ working Avahi
→ working CAPT
→ real print

Et surtout, nous n’utilisions toujours pas de ping continu pour maintenir la connexion.

Lors d’une vérification depuis Windows :

Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%)
Minimum = 5 ms
Maximum = 6 ms
Moyenne = 5 ms

Le test était d’autant plus intéressant que le Raspberry Pi ne faisait pas simplement attendre une console SSH.

Il faisait réellement fonctionner notre serveur d’impression.

Mais attention : nous n’avons toujours pas trouvé le coupable.

C’est ici que la discipline expérimentale devient importante.

Nous avons changé plusieurs variables simultanément :

Bookworm
   → armv7l
   → kernel 6.12.96
   → NetworkManager

vers

Armbian Ubuntu 26.04
   → aarch64
   → kernel 6.18.44
   → systemd-networkd

Nous ne pouvons donc pas écrire :

« NetworkManager était coupable. »

Pas plus que :

« le noyau 6.12 était coupable. »

Et encore moins :

« Bookworm est mauvais. »

Ce que nous pouvons dire, en revanche, est beaucoup plus solide :

La même Raspberry Pi Zero 2 W, dans les mêmes conditions physiques, est capable de maintenir une connexion Wi-Fi stable sous Armbian alors que notre installation Bookworm présentait des pertes de connexion.

Ça, c’est un résultat expérimental.

La Pi est-elle finalement innocente ?

Nous ne pouvons pas non plus l’affirmer à cent pour cent.

Un défaut matériel intermittent reste toujours théoriquement possible.

Mais le fait que le même Raspberry Pi puisse rester connecté sous Armbian, tout en faisant fonctionner simultanément CUPS, Avahi, USB, CAPT et l’impression réseau, constitue un argument sérieux contre l’hypothèse d’une panne matérielle permanente.

Notre meilleure méthode reste donc la plus simple :

laisser fonctionner le Raspberry Pi et observer.

Et soudain, notre projet change encore de nature.

Jusqu’ici, nous cherchions principalement à savoir comment faire fonctionner une Canon LBP-810.

Nous savons maintenant le faire.

Mais nous venons également de découvrir quelque chose d’autre :

le choix du système d’exploitation est devenu une partie intégrante de la reproductibilité du projet.

Une configuration qui imprime mais décroche du réseau n’est pas encore une bonne base pour un serveur autonome.

Nous voulons quelque chose que l’on puisse installer, laisser fonctionner, sauvegarder et reproduire.

Et c’est précisément ce que nous allions commencer à obtenir avec Armbian.

Une nouvelle base pour le laboratoire.

À ce stade, notre situation pouvait enfin être résumée ainsi :

Raspberry Pi Zero 2 W
        │
        ▼
Armbian Ubuntu 26.04
        │
        ├── Wi-Fi
        ├── SSH
        ├── CUPS
        ├── Avahi
        ├── CAPT 0.1
        └── Canon LBP-810
                │
                ▼
          network printing

Et surtout :

Bookworm
   → experimentation
   → working state
   → stability problems
   → cause not established

Armbian
   → new experiment
   → same hardware
   → working printing
   → significantly better stability
   → extended observation

Le changement n’était donc pas une fuite devant un échec.

C’était simplement une nouvelle étape de l’enquête.

Le serveur n’est pas encore « Gold Master ».

Nous avions maintenant une configuration très prometteuse.

Mais nous n’allions pas commettre la même erreur qu’au début :

déclarer le projet terminé trop tôt.

Le Raspberry Pi devait encore passer l’épreuve du temps.

Nous voulions vérifier qu’Armbian pouvait rester stable plusieurs heures, puis plusieurs jours, sans ping artificiel et sans intervention humaine.

Pour l’instant, les premiers résultats étaient extrêmement encourageants :

🟢 Wi-Fi
🟢 systemd-networkd
🟢 CUPS
🟢 Avahi
🟢 CAPT 0.1
🟢 Windows / IPP
🟢 Canon LBP-810
🟢 perfect printing

Et à 20:36, le Raspberry Pi était toujours joignable.

Sans ping permanent.

Sans tweak supplémentaire.

Sans redémarrage.

Une dernière précaution.

Nous avions enfin une raison valable de conserver cette installation exactement telle quelle.

Pas question de réinstaller quelque chose juste pour voir si une autre version est plus jolie.

Pas question non plus de modifier une configuration qui fonctionne pour essayer de la rendre encore plus « parfaite ».

Nous avions désormais un environnement expérimental suffisamment stable pour commencer à envisager une sauvegarde complète.

Et cette sauvegarde allait devenir essentielle.

La suite de l’enquête.

Avec Armbian, le problème initial n’était pas totalement expliqué.

Mais nous avions obtenu quelque chose de plus précieux qu’une hypothèse :

une deuxième plateforme fonctionnelle sur exactement la même Raspberry Pi Zero 2 W.

Le laboratoire disposait désormais d’un véritable point de comparaison :

Same Pi
   │
   ├── Bookworm
   │     └── unstable Wi-Fi
   │
   └── Armbian
         └── stable Wi-Fi

Nous ne savions pas encore précisément pourquoi.

Mais nous savions désormais quelque chose d’essentiel :

la petite Pi n’était probablement pas condamnée.

Et mieux encore :

notre serveur Canon venait peut-être enfin de trouver son véritable terrain de jeu.

À suivre…

(10) — Armbian : la configuration devient reproductible.

La prochaine étape sera de transformer cette installation qui fonctionne en véritable référence du projet.

Configuration finale, vérification de tous les services, sauvegarde complète de la carte et contrôle d’intégrité :

working
    ↓
stable
    ↓
backed up
    ↓
reproducible

Autrement dit :

nous allons fabriquer notre Gold Master.

AxehGo & DebIA — Independent Research & Experiments in Linux, AI and Statistical Computing