Batchyx a écrit 1261 commentaires

moi j'aurais mis -t raw -A POSTROUTING -s 224.0.0.251/32 -i eth0 -j DROP
Je DROP mDNS en sortie pour éviter que le multicast DNS se retrouve à l'extérieur de mon LAN

En théorie il faut dropper en entrée et en sortie. Ce n'est pas parce que tu droppe en sortie que t'en aura pas en entrée, surtout avec mDNS : il suffirai juste qu'il y ai un autre idiot qui fasse du mDNS dans le même sous-réseau que moi pour que j'en reçoive.

Par contre, 224.0.0.251, ou même 224.0.0.0/4 ne se trouve jamais dans l'adresse source, mais toujours dans l'adresse destination, comme le broadcast (255.255.255.255), en fait. Le noyau droppe déjà tout les paquets qui ont une adresse multicast/broadcast comme adresse source ;)

Donc si tu veut dropper en sortie, ça serai plutôt -t raw -A POSTROUTING -d 224.0.0.251 -o eth0 -j DROP, mais c'est bête de dropper dans -t raw -A POSTROUTING, parce que tu fait plus de traitement que si tu droppait dans OUTPUT directement, et puis tu à moins d'informations sur un paquet que tu à pourtant généré toi-même.

On parie ?

Avahi, tu connais ? Regarde dans /etc/avahi/services/

Arrête de lire le net, et commence à prendre les informations à leur source : lit le manuel d'iptables.

On peut très bien dropper dans la table raw. C'est à ça que je faisait allusion.

Sur mon système par exemple, j'ai (en gros) ça :
-t raw -A PREROUTING -d 224.0.0.251/32 -i eth0 -j DROP

autrement dit: dropper tout le trafic mDNS qui viendra de mon interface eth0 (qui dans mon cas, est reliée directement à Internet par un bridge).

Dropper dans la table raw à d'autres avantages, comme celui de ne pas attendre que le paquet soit fragmenté. Mais ça veut aussi dire qu'on ne peut pas faire directement du filtrage de port (le port n'est que dans un seul fragment, dans le cas d'un paquet fragmenté)

Ce n'est pas parce que c'est inutile pour toi que c'est inutile pour d'autres.

Pour moi, le simple fait que l'on puisse plus foirer une install de grub2 en virant/déplaçant la partition qui contient les modules m'a fait envie d'essayer grub2 avant même qu'il soit stabilisé. Parce que quand ton bios boote pas sur CD ou sur USB et que ton seul moyen de booter, c'est ton lecteur disquette capricieux, tu peux pas vraiment compter sur ton liveCD pour repartitionner ton disque et réparer ton système après.

Alors oui, ça à occasionné une belle perte de fonctionnalité pour toi, puisqu'il à fallu réduire le cœur de GRUB2 pour qu'il puisse afficher une ligne de commande qui permet d'explorer les périphériques, leurs systèmes de fichier et charger des modules, le tout dans un programme qui tient dans le MBR, et que cette modularité se ressent dans ses fichiers de configurations qui doivent devenir extensibles (mais t'a de la chance, si c'était Lennart qui avait fait ça, il aurai tenté d'utiliser du XML).

Mais moi ça me change la vie. Et je choisi grub2 pour la même raison que je choisi mon init : Parce que je veux un système réparable. J'ai eu du plaisir à apprendre les commandes de grub2 qui permettent de s'en sortir quand il trouve pas sa partoche. Et à les utiliser, aussi.

Ça n'a rien à voir avec grub2 qui serai plus mieux/performant/moderne ou qu'il supporterai de booter BSD.

Ce n'est pas parce que c'est du rolling release qu'il n'y a pas de version.

Au pire, tu met des dates …

Tu met la norme utilisée dans le type MIME. Problème résolu.

Il y a déjà de la négociation de la langue, du type MIME et du type de compression dans HTTP.

peut être éviter un traitement pour rien en entrée sur le Prérouting en le "Droppant" directement  ??

Oui, tu peux faire ça dans la chaîne pre_routing de la table raw. Dans ce cas, tu zappe tout ce qui est connection tracking, Mais ça restreint aussi les règles que l'on peut appliquer, et du coup ça change pas forcement grand chose au final.

xmodmap est ton ami.

Non.

(résumé court : xmodmap c'est de la rétrocompatibilité foireuse/un héritage d'X11, xkb cai mieu)

Tu fait quand même une présupposition majeure : le code parallèle sera forcement plus rapide que le code séquentiel, ce qui reviens à peu près à dire que ton nombre d'élément est élevé. Alors que si ça se trouve, cette fonction ne sera jamais appelée avec des tableaux de plus de 10 éléments, et tout ces trésors d'optimisations seront vains.

C'est bientôt fini cette mode de mettre des références partout ?

Je pensait que les gains de performances était pourtant évident entre lire une information adjacente et déréférencer un lien. Ça améliore la localité spatiale, et ça coûte souvent rien, il suffit juste d'utiliser l'espace qui est gâché pour des raisons d'alignement et de bourrage pour y mettre des informations supplémentaires, quitte à les dupliquer.

C'est pourtant pas compliqué à comprendre. Éviter les références et les déréférencements, c'est aussi éviter tout les problèmes associés : Est ce que ma référence est valide ? Est ce qu'elle est encore valide ? Combien de temps restera-t-elle valide ? Est ce qu'elle est partagée ? Réutilisée ? Est ce qu'elle est cohérente ?
Alors qu'avoir l'information dans un même enregistrement évite pas mal de ces problèmes (pas tous, évidement. savoir si l'information est à jour restera problématique par exemple). Et c'est pas comme si c'était plus compliqué à faire; vu le nombre de débutants qui ont du mal à comprendre les références, ne pas utiliser de référence lorsqu'il n'y en a pas besoin reste la meilleure chose à faire si on veut éviter les erreurs.

Enfin bref, faut se calmer un peu sur les références et les ressources dynamiques. Un de ces jours, il y en aura tellement qu'on sera obligé d'utiliser régulièrement un système de ramasse miette pour mettre de l'ordre dans ce bazar. Alors qu'à coté, ils se gausseront de nos systèmes abscons et de nos performances misérables.

Non, c'est juste que les deux premiers octets de l'adresse mac sont 00:00 (l'OUI, si tu veux savoir, est celle de Seiko/Epsonn, soit 00:00:48), du coup, quand t'a un paquet avec plein de 0 partout, tu te dit que 4 valeurs non-nulles en plein millieu d'octets nuls forment un champ de 4 octets. Sauf que le champ faisait 6 octets, avec les deux premiers nuls.

Le fait que le protocole utilise plein de champs de taille fixe pour stocker des chaînes de caractères aide pas mal à avoir plein d'octets nuls dans des paquets.

Même pas. Les compilateurs n'éliminent les variables que s'ils ont la garantie qu'elles ne seront pas utilisées. Si par exemple elles sont utilisées que si une certaine condition est fausse, et que tu ne peux pas garantir le résultat de la condition, et bien tu ne peux que faire des suppositions.

Tu est en train de faire un traducteur/compilateur. Tu ne peux vraiment pas présager la durée de vie de tes variables, ni comment elles vont être utilisées. Tu peux juste faire des suppositions en l'air… ou tenter d'éliminer des accès au tableau, mais ça c'est plutôt le rôle du compileur C++ dans ce cas.

Et parce que python n'a même pas de notion de tableau mais plutôt de listes, si tu veux représenter une liste python de manière contiguë avec des mmap, attend toi à des représailles si ton code python insère souvent des éléments en plein milieu.

Bon, c'est triste, mais je retrouve pas la moitié de mes sources… il me reste plus qu'une appli crade en C++ qui essayait de regrouper un peu tout (sauf vnc)

J'avais certainement du les virer parce que j'avais plus de place et que je me disais que ça resservirai jamais …

D'après sa trace, non ils ne sont pas renattés, et d'ailleurs, quand le client se prend un paquet de .16, il lui renvoie un RST direct, parce qu'il ne le connait pas (le client à demandé 192.168.0.17).

Pour que ça le soit, il faudrait que .16 n'aie ses routes 192.168.0.0/? via 192.168.0.17, ou alors que .16 fasse du snat sur les connections qui viennent de l'adresse mac de .17.

Fin bon, le plus simple, c'est quand même de mettre un proxy sur .17

Ah, je me souviens avoir fait la même chose il n'y a pas si longtemps. Mais bon, ça fait longtemps, et j'ai pu d'accès à un videoprojecteur EPSON, du coup mon code pourri à l'air libre.

Par contre, j'avais été un peu plus loin : certains des vidéoprojecteurs ont du code en GPL, et donc il y a du code source disponible sur le site d'EPSON. Le code ne compile pas (il en manque la moitié), mais fourni quelques informations intéressantes. Sinon je crois que j'avais cherché des chaînes de caractères dans les binaires officiels, et j'avais eu quelques informations.

Mais bon, le fait qu'il y ai un client VNC et un vieuw ffmpeg m'avais pas mal aidé, j'ai pas eu à découvrir qu'il y avais du VNC en dessous.

Faudrai peut-être que je te sorte le code crade que j'avais fait, peu importe dans quel état déplorable c'est. J'avais même écrit un petit analyseur pour wireshark pour m'aider un peu.

Mais bon, de ce que je souviens :

Les segments envoyés en unicast diffèrent des segments envoyés en broadcast puisque le dernier caractère avant la suite de caractères nuls est un STX (0x02). Ce mot permet certainement au vidéoprojecteur de savoir si le segment reçu lui est destiné ou si il a été envoyé en broadcast.

Si je me souviens bien, y en a un qui s'appelle 'easysearch' (le 0x01, celui en broadcast) et l'autre qui s'apelle 'ipsearch' (le 0x02). T'a peut-être du remarquer que si dans l'interface tu lui demande de choisir une IP à la main, il utilise le 0x02.

Le client envoie un segment UDP au vidéo projecteur : le code c'est 4. Plein de nombres dans ce message de 74 octets, je ne reconnais rien, il y a une suite de nombre (ascii), mais je ne vois pas ce que cela peut représenter (ni même si ça a bel et bien un sens).

Dans ce message, je me souviens avoir reconnu un morceau de protocole RFB, la partie qui permet au serveur d'indiquer au client quel est sa résolution, son nombre de bit par pixel, d'indiquer que la valeur max du rouge c'est 0xff avec un décalage de 16 bit pour y accéder …

Par contre, je vois une adresse IP un peu après. Pas la mienne, ni celle du vidéo projecteur. Par contre, c'est l'IP du routeur de ma route par défaut. Je me demande bien pourquoi le vidéo projecteur a besoin de ça … et de toutes façons, il la connait déja puisqu'il obtient son IP via le DHCP. Peut être que c'est une manière de vérifier que l'on soit bien sur le même réseau ? Bon, bah du coup, il m'a suffit de relire le segment pour voir que juste avant la passerelle par défaut, j'envoie le netmask du réseau ! Merci au réseau de l'école, sans le netmask un peu bizarre (255.255.252.0) je crois que j'aurais vraiment eu du mal à le trouver, même si il était facile à deviner. On continue la lecture et on voit que le message se termine par l'IP du vidéoprojecteur. Ah, encore dans le message, je retrouve une suite de 4 nombres qui m'avaient intrigués. Je ne sais toujours pas ce que c'est, peut être un identifiant du vidéo projecteur ? En tous cas, ça ne doit pas coder d'information dans les messages de code 3 (ça aurait pu être par exemple l'état du vidéo projecteur).

Ce qui est encore plus bizarre, c'est que dans les sources, c'est plus présenté comme une modification de la configuration IP qu'autre chose, sauf que si j'essaye de mettre d'autres adresses, ça marchai pas, ça modifiait pas la conf du vidéoproj…

En regardant un peu la conversation dans sa globalité, je remarque, de temps à autre, des messages "traditionnels" : un message de 8 octets (EPRD0600), suivie de l'IP source, le type du message est 0, et est suivi par un nombre de 32bits

Moi ce qui m'avais aussi surpris, c'est que dans le code source, il y avais du code pour chercher "EPRD0600" arbitrairement dans le flux … mais bon comme il en manquait la moitié du code …

Ce canal a l'air d'être ouvert en permanence. Je ne sais pas à quoi il sert mais peut être qu'il est utile pour l'utilisation de la télécommande. On verra ça plus tard.

Non, il sert pas à grand chose … Pour la télécommande, c'est le proto ESC/VP.net sur le port 3629. Y a une doc trouvable facilement qui spécifie les échanges, mais pas l'initialization, mais bon, c'est pas compliqué, juste un échange UDP et une ouverture de session TCP ou tu fait un échange similaire. J'ai pas les détails en tête, mais mon vieux code, si.

Avec ça, tu peut simuler un appui sur toutes les touches de la télécommande infrarouge.

Maintenant que ce canal est ouvert, je vais voir pour ouvrir le canal qui nous intéresse pour le moment : celui qui nous permet d'envoyer les images que le vidéo projecteur va afficher. Peut être que le canal coté projecteur (je vais l'appeler comme ça parce que c'est lui qui initialise la connexion) permet aussi de maintenir la connexion (avec un keep alive -like (type 0x0A ?).

oui, le 0x0a est un keepalive. j'ai cru un moment que c'était un "displayrefresh", sauf que ça correspondait à rien.

De plus, on peut supposer que si le protocole utilise un algorithme de chiffrement, celui-ci est connu et ouvert (AES, Serpent, 3DES…).

Je n'ai pas recherché de ce coté là (si tu parle de la case "crypter les communications", mais je vais te décevoir (ou te faire rire) : EPSON utilise du DES, ou alors de l'AES64. Qu'est ce que l'AES64 ? C'est de l'AES128, sauf que la clef de départ n'a que 64bit, et tu la répète deux fois pour avoir une clef de 128bit. C'est pratique AES64, c'est la même taille de clef que DES…

Ah, et il y a (peut-être) un champ dans le message 0x04 qui s'apelle 'encryption_key'. Et j'ai pas envie de vérifier si la clef est effectivement envoyée en clair.

Fin bon, moi mon but, c'était surtout d'envoyer de la vidéo au videoproj. Mais le meilleur truc que j'ai eu, ça n'était que du son… et j'ai jamais réussi à reproduire.

avec le SRV, on sait déjà ce qu'on cherche, donc on ne saura jamais qu'il y a de nouvelles méthodes.

J'ai une super idée pour ça. Tu n'a qu'à avoir des enregistrements du type :

_services._dns-sd._udp.exemple.com 86400 IN PTR _sip._tcp.exemple.com
_services._dns-sd._udp.exemple.com 86400 IN PTR _imap._tcp.exemple.com
_services._dns-sd._udp.exemple.com 86400 IN PTR _submission._tcp.exemple.com

Comme ça, avec une requête sur _services._dns-sd._udp.exemple.com, tu peux connaître la liste des services sur le réseau, y compris les nouvelles méthodes révolutionnaires que tu viens d'inventer et qu'aucun logiciel ne gère.

Et si il y a plusieurs serveurs HTTP disponibles sur le réseau et que l'utilisateur doit en choisir un, tu pourrai, plutôt que de mettre un SRV sur _http._tcp.example.com, tu mettrai un PTR sur _http._tcp.example.com qui pointerai vers webmail-interne._http._tcp.example.com et un autre vers intranet._http._tcp.example.com, avec chacun un SRV. Et tu présenterai juste à l'utilisateur "intranet" et "webmail-interne".

Et si jamais tu veux pouvoir répondre à la question "ou est le webmail", tu rajouterai aussi un PTR de _mail._sub._http._tcp.example.com vers webmail-interne._http._tcp.example.com, et tu pourra interroger _mail._sub._http._tcp.example.com pour trouver le serveur webmail.

C'est une idée super originale, je suis sur que personne ne l'a fait avant.

Toi ce que tu me dis, c'est que tu trouves normal lorsque je demande une Leffe à un serveur dans un bar, qu'il m'amene une Grimbergen ou une 1664 ou un autre truc, sans me préciser au préalable qu'il ne sert pas de Leffe. Moi je ne trouve pas ça normal, il doit me le préciser avant.

Il te l'a précisé avant : c'était clairement indiqué dans la description du paquet. À quoi ça sert de passer du temps à l'écrire si c'est pour que tu ne la lise pas ?

C'est comme sil y avais écrit en gros sur une pancarte "Leffe à été repris par Grimbergen (ce que tu savait déjà, au passage), et pendant le temps de transition, si vous demandez une Leffe, vous aurez une Grimbergen".

Vu le nombre de logiciels qui forkent/changent de noms/font sécession/sont abandonés puis repris/sont patchés par la distrib/ont un nom différent suite à une demande d'upstream/autres, si tu devais régler tout ces problèmes là à la main à chaque installation/upgrade, tu ne t'en sortirai jamais.

Ça fait depuis de années que c'est comme ça sous Debian.

Même s'il X.org n'a pas besoin d'évoluer, il évolue quand même ;) Notamment pour rajouter le support d'hotplug pour des cartes graphiques externes et le support d'offload en natif.

Enfin bref, X.org n'est pas un vieux projet mort. Ce n'est pas parce que son architecture n'était pas adaptée que ça le restera à jamais.

Ces boites s’intéressent aux problèmes, elles, elles ne les déportent pas chez les autres.

Dans quel cas le problème est déporté sur l'application déjà ? Ah oui, quand l'option pour activer le case-insensitive est gérée par le système, parce que tu te la prendra quand même en pleine face pour tes applications, puisqu'il faudra qu'elle marche à la fois avec un système en case-insensitive et un système en case-sensitive. Avec certainement des bugs nouveaux pour des cas d'erreurs qui n'existaient pas avant (ou qui n'étaient pas aussi courants), ou de nouvelles failles de sécurité. Et viens pas me dire que c'est pas du Bloat et que ça sera aussi rapide qu'avant.

Moi je te parle du cas ou l'option est optionnellement gérée par une bibliothèque dans ton application. Si tu n'a pas envie de gérer la chose, alors tu fait rien et t'a ton système case-sensitive. Si tu veut un système case-insensitive, tu utilise une bibliothèque qui fait que du case-insensitive. Si tu veut que ça puisse être changé selon la variable d'environnement nouvellement standardisée ZENITRAM_FILESYSTEM, alors tu utilise aussi une bibliothèque qui va gérer ça dans ton dos, exactement comme tes applications gèrent déjà TZ, LC_truc et autres (du moins j'espère).

Donc que ça soit ton application (ou plutôt, ta bibliothèque, parce que j'espère que tu passe pas ton temps à recoder des selecteurs/navigateurs de fichiers ou des comparateurs de chemins) ou ton système, de toute façon il faudra que tu le gère dans ton application. Donc ça fera chier tout le monde, tout ça pour pas grand chose.

Ça à un nom ce que tu décris : du gros Bloat. Si tu veut pouvoir changer le comportement de n'importe quelle appli, autant utiliser des variables d'environnement plutôt que de bidouiller le noyau. Sauf que changer le comportement de n'importe quelle appli n'est pas une bonne idée non plus, puisque tu va te retrouver tout les inconvénients de l'option de Windows que tu à déjà cité: les applications buggées qui ne supportent qu'un seul des deux modes.

Non, franchement, laisse ça aux applications.

Quand je disais 50% / 50% , je parlais de 50/50 d'un meme systeme.

Ça ne change rien; Si tu doit faire un système multiutilisateur qui sera à la fois utilisé par moi et Zenitram, alors ça sera même utile. Et peut être que quelqu'un de plus modéré entre nous deux verra l'intérêt du case-insensitive dans un cas mais pas dans l'autre.

L'utilisateur n'en à strictement rien à foutre du système de fichier. Un système de fichier, c'est fait pour les "informaticien le nez dans le guidon" pour justement éviter que leurs applications soient autistes entre elles. L'utilisateur en à rien a foutre de savoir si ça utilise des B-arbres ou si les nom des liens vers le fichier sont sensibles à la casse. La seule chose qui intéresse l'utilisateur, c'est le nom qu'ils donnent à leur document, qui n'est pas forcement le même que le nom du fichier sur le système de fichier.

Beaucoup de logiciels ont choisi de laisser à l'utilisateur le choix du nom du fichier sur le système de fichier et considère que le nom du document est le nom du fichier, mais ils ne sont pas obligés de le faire. Et même lorsque c'est le cas, les utilisateurs, de toute façon, vont choisir le fichier dans une liste, le rechercher avec des mots clefs, des tags ou d'autres métadonnées, mais n'auront JAMAIS à retaper un nom de fichier. Même les barbus ne taperont pas le nom du fichier dans leurs lignes de commandes, mais seulement quelques lettres et des tabulations.

"Zenitram" et "zenitram" sont deux chaînes de caractères différentes, et c'est ce qui importe pour des noms de liens ou des identifiants de base de données. Le reste n'est pas de la responsabilité du système de fichier, mais de l'interface utilisateur.

Sinon tu risques de te retrouver avec 50% de softs qui font A, et 50% qui font B.

Et en quoi c'est une mauvaise chose ?

Moi j'ai envie que mes noms de fichiers/noms de documents soient sensibles à la casse. Visiblement ça horrifie tellement Zenitram pour qu'il nous considères comme des hérétiques. Si tu laisse le choix, on sera tout les deux contents. Sinon l'un de nous deux sera pas content, et pourra insulter l'OS de tout les noms, et il aura bien raison.

Mais bon, tu n'est peut-être pas habitué à ne pas forcer la main à tes utilisateurs qui payent.

Mais dans Windows c'est pas le FS qui force ca, c'est l'environnement Win32. Le FS permet les 2 cas.

Donc ce n'est pas du ressort du système de fichier, CQFD.

ils essaient de ce logger en tant que service ou root, alors t'as aucun souci à te faire pour ton compte raoul.

Pourtant mon honeypot me montre que il y a plein de bots qui essayent un mot de passe "john" à la fois sur "root" et sur un utilisateur "john". Donc prend quand même un mot de passe fort pour ton utilisateur.