Le contexte

J’ai récupéré deux Cisco Aironet SAP1602I d’occasion — le genre de matos qu’on trouve pour presque rien parce qu’il sort de parcs d’entreprise. Problème classique : les deux étaient en mode CAP (Lightweight Access Point, firmware k9w8), c’est-à-dire configurées pour être pilotées par un contrôleur WLC. Sans WLC, elles cherchent un contrôleur dans le vide et restent inutilisables. Mon infra perso tourne en bornes autonomes SAP (k9w7), il fallait les migrer.

Deuxième problème : le firmware SAP de cette série est EOL depuis des années, Cisco a retiré les téléchargements publics, et sans compte partenaire t’es coincé.

Sauf que j’en avais déjà une en prod, modèle identique, en SAP, qui tournait très bien. Solution évidente.

Photos de la bête

Dessus, dessous, branchée pendant le flash :

Photo 1 Face avant

Photo 2 Face arriere

Photo 3 Connectée pendant la procedure

Le port CONSOLE c’est du RJ45 classique (câble console Cisco standard), le ETHERNET c’est du PoE 802.3af/at ou alim jack 48V DC. Et le bouton MODE, on va en avoir besoin.

SAP vs CAP : la différence en deux mots

SAP (k9w7) CAP (k9w8)
Mode Autonome Lightweight (contrôleur)
Config Directement sur la borne Déportée sur WLC
Usage Infra perso, bureau Déploiement entreprise

Les deux firmwares cohabitent dans le même boîtier, même image de boot. Seul le suffixe dans le nom du tar change. Si tu reçois une borne d’occase en CAP, c’est quasi systématiquement parce qu’elle sortait d’un réseau d’entreprise géré par WLC.

Étape 1 : récupérer le firmware depuis la borne de prod

Sur la borne de prod en SAP (k9w7), j’ai d’abord vérifié ce qu’il y avait en flash :

AP-PROD#dir flash:
Directory of flash:/
    3  drwx         896   Mar 1 1993 01:07:45 +01:00  ap1g2-k9w7-mx.153-3.JC
  ...

Le répertoire est là, mais le tar original n’existe plus — il a été décompressé lors de l’installation. C’est le premier piège : archive download-sw attend un tar structuré d’une certaine façon, et un tar reconstruit maison ne passe pas toujours. On y reviendra.

Pour extraire le firmware vers le serveur TFTP, IOS a une commande qui fait exactement ça :

archive tar /create tftp://192.168.X.254/ap1g2-k9w7-tar.153-3.JC.tar flash:/ap1g2-k9w7-mx.153-3.JC

Attention : la borne de prod était sur un VLAN dédié à l’interface d’admin des bornes wifi, et mon serveur TFTP sur un VLAN infrastructure. Vérifiez la politique de routage inter-VLAN pour que ça passe. Si la commande passe en timeout sans raison apparente, c’est là qu’il faut chercher.

Le tar est maintenant sur le TFTP. On attaque.

Étape 2 : passer par le bootloader

C’est la procédure universelle sur les Aironet quand archive download-sw ne suffit pas — et dans mon cas il ne suffisait pas, j’y reviens plus bas.

Procédure :

  1. Débrancher l’alimentation
  2. Maintenir le bouton MODE enfoncé
  3. Rebrancher l’alimentation, garder MODE enfoncé
  4. Attendre le message button is pressed, wait for button to be released..., attendez surtout que la borne passe au rouge fixe
  5. Relâcher

La borne tente un boot TFTP automatique sur 255.255.255.255/ap1g2-k9w7-tar.default — elle ne trouve rien, tombe au prompt ap:. C’est là qu’on veut être.

ap: set IP_ADDR 192.168.X.Y
ap: set NETMASK 255.255.255.0
ap: set DEFAULT_ROUTER 192.168.X.254
ap: tftp_init
ap: tar -xtract tftp://192.168.X.254/ap1g2-k9w7-tar.153-3.JC.tar flash:

L’extraction prend quelques minutes. Quand c’est fini :

ap: set BOOT flash:/ap1g2-k9w7-xx.153-3.JC
ap: boot

Piège classique : sur set BOOT, il faut pointer sur le fichier xx (l’image IOS compressée), pas sur le fichier mx (le bootloader secondaire). Les deux existent dans la flash après extraction. Pointer sur mx donne une erreur magic number mismatch au boot, et la borne tente de charger depuis un fallback — déroutant la première fois.

Étape 3 : nettoyer l’ancienne image CAP

Une fois bootée en SAP, vérifier qu’il reste de la place et supprimer l’image CAP k9w8 si elle est encore là :

dir flash:
delete /recursive /force flash:/ap1g2-k9w8-mx.153-3.JF7

Pourquoi archive download-sw ne fonctionnait pas

J’ai d’abord tenté la voie courte — flasher directement depuis IOS avec archive download-sw /overwrite /reload depuis une borne déjà démarrée. Ça échouait systématiquement avec ERROR: Problem extracting files from archive, même avec suffisamment d’espace libre.

La cause probable : le tar reconstruit avec archive tar /create a une structure légèrement différente d’un tar officiel téléchargé depuis Cisco. archive download-sw est plus exigeant sur la structure interne que le bootloader, qui lui accepte n’importe quel tar valide.

En résumé :

  • archive download-sw → fonctionne avec un tar officiel Cisco téléchargé
  • Bootloader ap: tar -xtract → fonctionne aussi bien avec un tar reconstruit

Si tu récupères le firmware d’une borne de prod, passe par le bootloader. Point.

Version firmware

Le 15.3(3)JC est la version la plus récente que j’ai pu obtenir par cette méthode — c’est la version de 2015. Il existerait des versions plus récentes dans la branche JF (15.3(3)JF5, JF15…) mais elles sont introuvables sans accès partenaire Cisco. Pour du matos EOL en infra perso, la JC fait le job.

Conclusion

La procédure complète tient en quelques commandes, mais les pièges sont là :

  • Le tar n’existe plus après installation, il faut le reconstruire avec archive tar /create
  • Le routage inter-VLAN doit être vérifié avant le transfert TFTP
  • archive download-sw peut refuser un tar reconstruit → bootloader obligatoire
  • set BOOT doit pointer sur xx et non sur mx

Une borne CAP récupérée pour trois fois rien qui redevient une SAP pleinement fonctionnelle. C’est ça aperturezone.