Freebox V5 ADSL

Ce qui m’a mis sur la voie c’est que le UPnPDevice de OSGi a une propriété CHILDREN_UDN qui contient un String[] des UDN des embedded devices ; à quoi bon, si les embedded devices doivent tous avoir le même UDN ? Par contre, si chaque device doit avoir un UDN différent de ses petits copains, ça prend tout son sens.

http://www.osgi.org/javadoc/r4v42/org/osgi/service/upnp/UPnPDevice.html#CHILDREN_UDN

“The value is an array of UDNs for each of the device’s children ( String[]). The array contains UDNs for the immediate descendants only.”

Pour la petite histoire...

Depuis le début je ne comprenais pas pourquoi les control point UPnP n’affichaient pas bien le IGD de la Freebox

Par exemple, avec gupnp-universal-cp 0.7.1, “A Generic Control Point based on GUPnP framework.
Inspired by Intel Tools for UPnP.”, qui est fourni dans la distribution GNU/Linux Ubuntu, je ne vois que “WAN Connection Device”, le dernier device de la liste avec cet UDN, aucun des deux autres “InternetGatewayDevice”, ni “WANDevice” qui ont été ecrasés parce qu’ils avaient le même UDN.

Tandis que avec un SpeedStream je vois bien un “InternetGatewayDevice”, contenant un “LANDevice” et un “WANDevice”, contenant à son tour un “WANConnectionDevice”, puisqu’ils ont tous des UDNs uniques et pas tous le même ; sinon, il n’y aurait pas besoin d’un élément “UDN” dans chaque élément “device”, un seul dans l’élément “root” aurait suffit pour tout le device physique, si tous les sous devices devaient avoir le même UDN que le root device, comme c’est le cas avec la Freebox.

Un UDN est l’identifiant d’un device logique, pas du device physique.

Pendant que j’y suis, j’en aurais un autre...

Au NOTIFY d’un event j’ai reçu ceci (j’ai changé l’adresse IP) :

<?xml version=”1.0”?><e:propertyset xmlns:e=”urn:schemas-upnp-org:event-1-0”><e:property><PossibleConnectionTypes>IP_Routed</PossibleConnectionTypes><ConnectionStatus>Connected</ConnectionStatus><ExternalIPAddress>192.0.2.254</ExternalIPAddress><PortMappingNumberOfEntries>5</PortMappingNumberOfEntries></e:property></e:propertyset>

Je pense qu’il aurait fallu un élément “property” pour chaque variable envoyée, comme ça :

<?xml version=”1.0”?><e:propertyset xmlns:e=”urn:schemas-upnp-org:event-1-0”><e:property><PossibleConnectionTypes>IP_Routed</PossibleConnectionTypes></e:property><e:property><ConnectionStatus>Connected</ConnectionStatus></e:property><e:property><ExternalIPAddress>192.0.2.254</ExternalIPAddress></e:property><e:property><PortMappingNumberOfEntries>5</PortMappingNumberOfEntries></e:property></e:propertyset>

Si j’interprète bien la phrase de la spécification concernant l’élément “property” suivante :
Repeat once for each variable name and value in the event message.

Encore un autre :

Le IGD de la Freebox n’envoie pas de ssdp:byebye quand on choisi de la “Redémarrer” par l’interface utilisateur.

Et, comme elle reboote en moins de trois minutes, aucun control point ne s’en rend compte tant qu’ils n’ont pas à renouveler une inscription aux événements, par exemple ; ce qui peut faire une demi heure après le reboot.

Je me demandais aussi pourquoi certains programmes n’avaient plus tous leurs port mappings après un reboot ; et on doit les relancer, eux aussi, pour que tout revienne dans l’ordre.

Pour constater l’absence de ssdp:byebye vous pouvez utiliser le petit programme Java que j’avais précédemment fourni :
http://bugs.freeplayer.org/task/3315

Vous le lancez, vous attendez un peu de recevoir les ssdp:alive de la Freebox, pour constater que tour marche bien et avec votre télécommande vous allez “Redémarrer” la Freebox ; et rien de spécial, alors que vous auriez du voir s’afficher une série de ssdp:byebye en une fraction de seconde, quasi immédiatement.

Alors, j’en ai parlé avec UPnP, après tout, peut-être que j’ai tout compris de travers, et voici la réponse qui m’a été faite :

We’ve discussed this issue in the UPnP Forum Technical Committee, and have come to the conclusion that the description of UDN in the UPnP Device Architecture is clear: it says, in the definition of UDN, “Universally-unique identifier for the device, whether root or embedded.” Unless the reader doesn’t understand the meaning of “universally-unique” – “unique in the universe” – this should be clear enough. We could add some redundant explanation, but before updating the UDA we want to understand the scope of the problem.

In your message, you indicate that you’ve seen “many” internet gateway devices that are using the same UDN for the root device and all the embedded devices. Such a device should not be able to pass the UPnP device certification test, but maybe the ones you’re seeing are not certified implementations. Could you tell us the manufacturer and model of the devices exhibiting this behavior?

Et c’est signé “Chair, UPnP Forum Technical Committee”.

En retour je lui demande s’ils ne pourraient pas au moins ajouter une clarification dans ce document http://www.upnp.org/download/UPnP_Vendor_Implementation_Guide_Jan2001.htm et aussi ajouter un sample device moins basique que ceux présents sur le site, c’est à dire un device avec subdevices.

Je lui explique aussi qu’il y a au moins un modèle de box par FAI, qu’elles utilisent toutes un kernel Linux pour minimiser les couts et que la seule certification réellement nécessaire est le comportement de Windows.

D’un coté, c’est bien, là, mon bundle OSGi devrait marcher avec n’importe quel bug de IGD, il est blindé. :)

Parce que, on peut toujours les contourner, quand on les croise. Je me suis résolu à faire mon propre Control Point vu que le package org.osgi.service.upnp seul ne permet pas de connaitre l’adresse de l’interface réseau qui a pu causer avec tel ou tel device et que pour faire du port mapping avec un IGD c’est un peu essentiel. :)

Je l’ai vu ailleurs, le bug de l’UDN. Les autres sont moins faciles à détecter : il faut causer aux devices. Comme il y a au moins autant de modèles de IGD que de FAIs dans le monde, les tests risquent d’être coton. Heureusement, mes sources sont open/free, d’autres hackers pourront les adapter pour moi.

Chacun fait à sa manière, vous n’êtes pas en contact entres FAIs du monde entier pour partager vos connaissances ? Une association de FAIs pour mettre en commun vos compétences techniques. Un ISP d’Australie pourrait utiliser et enrichir les sources du NAT-PMP d’un ISP d’Autriche et réciproquement et tous les usagers pourraient en bénéficier.

J’ai tout de même bien apprécié les fonctionnalités fournies pas le IGD de la Freebox, qui sont au-delà du strict minimum requis par la spécification. Comme, par exemple, le mapping qui n’est forcément statique (prise en compte du lease duration) et sûrement encore d’autres choses ; j’ai encore quelques modules à écrire avant de pouvoir l’utiliser en conditions réelles. :)

Bonjour,

Je vais essayer la 1.5.8 voir ce que ça donne... :)

Pour le bug intermittent, comme son nom l’indique, il faut tomber dessus.

- je suis sûr qu’il y avait des ssdp:alive, sinon j’aurais signalé leur absence en priorité ;
- pour les réponses au M-SEARCH, il faudrait que je retombe dessus, je serais moins catégorique : un petit oui, sans conviction ;
- pour les actions, je n’ai pas de programme capable d’en envoyer sans avoir reçu auparavant la description, alors ça va être moins simple...

Je vais rebooter quelques fois, dès que je pourrais sans pénaliser tout le monde ici.

Ah, tiens, je ne l’avais pas remarqué, je suppose que ça va de paire avec le ssdp:byebye : il n’y a pas de ssdp:alive au démarrage.

Maintenant, je vois bien toute l’arborescence des devices avec le control point gupnp-universal-cp : des UDNs différents.

C’est ok pour le “max-age=2700” ; j’attends un autre ssdp:alive qui devrait arriver d’ici 22 minutes, environ, comme le premier.

Il y a bien les 10 ssdp:alive, aussi, 1 par service (x3), 2 par device (x3) + 1 pour le rootdevice, avec les bons USNs.

Ça a l’air ok aussi pour les ssdp:alive suivants.

J’essaye de tomber sur le bug intermittent, maintenant... il n’est pas systématique, ça va être chaud.

Le bug intermittent ne se produit que certaines fois, assez rarement, au démarrage de la box. Je vais faire des essais à froid dans le courant de la nuit ; là, je ne peux pas trop.

Même sous Windows, maintenant il y a l’icône de la connexion à Internet.

Ah, oui, une autre chose très bien avec le IGD de la Freebox : on ne peut mapper un port que avec l’adresse locale ; on ne peut pas mapper avec une autre adresse du LAN. Sinon, ce serait un sacré trou dans la sécurité.

Ayest, j’ai réussi et je retire ce que j’ai dit : ça ne le fait pas tout de suite au démarage. J’ai démarré à froid après avoir coupé la Freebox ADSL une heure, pour tester si la nouvelle version de mon programme marchait bien en l’absence du ssdp:byebye.

Quand j’ai rallumé, j’ai bien eu le http://192.168.0.254:5678/desc/root . Par contre, après le premier ssdp:alive, environ 15 minutes après le démarrage, j’ai réessayé et je n’ai pas eu la description avec Firefox et telnet me répondait “Unable to connect to remote host: Connection refused”.

Ah, j’avais gupnp-universal-cp qui était aussi lancé et lui a bien eu la description. J’avais encore un autre programme, à part le mien, qui était lancé et qui n’a rien pu recevoir non plus et sûrement d’autres sur d’autres ordis. Ce serait la “simultanéité” des demandes que le IGD n’aimerait pas ?

Par contre, il continue bien d’envoyer les ssdp:alive ; mais, il ne répond pas aux M-SEARCH, contrairement à ce que j’ai dit plus haut.

Dommage que le bouton “Redémarrer” passe tout seule sur “Faire sonner le téléphone”, j’aurais pu faire des essais nocturnes. (je chercherais si ce bug a été signalé et je le signalerais le cas échéant, plus tard)

J’ai réussi à le planter avec un bug que j’avais : mon programme s’inscrivait aux events sans mettre les angle brackets < > autour du delivery URL.

CALLBACK: <delivery URL>

Pourtant, quand je fais ça après un M-SEARCH, ça ne pose pas de problème ; je recois bien les events en retour. Sans M-SEARCH, quand mon programme est lancé avant de démarrer la FB, elle n’aime pas.

C’est sûrement ça qui bloquait tout au démarrage, aussi.

D’accord, d’ici 10 minutes ça devrait être bon, si j’ai vu juste.

Ah ben, non, j’ai du me tromper d’erreur.

Mais, ok, je le signalerais ici si ça le refait et je ne redémarrerais pas la box.

Ayest, apu et je ne sais pas suite à quoi... :(

À votre service... :)

C’est plus mieux avec “HTTP/1.0 500 Internal Server Error”. :)

Ça se rétabli tout seul, avec un watchdog ?

Oui, ça s’est rétabli tout seul sans avoir à relancer quoi que ce soit.

Ça me l’a fait à 18:37:30, pour tous les events, la première fois. Ensuite ça me le fait presque tout le temps depuis.

Le petit programme spécial que j’ai fait attend les ssdp:alive et s’inscrit aux events pour 30s, afin de recevoir le premier jet qui devrait m’indiquer la totalité des variables à event.

Il vient encore de me le refaire à 20:52:30.

C'est bon, il y a ça dans Ubuntu. Je l'installe et je regarde ce que je peux en faire.

Non, ça ne va pas le faire. Mon programme n'utilise pas un port en particulier ; il prend le premier disponible. Peut-être, en coupant tous les autres programmes qui sont lancés en même temps ; mais, je ne peux pas me permettre de me couper du monde, à cette heure-ci .

J'ai coupé d'autres programmes qui causaient aussi avec le IGD et ça ne retourne plus de code 500.

Et j'en fais quoi, après ?

À quelle adresse email est-ce que j'envoie ça ? :D

Ce que je ne comprend pas, c'est ce que viennent faire ces 32, là. Je m'inscris toutes les 15 minutes, pour une durée ne dépassant pas 30 minutes, il ne peut jamais y avoir plus de 3 inscriptions dans la box, les trois dernières. À t0 j'inscris S0, pour une durée de 30 mn ; 15 mn plus tard, à t1, j'inscris S1, aussi pour 30 mn ; et enfin 15 mn plus tard à t2, j'inscris S2, toujours pour 30 mn ; au pire 15 minutes après, j'aurais les inscriptions S1, S2 et S3 encore actives ; parce que S0 aura forcément expiré ; je ne vois pas comment je pourrais avoir plus de 3 inscriptions simultanées, même en tenant compte du décalage des horloges, comme je viens de le faire. En plus, il ne compte pas vraiment, le décalage des horloges, puisque c'est la box qui fixe t0, t1 et t2 en envoyant ses ssdp:alive.

Je sais qu'on est short en ressources, en info indus. J'en ai fait assez d'années pour m'en rendre compte. :)