Le système Blink de caméras et sonnettes connectées

Première identification réseau : 23 août 2026, depuis le poste Windows julie (192.168.1.26, Ethernet). Script de relevé : Jux-scripts/Reseau-LAN/scan_lan.py

Ce qui a été cherché

Question de départ : la sonnette Blink est-elle visible sur le réseau local ? Réponse : oui, un unique appareil au constructeur Amazon répond sur le LAN domestique.

L'appareil Blink

Champ Valeur Adresse IP 192.168.1.128 (bail DHCP Livebox) Adresse MAC e8:4c:4a:62:8d:d9 OUI E8:4C:4A Amazon Technologies Inc. Nom DHCP / DNS inverse device-19.home Ports TCP ouverts 443 uniquement Latence 3–6 ms, 0 % de perte

Le port 443 n'accepte aucun client anonyme. Handshake TLS rejeté dans toutes les configurations testées :

Tentative Résultat TLS auto (jusqu'à 1.3), ALL:@SECLEVEL=0 SSLV3_ALERT_HANDSHAKE_FAILURE TLS 1.2 forcé, ALL:@SECLEVEL=0 SSLV3_ALERT_HANDSHAKE_FAILURE TLS 1.0 forcé TLSV1_ALERT_PROTOCOL_VERSION

L'appareil impose donc son propre jeu de suites cryptographiques, et exige vraisemblablement un certificat client (authentification mutuelle). Comportement attendu et sain : le point de contact local ne parle qu'à l'application Blink et au cloud Amazon. Il n'y a pas d'interface web, pas de flux RTSP, pas d'API locale exploitable — inutile de chercher à brancher Frigate, Scrypted ou Home Assistant dessus par cette voie.

Ce que le réseau ne dit pas

Impossible de distinguer la sonnette du module Sync depuis le LAN. Les deux portent une OUI Amazon et le même profil de port. Pour trancher : application Blink → Paramètres de l'appareil → Informations, qui affiche l'adresse MAC de chaque appareil. À reporter ici une fois relevé. Un seul appareil Amazon répond. Si le foyer compte à la fois une sonnette et un module Sync, le second est en veille au moment du relevé. La Blink Video Doorbell sur batterie en mode standard dort entre deux événements et ne répond alors ni au ping ni à l'ARP ; elle n'est connectée en permanence qu'en câblage secteur (mode « enhanced »). Point à confirmer par un relevé déclenché juste après avoir sonné à la porte.

Inventaire complet du LAN — 192.168.1.0/24

Relevé du 2026-08-23 (balayage ping de .1 à .254, puis lecture de la table ARP) :

IP MAC Constructeur Nom DNS Ports TCP .1 20:37:f0:a1:fa:dc Arcadyan Corporation lan.home 80, 443, 8883 .10 72:75:be:32:27:c4 [MAC aléatoire] lenovo-tab-k11.home aucun .11 4e:16:10:cb:79:51 [MAC aléatoire] redmi-note-11-pro.home aucun .17 00:11:32:9c:8e:c9 Synology Incorporated — 21, 22, 80, 139, 443, 445 .23 2e:a5:80:20:23:b8 [MAC aléatoire] s23-de-elio.home aucun .128 e8:4c:4a:62:8d:d9 Amazon Technologies Inc. device-19.home 443 .129 d4:3a:2e:d8:c5:52 SHENZHEN MTC CO LTD — 80 .200 d4:3a:2e:d8:c5:52 SHENZHEN MTC CO LTD — 80

.1 = la Livebox (Arcadyan en fabrique les modèles récents). Le port 8883 est du MQTT sur TLS — canal de télégestion Orange. .17 = le NAS Synology NASMAISON, déjà documenté ailleurs (lecteur A: → \NASMAISON\foxy). .129 et .200 portent la même MAC. Un seul appareil Shenzhen MTC (fabricant de cartes mère de téléviseurs et de boîtiers connectés) avec deux baux DHCP actifs — il a changé d'adresse sans que l'ancien bail soit purgé. Sans gravité, mais à nettoyer dans l'interface Livebox si la table se remplit.

Points de méthode — à ne pas re-découvrir

arp -a seul ne montre presque rien. Le cache ARP ne contient que les hôtes contactés récemment — 3 entrées au premier relevé, contre 8 après balayage. Toujours pinger le /24 avant de lire la table ARP. La sortie de arp -a est traduite sous Windows (dynamique et non dynamic). Ne jamais filtrer sur ce mot-clé : parser par expression régulière sur le couple IP + MAC. C'est ce que fait scan_lan.py. Une MAC dont le 2e bit du premier octet est posé est aléatoire, pas un vrai constructeur : 72:, 4e:, 2e:… Test : int(octet1, 16) & 0x02. C'est la randomisation MAC des OS modernes (Android, iOS, Windows) — inutile d'interroger une base OUI, elle ne renverra rien. Trois des huit appareils du LAN sont dans ce cas. Le DNS inverse de la Livebox est la source la plus riche. socket.gethostbyaddr() renvoie les noms d'hôte du domaine .home (redmi-note-11-pro.home, s23-de-elio.home) — bien plus parlant que l'OUI pour les téléphones à MAC aléatoire. Ne pas s'arrêter à l'OUI. api.macvendors.com limite à ~1 requête/seconde en accès gratuit. Le script temporise 1,5 s et met en cache dans oui_cache.json ; les relevés suivants peuvent tourner en --hors-ligne. curl.exe est absent du poste julie — tout passe par Python (urllib) ou Invoke-RestMethod. Un TTL de 64 dans la réponse ping indique une pile réseau Linux/BSD embarquée (Windows répondrait 128). Indice utile pour typer un objet connecté muet.

Commandes de vérification

Inventaire complet, avec sondage des ports :

py -3.12 D:\Syncthing\Jux_univers\Jux-scripts\Reseau-LAN\scan_lan.py --ports

Relevé rapide sans rien pinger ni interroger en ligne (lit le cache ARP et le cache OUI) :

py -3.12 scan_lan.py --sans-balayage --hors-ligne

Vérifier que l'appareil Blink est éveillé :

ping -n 4 192.168.1.128

Le script est en stdlib Python pure — aucune dépendance à installer, il tourne tel quel sur Windows, Ubuntu et le VPS. Il détecte le préfixe /24 tout seul et accepte --reseau pour le forcer.

Reste à faire

Relever dans l'application Blink les adresses MAC de la sonnette et du module Sync, pour savoir lequel est e8:4c:4a:62:8d:d9 Refaire un balayage immédiatement après avoir sonné, pour voir apparaître le second appareil Amazon s'il existe Identifier l'appareil Shenzhen MTC (.129/.200) — probablement un téléviseur ou un boîtier ; son port 80 est peut-être une interface de configuration Purger le bail DHCP en double dans l'interface Livebox Réserver une IP fixe pour la Blink dans le DHCP, si l'on veut la surveiller dans la durée