e-t172.net
Développement, réseaux, sysadmin et futilités
Tirez le meilleur de votre moniteur avec EDID Override
Lorsque vous connectez un dispositif d’affichage (écran, TV, vidéoprojecteur) à votre ordinateur, ce dernier prend connaissance les caractéristiques de celui-ci en analysant un bloc de données appelé EDID. Ces données sont généralement stockées dans une puce mémoire à l’intérieur du moniteur, et sont transmises à l’ordinateur à travers le câble de connexion en utilisant un bus I²C et le protocole DDC. EDID comme DDC sont spécifiés par l’organisme de normalisation VESA.
Les informations contenues dans un bloc EDID sont diverses et variées. Au-delà des informations d’usage telles que le nom du fabricant ou le numéro de série, sont transmises également des données plus importantes telles que les résolutions et fréquences de rafraichissement supportées. C’est ce qui permet au système d’exploitation de déterminer automatiquement les paramètres utilisables, assurant ainsi un fonctionnement « Plug and Play ». Par ailleurs, il est possible d’étendre EDID pour transmettre d’autres informations utiles – ainsi, la troisième révision du bloc d’extension CEA permet également d’indiquer le support de formats audio, et facilite ainsi, par exemple, le transport du son à travers un câble HDMI.
Si l’EDID remplit dans la très grande majorité des cas parfaitement son rôle pour une utilisation basique, les informations qu’il contient peuvent se révéler inadaptées lorsqu’on sort des « sentiers battus ». Par exemple, elles peuvent être incomplètes : ainsi un constructeur peut « oublier » de mentionner dans l’EDID que le moniteur supporte une fréquence de rafraichissement alors que ce dernier l’accepte parfaitement, partant du principe que le grand public ne s’en préoccupera pas. Autre exemple, un amplificateur avec entrée HDMI peut lui aussi « oublier » d’annoncer certains formats audio qu’il supporte pourtant très bien, empêchant d’utiliser tout son potentiel.
Un écran Hyundai W240D.
Prenons un exemple concret. Je dispose actuellement d’un moniteur Hyundai W240D. Sans intervention, ce moniteur n’annonce que la fréquence de rafraichissement de 60 Hz dans son EDID. Cependant, après quelques tests avec PowerStrip (qui ignore les informations contenues dans l’EDID), il se trouve que l’écran accepte également des fréquences aussi basses que 48 ou 50 Hz, qui sont utiles pour améliorer la fluidité des vidéos 24p ou PAL. Malheureusement, Windows ne propose pas ces fréquences pourtant acceptées par l’écran, car ce dernier ne les mentionne pas dans ses informations EDID.
Il existe plusieurs solutions pour contourner de telles limitations. Je ne parlerai pas de Linux, qui de part son côté ouvert et orienté technique permet de modifier facilement son comportement interne ; la situation sous Windows est loin d’être aussi idyllique. Parfois le constructeur de la carte graphique propose dans ses drivers de forcer des résolutions ou des fréquences de rafraichissement manuellement, les ajoutant ainsi à la liste des modes utilisables par Windows. Malheureusement, cela ne fonctionne pas toujours : par exemple, l’outil proposé par NVidia à cet effet est criblé de bugs. Une autre solution consiste à utiliser PowerStrip, qui bien qu’étant extrêmement puissant dans ses possibilités, est nettement moins pratique si l’objectif est d’obtenir une solution propre bien intégrée au système d’exploitation. Bémol : ces solutions ne permettent généralement pas de modifier toutes les caractéristiques annoncées par l’EDID, particulièrement du côté de l’audio.
Ce billet présente une autre solution pour Windows appelée « EDID Override ». Plus compliquée à mettre en place, elle présente cependant l’avantage de pouvoir « écraser » n’importe quelle information présente dans l’EDID. De plus, le résultat final est très propre et bien intégré au système d’exploitation, et pour cause : c’est Microsoft qui propose la technique ! Il est cependant difficile de trouver des informations concrètes sur la procédure à suivre pour appliquer cette méthode : ce billet est là pour ça.
Le principe de l’EDID Override est simple : il consiste à générer un driver personnalisé pour votre écran sous la forme d’un simple fichier INF qui a la particularité de contenir un bloc EDID qui écrasera purement et simplement celui annoncé par l’écran. Microsoft destine cette fonctionnalité aux constructeurs qui souhaiteraient corriger un EDID erroné sous la forme d’une mise à jour logicielle, mais rien n’empêche l’utilisateur lambda d’en profiter pour dicter son propre EDID en lieu et place de celui du constructeur.
Dès lors, la solution prend la forme de la procédure suivante :
- Récupérer l’EDID actuel de l’écran et l’enregistrer dans un fichier.
- Altérer l’EDID ainsi sauvegardé en appliquant les modifications voulues.
- Générer un fichier INF contenant l’EDID ainsi modifié.
- Installer le fichier INF sur le périphérique correspondant à l’écran.
Le logiciel le plus adapté pour accomplir la première étape est Monitor Asset Manager (MonInfo), du même développeur que l’excellent PowerStrip. MonInfo est le seul logiciel que je connaisse capable de lire l’EDID directement depuis le matériel (les autres logiciels l’obtiennent depuis la base de registres de Windows). MonInfo vous offre ensuite la possibilité de l’enregistrer dans un fichier.
La deuxième étape est de loin la plus ardue. En effet, je n’ai pas trouvé de logiciel permettant d’éditer de manière simple un EDID. Nous en sommes donc réduits à éditer directement le binaire à l’aide d’un éditeur hexadécimal. Celui que je vous recommande est EDID Editor qui présente l’avantage par rapport à un éditeur générique de faciliter l’écriture de la somme de contrôle dans l’EDID, indispensable pour le rendre à nouveau valide après une modification.
Extron EDID Manager. Remarquez les octets en surbrillance correspondants au champ sélectionné, ici la résolution horizontale du timing détaillé.
Modifier le binaire à la main nécessite de connaitre sa structure. Et là encore, on est pas aidé. Les spécifications VESA sont pour la plupart payantes ; quelques « miettes » disponibles dans la section gratuite peuvent vous aider, comme des guides d’implémentation (qui ne décrivent que très partiellement EDID) ou encore la spécification du bloc d’extension concernant les timings étendus. Pour vous faciliter la tâche, je ne peux que vous recommander l’utilisation de Extron EDID Manager qui décrit le contenu de l’EDID à la manière de MonInfo mais avec l’énorme avantage d’afficher la correspondance entre chaque information et les valeurs qui correspondent dans le binaire. Dans de nombreux cas cela vous permettra de déterminer comment modifier les valeurs qui vous intéressent sans avoir besoin de spécification.
Étant donné que MonInfo et EDID Manager sont capables de lire des blocs EDID à partir d’un fichier, vous pouvez les utiliser pour vérifier les modifications que vous avez effectuées avec EDID Editor. Si vous désirez ajouter ou modifier un timing détaillé (par exemple pour une fréquence de rafraichissement), la méthode la plus simple consiste à régler le timing en question avec PowerStrip d’abord, et de reproduire les réglages dans l’EDID par la suite ; pour vérifier, comparez les « modelines » générées par PowerStrip à celles affichées par MonInfo.
La troisième étape consiste à générer le fichier INF à partir de votre EDID. MonInfo vous le propose directement. Ensuite, il peut être judicieux de modifier les informations contenues dans le fichier INF à l’aide d’un éditeur de texte pour personnaliser le nom affiché par le driver, ceci afin de faire la différence entre plusieurs EDID si vous veniez à en générer plus d’un (vous ne réussirez pas forcément du premier coup…).
Enfin, pour terminer, il vous suffit de vous rendre dans le gestionnaire de périphériques de Windows, de choisir de mettre à jour le pilote de votre moniteur, et d’indiquer ensuite l’emplacement de votre fichier INF.
Bonne chance !
Bypasser sa Neuf Box
Je fais partie des heureux élus qui disposent d’une connexion fibre optique à la maison (FTTH), sur le réseau de Pau Broadband Country. Je dispose pour cela d’un abonnement à SFR Fibre optique, avec un débit de 100 Mbits en réception et de 50 Mbits en émission.
Comme pour ses clients ADSL, SFR fournit un modem-routeur, la Neufbox, qui ne fait ici que routeur car il n’y a rien à moduler/démoduler (en effet, la Neufbox est connectée via un lien Ethernet à un media converter qui est lui-même connecté à la fibre elle-même). Le rôle de la Neufbox est ici de constituer une passerelle d’accès à Internet et de fournir la téléphonie incluse dans l’offre SFR.
Tout sysadmin geek qui se respecte dispose d’un serveur personnel à la maison. Cette solution est d’autant plus intéressante avec une connexion à Internet aussi rapide qui décuple le potentiel d’une telle solution. Généralement, une telle machine sert l’accès à Internet et un certain nombre d’autres services aux clients se trouvant sur le réseau domestique ainsi que sur Internet.
Logiquement, il faudrait placer le serveur domestique derrière la Neufbox. On remarque cependant une certaine redondance dans une telle situation : la Neufbox constitue un intermédiaire superflu entre le serveur et Internet, et on se passerait bien de son routeur qui ajoute une couche de NAT inutile. L’idéal serait de pouvoir connecter directement le serveur au media converter (c’est-à-dire à la fibre), passant outre la Neufbox, ne laissant que le serveur domestique pour gérer l’accès à Internet. On gagne ainsi en contrôle et en souplesse et les diagnostics sont facilités. On gagne même en performances : en effet, avec les débits élevés permis par la fibre, la Neufbox montre ses limites et a tendance à flancher lors du routage d’un grand nombre de flux TCP simultanés (quoique ce problème a peut-être disparu avec le passage à la Neufbox 5 qui dispose de plus de puissance de calcul).
J’ai réussi à mettre en place une telle solution quelques temps après mon raccordement à la fibre, alors que l’infrastructure de Neuf reposait sur des Neufbox 4. Pour trouver la configuration à mettre en place, j’ai utilisé un sniffer placé entre la Neufbox et la fibre pour déterminer le comportement adopté par la Neufbox. J’ai ensuite raccordé une des interfaces réseau de mon serveur directement au media converter, déconnectant la Neuf Box. Par la suite j’ai détaillé la procédure sur le wiki de la communauté OpenBox4.
Si l’accès à Internet lui-même ne posait pas de problème particulier (c’est une simple requête DHCP avec quelques subtilités), en revanche la téléphonie était une tout autre histoire, car l’infrastructure de Neuf utilisait à cette époque MGCP (protocole équivalent à SIP), protocole méconnu avec peu d’applications disponibles sur Internet.
La solution que j’ai adoptée a consisté à utiliser à nouveau la Neufbox non plus en tant que passerelle mais en tant que client sur mon réseau local, dans le seul but d’y brancher un téléphone pour conserver la téléphonie. Manque de bol, MGCP a un point commun avec SIP : il n’aime pas du tout les NATs, ce qui posait un gros problème étant donné que la Neufbox se trouvait derrière ma passerelle. Netfilter ne dispose pas de module permettant de faciliter la traversée du NAT pour le protocole MGCP (contrairement à SIP), et je n’ai trouvé aucun proxy MGCP sur Internet, j’ai donc créé le mien de toutes pièces. Développé à la va-vite, ce dernier était d’une fiabilité douteuse et avait notamment la fâcheuse tendance à planter fréquemment.
La solution s’est grandement améliorée depuis le 12 mars dernier, date de la migration du réseau Neuf de l’infrastructure Neufbox 4 à Neufbox 5, qui a apporté son lot de modifications intéressantes. La plus importante est probablement le passage de MGCP à SIP, ce qui permet d’utiliser un vrai proxy SIP à la fiabilité éprouvée pour assurer la téléphonie. La procédure de bypass de la Neuf Box devient ainsi nettement plus attractive et moins risquée.
Par conséquent j’ai mis à jour et détaillé la procédure pour passer outre sa Neufbox pour les abonnés SFR fibrés. La procédure à jour permet à toute personne disposant d’un minimum de compétences en administration réseau et système de bypasser sa Neuf Box tout en conservant le téléphone et la télévision.
Broadcast global avec plusieurs interfaces réseau
Dans le merveilleux monde d’IP, il est possible d’envoyer des paquets de type « broadcast », c’est à dire envoyés à tous les ordinateurs sur un réseau local. Cette fonctionnalité est décrite dans les RFC 919 et 922. Ces RFC définissent une adresse IP particulière, 255.255.255.255 (c’est à dire tous les bits de l’adresse à 1), qui caractérise un paquet broadcast envoyé à tous les hôtes quel que soit le sous-réseau auquel ils appartiennent. Pour cette raison, elle est généralement appelée adresse de broadcast global [1].
Concrètement, lorsqu’un paquet IP portant l’adresse de destination 255.255.255.255 est envoyé sur un réseau local, il est reçu par tous les hôtes se trouvant sur le même segment que la source. Typiquement, sur un réseau Ethernet, l’adresse MAC de destination du paquet sera FF:FF:FF:FF:FF:FF (l’adresse de broadcast Ethernet), ce qui pour un switch provoque la transmission du paquet sur tous les ports (sauf celui sur lequel le paquet a été reçu, pour des raisons évidentes). Ces paquets ne passent cependant pas les routeurs afin d’éviter une « inondation » d’Internet par des paquets broadcast. Le broadcast IP est donc clairement une fonctionnalité restreinte au réseau local, et n’a pas de sens sur Internet.
Maintenant que les présentations sont faites, entrons dans le vif du sujet. Le problème qui nous intéresse ici est que les RFC ne définissent pas explicitement le comportement à adopter lorsqu’une application envoie un paquet à destination de l’adresse de broadcast global sur une machine disposant de plusieurs interfaces réseau (qui peuvent être connectés à plusieurs réseaux locaux différents).
Intuitivement, on est tenté de penser que dans ce cas, il faut que le système d’exploitation envoie le paquet sur toutes les interfaces. Après tout, la RFC 919 indique bien dans sa section 7 :
Thus, a host on net 36, for example, may broadcast to all of its immediate neighbors by using 255.255.255.255
« Tous ses voisins immédiats ». On serait tentés d’en conclure que sont inclus dans cet ensemble l’intégralité des voisins de tous les réseaux auquel est connecté l’expéditeur du paquet. Mais la RFC ne le dit pas explicitement, et d’ailleurs, l’exemple indiqué ne parle que d’un seul réseau (« réseau 36 »).
Windows (en version 7) et Linux (en version 2.6.32) adoptent un comportement similaire sur ce sujet. Ils considèrent un paquet broadcast comme n’importe quel autre paquet IP. C’est à dire que si une application tente d’envoyer un paquet à 255.255.255.255 sans se lier (« bind ») à une adresse spécifique, le système d’exploitation consulte sa table de routage, cherche une route correspondant à 255.255.255.255, et envoie le paquet sur l’interface correspondant à la route [2]. Comme d’habitude, pourrait-on dire. C’est le comportement le plus souhaitable car il ne contredit aucun standard. En pratique, Windows ajoute automatiquement dans sa table de routage des entrées pour l’adresse de broadcast global pour chaque interface ; Linux en revanche ne le fait pas, et il faut les ajouter à la main si on veut permettre à une application de pouvoir envoyer un paquet broadcast sans avoir à se lier à une adresse.
Malheureusement, les développeurs d’applications, d’un naturel fainéant, ne semblent pas être conscients de ce phénomène. En effet, un grand nombre d’applications utilise le broadcast global pour rechercher la présence de services sur le réseau local. Intuitivement, le développeur aura programmé son application pour simplement envoyer ses paquets de recherche vers 255.255.255.255 sans se poser de questions. Cela fonctionne très bien dans le cas où la machine sur laquelle l’application s’exécute ne dispose que d’une seule interface réseau. Mais s’il y en a plusieurs, alors le paquet ne sera envoyé que sur une seule interface choisie arbitrairement, excluant ainsi les hôtes joignables via d’autres interfaces de la recherche, ce qui n’est probablement pas ce que le développeur de l’application aurait voulu !
L’exemple qui vient à l’esprit est le jeu multijoueur proposant une liste des parties qui sont joignables sur le réseau local. Pour trouver les parties, le jeu envoie des paquets d’interrogation vers l’adresse de broadcast global. Les autres instances du jeu sur le réseau local, écoutant sur le port correspondant, répondent pour signaler leur présence. Si plusieurs interfaces réseau sont présentes sur la machine du joueur, celui-ci ne verra que les parties d’un seul réseau, à l’exception de tous les autres auquel le joueur est connecté. Cette situation arrive plus souvent que l’on pourrait le penser car certains joueurs jouent sur un réseau privé virtuel (très souvent, Hamachi), qui vient s’ajouter à leur interface réseau physique. Dans ce cas, le joueur verra soit les parties présentes sur le réseau virtuel, soit sur le réseau physique (sans possibilité simple de choisir entre les deux). Ce qui, vous en conviendrez, n’est pas un comportement très judicieux.
D’aucuns pourraient objecter que ce comportement viole le principe de moindre surprise. Dans un sens, c’est le cas. Le problème, c’est que si le système d’exploitation envoyait les paquets broadcast sur toutes les interfaces, cela voudrait dire que ces paquets sont traités de manière spéciale, ce qui viole également le même principe. C’est donc bien aux développeurs d’applications de faire attention, et d’envoyer les paquets broadcast de manière explicite sur chacune des interfaces réseau présentes sur le système, pour être sûr de joindre tous les voisins de la machine.
Mais parce qu’on ne vit pas dans un monde de bisounours, et que l’écrasante majorité des applications utilisant le broadcast global le font mal, il serait intéressant de pouvoir modifier le comportement du système d’exploitation pour que les paquets broadcast soient réellement envoyés sur toutes les interfaces, quand bien même l’application ne le ferait pas elle-même. Cela n’est pas possible nativement, ce qui n’est pas surprenant. Une solution consiste à développer une application qui écouterait le trafic broadcast global, et renverrait elle-même les paquets sur chacune des interfaces « oubliées » par l’application.
C’est ce qu’a fait votre serviteur, et cela donne WinIPBroadcast : un minuscule programme Windows, fonctionnant en tant que service, qui se contente de dupliquer chacun des paquets broadcast envoyés par le système vers les interfaces autres que celle qui a la préférence de la table de routage. De cette manière, vos applications envoyant des paquets à l’adresse de broadcast global (par exemple, votre jeu multijoueur favori) les enverront sur toutes les interfaces d’une manière totalement transparente aux yeux de l’application comme de l’utilisateur. Je n’ai pas fait de version Linux (je n’en ai pas l’utilité), mais il devrait être aisé d’appliquer le même principe sur ce système, ou sur tout autre système d’exploitation.
Liens
- WinIPBroadcast
- RFC 919 – Broadcasting Internet Datagrams
- RFC 922 – Broadcasting Internet Datagrams in the presence of subnets
- Sur Server Fault : How to fix the global broadcast address (255.255.255.255) behavior on Windows?
- Sur Microsoft TechNet Forums : How to fix the global broadcast address (255.255.255.255) behavior on Windows?
Notes
[1] : il existe aussi l’adresse de broadcast dirigé, qui est composée de tous les bits du sous-réseau avec le reste des bits à 1 (par exemple, l’adresse de broadcast dirigé de 192.168.18.0/24 est 192.168.18.255).
[2] : Windows XP adopte un comportement étrange et envoie le paquet sur toutes les interfaces, mais avec une seule adresse source (celle de la route choisie), même lorsque l’adresse IP affectée à l’interface ne correspond pas à cette adresse ! Bien évidemment, cela n’a aucune chance de fonctionner sur les interfaces autres que celle correspondant à la route.
rrsync ne fonctionne plus avec rsync 3.0.0
Si vous utilisez le fort pratique script Perl « rrsync », livré avec la distribution de rsync, et permettant de contraindre un client utilisant une clé SSH spécifique à rester dans un répertoire précis et uniquement celui-là (un chroot virtuel, en quelque sorte), il y a de fortes chances pour que ce script échoue lamentablement une fois la mise à jour vers la version 3.0.0 de rsync effectuée, et ce même si vous utilisez le rrsync se trouvant dans la nouvelle version. Vous aurez alors l’occasion de faire connaissance avec ce sympathique message d’erreur :
rrsync: invalid rsync-command syntax or options
En effet, sous certaines conditions, lorsque le rsync client lance son homologue côté serveur, il lui passe certaines options qui n’existaient pas dans la version précédente de rsync. Voici une ligne de commande (lancée en interne par rsync sur le serveur) type rsync < 3.0.0 :
rsync --server --sender -logDtpr . ./
Et voici une ligne de commande type rsync >= 3.0.0 :
rsync --server --sender -logDtpre.iL . ./
On constate que de nouveaux caractères font leur apparition : e.iL. A quoi correspondent-ils ? Notez que les options de rsync lorsque celui-ci fonctionne avec --server (qui est une option interne « cachée », cf rsync(1)) sont légèrement différentes de celles utilisées en mode « normal ». On trouve une explication de ces nouveaux caractères dans le fichier options.c de rsync, fonction server_options() :
/* We make use of the -e option to let the server know about any
* pre-release protocol version && some behavior flags. */
argstr[x++] = 'e';
#if SUBPROTOCOL_VERSION != 0
if (protocol_version == PROTOCOL_VERSION) {
x += snprintf(argstr+x, sizeof argstr - x,
"%d.%d", PROTOCOL_VERSION, SUBPROTOCOL_VERSION);
} else
#endif
argstr[x++] = '.';
set_allow_inc_recurse();
if (allow_inc_recurse)
argstr[x++] = 'i';
#if defined HAVE_LUTIMES && defined HAVE_UTIMES
argstr[x++] = 'L';
#endif
On constate que :
- L’option « e » sert à informer le rsync côté serveur du protocole utilisé par le rsync côté client au cas où les deux rsync auraient des versions de protocole différentes. En fait, rrsync gère l’option « e », mais s’attend à la trouver sous cette forme : « eX.Y », où X et Y sont des nombres représentant respectivement le protocole et le sous-protocole utilisé. Or, ici, on voit que cette option peut également s’écrire simplement « e. » lorsque les protocoles sont de même version, ce que rrsync ne reconnaît pas, d’où erreur.
- L’option « i » n’est pas reconnue par rrsync, d’où erreur.
- L’option « L » est reconnue par rrsync.
Pour corriger le problème, il faut donc modifier rrsync pour ajouter la nouvelle option « i » et la nouvelle syntaxe « e. ».
J’ai concocté un patch qui effectue ces modifications : rrsync-bug-3.0.0.patch.
Sous-titres Battlestar Galactica 3×03 Exodus VO/VF
1931 jours
by e-t172
Dans les grands problèmes existenciels qui forment ce monde, nous pouvons en citer un, et pas des moindres : l’attente des sous-titres de certaines séries, telles que Battlestar Galactica.
En effet, l’équipe des Lords Of Kobol, principale productrice de sous-titres pour cette série, ne met pas moins d’une semaine pour sortir les sous-titres après la sortie de l’épisode. Ces derniers se justifient par des sous-titres de très bonne qualité (ce que je leur concède).
Néanmoins, Keger et moi avons décidé de tenter l’expérience du sous-titrage « pour le fun », juste pour se faire une idée du travail et du temps nécéssaire par nous-mêmes.
Il semblerait que cette expérience ait été concluante, car après une journée de travail, nous avons réussi, avec l’aide de ma soeur, à produire des sous-titres en VO et VF de qualité acceptable.
Vous pouvez les télécharger à l’emplacement suivant : Sous-titres Battlestar Galactica 3×03 Exodus VO/VF pour releases YEM et EZTV.
Par ailleurs, ces derniers sont distribués sous licence Creative Commons BY, ce qui signifie, en gros, que vous pouvez en faire tout ce que vous voulez, à condition de citer l’auteur. En cela nous nous démarquons encore des autres équipes de sous-titrage, qui interdisent jalousement toute redistribution en dehors des sites qu’ils ont choisis.
Je tiens à préciser qu’il s’agit d’une expérience ponctuelle. Nous ne savons pas encore si nous allons faire de même pour les prochains épisodes à venir.
En dernier lieu, je tiens à signaler le comportement pour le moins puéril de certains sites de séries (Projet-SG, SeriesTele), qui visiblement tiennent plus que tout à leur gloire et à leur popularité et qui à ce titre ont systématiquement censuré toutes nos tentatives de signalement sur leurs forums, au lieu de penser à l’intérêt général, ce qui est pourtant censé être leur but.