Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Bonjour

A priori ce modèle de camera google ne supporte pas plus que le wifi 5 (802.11ac).
donc "WPA2/WPA3 Transition, PMF, MLO, le steering…" bah c'est certainement mal supporté.

Avez vous la conf du "supplicant" faisant les requêtes d'authentifications (dans la camera ?) ?
Poster les logs du 4-way handshake et les pcap associés permettrait de mieux comprendre le souci.

Mais perso j'essayerai en WPA2 PSK le plus standard possible en désactivnat 802.11r + 802.11k/v, 802.11ax, 802.11be, etc, au moins le temps de configurer les caméras, puis je réactiverai les features qui sont supportées au fur et à mesure en fonction du besoin des autres devices présent sur le réseau wifi.

Aussi je supprimerai tous les repeaters, créérait une config multiple SSID avec 1 ssid par bssid histoire de supprimer les demandes de roaming intra ssid et je choisirai des cannaux les plus libres possibles histoire que l'AP n'essaye pas de vous ejecter sur une autre frequence car la bande half-duplex de la frequence sur laquelle est la camera est saturée par les voisins.

Après faudrait que Free vous sorte les logs côté freebox sinon l'analyse sera compliqué et peu objective.

Cordialement
nbanba

Bonjour nbanba,

Merci pour votre retour.

Concernant les capacités de la caméra, Google indique officiellement pour la Nest Cam Indoor filaire de 3e génération :

1. Wi-Fi « 802.11ac-ready » en 2,4 GHz et 5 GHz ;
2. prise en charge de WEP, WPA, WPA2 et WPA3 ;
3. Bluetooth Low Energy pour la configuration.

Source :
https://support.google.com/googlehome/answer/9259110

Je suis néanmoins d’accord sur le fait qu’un profil Wi-Fi 5 ne garantit pas une bonne compatibilité avec MLO, 802.11be, le roaming ou toutes les fonctions avancées de la Freebox.

Je n’ai malheureusement pas accès à la configuration du supplicant de la caméra. Le firmware Google est fermé et Google Home ne fournit ni configuration wpa_supplicant ni journaux Wi-Fi détaillés. Un dossier est également ouvert auprès du
support Google afin de leur demander des informations supplémentaires.

En revanche, je dispose bien de captures radio du 4-way handshake.

Voici l’extrait d’une tentative ayant échoué, avec les adresses MAC masquées :

0,965326 s — AP vers caméra — Key Information 0x008a — message 1/4
0,965339 s — caméra vers AP — Key Information 0x010a — message 2/4
1,958459 s — AP vers caméra — Key Information 0x008a — retransmission du message 1/4
1,964327 s — caméra vers AP — Key Information 0x010a — retransmission du message 2/4
2,961263 s — AP vers caméra — désauthentification, reason code 15

Une seconde tentative vers un autre BSSID du même SSID montre le même comportement :

95,937226 s — AP vers caméra — message 1/4
96,122911 s — caméra vers AP — message 2/4
96,940951 s — AP vers caméra — retransmission du message 1/4
96,946821 s — caméra vers AP — retransmission du message 2/4
97,942043 s — AP vers caméra — nouvelle retransmission du message 1/4
97,947263 s — caméra vers AP — nouvelle retransmission du message 2/4
99,941218 s — AP vers caméra — désauthentification, reason code 15

La caméra répond donc bien au message EAPOL 1/4. En revanche, lors de ces échecs, le point d’accès ne transmet jamais le message 3/4 après réception du message 2/4.

La même capture contient ensuite une tentative réussie :

123,067934 s — AP vers caméra — Key Information 0x008a — message 1/4
123,073854 s — caméra vers AP — Key Information 0x010a — message 2/4
123,102472 s — AP vers caméra — Key Information 0x13ca — message 3/4
123,112455 s — caméra vers AP — Key Information 0x030a — message 4/4

Le handshake fonctionne donc parfois intégralement avec le même appareil et le même réseau.

Le point intéressant est que, pendant les tentatives qui échouent, la Freebox reçoit apparemment le message 2/4 mais ne passe pas au message 3/4. Les logs internes de la Freebox permettraient de savoir si le message 2/4 est rejeté pour cause
de MIC invalide, de PMK incorrecte, d’état WPA incohérent ou d’un autre problème dans l’authenticator.

J’ai déjà testé un profil simplifié :

1. SSID dédié au 2,4 GHz ;
2. WPA2-PSK uniquement ;
3. CCMP/AES ;
4. PMF désactivé ;
5. largeur de bande de 20 MHz ;
6. canal fixe ;
7. MLO désactivé ;
8. steering désactivé ;
9. 802.11ax et 802.11be désactivés ;
10. WPS désactivé ;
11. EAPOL version 2.

Même avec ce profil, l’association est restée intermittente.

Lors de la création du SSID dédié, celui-ci était toujours annoncé par plusieurs BSSID de la Freebox. La caméra a essayé successivement ces différents BSSID et les échecs n’étaient pas toujours identiques. Je ne sais pas s’il est possible
dans Freebox OS d’affecter réellement un SSID à un seul BSSID ou à une seule carte physique.

Je n’ai pas identifié de réglages explicites permettant de désactiver séparément 802.11r et 802.11k/v dans Freebox OS. Si ces réglages existent, pouvez-vous m’indiquer où ils se trouvent ?

Pour comparaison, la même caméra a réussi immédiatement sur un point d’accès Linux indépendant configuré en 2,4 GHz, WPA2-PSK, CCMP, PMF désactivé, 20 MHz et canal 6. Elle a obtenu une adresse DHCP, téléchargé sa mise à jour OTA, redémarré,
rejoint automatiquement le réseau puis affiché le flux vidéo.

Je possède les captures PCAP complètes, notamment :

1. une tentative Freebox avec plusieurs échecs EAPOL puis une réussite ;
2. une tentative échouée ;
3. l’appairage réussi sur le point d’accès indépendant ;
4. la reconnexion après mise à jour.

Je peux fournir une capture réduite aux seules trames d’association, EAPOL et désauthentification. Je préfère éviter de publier la capture complète sans anonymisation, car elle contient les BSSID et d’autres identifiants du réseau.

Serait-il possible qu’une personne ayant accès aux logs de l’authenticator Wi-Fi de la Freebox vérifie pourquoi le message 2/4 est refusé lors des tentatives en échec ?

Je peux également reproduire le problème à une heure précise pour faciliter la corrélation avec les journaux internes. ou alors me donner accée au journaux comme ca je le fait de mon coté ?

Cordialement,

Nathan Samani

Bonjour

En effet il faut qu'une personne chez Free regarde les logs dans votre box, surtout si vous n'avez pas accès aux logs du suplicant côté client

Niveau BSSID, si vous éteignez les repeaters et que vous isolez sur uniquement la radio 2.4 le SSID, il y a de forte chance pour qu'il n'y ait qu'1 seule radio 2.4 et 1 seul BSSID en 2.4, en tout cas c'est le cas chez moi (mais je n'ia pas une ultra):

$ list_wifi_bss 
 
				WIFI NETWORKS (BSS):
 
#:    id:                 ssid:               enabled: stations: state:
0:    34:27:92:D9:E0:36   AP                  true     0         phy_stopped
1:    34:27:92:D9:E0:34   AP                  true     0         active
2:    34:27:92:D9:E0:30   AP-2.4GHZ           true     1         active

Le repeater ajoute bien un bssid sur la frequence 2.4GHz d'ou ma recommandation de désactiver les repeaters si vous en avez:

$ show_repeater_detail 1
 
REPEATER 1 (Entrée):
 
	model: fbxwmr-r1	firmware: 2.7.13.1	api_ver: 2	sn: 399904J202042344
	connection: connected	status: running	enabled: true	led_activated: true
	main_mac: 8C:97:EA:55:BB:B6	ip_v4: 192.168.1.189
	ip_v6: fd0f:ee:b0:0:8e97:eaff:fe55:bbb6
	boot_time: mer. 05 août 2026 09:52:03 CEST	last_seen: 0	too_close: false
 
	backhaul:
	  mac: 16:E4:EF:4D:F7:1F	type: eth	band: -	best: false
	  mac: 8E:97:EA:9B:1F:91	type: wifi	band: 2d4g	best: false
	    placement: 1 (weak)	too_close: false	throughput: 6074	signal: -67 dBm
	  mac: 8E:97:EA:9B:1F:95	type: wifi	band: 5g	best: true
	    placement: 55 (strong)	too_close: false	throughput: 221699	signal: -79 dBm
 
	fronthaul:
	  bssid: 8C:97:EA:9B:1F:90	band: 2d4g	enabled: true	ssid: AP-2.4GHZ
	  bssid: 8E:97:EA:9B:1F:90	band: 2d4g	enabled: false	ssid: (hidden/disabled)
	  bssid: 8C:97:EA:9B:1F:94	band: 5g	enabled: true	ssid: AP
	  bssid: 8E:97:EA:9B:1F:94	band: 5g	enabled: false	ssid: (hidden/disabled)

mais si je désactive il ne reste qu'1 BSSID attaché à l'AP 0 (interne à la box):

$ show_wifi_ap 0
 
WIFI AP 0 (2.4G):
 
	band: 2d4g	state: active
	config: width=40 primary=9 secondary=13 dfs_enabled=false
	effective: width=20 primary=9 secondary=0
	ht_enabled: true	ac_enabled: false	he_enabled: false	eht_enabled: false
	bssid: 34:27:92:D9:E0:30	ssid: AP-2.4GHZ

De mon côté j'ai listé ces options configurables sur la carte wifi de la Freebox:

Option par AP:

$ upd_wifi_ap
 
ERROR: "upd_wifi_ap" takes an AP 'id', then at least one of:
id			# ap id, ex: 0 (run "show_wifi_ap_list" to see all APs and their id)
channel_width=		# wanted channel width in MHz: 20, 40, 80, or 160
primary_channel=	# wanted primary channel, 0 = automatic
secondary_channel=	# wanted secondary channel, 0 = automatic
dfs_enabled=		# boolean - enable channels that require DFS
ht_enabled=		# boolean - enable 802.11n
ac_enabled=		# boolean - enable 802.11ac

ERROR: an id is required
 
EXAMPLE:
upd_wifi_ap 0 primary_channel="0" secondary_channel="0"

Option par BSS:

$ upd_wifi_bss
 
ERROR: "upd_wifi_bss" takes a BSS 'id', then at least one of:
id			# bss id (a mac address), ex: 00:24:D4:AA:BB:CC (run "list_wifi_bss" to see all BSS and their id)
enabled=		# boolean
ssid=			# network name
key=			# wifi password
hide_ssid=		# boolean - hide this network from scan lists
encryption=		# ex: wpa2_psk_ccmp, wpa3_psk_ccmp (see show_wifi_bss for the full list this box accepts)

ERROR: an id is required
 
EXAMPLE:
upd_wifi_bss 00:24:D4:AA:BB:CC key="a new wifi password"

Option avancées par BSS:

$ upd_wifi_bss_adv 
 
ERROR: "upd_wifi_bss_adv" takes a BSS 'id', then at least one of:
id			# bss id, MUST be a mac address (ex: 00:24:D4:AA:BB:CC) - a BSS is 
                          identified by the mac address it broadcasts over its own wireless 
                          channel/frequency (a half-duplex medium), unlike an AP which just 
                          has a small numeric id - run "list_wifi_bss" to see all BSS and 
                          their id
eapol_version=		# integer: 1 or 2 - which version of the EAPOL (802.1X 
                          authentication) handshake this network requires. 2 is the modern 
                          default and works with virtually every client made in the last ~15 
                          years; 1 only matters for genuinely old client hardware that can't 
                          do version 2. ex: eapol_version="2" unless you have a specific 
                          old-device compatibility need
gcmp256=		# boolean - use GCMP-256 instead of the default CCMP-128 for 
                          encryption when WPA3/AES is active: a stronger cipher, part of the 
                          WPA3-Enterprise 192-bit security suite. Only useful if every client 
                          on this network actually supports it - enabling it won't help (and 
                          may hurt compatibility) if clients don't
disable_wep=		# boolean - whether the (very old, broken) WEP encryption option is 
                          disabled for this network. Leave disable_wep="true" unless you 
                          specifically need to support a legacy device that only speaks WEP - 
                          WEP itself provides essentially no real security by modern standards
EXAMPLE:
upd_wifi_bss_adv 00:24:D4:AA:BB:CC eapol_version="2"

Option avancées par AP:

$ upd_wifi_ap_adv 
 
ERROR: "upd_wifi_ap_adv" takes an AP 'id', then at least one of:
id					# ap id, ex: 0 (run "show_wifi_ap_list" to see all APs and their id)
 
-- HT (802.11n) --
greenfield=				# bool - "Greenfield" mode: skip legacy (pre-11n) compatibility 
                                          preambles for slightly higher throughput - but a legacy device 
                                          nearby may then interfere, since it can no longer detect the 
                                          transmission is happening. ex: greenfield="false" (safe default, 
                                          keeps compatibility)
shortgi20=				# bool - Short Guard Interval on 20MHz channels: shortens the gap 
                                          between symbols (400ns vs 800ns) for ~10% more throughput, at 
                                          slightly higher risk of inter-symbol interference on a 
                                          noisy/multipath-heavy link. ex: shortgi20="true" (typical for a 
                                          clean home RF environment)
shortgi40=				# bool - same as shortgi20, for 40MHz channels
ldpc=					# bool - Low-Density Parity Check error correction: more efficient 
                                          than the older convolutional coding, improves range/throughput 
                                          especially at a weak signal. ex: ldpc="true" (recommended if the 
                                          client also supports it)
smps=					# 'disabled'/'static'/'dynamic' - Spatial Multiplexing Power Save, a 
                                          MIMO power-saving mode: 'disabled' keeps every antenna active (best 
                                          throughput, most power); 'static' keeps only one active until more 
                                          are explicitly needed; 'dynamic' switches automatically based on 
                                          traffic. ex: smps="disabled" if the AP is mains-powered and 
                                          throughput matters more than power draw
tx_stbc=				# bool - Space-Time Block Coding on transmit: sends the same data 
                                          redundantly across multiple antennas for better reliability, 
                                          particularly useful for single-antenna client devices. ex: 
                                          tx_stbc="true"
rx_stbc=				# 'disabled' or a number as a string (ex: '1') - how many streams 
                                          this radio can decode via STBC on receive. ex: rx_stbc="1"
delayed_ba=				# bool - Delayed Block Acknowledgment: acknowledges a batch of frames 
                                          after a short delay instead of immediately after each one - can 
                                          help throughput on a high-latency link, rarely needed on a typical 
                                          home LAN. ex: delayed_ba="false"
max_amsdu_7935=			# bool - allow A-MSDU (Aggregate MAC Service Data Unit) frames up to 
                                  7935 bytes instead of the smaller default, letting more data travel 
                                  per frame aggregation. ex: max_amsdu_7935="false" unless you know 
                                  client devices benefit from it
dsss_cck_40=				# bool - allow legacy DSSS/CCK modulation (the original 802.11b data 
                                          rates) on a 40MHz-wide channel. Mostly relevant only if very old 
                                          802.11b devices are expected on this band
psmp=					# bool - Power Save Multi-Poll: a scheduling mechanism that lets 
                                          several stations share power-save polling. Legacy 802.11n feature, 
                                          rarely relevant today
lsig_txop_prot=				# bool - L-SIG TXOP Protection: reserves the transmission time so 
                                          legacy (non-11n) devices correctly back off instead of colliding 
                                          mid-transmission. Worth enabling if older devices share the band
-- VHT (802.11ac) --
vht_shortgi80=				# bool - Short Guard Interval on 80MHz channels, same trade-off as 
                                          shortgi20/40
vht_shortgi160=			# bool - Short Guard Interval on 160MHz channels
vht_max_mpdu_len=			# 'default' or a number as a string (ex: '11454') - maximum MAC frame 
                                          size this radio will build/accept; a larger value fits more payload 
                                          per frame (less overhead) but any single lost frame costs more to 
                                          retransmit
vht_rx_ldpc=				# bool - LDPC coding support on receive, VHT equivalent of ldpc above
vht_tx_stbc=				# bool - STBC on transmit, VHT equivalent of tx_stbc above
vht_rx_stbc=				# 'disabled' or a number as a string (ex: '1') - STBC streams on 
                                          receive, VHT equivalent of rx_stbc above
vht_max_ampdu_len_exp=			# integer 0-7 - maximum A-MPDU (Aggregate MPDU) length as an 
                                          exponent: the actual byte limit is 2^(13+exp), so 0 = 8191 bytes, 7 
                                          = 1048575 bytes. Higher allows more frames bundled per transmission 
                                          (more efficient on a clean link, worse if the link is lossy since a 
                                          bundle failure costs more)
vht_rx_antenna_consistency=		# bool - whether this radio uses a consistent antenna pattern across 
                                          packets on receive, which affects how accurately beamforming can be 
                                          computed
vht_tx_antenna_consistency=		# bool - same, for transmit
vht_su_beamformer=			# bool - Single-User beamforming, transmit side: this radio can focus 
                                          its signal toward one client that supports receiving it (see 
                                          vht_su_beamformee)
vht_su_beamformee=			# bool - Single-User beamforming, receive side: this radio can 
                                          receive a signal another beamformer focuses toward it
vht_mu_beamformer=			# bool - Multi-User beamforming: this radio can focus separate 
                                          signals toward several clients at the same time instead of one at a 
                                          time, improving efficiency with many simultaneous clients
vht_sounding_dimensions=		# 'disabled' or an integer - number of spatial streams used for 
                                          channel sounding (measuring the radio link to compute beamforming 
                                          weights). More dimensions = more accurate beamforming, at some 
                                          airtime cost for the sounding exchange itself
vht_beamformee_sts=			# 'disabled' or an integer - number of Space-Time Streams this radio 
                                          can receive as a beamformee (see vht_su_beamformee)
-- HE (802.11ax / wifi 6, hardware-dependent) --
he_enabled=				# bool - enable 802.11ax (wifi 6) on this radio, if the hardware 
                                          supports it
he_su_beamformer=			# bool - Single-User beamforming for wifi 6, transmit side - same 
                                          concept as vht_su_beamformer
he_su_beamformee=			# bool - Single-User beamforming for wifi 6, receive side - same 
                                          concept as vht_su_beamformee
he_mu_beamformer=			# bool - Multi-User beamforming for wifi 6 (works together with OFDMA 
                                          to serve several clients per transmission)
he_twt_responder=			# bool - Target Wake Time responder: lets client devices negotiate 
                                          their own wake/sleep schedule with this AP, reducing their power 
                                          draw (particularly useful for battery/IoT devices). ex: 
                                          he_twt_responder="true" if you have battery-powered wifi 6 devices
he_twt_required=			# bool - whether TWT support is mandatory for a client to associate 
                                          at all - leave false unless you specifically need to exclude 
                                          non-TWT clients
-- EHT (802.11be / wifi 7, hardware-dependent) --
eht_enabled=				# bool - enable 802.11be (wifi 7) on this radio, if the hardware 
                                          supports it
eht_su_beamformer=			# bool - Single-User beamforming for wifi 7, transmit side
eht_su_beamformee=			# bool - Single-User beamforming for wifi 7, receive side
eht_mu_beamformer=			# bool - Multi-User beamforming for wifi 7
EXAMPLE:
upd_wifi_ap_adv 0 shortgi20="true" ldpc="true"
 
EXAMPLE (wifi 7 hardware):
upd_wifi_ap_adv 0 eht_enabled="true" eht_mu_beamformer="true"

Steering :

$ upd_wifi_steering 
 
ERROR: "upd_wifi_steering" takes 'level=':
level=			# 0 (disabled), 1 (steer if the device accepts), or 2 (steer more aggressively)

ERROR: level= is required
 
EXAMPLE:
upd_wifi_steering level="2"

Mais pas d'options explicite pour empêcher de roam entre 2 frequences de la même bande portés par 2 bssid différents.

Niveau authentification, je n'ai pas trouvé le moyen d'avoir les logs, donc en général j'essaye de reproduire avec un laptop sous linux et wpa_supplicant démarré avec l'option '-ddd', c'est assez verbeux et souvent on peut voir les raisons des rejets des handshakes, etc.

De même depuis cette station, je laisse run un terminal avec

iw event -t

Si ça roam à tout va intra ssid cross frequences/bssid, ça peut être assez parlant sur la qualité des ondes autour de vous.

Cordialement
nbanba

Bonjour,

Test effectué le 6 septembre à 19 h 04 avec les répéteurs éteints.

L’appairage a de nouveau échoué, cette fois avec le message « Impossible de trouver la caméra ».

La suppression des répéteurs ne suffit donc pas à résoudre le problème. Je dois encore vérifier le nombre exact de BSSID restant diffusés dans cette configuration, mais le problème persiste sans le réseau maillé des répéteurs.

Pouvez-vous m’indiquer comment obtenir sur ma Freebox les sorties équivalentes à list_wifi_bss et show_wifi_ap afin que je publie l’état exact des radios pendant le prochain essai ?

Pour le prochain test, je relancerai également une capture dès le début de l’appairage afin de déterminer si la caméra atteint l’authentification Wi‑Fi ou si cet échec intervient encore plus tôt, pendant sa détection par Google Home.

Cordialement,

Nathan Samani

J’ai ouvert un ticket free support pour les logs.
Merci !

Bonjour

En fait c'est ma library qui à ces fonctions.
C'est un parsing fait depuis des calls API sur la freebox, vous pouvez reproduire (sans parsing) avec:

curl -s https://mafreebox.freebox.fr/api/v16/wifi/bss/ -H Content-Type: application/json -H "X-Fbx-App-Auth: $_SESSION_TOKEN" -G --cacert /dev/shm/fbx-cacert

si vous n'avez pas les certif de la box pour créer le bundle de certificats dev/shm/fbx-cacert, remplacez '–cacert /dev/shm/fbx-cacert' par '-k' ou '–insecure'

Pour show_wifi_ap <id>, ma commande merge les résultats du call API ci dessus et de :

curl -s https://mafreebox.freebox.fr/api/v16/wifi/ ap/0 -H Content-Type: application/json -H "X-Fbx-App-Auth: $_SESSION_TOKEN" -G --cacert /dev/shm/fbx-cacert

Ou sinon je peux vous passer une "preview" de ma library (je n'ai pas encode push sur github cette version permettant de gérer le wifi, mais je peux vous la passer en avant première si vous voulez, ~100% des calls de l'API freeboxOS sont implémentés)

Cordialement
nbanba

Bonjour,

Merci beaucoup pour votre aide et pour la proposition concernant votre bibliothèque.

Nous avons finalement réussi à récupérer les informations directement via l’API Freebox et à réaliser une capture radio avec une Alfa Network.

Le résultat est assez précis : la caméra détecte bien le SSID Freebox-Samani et reçoit les réponses du BSSID 2,4 GHz, mais elle n’envoie ensuite aucune trame d’authentification, aucune association et aucun paquet EAPOL.

Le test a été effectué en WPA2/WPA3 transition puis en WPA2-AES pur, avec les répéteurs désactivés, un seul BSSID 2,4 GHz actif, canal 1, largeur 20 MHz et les fonctions Wi‑Fi 6/7 désactivées. Le comportement reste identique.

La caméra fonctionne pourtant parfaitement sur un point d’accès Alfa Network configuré en WPA2-AES minimal.

Nous avons donc transmis les captures à Google et ouvert le sujet auprès de Free. À ce stade, la bibliothèque ne semble pas indispensable, car les appels API directs nous ont permis d’obtenir les informations nécessaires.

Merci encore pour votre disponibilité et votre aide précieuse.

Cordialement,

Nathan

Bonjour

Merci pour votre retour.

Il semble que vous ayez bien isolé le souci et qu'un dev de Free devrait regarder pour vous fournir les logs, même s'il s'agit d'une erreur probablement "propre au device"

Le dev Free qui répond ici sur les sujets wifi c est @pablomg.

Si vous êtes intéressés par ma library, elle implémentes 800+ fonctions permettant de gérer l'environnement freebox depuis un simple terminal et de tout automatiser dans des scripts "user-friendly" contrairement au raw json parsing… N'hésitez pas à demander…

Cordialement
nbanba