GuiGui's Show

« Attendez, attendez, moi je n'ai pas de leçon à recevoir ! [...] Si vous n'aimez pas que la France soit bloquée, arrêtez de la bloquer ! [...] Ce n'est pas moi qui vais créer des emplois, c'est la conjoncture [...] La meilleure façon de se payer un costard ? Vous n'allez pas me faire peur avec votre T-shirt ! La meilleure façon de se payer un costard, c'est de travailler ! » Emmanuel Macron à Lunel, le 27 mai 2016.

La première partie de cette déclaration est débile, tout simplement : on a tous et toutes quelque chose à apprendre, seul-e ou via une autre personne. Même quand t'es ministre, c'est-à-dire un glandu à la tête d'une administration centrale dans laquelle les décisions sont réellement prises par tout un tas de conseillers.

La deuxième partie est une inversion de la charge : le gouvernement est sourd à toute autre forme de dialogue mais les syndicalistes sont les méchants de l'histoire, le gouvernement n'ayant plus que ça pour rallier l'opinion publique à sa cause et sortir de ce bourbier politique (remember CPE, remember de quelle manière on est sorti de 68 pour aller voter massivement De Gaulle pour remettre de l'ordre).

La dernière partie de la phrase est paternaliste/infantilisante/moralisatrice et en tout cas indigne d'un ministre, c'est-à-dire d'un gus grassement payé par les impôts/taxes/valeur_ajoutée donc par le travail des autres pour faire la marionnette comme c'était le cas à Lunel qui était clairement une opération de communication du gouvernement (montrer un peu de numérique pour dire que y'a de l'espoir en France, qu'il y'a de l'espoir à Lunel (8 départs vers la Syrie) pourvu que tu retournes travailler, saloperie de gréviste car le salut, c'est le travail).


Quand son interlocuteur lui dira « Prenez garde parce que la jeunesse est désespérée », sur un ton pas plus menaçant que ce que Balavoine avait sorti à Mitterand en 1980 ( voir http://www.ina.fr/video/I00000219 ), Macron répliquera : « Je ne vous menace pas, alors vous ne me menacez pas ! Non, la jeunesse n'est pas que désespérée, y'en a une qui veut bosser [ la bande son est difficilement compréhensible à partir d'ici ] et nous l'aiderons. »

Je note que la liberté de parole a bien régressé en France en 26 ans.


Bref, c'est du Macron tout craché : du libéralisme économique et des bourdes partout. :)

« Avec cette visite, Barack Obama souhaitait essentiellement développer sa politique étrangère en Asie et contrer l’influence commerciale de la Chine dans le continent. Néanmoins, il a également promu l’importance de la liberté d’expression et a reproché au gouvernement communiste vietnamien sa forte répression à l’encontre des mouvements de protestation.

Vaine, cette réprimande sonne comme un coup d’épée dans l’eau puisque, selon les activistes qui ont révélé l’information, c’est précisément pour museler l’opposition que l’accès à Facebook a été censuré. Les militants auraient en effet pu profiter de cet événement diplomatique pour organiser des manifestations en se mobilisant sur le réseau social. À noter que l’arrivée de Barack Obama, le dimanche 22 mai, coïncidait avec les élections parlementaires pendant lesquelles les opposants avaient appelé au boycott.

Le gouvernement vietnamien n’en est pas à son coup d’essai. À peine quelques jours plus tôt, les autorités avait déjà décidé de bloquer Facebook pour limiter les risques de manifestations. Il s’agissait cette fois d’éviter des contestations contre sa gestion d’une catastrophe environnementale provoquée par un industriel, qui entraîne depuis plusieurs mois la mort d’un nombre impressionnant de poissons tout le long de la côte littoral du pays.
Une pratique courante

Censurer les réseaux sociaux est monnaie courante dans les pays aux tendances autocratiques. Même près de chez nous. On se rappelle ainsi de la Turquie où Recep Tayyip Erdogan a fait de YouTube et Twitter ses ennemis jurés. Les deux plateformes sont en effet les outils préférés de ses détracteurs qui y dénoncent notamment les nombreuses affaires judiciaires dans lesquelles le chef de l’état est impliqué. En 2014, elles étaient toutes les deux momentanément censurées. Même son de cloche au Pakistan où YouTube a été bloqué en 2012 pour des contenus jugés blasphématoires.

D’autres pays s’ajoutent à liste : Ouganda, Thaïlande, Malaisie, Irak, Iran… Les réseaux sociaux ne sont pas appréciés par les gouvernements non démocratiques, pour qui le contrôle de l’information permet un contrôle de la population. La censure est très souvent justifiée par la volonté de protéger l’ordre public et de garantir la sécurité de la population. Pourtant, comme l’écrit Access Now sur son site, « ces coupures, au contraire, mettent en péril l’accès à des informations vitales et aux services d’urgence et plongent des sociétés dans la peur et déstabilisent la capacité d’Internet à soutenir des petits commerces et développer l’économie ». »

CETA = accord de libre échange (comprendre : bien libéral comme il faut) entre le Canada et l'Union européenne. Une sorte de pré-TAFTA qui est un accord de libre échange entre les USA et l'UE. Les deux ont des points communs comme d'être négociés dans le secret avant d'arriver dans les Parlements, de remettre en cause la souveraineté des États et le Droit propre à chacun. J-O-I-E.

« Certes, le Ceta doit encore être traduit dans les 23 langues officielles de l’Union, puis obtenir le feu vert du Parlement européen, [ NDLR : du Conseil de l'UE, c'est-à-dire des ministres des 28 États membres… ], des 28 Parlements des Etats membres [ NDLR : uniquement si l'accord est décrété mixte (aka un accord qui touche aux compétences de l'UE *ET* des états membres) par la Commission européenne) et du Parlement canadien. Mais ce processus pourrait être entravé.

[...]

Pourtant, à en croire la Commission, le Ceta stimulerait la croissance. Pas tant grâce à l’abaissement des barrières douanières, dont le niveau est faible (5 % en moyenne). Mais via la convergence des normes industrielles, sanitaires, phytosanitaires ou environnementales. Il s’agit aussi d’ouvrir en grand les marchés publics aux entreprises européennes et canadiennes, d’harmoniser les normes dans les services financiers, les télécommunications, l’agriculture… «Ils n’ont rien oublié», résume l’eurodéputé José Bové.

[...] les indications géographiques (Grana Padano, Roquefort…) ne pourront être utilisées au Canada que pour les produits importés des régions européennes d’où ils sont traditionnellement issus. [ NDLR : sauf que seulement 176 sur 1400 AOP ont été retenues et que les autorités canadiennes ont indiqué qu'elles ne veilleront pas à leur respect sur le territoire canadien. Le problème est que les AOP restantes subiront la concurrence canadienne directe avec des normes de production inférieures. ]

[ NDLR : Dans la même veine, les IGP (Indication Géographique Contrôlée ne sont plus garanti en totalité genre des matières premières ne sont pas obligées de provenir du territoire géographique de l'IGP et pourront donc être importées. ]

En échange, l’Europe a autorisé l’importation de plus de 50 000 tonnes de viande de bœuf (près de 1 % de la consommation globale du continent) [ NDLR : + 75 000 tonnes de viande porcine selon le Canard ]. A condition qu’il soit élevé sans hormones [ NDLR : ce dont doute le Canard Enchaîné du 25/05 puisque les fermes-usines sont fort nombreuses au Canada. De plus, la France est déjà dans un état de surproduction porcine (voir http://shaarli.guiguishow.info/?yNJOrg ) ! ].

[...]

Mais cette avalanche de chiffres est loin de tempérer l’exaspération des ONG ou des syndicats qui craignent la généralisation des tribunaux d’arbitrages (les ISDS) pour régler les différends entre Etats et entreprises. [...] Karine Jacquemart, directrice générale de Foodwatch France : «Il est hors de question que des entreprises dictent leurs lois à des Etats souverains… Et c’est pour cette raison que la France a plaidé, et obtenu, une rénovation de l’approche de la protection des investissements», corrige-t-on à Paris.

En février 2016, Ottawa et Bruxelles ont finalement décidé d’enterrer les ISDS. Terminé, ce système de règlement des différends assuré par des arbitres privés. Finies, ces procédures arbitrales à huis clos. L’ISDS est mort, vive l’ICS, pour Investment Court System. La différence ? Les discordes seront traitées par une cour permanente, à double degré de juridiction, où siégeront 15 juges, et non plus des arbitres. Surtout, les arbitrages seront rendus publics. «De plus, les émoluments ne seront pas versés par les entreprises,se félicite-t-on à Paris. Ottawa et Bruxelles mettront la main à la poche pour rétribuer ces juges d’un nouveau genre.» Pas de quoi rassurer les détracteurs du Ceta, qui parlent d’un tour de bonneteau. Plusieurs organisations, dont la fondation Nicolas Hulot et Foodwatch, ont appelé les Etats de l’UE, le 29 avril, à rejeter le Ceta, «cousin canadien du Tafta qui présente les mêmes dangers». Comme le relève Karine Jacquemart, si le nouveau mécanisme de règlement des différends n’a en apparence rien à voir avec l’arbitrage privé, «pour autant, ce n’est pas un tribunal public. Ce ne sont pas des juges, car ils ne dépendent d’aucune magistrature de supervision indépendante. Ces pseudo-juges seront des avocats d’affaires liés à des cabinets privés.» Bien sûr, ils toucheront un salaire public, autour de 2 000 euros. De quoi provoquer rires et railleries. «C’est une blague ? Qui peut imaginer que ces faux juges se contenteront de si peu, alors qu’ils empochent d’ordinaire des dizaines de milliers d’euros pour n’être que de simples conseils en droit des affaires ?» ajoute la directrice de Foodwatch. Pas question pour Bruxelles et Ottawa d’interdire à ces «juges» d’exercer la profession d’avocat d’affaires pendant cinq ans avant et après leur mandat.

Pas plus qu’il ne s’agit de remettre en cause le «forum de réglementation renforcée». Selon José Bové, «tout ce qui n’aura pas été discuté dans le traité pourra l’être, par la suite, dans ce cadre-là». Voilà pourquoi le Ceta est qualifié de «traité vivant». La directrice de Foodwatch : «Qui trouvera-t-on en arrière-plan de ce forum permanent où sont censés discuter les représentants des deux blocs commerciaux ? Des entreprises qui feront du lobby pour détricoter des normes sociales ou environnementales. Elles le font déjà à Bruxelles pour influencer la Commission.» »


J'ajoute ces éléments relevés par le Canard du 25/05/2016 :
    * Le principe de précaution n'est pas reconnu au Canada donc l'UE et ses autorités (nationales et européennes) ne pourront pas retoquer un produit au nom d'un éventuel risque, il faudra de solides preuves que le risque est avéré.

    * Près de 81 % des firmes qui ont un pied en UE, ont aussi un pied au Canada. Au travers des filiales canadiennes, ces firmes pourront attaquer les attaques via les tribunaux arbitraux avant que TAFTA entre en application.

    * Une fois que le Conseil de l'UE et le Parlement européen auront décidé que le CETA est ratifié, il peut être appliqué 3 ans. Et que les firmes pourront utiliser les tribunaux d'arbitrage pour se plaindre pendant que l'accord est temporairement actif et même pour des faits survenus 3 ans après la fin de l'application provisoire, même s'il n'est pas appliqué ensuite car retoquer par les parlements nationaux (si l'accord est jugé mixte, voir plus haut).


Les élus de la France font mine de ne pas vouloir du TAFTA mais se disent prêts pour ratifier le CETA (http://www.liberation.fr/planete/2016/05/26/hollande-et-trudeau-appellent-a-mettre-en-oeuvre-l-accord-de-libre-echange-ue-canada_1455396 )… Absence de cohérence et enfumage en vue (si CETA passe, pas besoin de TAFTA puisque 81 % des sociétés commerciales qui profiteraient de TAFTA profiteront de CETA ;) ).


Voir aussi https://france.attac.org/se-mobiliser/le-grand-marche-transatlantique/article/apres-le-ttip-leaks-faire-echec-a-ceta et http://transatlantique.blog.lemonde.fr/2016/02/19/laccord-ceta-europe-canada-sera-t-il-applique-avant-meme-le-feu-vert-des-parlements/

« Le bureau du Sénat a décidé jeudi "qu'il n'y avait pas lieu de saisir la justice" pour faux témoignage à l’encontre de Frédéric Oudéa, patron de la banque Société Générale.

[...]

Pourtant, les faits sont têtus.  Frédéric Oudéa avait affirmé en 2012 sous serment que la Société Générale « avait fermé ses implantations et n’avait plus d’“activités au Panama”. Pourtant les révélations des "Panama Papers", début avril, prouvaient le contraire. Plusieurs sénateurs, dont Éric Bocquet (Communiste, républicain et citoyen), avaient annoncé leur intention de saisir le bureau du Sénat, estimant que Frédéric Oudéa avait menti devant la commission d'enquête sénatoriale sur l'évasion de capitaux, créée en 2012. A nouveau convoqué au Sénat le 11 mai dernier, le patron de la Société Générale n’a plus contesté l’existence de ces sociétés offshore mais seulement leur nombre (près de 1000)... Il avait d’ailleurs précisé que le nombre de sociétés offshore encore actives et montées avec le cabinet panaméen Mossack Fonseca s'élevait au total à 66, dont 6 à Panama. »

Pour moi, la réalité des faits est là.

En revanche, il y a deux questions qui se posent :
    * Les faits sont-ils prescrits ? Il semble que oui (délit instantané donc 3 ans à partir du jour de la commission du fait, pas de sa découverte). On pourrait augmenter le délai avant prescription (ce qui risque d'être fait pour la prescription de droit commun, voir le 2 juin au Sénat si la proposition de loi passe http://www.assemblee-nationale.fr/14/dossiers/reforme_prescription_matiere_penale.asp ) mais ça pose de vraies questions d'équilibre de la justice (voir : http://shaarli.guiguishow.info/?c0Sfpg ). On ne peut pas vouloir un délai de prescription plus long quand ça nous arrange.

    * Est-ce que les propos relèvent vraiment du faux témoignage tel qu'il est défini dans le Code pénal (interprétation stricte) ? Si ce n'est pas le cas, le Sénat serait dans un cas de dénonciation calomnieuse, qui est un délit.

Mais, pour moi, au vu des éléments factuels (qui n'ont pas été réfutés par la Générale lors de la récente audition !) dont on dispose, ces questionnements ne sont pas de nature à empêcher une saisie de la justice. Autrement dit : le Sénat fait de la merde sur ce coup. :(


Via Le Canard Enchaîné du 25/05/2016 et http://lehollandaisvolant.net/?id=20160526155012 (même si les propos sur le revenu de base sont faux, voir http://shaarli.guiguishow.info/?-2_oTA )

Cambadélis, premier secrétaire du PS qui balance à ses proches que la belle Volkswagen suréquipée détectée par Le Point y'a une semaine est en fait une voiture de campagne d'Hollande.

Ha bon ?! Je croyais qu'il prendrait la décision de se représenter à la fin de l'année ?! Nous aurait-il menti une fois de plus ? :))))))))))

Via Le Canard Enchaîné du 25/05/2016.

« OMG. 16 Go de RAM pour faire tourner Doom ? »

Vous êtes plusieurs à avoir réagi sur ce point. J'ai 16G de RAM en tout car mon autre ordi n'a que 2*8G. J'ai donc transplanté une barrette de 8G. Si ça avait été 8*2G, j'aurais donc eu 10G au total puisque j'aurais transplanté une barrette de 2G. J'ai fait tourner le moniteur des ressources de winwin en arrière-plan et le jeu pompe 5G en moyenne, avec des pics à 7G. Il n'y a pas de fuite mémoire, àmha. Je pense plutôt qu'il y'a un fail de l'OOM-killer de winwin. Est-ce que je suis sûr que c'est bien l'OOM-killer qui bute le jeu ? Oui, j'avais le message d'erreur "ce programme consomme trop, fermez-le blablabla".


« Steam n'est pas encore tombé dans ce travers là ; les jeux supprimés de son catalogue restent dans la logithèque du joueur. Mais je suis d'accord avec toi : les CGU, ça évolue... »

Oui, pas encore. Avant la suppression de « 1984 » et de « La Ferme des animaux », Amazon n'avait pas non plus d'antécédents, CQFD. Ce n'est pas un problème d'évolution des CGU, elles disent déjà à quelle sauce tu peux être mangé. Simplement, les clauses en question ne sont pas *encore* appliquées.

Pour les noobs de Steam comme moi, je rapporte ici ce que blusky m'a appris : quand tu te fais gauler pour triche en multi, apparemment, ça ne va pas jusqu'à la fermeture du compte du tricheur (ce qui conduirait à la perte des jeux achetés), simplement à l'exclusion de tous les serveurs de jeux multi équipés du système anti-triche (ce qui peut représenter 100 % des serveurs selon les jeux). Mais, selon les CGU, c'est parfaitement possible, ça peut aller jusque-là alors que l'on sent bien que la sanction est disproportionnée par rapport à l'acte. Un peu comme Youtube qui te supprime ton compte après des avertissements pour atteinte au droit d'auteur.


« Quand tu tu dis que le choix par défaut n'est pas le bon, il n'est certes pas bon pour la vie privée du joueur, pas pour l'entreprise Steam qui se fait des bénéf tellement énorme qu'on ne connait pas au juste leur montant exact. Je suis même prêt à affirmer (si quelqu'un pouvait me le confirmer... Liandri ?) que désactiver les publicité comme tu l'indiques ne règle qu'une partie du problème : le gros panneau défilant en haut de la page d'accueil du catalogue, et même tout le bas de la page du catalogue quand tu scrolles, s'adapte en fonction de tes habitudes de jeu / consultation de pages du catalogue. »

Rien à dire, j'archive juste.


Sur l'aspect pérennité, j'ajoute une remarque de blusky : les CGU de Steam interdisent la transmission (héritage) de la bibliothèque de jeux. Alors, certes, suffit de communiquer le mdp du compte aux descendant-e-s mais il n'empêche que c'est interdit. On est donc bien sur de la location. Qui s'arrête à la mort d'une des parties (Steam ou moi).

Grifon ( https://www.grifon.fr/ ) est un FAI associatif autour de Rennes. Hier, les techs ont rencontré un problème bien connu mais toujours aussi relou. Alarig a écrit une version synthétique, sans tous les rappels, voir https://www.swordarmor.fr/le-mtu-et-le-mss.html .

Quel est le problème ? Certains sites web ne fonctionnent pas comme un téléchargement sur dovecot.org, une visite sur laposte.net ou bien encore une visite sur un site web hébergé chez aws. On constate également que des mails n'arrivent pas et que Postfix consigne ce qui suit dans son journal : « postfix/smtpd[9095]: timeout after DATA (0 bytes) from [...] ».

Que montre une capture réseau (tcpdump, wireshark, etc.) ? Que la poignée de main TCP se passe bien, le GET HTTP aussi mais qu'ensuite, plus rien ne transite, puis la connexion TCP est fermée. Ça, ça illustre typiquement un problème de MTU.


Qu'est-ce que la MTU (Maximum transmission unit) ? La taille maximale d'un paquet IP, entête compris. En effet, tout ce qui transite sur nos réseaux informatiques est découpé en paquets de taille $MTU octets. C'est ça, la fragmentation IP. La MTU standard est de 1500 octets. Pourquoi ? Parce que c'est celle qui découle de celle normalisée à l'IEEE pour les réseaux Ethernet (1518) et vu la suprématie des réseaux Ethernet, cette taille est devenue un standard de fait. Pourquoi l'IEEE a-t-elle choisi une trame de 1518 octets au niveau 2 ?
    * Parce qu'à l'époque, on avait des réseaux en bus et/ou des hubs. Le support de communication était beaucoup plus partagé qu'aujourd'hui. Il fallait donc gérer les collisions (deux machines qui causent en même temps, ça va donner nawak au niveau électrique dans les câbles donc plus aucune donnée récupérable). Fixer une limite permet d'éviter qu'une machine émette en permanence et bloque le support de communication (chaque trame Ethernet doit être suivie de 12 octets de vide ). Une taille connue permet également aux machines de se synchroniser plus simplement pour émettre puisqu'on connaît le temps que prendra la trame pour être émise et progagée sur le support de communication.

    * Il fallait également tenir compte de la vitesse de propagation de bout en bout dans les supports physiques de communication et les topologies de l'époque (genre le temps que le signal arrive à l'autre bout du bus…). « Large packets occupy a slow link for more time than a smaller packet, causing greater delays to subsequent packets, and increasing lag and minimum latency. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer (and hence over most of the Internet), ties up a 14.4k modem for about one second. » ( source : https://en.wikipedia.org/wiki/Maximum_transmission_unit ). C'est avec une charge utile (au niveau 3) de 1500 octets que l'on arrivait à avoir une bonne efficacité (ratio charge utile / taille totale de la trame au niveau 2) et du coup, un débit décent. Et 1500 octets, c'était important pour l'époque.

    * Enfin, il fallait tenir compte de la mémoire disponible dans les machines de l'époque car, le temps "d'avoir l'autorisation d'émettre" sur le réseau, il faut bien stocker l'information dans un espace temporaire, un buffer, que ça soit sur les commutateurs, les routeurs ou les ordis.

La MTU a du sens uniquement sur le réseau local c'est-à-dire entre deux routeurs. Internet étant un agglomérat de réseaux interconnectés les uns aux autres et causant IP, on imagine bien que, pour aller d'un point A à un point B d'Internet (genre de chez vous à Google), on croisera plusieurs routeurs… possiblement interconnectés entre eux avec des technologies bien différentes… donc avec des MTU différentes. Ce qu'on nomme la PMTU (Path MTU) est simplement la taille de paquet qui permet la communication d'un point A à un point B sans fragmentation IP. Elle est forcément égale à la plus petite MTU des liaisons physiques traversées. Genre, soit les MTU de 5 segments réseaux traversés pour aller d'un point A à un point B d'Internet : 1492 - 1500 - 1476 - 1500 - 1500, la PMTU sera de 1476.




Heu mais ça veut dire que sur un réseau mondial très hétérogène, la PMTU peut varier du tout au tout entre un point A et un un point B et entre le même point A et un point C ? Oui, c'est l'idée. Heu… Et du coup, comment le point A apprend que la PMTU pour joindre A c'est 1500 octets et que la MTU pour joindre C c'est 1476 octets ?
    * Soit on s'accorde sur une PMTU minimale, que tout le monde doit savoir gérer. IPv4 normalise une taille de 68 octets, IPv6 une taille de 1280 octets. Au passage, on comprend que 1280 était une valeur de MTU raisonnable pour la fin des années 1990, quand IPv6 a été normalisé. Cela signifie donc qu'on était loin du tout Internet en 1500 octets à ce moment-là. ;)

        Quel est le problème avec cette méthode de fixer une valeur plancher ? Elle n'est pas du tout optimale : la destination perd des ressources à re-assembler les paquets. On perd en efficacité (la proportion d'entêtes pour transmettre un même message utile augmente) et en débit (il faut transmettre beaucoup plus de paquets par seconde pour échanger la même quantité d'infos).


    * Bah, c'est trop facile, le routeur qui doit émettre sur un lien qui dispose d'une MTU plus faible n'a qu'à fragmenter chaque paquet reçu, en plus petit. Ainsi, on est au plus près de la PMTU. Dans mon exemple précédent de 5 réseaux interconnectés avec les MTU suivantes 1492 - 1500 - 1476 - 1500 - 1500 , la machine source émettra avec une MTU = 1492 octets et le routeur qui fait le lien entre le réseau avec une MTU de 1500 octets et celui avec une MTU de 1476 aura qu'à fragmenter les paquets reçus (de taille 1492 donc) en paquets de taille 1476 + 16 octets.

        Oui, mais la destination perdra toujours des ressources à re-assembler les paquets. Pire, les routeurs perdront des ressources énormes à fragmenter les paquets (car il faudra traiter les paquets de manière logicielle alors que leur transfert sans fragmentation se fait de manière matérielle, sur des circuits optimisés) et à transférer de petits paquets (la limite d'un routeur, ce n'est jamais le nombre d'octets transmis par seconde mais plutôt le nombre de paquets transférés par seconde). Sans compter qu'ils devront avoir un bufffer pour stocker temporairement les données reçues en attendant d'avoir émis tous les fragments sur le lien à la MTU plus faible. On peut remplacer le buffer par un mécanisme permettant de signaler à la destination qu'on est débordé, prière de ralentir le rythme d'envoi mais aucun des mécanismes de ce type normalisés n'a réussi à percer à grande échelle). Bref, mauvaise idée.

        Notons qu'en IPv6, les routeurs n'ont plus le droit de fragmenter selon les RFC.


    * Soit on adopte un processus permettant de déterminer dynamiquement la "bonne" PMTU pour chaque destination. Plusieurs méthodes co-existent aujourd'hui.
        * La première a été normalisée dans TCP ( https://www.ietf.org/rfc/rfc793.txt ), en 1981. Elle se nomme Maximum Segment Size (MSS). Il s'agit d'une option de TCP. Oui, UDP peut aller se faire voir. UDP est minimaliste et ne permet pas d'implémenter cela. De plus, à l'époque, personne ne pouvait prévoir que quelques usages gourmands apparaitraient 25 ans plus tard comme DNSSEC. Cette option permet de dire : je ne suis pas en mesure de recevoir/émettre plus de telle quantité de données. Cette quantité exclut l'entête TCP. En gros, on a donc MSS = MTU - entête IP (20 octets en IPv4, 40 octets en IPv6, sans les options dont il ne faut pas tenir compte) - entête TCP (20 octets, sans les options dont il ne faut pas tenir compte, selon les RFC). Donc, pour une MTU de 1500 octets, on a une MSS de 1460 octets, par exemple. Cette option est échangée une seule fois, uniquement lors de la poignée de main TCP (dans le SYN et le SYN ACK). La source apprend donc la MSS de la destination et inversement. Elle est calculée automatiquement à partir de la MTU configurée sur l'interface réseau par laquelle le trafic sera émis.

            Heu ? Cette méthode ne permet pas de trouver la PMTU mais uniquement de s'échanger la MTU des extrémités ?! Et si la MTU diminue subitement en plein milieu du chemin ? Hé bah oui, MSS ne permet pas de voir cela… À moins de ré-écrire sauvagement la valeur de l'option MSS de tous les paquets réseau amenés à circuler sur la liaison à la MTU limitée. C'est typiquement ce qui se passe dans nos box Internet : les données sont encapsulées en PPoE. Ce protocole consomme 8 octets d'entête. On ne peut donc plus stocker 1500 octets au niveau IP mais 1492 octets. Pourtant, entre nos ordinateurs et notre box, la MTU est bien de 1500 octets. Donc la valeur MSS transmise sera de 1460 car notre ordinateur ignore que la MTU sera inférieure derrière la box. La box réécrit ça en douce : MSS = 1456. Cette méthode se nomme TCP MSS clamping. Cette méthode est plutôt crade. D'abord parce qu'elle consomme des ressources sur les routeurs (ça ne se voit pas sur une ligne ADSL, j'en conviens). Ensuite parce qu'un opérateur réseau n'a pas à regarder au-delà d'IP (vous n'avez pas le contrôle de la box donc c'est bien un routeur qui obéit à votre FAI).

            Dans le même genre, notons bien que la MSS est échangée uniquement à l'initialisation de la session TCP. Et si le routage change alors que la session TCP est encore ouverte ? La MSS n'est pas optimale (cas d'une PMTU qui augmente) voire le transfert s'interrompt (PMTU en baisse).


        * La seconde, nommée PMTUD (PMTU discovery) a été normalisée en 1990 ( https://tools.ietf.org/html/rfc1191 ). Il s'agit de découvrir la PMTU. Comment ? L'émetteur émet au max de sa MTU en positionnant le flag Don't Fragment (DF) dans l'entête IP. Les routeurs n'ont ainsi pas l'autorisation de fragmenter le paquet. Si le paquet doit être fragmenté à moment donné sur le chemin, le routeur émet un message ICMP type 3 code 4 « Fragmentation needed » à destination de la source. La source doit adapter la taille des paquets qu'elle émet. Cette fois-ci, ça fonctionne pour TCP, UDP et n'importe quel autre protocole de couche 4 (SCTP, etc.) ! \o/

            Notons que la PMTUD est la seule méthode utilisable en IPv6 puisque les routeurs ne doivent plus fragmenter même quand c'est nécessaire. Booon, y'a aussi la méthode de la taille minimale, en vrai, mais bon… :)

            Enfin une méthode magique qui résout tous nos problèmes ?! Hé bah non. Beaucoup d'administrateurs-trices systèmes et réseaux sont incompétent-e-s et bloquent tout ICMP sur leur réseau et/ou leurs serveurs. Ainsi, leurs machines ne reçoivent pas le message ICMP « Fragmentation needed » et n'adaptent pas leur taille d'émission en conséquence. La PMTUD ne peut produire aucun résultat.

                Pourquoi les administrateurs-trices font-ils cela ? Parce qu'ils-elles ont peur du Ping of Death (une vieille attaque par déni de service qui ne fonctionne plus aujourd'hui, qui consistait à envoyer des paquets IP dépassant la taille maximale normalisée (2^16 -1), en espérant un buffer oveflow dans l'implémentation, ce qui n'a rien de spécifique à ping/ICPM mais ping permettait de faire une démo rapide et efficace) ? Parce qu'ils-elles ont acheté une middlebox filtrante magique pour éviter d'avoir à réfléchir et que les codeurs-euses qui ont sorti c'te box n'y connaissent rien en réseaux informatiques parce que c'pas leur domaine ? Parce qu'ils-elles ont peur de certaines parties du protocole comme l'échange de timestamp ou le redirect (on peut désactiver ça simplement sur tous les systèmes sérieux…) ? Bref, avec tout pare-feu de ce nom, on peut laisser passer uniquement les messages ICMP en rapport avec une connexion existante (echo reply d'un request qu'on a lancé, ttl expired, destination unreachable, etc.) : iptables -A INPUT -p icmp -m state --state RELATED -j ACCEPT ; ip6tables -A INPUT -p icmp6 -m state --state RELATED -j ACCEPT . Il n'y a aucune raison valable de filtrer intégralement ICMP.

           Une nouvelle méthode a été normalisée depuis 2007 ( https://www.bortzmeyer.org/4821.html ). « Notre RFC propose donc une alternative, ne dépendant pas de la réception des paquets ICMP et fonctionnant donc en présence de « trous noirs » qui absorbent tous ces paquets ICMP. Il suggère tout simplement de tenir compte des paquets perdus, en supposant que si seuls les plus gros se perdent, c'est probablement qu'ils étaient plus gros que la MTU. La nouvelle méthode est donc d'essayer des paquets de différentes tailles et de surveiller les pertes. ». Inutile de préciser que cette méthode n'est pas déployée.


Bref, la découverte de la PMTU c'est toujours la merde en 2016. Comme c'est la méthode privilégiée, les paquets IP se retrouvent avec le flag DF et donc, quand la PMTU foire, tout foire puisque les routeurs ne sont pas autorisés à fragmenter…




Hum, mais attend… si Ethernet est répandu partout, on devrait avoir 1500 octets partout donc osef de la découverte de PMTU ? Non. Cœur de réseau = 1500 octets. Fibre optique à la maison = PPoE = 1492. ADSL soit PPoE soit PPoA (1468 même si ça se fait plus trop), etc. Ensuite, il faut rajouter toute sorte de tunnels qui font notre quotidien : IPv6 over IPv4 pour avoir de la connectivité v6 quand on a un FAI qui n'en fournit pas, VPN pour contourner la censure et autres filtrages débiles, IPSec pour des liens sécurisés, etc. Donc non, les problèmes de MTU n'ont pas disparu, bien au contraire.




Revenons à Grifon : l'association a deux transitaires (voir ici pour une définition : https://wiki.arn-fai.net/technique:routage#qu_est-ce_qu_un_transitaire ) : Cogent et ARN. Oui, ARN fournit de la connectivité à Grifon car Cogent ne fournit pas toutes les routes vers tous les réseaux qui composent Internet : il manque au moins Google et HE en IPv6. De plus, cela apporte de la redondance dans le cas où Cogent se vautre sur le routage mais que le routeur est encore en mesure de transférer des paquets (rigolez pas, ce cas s'est déjà produit suite à une maintenance).

On remarque que les destinations à problèmes passent toutes par ARN, partiellement (juste aller ou retour) ou en totalité (pour l'aller et le retour). Quelle est la particularité de l'interconnexion entre ARN et Grifon ? Comme les deux assos sont totalement à l'opposé d'un point de vue géographique (Rennes - Strasbourg :D ), on se doute bien qu'elles n'ont pas pu investir dans une liaison physique à plusieurs milliers d'euros/mois. Il s'agit donc d'un tunnel GRE. On perd donc 4 octets pour les entêtes GRE + 20 octets pour l'entête IP encapsulée. Sur la liaison entre ARN et Grifon, on a donc une MTU de 1476 octets.


Le premier réflexe quand on détecte un fail de MTU, c'est de diminuer la taille de la MTU des deux côtés de la liaison problématique. Mais c'est bien souvent une erreur. En l'occurrence, entre Grifon et ARN :
    * La MTU configurée sur les interfaces GRE était 1476 donc elle correspondait à la théorie ( 1500 - entête GRE - entête IP) ;

    * Un « ping <IP_pair> -s 1448 -M do » fonctionnait parfaitement. Cette commande envoie un paquet ICMP avec 1448 octets de bourrage. On ajoute l'entête ICMP (8 octets) et l'entête IP (20 octets). On arrive donc à 1476, notre MTU. La liaison était donc fonctionnelle ;

    * Sur cette interconnexion, on avait une session BGP parfaitement fonctionnelle. Or, la table de routage complète d'Internet est beaucoup plus grosse que 1500 octets. En faisant une capture réseau, on voit bien que la MTU = 1476 et que la MSS = 1436.

        BTW, pro-tips : dans notre cas, la length affichée par tcpdump est celle au niveau TCP, sans les entêtes. La length affichée par wireshark correspond à la totalité du paquet sauf que la libpcap ne lui file pas un header "valide" (aka que c'est une interface de niveau 3 mais pas enregistrée comme telle), comme GRE, il remplace par Linux cooked capture (https://wiki.wireshark.org/SLL ) soit 16 octets qui n'existent pas. La technique imparable est de regarder la taille inscrite dans l'entête IP avec Wireshark.

    Autre pro-tips : lors d'un changement de MTU sur une interface, on constate que l'ancienne valeur est mise en cache (on voit ça avec ip r g <IP> ou route show <IP> sous BSD). Il faut donc vider le cache (ip route flush cache <IP>) ou up/down l'interface réseau.

On retiendra donc ceci : quand un ping (avec du bourrage) dont la taille est égale à la MTU circule sur un lien, alors diminuer la MTU ne corrigera pas le problème. Par contre, cela ne met pas en évidence une MTU sous-optimale. ;)


Le deuxième réflexe, c'est de remonter la chaîne : on wget les sites web problématiques depuis le routeur d'ARN : ça fonctionne. On wget les sites web problématiques depuis le routeur de Grifon, ça fonctionne. On wget depuis toute autre machine (physique ou virtuelle) située derrière le routeur Grifon, ça ne fonctionne pas. Quelle est la différence entre une machine derrière le routeur et le routeur lui-même ? Ça ne peut pas être un problème de routage interne puisque c'est spécifique à l'interconnexion avec ARN et que si on vire temporairement cette interconnexion, les wget fonctionnent depuis les machines derrière le routeur Grifon.

La différence, c'est la MSS. Le routeur Grifon sait que le paquet va sortir par l'interface ARN. Il calcule donc la MSS (1436) par rapport à la MTU de cette interface (1476). Mais la machine derrière le routeur, elle calcule la MSS (1460) en fonction de son interface à elle (1500), celle qui donne sur le réseau Grifon. C'est ce qui fait que ça fonctionne sur le routeur mais pas plus loin.


Mais… la découverte auto de la PMTU n'est pas censée résoudre ce souci ? Si,si, mais pas quand la destination bloque tout ICMP… C'est clairement le cas ici et une capture réseau sur le routeur d'ARN le met en évidence : au premier paquet dépassant 1476 octets (la MTU sur le GRE entre ARN et Grifon), le routeur d'ARN émet un message ICMP « Fragmentation needed » mais la destination n'en tient pas compte. Le routeur d'ARN ne peut pas fragmenter lui-même puisque, pour que la PMTU fonctionne, il faut positionner le flag « Don't Fragment » d'IP, chose que fait la destination. On sent l'incompétence : laisser la PMTUD activée et virer tout ICMP… paie ta cohérence…


Quelles sont les solutions ?
    * Grifon souscrit à une deuxième vraie prestation de transit IP qui ne lui sera pas livrée dans un tunnel donc la MTU sera égale à 1500 octets. Cette solution serait la meilleure (et pas que pour le problème de MTU) mais les finances de l'association ne permettent pas cela pour l'instant.

    * Sur toutes les machines des abonné-e-s Grifon, on fixe la MTU à 1476 octets c'est-à-dire, la valeur minimale des MTU des interconnexions de Grifon avec le reste du monde. Ainsi, on fait une partie du job de la PMTUD et la MSS sera fixée à 1436 octets ce qui permettra d'accéder à des réseaux dans lesquels ICMP est bloqué. C'est chiant à faire (il faut prévenir les abonné-e-s, les relancer, s'assurer que la modif' a été faite, changer le template utilisé lors de la création des machines virtuelles,…) mais c'est jouable. Dans /etc/network/interfaces, il faut ajouter « mtu 1476 » dans une description d'interface static/manual.

    * Sur le routeur de Grifon, on peut re-écrire la MSS, faire du MSS clamping, quoi. Avec Packet Filter (pf), ça se dit : « scrub out all max-mss 1436 ». Avec iptables, ça se prononce : « iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1476 » + la même chose avec ip6tables. Rapide et efficace.

        Un côté pas cool c'est qu'il y a un routeur qui lit la couche 4 et qui la modifie. Ce n'est pas son rôle. BTW, ça ne passerait pas avec un IPSec configuré pour faire de l'authentification. ;)

        Un autre aspect pas top, c'est que ça concerne uniquement TCP. Quid des applications au-dessus d'UDP ? Celles qui ne positionnent pas le flag DF verront leurs paquets fragmentés donc pas de soucis. Pour les autres, on retournera dans les travers de la PMTUD : ça ne fonctionnera pas avec des réseaux mal configurés. La question est : est-ce que les usages qui ont recours à des gros paquets + UDP + DF sont nombreux ? DNS ne semble pas positionner le flag DF (j'ai testé avec dig et unbound). La VOIP positionne le flag DF (pour RTP et STUN) mais les paquets ont une taille ridicule. En torrent, en revanche, l'usage du flag DF et de paquets > 1400 m'apparaît bien plus courant. Pour les VPN TLS (OpenVPN, par exemple), le flag DF est positionné et les paquets IP sont gros, mais, généralement, l'administrateur-trice du serveur VPN a prévu le coup (il-elle sait que son VPN sera utilisé sur des réseaux nazis… ) et demande à OpenVPN de fragmenter à une valeur qui passe partout comme 1300-1400 octets (paramètres de configuration « fragment » et « mssfix »).

    * On pourrait imaginer une sorte de compromis genre fixer une MTU de 1476 sur l'interface interne du routeur Grifon et espérer que les machines des abonné-e-s l'utilise pour calculer la MSS. Mais ce n'est pas le cas : on n'utilise pas la PMTU pour calculer la MSS (https://www.rfc-editor.org/rfc/rfc2923.txt , section 2.3 ) à cause du routage asymétrique et du fait que la MSS ne peut plus changer une fois la session TCP établie alors que le routage peut fluctuer, faisant ainsi changer le chemin.

« Chypre a renouvelé son parlement dimanche. Même si le parti au pouvoir de centre-droit reste en tête, l'abstention est en forte hausse et la fragmentation politique est renforcée. Les politiques d'austérité n'ont plus de majorité.

[...]

Pour la première fois depuis la division de fait de l'île en 1974, huit partis seront représentés au parlement, contre six dans l'ancienne chambre élue en 2011. Globalement, les grands partis ont subi de lourdes pertes. Les quatre partis traditionnels, le Disy (centre-droit), le Diko (centriste), l'Akel (communiste) et l'Edek (social-démocrate) représentent désormais 77,03 % des voix contre 91,93 % voici cinq ans, un recul de 14,9 points.

[...]

L'électeur chypriote a donc cherché des solutions nouvelles, principalement dans les petits partis. Ce sont les centristes de l'Alliance citoyenne (Symmahia Politou), opposés à la politique d'austérité, qui en ont principalement profité avec 6,01 %, alors que le parti européen, son prédécesseur avait obtenu 3,88 % en 2011. Le parti de gauche Solidarité, nouveau venu, arrive derrière avec 5,24 % des voix pour sa première apparition, suivi par les Verts (4,81 %, soit une hausse de 2,6 points).

[...]

Mais l'élément le plus inquiétant, c'est l'entrée du parti d'extrême-droite ELAM, proche des néo-nazis grecs de l'Aube Dorée, qui passe la limite de 3,6 % des voix nécessaires pour entrer au parlement avec 3,71 % des voix et qui gagne ainsi deux sièges.

[ NDLR : « Les élections législatives chypriotes dimanche ont été marquées par l'entrée d'un parti d'extrême droite au parlement, une première sur l'île méditerranéenne. » (source : https://www.afp.com/fr/infos/259/lautriche-elit-un-president-vert-qui-bat-de-justesse-lextreme-droite ) et « De ce suffrage sort une assemblée très fragmentée où l'extrême droite fait son entrée pour la première fois. » (source : https://www.rtbf.be/info/monde/detail_chypre-un-nouveau-parlement-fragmente-a-l-issue-d-un-scrutin-boude?id=9305166 ). ] »

« Pendant plusieurs mois, deux chercheurs de l’université de Princeton (New Jersey), Steven Englehardt et Arvind Narayanan, se sont livrés à la plus vaste étude (en PDF) jamais publiée sur les trackers, des morceaux de code utilisés pour identifier ou suivre la navigation des internautes, en passant au peigne fin un million de sites Web.

[...]

Ce robot a visité les un million de sites les plus fréquentés, selon le classement Alexa, et a listé l’ensemble des trackers qui y étaient présents.

[...]

Première conclusion : un vaste mouvement de consolidation a eu lieu ces dernières années, et seule une minorité d’acteurs bien connus sont présents sur la grande majorité des sites – seuls 123 trackers, sur un total de plus de 80 000, sont présents sur plus de 1 % des sites. Sans surprise, on trouve, largement en tête, Google, qui collecte de vastes quantités de données personnelles pour afficher des publicités ciblées et dont le seul tracker Google Analytics figure sur un peu moins de 70 % des sites analysés. Juste derrière se trouvent Facebook (20 % des sites) et Twitter (10 %).

[ NDLR : donc Google connaît 70 % de votre historique de navigation, que vous ayez un compte Google ou non ! ]

[...] Les sites comportant le moins de trackers sont les sites associatifs ou gouvernementaux, qui n’affichent pas de publicité, suivis par… les sites pornographiques, avec une moyenne de six trackers par site. En revanche, les sites d’information sont de loin les plus gros utilisateurs de trackers externes, avec un peu moins de quarante mouchards par site, soit le double du nombre moyen constaté.

[ NDLR : LALA ! ]

L’étude comporte cependant une bonne nouvelle pour les personnes soucieuses de leur vie privée en ligne : conduite sur un très grand nombre de sites, l’une des expériences des chercheurs montre que les outils de blocage des trackers, comme le module Ghostery, sont très efficaces dans la grande majorité des cas. Seuls certains trackers utilisant des méthodes peu courantes de fingerprinting — consistant à bâtir un « profil unique » en fonction des spécificités graphiques, sonores ou autres d’une machine — échappent à Ghostery, principalement, jugent les auteurs, parce que ces mouchards particulièrement intrusifs sont peu répandus.

[ NDLR : Ghostery n'est pas sous licence libre et appartient à une société commerciale de conseil qui étudie comment le marché numérique fonctionne. Il faut lui préférer Disconnect (https://addons.mozilla.org/en-US/firefox/addon/disconnect/ ). De manière générale, Adblock Edge (ou uBlock), + NoScript + Decentraleyes + Pure URL font le job.

Pour les techniques de pistage très intrusives, non, ce n'est pas du fake, voir, par exemple : http://www.numerama.com/tech/171804-une-nouvelle-methode-pour-vous-pister-sur-le-web-sans-cookie.html . Seul moyen d'empêcher ça ? Désactiver tout javascript sauf sur les sites web de confiance… Super pratique… ] »

Via https://twitter.com/aeris22/status/733685691079622656