All Projects

L’API de lecture AirMedia marche (littéralement) une fois sur deux pour les lectures de vidéos sur le Freebox Player:

1. si on lance une lecture après une autre, elle a pour effet de stopper la précédente, mais ne se lance pas elle même. Il faut la relancer. On pourrait contourner ce problème en envoyant deux fois la lecture, mais pour le cas de démarrage où aucune vidéo n’est en train d’être lue, on arriverait jamais à lire quoi que ce soit vu que le deuxième envoi annulerait le premier.
2. si on utilise un stop avant chaque lecture, seul un couple (stop, start) sur deux est prit en compte.

J’ai fait un programme minimaliste pour illustrer le problème:
https://gist.github.com/anisse/ed92d218fd05dd6e1c03

Il met en exergue le problème 2 par défaut. Il faut commenter les stop pour tester le cas 1. Pour l’utiliser il faut le configurer avec un app_token et un app_id valide.

Comme le programme lit 3 vidéos, si on le lance plusieurs fois de suite, on voit bien qu’il lit une vidéo sur deux à chaque fois.

Essayer de lire certaines URL avec AirMedia ne fonctionne plus, par exemple, chez YouTube:
youtube-dl –get-url https://www.youtube.com/watch?v=ZM8ECpBuQYE

Streamer cette URL avec l’api AirMedia (POST /api/v3/airmedia/receviers/...) renvoie une erreur avec le code “http” et le message “Erreur airmedia : Erreur http”. Passer la même URL au Freebox Server via l’API de Download fonctionne correctement, donc pas de soucis à ce niveau (blocage d’IP, etc.)

Cela fonctionnait parfaitement avant fin avril 2016.

Bonjour,

Un de mes utilisateurs est récemment passé en Fibre ZMD, et dispose maintenant d’un quart des ports entrants. L’accès à distant Freebox OS ne fonctionne plus, idem avec Freebox Compagnon. Que lui conseiller dans ce cas là ?

a/ Modifier les ports à la main dans l’interface? Cela résout le problème, mais l’opération nécessite quelques manipulation
b/ Demander une adresse IPv4 full stack dans l’espace abonné ?
c/ Remettre son Freebox Server en configuration d’usine ?

b/ et c/ sont les plus simples, mais pour c/ est trop agressif avec l’utilisateur, b/ va (peut-être?) à l’encontre de la stratégie de Free et demande quelque manipulations, et a/ est compliqué résout le problème uniquement pour l’accès distant Freebox OS, il faut faire plus de manipulations pour les autres services (ftp, vpn, …).

C’est probablement le seul à m’avoir contacté, mais nul doute que d’autres ont eut le même soucis et pas fait le rapprochement avec le passage en fibre (par exemple s’ils ont migré il y a longtemps et n’utilisent aucune fonctionnalité Freebox OS). Il faut que la transition soit automatique, et c’est le sujet de ce ticket.

La transition automatique des ports d’accès distants ne devrait pas être trop douloureuse: Freebox Compagnon sait déjà détecter une Freebox locale; les autres applications pourront refaire l’association ou améliorer leur détection. Pour les services d’accès distants, ils ne fonctionnent de toute façon plus; refaire leur configuration est obligatoire.

Cela casse par contre la connectivité IPv6. Mais je ne sais pas à quelle point elle est répandue; il semblerait que pour cet utilisateur elle n’ait pas fonctionné avec Freebox Compagnon et son opérateur mobile. Pour mon service, j’avoue ne pas avoir utilisé le nouveau sous-domaine .fbxos.fr (je vois qu’il y a bien un champ AAAA), et je ferai cette modification dés que possible.

Il arrive (assez rarement, je n’ai pu le reproduire personnellement) qu’une application Freebox OS perde l’intégralité de ses permissions. On mesure une occurrence d’environ 1%.

Il n’y pas de certitude que les utilisateurs ne changent pas eux même les permissions, mais ça me paraitrait bizarre.

Désolé pour la légèreté du rapport, j’essaierai de compléter si jamais il y a plus d’infos.

Bonjour,

Sur ma Freebox Delta, version 4.8.11, moins d’une heure après le renouvellement du certificat Let’s Encrypt (Dimanche 23 juin vers 7h30, le renouvellement ayant eu lieu à 4h36 GMT), le certificat envoyé n’est plus complet: il manque la chaine de certificat (ISRG root + R11), seul le leaf est envoyé.

L’impact est que tous les clients qui n’ont pas le root et l’intermediaire en cache vont avoir une erreur TLS lors de la connexion (API, etc.); n’affecte pas les navigateurs qui ont quasiment toujours une copie de ces certificats en cache.

Mac: 34:27:92:66:98:20

Merci d’avance

Suite au passage de mon app à l’api .fbxos.fr HTTPS, j’ai eu des retours de plusieurs utilisateurs qui n’arrivaient pas à associer leur Freebox.

Il semblerait que la première fois qu’on fait une demande d’association, les ports sont fermés, et qu’il faille obligatoirement faire l’association en HTTP. Les fois suivantes, cela fonctionne bien. La Freebox ne détecte pas non plus que l’IP publique que l’ont cherche à joindre est la sienne; un routage adéquat serait appréciable.

Autre point: le /api_version contient bien https_available = true, donc pas de fallback possible sur l’hôte mafreebox.freebox.fr. Ni les ports http, ni https ne sont ouverts depuis l’IP extérieure.

https://dev.freebox.fr/sdk/os/login/ mentionne l’hôte HTTP mafreebox.freebox.fr, mais ne précise pas que la connexion d’association doit se faire en clair sur le port 80.

Ce comportement est appréciable au niveau sécurité, mais il serait bon soit de le documenter, soit de router les IPs publiques en interne directement.

Bonjour,

Quelles sont les nouveautés de l’API 5.0 ? Il me semble que la doc ne les affiche pas encore