- État Fermée
- Pourcentage achevé
- Type Anomalie
- Catégorie Routeur
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 1.2.4
- Due pour la version Non décidée
-
Échéance
Non décidée
- Votes
- Privée
FS#3445 - Un seul UDN pour tous les devices du IGD
Depuis le début je ne comprenais pas pourquoi les control point UPnP n’affichaient pas bien le IGD de la Freebox ; et j’en ai essayé quelques uns.
En fait, tous les devices du IGD ont le même UDN, Unique Device Name, que ce soit le root device ou bien les embedded devices.
La doc n’est pas très clair à ce sujet, elle dit de mettre uid:UUID, sans vraiment préciser si tout ces UDN doivent être identiques ou différents ; tout ce que j’ai pu trouver sur le sujet, c’est que d’autres IGD ont des UDN différents pour chacun de leurs embedded devices.
Quelques exemples :
http://www.securiteam.com/securityreviews/6K00L20EUE.html http://svn.dd-wrt.com:8000/dd-wrt/browser/src/router/upnp/xml/InternetGatewayDevice/InternetGatewayDevice.xml http://forum.utorrent.com/viewtopic.php?id=10373 http://pidgin.im/pipermail/devel/2008-May/005823.html
Mis à part ceci, qui est le plus important, j’ai remarqué trois non conformités au protocole SSDP implémenté dans le IGD de la Freebox.
Par ordre d’importance :
1) il envoie des “NOTIFY * HTTP/1.0” ; alors que il devrait envoyer HTTP/1.1, conformément à UPnP/1.0 ;
il pourrait être ignoré par des control points pointilleux.
2) il envoie des headers “CACHE-CONTROL: max-age=180” ; alors que pour UPnP/1.0 max-age doit être au minimum de 1800 secondes ;
et il envoie ses NOTIFY toutes les minutes et quelques au lieu de toutes les 15 minutes environ.
3) il envoie des headers “SERVER: UPnP/1.0 fbxigdd/1.0” qui ne commencent pas avec OS_name/OS_version ;
là, je ne vois pas trop ce que ça pourrait gêner, à part des control points pointilleux².
19.02.2010 21:02
Raison de la fermeture : Résolu
Commentaires de fermeture :
corrigé dans la version 1.5.9
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
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...
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.
Ajoutez à ça miniupnp (http://miniupnp.free.fr/) qui fait la même chose, plus le fait que l’activeX de “validation” d’igd disponible sous Windows ne voit pas de problème et avouez qu’il y a de quoi être dans le doute :)
Toutes vos remarques sont fondées, je vais faire les corrections nécessaires.
Merci pour vos retours très constructifs.
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,
J’ai mis un firmware en béta sur votre Freebox ADSL (1.5.8-pre7 dispo sur simple reboot).
Tout est corrigé sauf le bye au reboot.
Et je n’arrive pas à reproduire le bug que vous décrivez où l’igd ne répond plus aux requetes de description, il me faudrait plus d’infos. Quand ca se produit:
- est ce que le ssdp de keepalive est toujours envoyé ?
- est ce que la box répond toujours aux msearch ssdp ?
- est ce que les requetes d’ouverture/fermeture/listing de port sont toujours honorées ? (ou n’importe quoi sur le port 5678)
Merci !
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.
Est ce que vous pourriez laisser la box en l’état quand le problème se manifeste et me prévenir pour que je regarde svp ?
Merci
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... :(
Ok vu, je regarde merci
C’est bon, c’est corrigé, version -pre8 dispo si vous rebootez.
Le bug se produisait lorsque le nombre de connexions simultanées au serveur http atteignait la limite (5). J’ai corrigé le bug et monté la valeur à 10.
À votre service... :)
C’est plus mieux avec “HTTP/1.0 500 Internal Server Error”. :)
Ça se rétabli tout seul, avec un watchdog ?
Je ne comprends pas, vous recevez cette erreur ?
Oui, ça s’est rétabli tout seul sans avoir à relancer quoi que ce soit.
C’est autre chose... si vous arrivez à reproduire ca m’interesse.
Ç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.
Vous auriez une trace de la requete HTTP complète avec l'erreur ? Avec wireshark c'est pas compliqué à faire.
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 .
dans le filtre de wireshark, mettez "tcp.dstport == 5678", afin de ne capturer que ce qui sort vers le httpd de l'igd.
J'ai coupé d'autres programmes qui causaient aussi avec le IGD et ça ne retourne plus de code 500.
Si ces programmes tournent aussi sur votre machine, alors la capture wireshark aidera à comprendre ce qui se passe. En mettant le filtre "tcp.dstport == 5678", tout le traffic de votre machine vers l'igd sera capturé.
Et j'en fais quoi, après ?
À quelle adresse email est-ce que j'envoie ça ? :D
la mienne (mbizon@freebox.fr)
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.
Une inscription par service, et il y a 3 services. Si vous vous inscrivez toutes les 15 minutes, ça fait au total potentiellement 9 (3 * 3) inscriptions actives a un instant donné. Le 32 c'est une limite pour ne pas consommer trop de ressources dans la box. Si vous quittez votre soft sans vous désinscrire et que vous le relancez plusieurs fois de suite, vous pouvez arriver a 32. Il faut alors attendre qu'elles expirent.
Je sais qu'on est short en ressources, en info indus. J'en ai fait assez d'années pour m'en rendre compte. :)