• Actualités
  • Images ISO de FC6 mise à jour (« Re-Spin »)

+1

eddy33, un non-dégroupé bridé.
Mais je le crois ... (cependant, l'explication donnéereposant sur un filtrage en couche 7 me laisse perplexe: on modifie l'identifiant du browser et on se fait filtrer, alors qu'en termes protocolaire, rien n'a changé !). Par ailleurs, plusieurs recherches sur le forum lagrenouille n'ont rien ramené de tangible...

Il ne s'agit cependant pas d'une généralité et il faut donc prendre garde aux approximations.

Herrib, un non dégroupé "non bridé" très satisfait

+1 (puisque cela semble faire bien... ++ pour incrémenter le compteur, d'ailleurs).
Bon, j'ai du mal à le mettre sur serveur, j'ai réussi à foutre 1,75 Go mais maintenant j'ai tout le temps des « lost data connection to remote host: Relais brisé (pipe) » et autres « so: socket write error ».
Eddy33 : si tu en as besoin rapidement je peux lancer le serveur FTP sur ma machine, ça n'enverra qu'à 125 Ko/s mais c'est déjà mieux que 30.

Un câblé non bridé.
Je te remercie Yannick.
Je ne suis pas presse a ce point. Je vais lancer un torrent. Ca fera consommer des octets a mon FAI.

++
Attention Eddy33, il va encore plus te brider!
Salut...

Ca y est ! Je l'ai apres une nuit de DL. Mon FAI lache un peu la bride dans la nuit ce qui m'a permis d'avoir un debit gigantesque de 60 ko/s 😉


++
eddy33 wrote:Salut.
Tres bonne initiative ces re-spins....
Existe-t-il un moyen de les recuperer par FTP ou HTTP ?
Je suis en non degroupe et j'ai un debit de daube sur les torrents 🙁

++
utilise ktorrent passe en mode crypté et met un port entre 50000 et 60000

free bloque 6881 a 6889 ou jusque 6999 quelque chose comme ça.




c est vraiment une bonne nouvelle ses iso refaitent avec maj 🙂
Ce serait donc un blocage de ports et non un filtrage en couche 7 ... (voir dans le fil la supposée explication). Ca se contourne très simplement n'est-il pas?
Heu, je suis chez Free, dégroupage partiel, j'utilise Ktorrent sur le port 6881, et je n'ai eu aucun soucis pour télécharger l'ISO DVD (en 4h).

D'ailleurs, pour ceux qui passent par le Torrent, une fois le téléchargement terminé, merci de laisser ouvert les robinets pendant quelques jours pour les autres, ça aide aussi à télécharger plus rapidement les ISO 😉
@herrib
Il y a les 2 :
Une reduction du debit sur les ports "well known" ET une analyse des donnees du datagramme IP au routage pour retrouver les entetes des protocoles de P2P. Maudits routeurs Cisco...

@n1ck0
ok, je regarde merci....

@mercury
La c'est normal, tu n'es pas "brime" euh bride... Il n'y a que le non degroupe de concerne...

@trasher
merci, je regarde.
<edit>
Trasher, je fais deja ce qu'il est ecrit.

++
eddy33 wrote:@herrib
Il y a les 2 : Une reduction du debit sur les ports "well known" ET une analyse des donnees du datagramme IP au routage pour retrouver les entetes des protocoles de P2P. Maudits routeurs Cisco...
Merci, je connais les mécanismes (quoique ... Free utilise MPLS pour les différentes classes de trafic?). Je suis simplement étonné (voir les références précédentes) qu'on puisse, dans une référence supposée sérieuse, établir la discrimination que Free opérerait, en modifiant l'identité d'un browser ... ScvoOne a donné des références, dont celle-ci qui me semblent raconter n'importe quoi. J'attends donc la proof of the concept ou comment mettre en évidence le fameux "bridage" (et non pas parler de la théorie).
Et bien herrib je peux te dire que la référence donnée par ScvoOne ne raconte pas n'importe, au moment du bridage opéré par mon faï, j'ai fais le test et j'ai pu le constater par moi même.

Par contre depuis quelques temps j'ai l'impression qu'il n'y a plus de bridage ou très peu.
Mais je ne comprends comment changer l'identité d'un browser, en la passant à eMule, peut modifier les choses. La session protocolaire qui supporte le test mentionné dans la référence reste du http; aucun client eMule n'est lancé. C'est le sens de ma remarque. La preuve du concept me paraît vaseuse pour ne pas dire plus ...
trasher wrote:@bodman : Il suffit de lire la description qu'à gentillement faite herrib...

Re-Spin est justement une version à jour de Fedora, incluant les dernières mises à jour à la date de construction de l'ISO.

Plus d'infos sur Re-Spin :
http://fedoraunity.org/re-spins
Oui mais fedoraunity n'est pas le point de depart d'un debutant, le point de depart, c'est le site officiel de fedora. C'est sur ce site que les mises a jour d'ISO devraient être faites.
Je ne vois pas trop ce que tu comprends, le lien me semble assez explicite.

La valeur general.useragent.override sert à identifer le navigateur. Dans les entetes des paquets IP, le protocole reste http mais firefox n'est plus identifier comme Mozilla/4.0 mais comme eMule. Or les dès que les routeurs de Cisco détectent dans les paquets IP "eMule" les paquets sont bloqués. Corriger moi si je me trompe.
oui...
C'est le champ "User Agent" de l'entete HTTP qui est change...Cette valeur est envoyee par le navigateur (il existe un plugin firefox pour changer cette valeur).
Les routeurs Cisco analysent le debut des donnees du datagramme IP a router pour retrouver les entetes de certains protocoles. En voyant la chaine de caracteres "emule", il te diminue le debit.

++
La valeur general.useragent.override sert à identifer le navigateur. Dans les entetes des paquets IP,
Désolé de m'insérer dans ce débat, mais je n'ai jamais vu d'information sur l'agent dans les paquets IP...
Cette information se situe dans le protocole http (située beaucoup plus haut dans les couches réseaux).
Il n'y a donc pas de paquets IP "emule" ou autre.

Bien sur, certain outils permettent de démonter les protocoles de haut niveau pour analyser leur contenu. Mais effectivement changer l'agent d'un navigateur ne sera absolument pas significatif.

A+
Bien sur, certain outils permettent de démonter les protocoles de haut niveau pour analyser leur contenu
Ce n'est pas ce que font les routeurs cisco puisqu'il travaille au niveau 7 de la couche OSI ?
Si l'analyse est protocolaire, elle ne s'intéresse pas à une séquence request - respond concernant http et visant à faire connaître l'identité du browser mais à des séquences qui concernent eMule, supportées par un protocole spécifique (je donne la référence ci-après) distinct de http (bien évidemment!).

L'initial handshake qui initie les échanges eMule s'appuie sur TCP et suit un connect TCP . Le message hello émis par le le client eMule, porte l'identifiant du protocole (premier octet du message comprenant la valeur 0xC5). On est bien loin de l'identité du browser!

Le protocole eMule est décrit dans le document: http://ovh.dl.sourceforge.net/sourceforge/emule/protocol_guide.pdf . Pour l'identification du protocole, voir pages 60 et suivantes.

Quant au filtrage sur les ports, permettez-moi de rire s'agissant des P2P et de vous ramener au lien suivant: http://www.haypocalc.com/wiki/Liste_des_ports_TCP_et_UDP

Voilà. Je persiste à penser que le point n'est pas réellement éclairé et que les liens fournis donnent des éléments parfaitement (ou à peu près) abscons ...