Euh, Moi dans des cas comme ça, j'aurai plutôt envie de l'activer. Même si aujourd'hui, j'imagine qu'il doit être complètement fake, entre le câble qui court-circuite des pins pour économiser des fils de cuivre et les périphs qui ne l'implémentent même pas, sans parler des périphs qui le désactivent par défaut… Il faut que le périph et le câble supportent le flow control avant de vouloir l'utiliser.
S'il était activé sur le PC et que ça passait, je vois pas en quoi le désactiver améliorera quelque chose.
Sinon, à défaut de flow control hard, essaye voir si ton périph ne supporte pas le XON/XOFF (flow control 'soft')
Sinon, je me souviens que le noyau avait implémenté un mécanisme pour éviter qu'un port série plante une machine si jamais le port série débitait tellement que le noyau ne pouvais jamais redonner la main aux applis. J'ai pas regardé depuis, mais à l'époque, j'étais obligé de patcher mon noyau si je voulais bourriner avec une vielle machine, même en 9600 baud. Si ta machine est trop chargée et que t'a pas de flow control, c'est normal que ça merde.
Mais bon, la vraie solution reste quand même d'utiliser un vrai protocole de transfert avec gestion des erreurs.
Oui, mais seulement pour ce qu'il est : il sert à contrôler, pas à configurer. La config, c'est dans /etc/NetworkManager/.
Donc il n'y a rien pour configurer en ligne de commande.
Déjà, tu pars de la doc (lien que tu obtiens depuis la doc du site officiel) et tu crées une connexion dans /etc/NetworkManager/system-connections/ssid :
Encore faut-il connaître, ces foutus paramètres. Sachant qu'en Wi-Fi, la méthode normale et standard pour récupérer les paramètres, c'est de regarder les informations qu'il y a dans le beacon du point d'accès/élu (Oui, tu sais la, le machin qui contient le SSID, le type de cryptage et tout le reste quand tu cherche un réseau). Et non, j'ai pas envie de sortir tshark et une interface en mode monitor pour découvrir si l'AP est en WPA 1 ou 2, avec CCMP ou TKIP et tout le reste. Oui je sais, iw et iwconfig permettent de sortir les IE en hexa, que je devrai connaître par cœur... C'est ça, ouais.
[connection]id=nom de la connexionuuid=un uuid que tu génère avec uuidgen, ça c'est userfriendly !autoconnect=true ou false[ipv4]method=manualaddress1=adresse;masque;passerelledns=dns1;dns2[802-11-wireless]# ssid est de type 'byte array', donc il faut l'écrire en hexa, séparé de point virgules.# faut arrêter le foutage de gueule, c'est pas fait pour les utilisateurs.# (OK, la norme n'a jamais dit qu'un SSID doit être lisible, et donc ne spécifie pas d'encodage)ssid=SSID# mon réseau c'est pas un réseau ad-hoc. Je suis sur que le tiens aussi.# et même si ça en était un, de toute façon, t'est censé lire le beacon pour le savoir.mode=adhocsecurity=802-11-wireless-security[802-11-wireless-security]# ce que network-manager appelle "wpa-psk" en mode ad-hoc, c'est pas du wpa-psk.# d'ailleurs, ça marche pas; au mieux ça foire, au pire ça marche avec tout en clair.key-mgmt=wpa-pskpsk=passphrase
Je dirais dix minutes, mais je n'ai pas testé. De toute façon, on lit la doc une fois, et quand on a pigé, on n'a plus à la lire.
Seulement si le format du fichier de conf est naturel et logique. Avec ifconfig, je n'ai jamais besoin de regarder la doc. Mais là, sortir un fichier aussi long de ma poche, non je sais pas faire. Surtout que lorsqu'il y a une erreur de syntaxe, le message d'erreur est planqué dans syslog, et il est incompréhensible pour un humain.
De mémoire, voici ce que serait un fichier de conf wpa_supplicant, rien que pour les paramètres wifi
Et non, je n'ai pas regardé la doc. Et j'ai pas du en écrire depuis des lustres.
Reste qu'avant on critiquait NM parce qu'il n'avait pas de doc, et maintenant on critique parce que la doc est longue à lire ?
Non seulement la doc de NM est longue, elle est aussi nulle, parce que elle te décrit comment NM est un programme qui n'est pas fait pour être utilisé autrement que par nm-applet. Essaye de l'attaquer en D-Bus, aussi, pour voir.
Tu vas nous faire croire que tu sais tout configurer sans lire la doc, sauf NM ? C'est bien pratique pour critiquer, tiens.
Faut arrêter un peu : un /etc/network/interface pour se connecter à un réseau en clair avec iwconfig (ce qui est mal), ça doit être dix lignes. mon script wpa_supplicant, ça doit être 6 lignes. Ton machin minimal, c'est déjà 18 lignes et en plus ça marche pas.
Y a des fichiers de configs qui sont vraiment fait pour être lisibles et utilisables par des humains, et d'autre non.
À ce compte-là, on peut tout critiquer : je n'ai jamais lu de doc pour utiliser Windows.
Normal, y en a pas. La seule méthode d'apprentissage sur ce système, c'est de l'essai et de l'erreur (fatale). Il y a des articles sur microsoft.com, mais tu n'y comprend rien.
Est-ce qu'on peut déduire que Windows est mieux que Linux ?
J'en sais rien, j'ai même pas 25% des fonctionnalités que j'utilise sous Linux.
Au passage, tu sais configurer /etc/network/interfaces pour avoir une IP dynamique mais avec des DNS prédéfinis ? Parce que j'ai dû lire la doc pour le faire.
C'est la faute à dhclient. Et encore, essaye de le configurer pour qu'il ignore le serveur DNS du serveur et ne configure aucun DNS; C'est juste impossible avec les derniers dhclient, merci l'ISC. Et je ne parlerai pas de la non-lisibilité du code source. Ah merde, j'en ai parlé...
Et sinon, tu fait ça comment avec Network Manager ?
Et comment tu détermine ce qu'est une adresse email ? parce que aaaaaa@example.org pourrait très bien être un identifiant Jabber, par exemple. Sans compter le classique moi@babasse ~$
Tu vas quand même devoir passer en mode router advanced pour que ça serve à quelque chose.
Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Parce que le local-link doit correspondre à une présence unique sur le réseau. Sinon tu es hors specs. Peut-être que ça marche en config de base avec du local-link, j'en sais rien.
Bien sûr que ça marche...
Vu qu'ils interviennent exclusivement quand l'interface n'a pas su trouver une IP toute seule...
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Ce serait dommage, vu que c'est son boulot.
Non ?
Mais j'imagine que tu voulais dire "dans les distribs avec IPv4LL et ip on fait toujours attention à passer comme interface à avahi-autopid.action une interface avec un pseudo scope local pour ne pas perturber l'interface principale".
Non plus. Avahi-autoipd va directement taper sur netlink et observer les interfaces voulues en regardant si elles deviennent up ou pas. Si c'est up, on rajoute une ip. si c'est down, on l'enlève. Et si on rajoute une adresse sur la même interface ... ben avahi-autoipd s'en fout.
Et là la question qui fâche, sais-tu comment ip gére les pseudo scope IPv4 ? En utilisant les mécanismes d'alias.
Pas du tout, c'est plutôt le contraire : les mécanismes d'alias sont utilisés pour rendre ifconfig compatible avec ip. Il n'y a pas si longtemps, ça n'était pas le cas, d'ou confusion pour les utilisateurs d'ifconfig, surtout avec avahi-autoipd, justement. Y avais des rapports de bug "avahi-autoipd écrase mon IP", alors que non, Internet fonctionne encore. C'est juste que ifconfig affichait seulement la première adresse IP que le noyau trouvait, et qui était, comme par hasard, l'IP link-local d'avahi. L'autre adresse n'était visible qu'avec ip.
Si tu veux on peut discuter pendant des heures de pourquoi le modèle "weak host" de Linux est un nid à bug qui peut foutre une grouille assez violente dans les réseaux avec son lot de routes asymétriques et son ARP qui clignote d'une carte à l'autre.
Mauvaise configuration, changer configuration ?
Sous BSD pour changer l'adresse source il faut passer par une étape de firewalling (PF ou IPFW le font très bien). Ça a l'air lourd comme ça, mais c'est fou le nombre de problèmes qu'on évite sur les systèmes qui ont plusieurs interfaces physiques.
Non mais vu que la deuxième ne sera pas en autoconf que ce soit statefull ou stateless ca coute rien de créer un alias à ce moment là.
Hein ? la deuxième peut très bien venir de l'autoconf; tu peux mettre autant de préfixes que tu veux dans ton RA.
Le local sur site/organisation en ::2 avec un RAD qui tourne (radvd ou rtadvd)
Pourquoi y a t'il besoin d'avoir un mode routeur particulier dans ce cas ?
avahi_autopid va attribuer une adresse et une seule à une interface, en giclant l'adresse en place si il le faut.
Si ta distro met de la merde dans ton /etc/avahi/avahi-autoipd.action, peut être
avahi-autoipd is best used as a plugin for ISC's dhclient.
Those scripts make sure that avahi-autoipd is automatically started when dhclient fails to acquire an IP address via DHCP.
Je sais pas si ma "distrib" fait de la merde, mais c'est ce qui est fortement préconisé par les auteurs du programme eux même.
Et ces scripts "gicle l'adresse en place s'il le faut" ? ah ben non ... ils appellent avahi-autoipd, qui lui va utiliser /etc/avahi/avahi-autoipd.action au moment de configurer l'interface ... et le /etc/avahi/avahi-autoipd.action upstream ne gicle jamais les IP en place. Si quelqu'un t'a viré tes IP lorsque ton DHCP foire, c'est le script de dhclient.
Que ce soit via ip ou via ifconfig, que ce soit une bonne ou une mauvaise distrib tu auras toujours une seule adresse IP par interface (réelle, virtuelle ou alias).
Non. Tu peux très bien avoir 256 adresses sur la même interface. Et dans le même subnet. Tu peux aussi en avoir 65536, mais le noyau aime pas trop, c'est dans une liste chaînée, il me semble.
Il n'y a pas de notions de scope en IPv4 donc à un moment ou à un autre se pose la question "avec quelle interface je sors".
La question "avec quelle interface je sors" se pose déjà lorsqu'on à une seule adresse par interface ... Il suffit juste de regarder la bonne table de routage.
Et pour répondre à "une fois que j'ai trouvé la bonne interface, avec quelle adresse je sors si l'appli n'a pas fait de bind()", tu regarde la même table de routage, sur la même entrée, et tu regarde le champ "adresse source préférée si pas indiquée par l'application". Si tu utilise ip route, tu pourra la mettre bien comme il faut. Si tu utilise encore /sbin/route, le noyau choisira une adresse source préférée à ta place, et prendra toujours celle que tu veux pas. Et tant pis pour toi, ça sera de ta faute.
Non. Fort heureusement je n'ai pas à le faire, ils sont sur des scopes différents donc tout va bien. J'ai du mal à comprendre de quoi tu parles là.
Rien n'empêche d'avoir deux adresses globales sur une même interface ...
En mode routeur on peut même avoir plusieurs branches.
C'est quoi un "mode routeur" ?
avahi_autopid va attribuer une adresse et une seule à une interface, en giclant l'adresse en place si il le faut.
Si ta distro met de la merde dans ton /etc/avahi/avahi-autoipd.action, peut être. Mais celui upstream pour Linux utilise ip pour rajouter l'adresse, ou crée des alias avec ifconfig si ip n'est pas installé. Donc non.
ifconfig supporte très bien les interface avec plusieurs IP sur des protocoles différents.
On est en 2012. Toute interface physique à au moins une adresse IPv6 link-local, même lorsqu'on à pas de connéctivité IPv6. Lorsqu'on à une connéctivité IPv6, on à deux adresses. On peut même en avoir plus que deux si l'admin le décide. T'a vraiment envie de te panner 2 alias pour une connéctivité normale ? Oui, j'ai dit connéctivité normale, t'aura peut-être besoin des deux pour que ça marche.
Quand à avahiautoipd, le mieux c'est quand même de le lancer seulement si les mécanismes de dhcp se vautrent, et que les tests avec l'ip par défaut/précédente se vautrent.
avahi-autoipd c'est une blague, c'est l'équivalent des adresses link-local d'IPv6, pour IPv4. Tu peux toujours crier sur l'implémentation qu'est avahi-autoipd (l'implem, c'est du lennart, mais l'algorithme/protocole, c'est normalisé IETF), mais tu pourra pas crier longtemps sur le principe. Sache que ton linux chéri n'a pas attendu avahi-autoipd pour rajouter des adresses IPv6 link local à tes interfaces. Oui, tu en a maintenant. Il faudra vivre avec, tu en aura besoin pour récupérer des adresses globales...
Simple test : montre moi comment me connecter sur un réseau Wi-Fi sécurisé (paramètres exacts inconnus, sauf pour le SSID et la passphrase) avec une IPv4 fixe. En chronométrant le temps que t'a mis pour lire la doc. Parce que moi je n'ai pas lu la doc pour utiliser nm-applet, ni pour éditer /etc/network/interfaces.
J'ai pas envie d'endormir NetworkManager, j'ai envie qu'il arrête temporairement de toucher à une certaine interface, de manière dynamique, en continuant à utiliser les autres.
Oui, ça résoud le problème dans ce cas ... Encore faut-il en être au courant, une option dans l'interface graphique, ça serait trop demander ?
Mais de manière générale, j'aurai bien envie d'un moyen pour dire à NetworkManager d'arrêter de toucher à une interface, parce que je vais y faire des choses en dehors de sa portée. Le problème, c'est que, généralement, ces "choses" détruisent des interfaces et en créent d'autres avec des MAC différentes ou inexistantes ...
Sauf que pour moi et pour beaucoup d'autres utilisateurs, la méthode la plus simple reste trop souvent de purger NetworkManager...
ifconfig c'est le MAL. Il faut utiliser ip maintenant. C'est d'autant plus vrai lorsque tu passera tout ton réseau en IPv6. ifconfig ne supporte pas d'avoir plusieurs adresses IP sur une interface, alors que c'est nécessaire pour avahi-autoipd. Non ça va pas rentrer en conflit avec tout le reste, Le noyau à tout prévu pour, et de manière bien (pas du Lennart); il n'avait pas le choix de toute façon, s'il ne voulait pas rendre l'utilisation d'IPv6 trop chiante. Du coup ça marche en IPv4 aussi. Que demande le peuple ?
Pareil pour route : utilisez ip route à la place, vous serez moins surpris lorsque le noyau prendra des adresses sources bizarres pour aller sur le net, en IPv4 ou en IPv6...
Après, avahi-autoipd pourrait faire autre chose que créer un alias d'interface (encore un de ces trucs vieillots) lorsqu'il se rend compte qu'un truc vieillot lui à pété toute sa conf, mais ça c'est du Lennart tout craché : "Il faut que le programme marche, que l'utilisateur le veuille ou non !".
et dhclient pourrait disparaître lorsqu'on à plus besoin de lui ... mais bon, l'ISC est trop occupé à le récrire en espérant que le code soit moins horrible, puis à le récrire pour la même raison, parce que le code est toujours aussi horrible...
Et si eth0 n'est pas spécifié explicitement, mais via un mapping (exemple : t'utilise guessnet pour faire de l'autodétéction via requête ARP. Encore l'un des trucs tout bêtes que network-manager ne supporte pas), ça continue à marcher ? Ah non. Et encore, y a pas si longtemps que ça, NetworkManager était très tatillon sur le format possible de /etc/network/interfaces, en interdisant par exemple la combinaison d'espaces et de tabs pour l'indentation ou pour séparer les options de leurs valeurs...
Et savait tu qu'avec les derniers ifupdown tu pouvait désormais splitter ton /etc/network/interfaces en plusieurs fichiers ? Ah ben non, NetworkManager le supporte pas...
Pourquoi ne pas mettre simplement le VPN dans le second namespace ? comme ça y a une configuration classique sans VPN d'un coté et une configuration classique avec VPN de l'autre. Ça serait plus simple à gérer je pense.
Tu n'as pas le droit de supprimer le nom de l'auteur original, donc tu n'as pas l'abusus.
Dans le cas matériel c'est pareil : Pour la bouffe en tout cas, je n'ai pas le droit d'enlever l'étiquette de l'emballage, de mettre la mienne et de la revendre. Ni de revendre l'emballage avec la même étiquette mais avec un contenu différent, Ni de changer d'emballage et de revendre.
Est ce que je suis plus propriétaire de la quasi-totalité de ma bouffe ?
Il te faut une règle iptables qui va matcher tout le trafic de transmission.
Le plus simple, c'est d'exécuter tes applis qui doivent passer dans le VPN avec un utilisateur spécial, et d'utiliser le module 'owner' d'iptables. Ou d'utiliser un wrapper qui va marquer les paquets. Ou quoi que ce soit d'autre...
Pour les paquets que tu veut faire passer par ton VPN, marque tes paquets dans une chaîne OUTPUT avec -j MARK --set-mark 0x42, par exemple. Ou avec n'importe quelle marque... Il faut être dans la table mangle pour pouvoir modifier des marques.
Après, tu peux créer une table de routage spéciale qui va faire passer tout le trafic sur ton VPN, du genre ip route add default via la_bonne_gateway_de_ton_vpn table 42. Puis créer une règle pour dire d'utiliser cette table de routage avec les paquets marqués : ip rule add type unicast fwmark 0x42 table 42. Il faudra peut-être une règle pour le retour aussi, pour dire que tes paquets qui viennent de l'interface de ton vpn utilisaient cette table de routage, sinon le reverse path filtering va jeter tes paquets parce qu'ils sont censé venir de ton interface filaire...
Fin bref, ça doit être drôle à expérimenter, tout ça. Après il faudra le sécuriser ;) Le noyau linux peut faire des choses bizarre, comme répondre à une requête ARP qui concerne l'IP que tu à sur le vpn, mais depuis ton interface filaire publique. Du coup c'est facile pour un espion avec le même FAI que le tiens de te trouver s'il cherche qui est derrière le VPN...
À économiser de la bande passante, quand t'en a pas.
C'était la raison n°1 qui m'a fait installer une Debian x86 sur un PC qui supportait le 64bit : je voulais réutiliser les 20Go de paquets x86 du cache d'apt-proxy/cacher-ng, parce que 1Go à 60 ko/s, c'est lent.
Mwai dans le contexte du C++, je sais pas. Les données sérialisées seront probablement incompatible binaire pour commencer (même si ça ne serait pas un grave inconvénient dans tous les domaines)
Ah bon ? pourquoi ?
Qu'est ce qui empêche de sérialiser vers du XML ou vers une ribambelle de formats de sérializations tout aussi bizarres les uns que les autres ?
Et de toute façon, tu peux de toute façon pas dumper un objet dans un fichier à cause de tes pointeurs... Alors autant sérialiser avec Boost::Serialization en utilisant/écrivant le backend de tes rêves.
De toute manière tu veut l'écrire en quoi la bibliothèque standard du C++ ?
En ce que tu veux, du moment qu'il y a plusieurs implémentations par des acteurs indépendants, de telle sorte que le langage ne meure pas si un acteur principal tombe.
Si il n'y a qu'un seul acteur qui décide de la bibliothèque standard et qui lui ajoute des fonctionnalités tout les 4 matins sans que les autres puissent suivre, j'ai un peu moins confiance.
C'était beaucoup moins contestable lorsque Sun était en train de faire faillite et de se faire racheter par Oracle. J'ai aussi vus des articles de dev C# qui se disaient "abandonnés par microsoft" qui délaissait Silverlight et d'autres trucs, pour faire du HTML5...
Avoir un langage et des implémentations indépendantes, ça à ses avantages.
Quand on regarde les langages avec une grosse bibliothèque standard, on fini souvent par tomber soit sur des langages ou il n'y a qu'une seule implémentation utilisée par la majorité, soit sur un langage qui nécessite une bibliothèque ou il n'y a qu'une seule implémentation écrite dans le langage lui-même. Ça veut généralement dire que le langage n'est pas indépendant.
Aujourd'hui tu à plusieurs implémentations indépendantes et conformes de C++ et sa bibliothèque standard. J'ai pas suivi pour Java et C#, mais il me semble que au mieux il y avait deux ou trois implémentation qui tiennent la route, dont une majoritaire. Pour Python, c'est un peu mieux, parce que la bibliothèque standard est en grande partie écrite en Python, et c'est d'ailleurs quand ça l'est pas qu'on se paye les incompatibilités dans les autres implémentations.
Après il faut choisir : grosse bibliothèque ou langage durable dans le temps ?
Il faut quand même bien se rendre compte que la plupart des automobilistes conduisent correctement
En tant qu'automobiliste, je ne suis pas d'accord. Entre les gens qui ne savent pas ce qu'est une distance de sécurité, ceux qui me doublent comme un sauvage quand je roule à la vitesse légale, ceux qui forcent lors d'un rétrécissement 2 voie -> une voie parfaitement fluide, sans parler des clignotants dans un rond point chargé ou de l'impréssion générale "course de dragster" dans une 2*2 voie limitée à 90 ...
La plupart des automobilistes en ont autant rien à foutre des motards que des autres automobilistes.
La question est donc quelle architecture pour ecouter 2 entrees différentes en meme temps ?
Tu à largement le choix, mais attention ! les trolls veillent ;)
Tu à le choix entre :
du poll/select() : tu leur file une liste de descripteurs de fichiers, et ce que tu veux surveiller dessus, et il te diront que par exemple, il y a des données en attente sur ton port série, et que ton read() ne bloquera pas. Ou il te diront que tu peux maintenant écrire sur le socket reliée à ton PHP ...
des pthreads : tu à simplement deux fonctions qui s'exécutent en même temps. Attention à synchroniser les deux lorsque les deux utilisent des variables/ressources partagées.
De l'asynchrone multithréadé (aio sous linux) : tu dit à ton programme "envoie ça", ça bloquera pas, mais ça sera envoyé en tache de fond, et ça t'appellera optionellement une fonction quand c'est fini. Ça à l'air simple, non ? Sauf que c'est exactement le même mécanisme pour recevoir ;)
Une machine allumée répond très bien au besoin pour le grand public.
Pour les salariés d'EDF, peut être. Pour les autres, c'est hors de prix, vu que ce n'est pas gratuit. Qui est prêt à payer un service sur Internet aujourd'hui ?
Personnellement, quand je dit à des michus que le PC doit faire un memtest pendant une journée, ça rale, non pas parce qu'il ne pourront pas utiliser le PC (vu qu'il marche pas), mais parce que ça consomme, et c'est eux qui payent.
[^] # Re: Des pistes
Posté par Batchyx . En réponse au message input overrun sur port série. Évalué à 2.
Euh, Moi dans des cas comme ça, j'aurai plutôt envie de l'activer. Même si aujourd'hui, j'imagine qu'il doit être complètement fake, entre le câble qui court-circuite des pins pour économiser des fils de cuivre et les périphs qui ne l'implémentent même pas, sans parler des périphs qui le désactivent par défaut… Il faut que le périph et le câble supportent le flow control avant de vouloir l'utiliser.
S'il était activé sur le PC et que ça passait, je vois pas en quoi le désactiver améliorera quelque chose.
Sinon, à défaut de flow control hard, essaye voir si ton périph ne supporte pas le XON/XOFF (flow control 'soft')
Sinon, je me souviens que le noyau avait implémenté un mécanisme pour éviter qu'un port série plante une machine si jamais le port série débitait tellement que le noyau ne pouvais jamais redonner la main aux applis. J'ai pas regardé depuis, mais à l'époque, j'étais obligé de patcher mon noyau si je voulais bourriner avec une vielle machine, même en 9600 baud. Si ta machine est trop chargée et que t'a pas de flow control, c'est normal que ça merde.
Mais bon, la vraie solution reste quand même d'utiliser un vrai protocole de transfert avec gestion des erreurs.
[^] # Re: Ça sent le réchauffé…
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 4.
Donc il n'y a rien pour configurer en ligne de commande.
Encore faut-il connaître, ces foutus paramètres. Sachant qu'en Wi-Fi, la méthode normale et standard pour récupérer les paramètres, c'est de regarder les informations qu'il y a dans le beacon du point d'accès/élu (Oui, tu sais la, le machin qui contient le SSID, le type de cryptage et tout le reste quand tu cherche un réseau). Et non, j'ai pas envie de sortir tshark et une interface en mode monitor pour découvrir si l'AP est en WPA 1 ou 2, avec CCMP ou TKIP et tout le reste. Oui je sais, iw et iwconfig permettent de sortir les IE en hexa, que je devrai connaître par cœur... C'est ça, ouais.
Seulement si le format du fichier de conf est naturel et logique. Avec ifconfig, je n'ai jamais besoin de regarder la doc. Mais là, sortir un fichier aussi long de ma poche, non je sais pas faire. Surtout que lorsqu'il y a une erreur de syntaxe, le message d'erreur est planqué dans syslog, et il est incompréhensible pour un humain.
De mémoire, voici ce que serait un fichier de conf wpa_supplicant, rien que pour les paramètres wifi
Et non, je n'ai pas regardé la doc. Et j'ai pas du en écrire depuis des lustres.
Non seulement la doc de NM est longue, elle est aussi nulle, parce que elle te décrit comment NM est un programme qui n'est pas fait pour être utilisé autrement que par nm-applet. Essaye de l'attaquer en D-Bus, aussi, pour voir.
Faut arrêter un peu : un /etc/network/interface pour se connecter à un réseau en clair avec iwconfig (ce qui est mal), ça doit être dix lignes. mon script wpa_supplicant, ça doit être 6 lignes. Ton machin minimal, c'est déjà 18 lignes et en plus ça marche pas.
Y a des fichiers de configs qui sont vraiment fait pour être lisibles et utilisables par des humains, et d'autre non.
Normal, y en a pas. La seule méthode d'apprentissage sur ce système, c'est de l'essai et de l'erreur (fatale). Il y a des articles sur microsoft.com, mais tu n'y comprend rien.
C'est la faute à dhclient. Et encore, essaye de le configurer pour qu'il ignore le serveur DNS du serveur et ne configure aucun DNS; C'est juste impossible avec les derniers dhclient, merci l'ISC. Et je ne parlerai pas de la non-lisibilité du code source. Ah merde, j'en ai parlé...
Et sinon, tu fait ça comment avec Network Manager ?
[^] # Re: Adresse modifiée pour le spam
Posté par Batchyx . En réponse au journal Comment je ne vais pas quitter gmail. Évalué à 0.
Et comment tu détermine ce qu'est une adresse email ? parce que
aaaaaa@example.orgpourrait très bien être un identifiant Jabber, par exemple. Sans compter le classiquemoi@babasse ~$[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 2.
Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Bien sûr que ça marche...
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Non ?
Non plus. Avahi-autoipd va directement taper sur netlink et observer les interfaces voulues en regardant si elles deviennent up ou pas. Si c'est up, on rajoute une ip. si c'est down, on l'enlève. Et si on rajoute une adresse sur la même interface ... ben avahi-autoipd s'en fout.
Pas du tout, c'est plutôt le contraire : les mécanismes d'alias sont utilisés pour rendre ifconfig compatible avec ip. Il n'y a pas si longtemps, ça n'était pas le cas, d'ou confusion pour les utilisateurs d'ifconfig, surtout avec avahi-autoipd, justement. Y avais des rapports de bug "avahi-autoipd écrase mon IP", alors que non, Internet fonctionne encore. C'est juste que ifconfig affichait seulement la première adresse IP que le noyau trouvait, et qui était, comme par hasard, l'IP link-local d'avahi. L'autre adresse n'était visible qu'avec ip.
Mauvaise configuration, changer configuration ?
Ça doit être génial pour les performances, non ?
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 2. Dernière modification le 18 février 2012 à 15:42.
Hein ? la deuxième peut très bien venir de l'autoconf; tu peux mettre autant de préfixes que tu veux dans ton RA.
Pourquoi y a t'il besoin d'avoir un mode routeur particulier dans ce cas ?
Et ces scripts "gicle l'adresse en place s'il le faut" ? ah ben non ... ils appellent avahi-autoipd, qui lui va utiliser /etc/avahi/avahi-autoipd.action au moment de configurer l'interface ... et le /etc/avahi/avahi-autoipd.action upstream ne gicle jamais les IP en place. Si quelqu'un t'a viré tes IP lorsque ton DHCP foire, c'est le script de dhclient.
Non. Tu peux très bien avoir 256 adresses sur la même interface. Et dans le même subnet. Tu peux aussi en avoir 65536, mais le noyau aime pas trop, c'est dans une liste chaînée, il me semble.
La question "avec quelle interface je sors" se pose déjà lorsqu'on à une seule adresse par interface ... Il suffit juste de regarder la bonne table de routage.
Et pour répondre à "une fois que j'ai trouvé la bonne interface, avec quelle adresse je sors si l'appli n'a pas fait de bind()", tu regarde la même table de routage, sur la même entrée, et tu regarde le champ "adresse source préférée si pas indiquée par l'application". Si tu utilise ip route, tu pourra la mettre bien comme il faut. Si tu utilise encore /sbin/route, le noyau choisira une adresse source préférée à ta place, et prendra toujours celle que tu veux pas. Et tant pis pour toi, ça sera de ta faute.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 2.
Rien n'empêche d'avoir deux adresses globales sur une même interface ...
C'est quoi un "mode routeur" ?
Si ta distro met de la merde dans ton /etc/avahi/avahi-autoipd.action, peut être. Mais celui upstream pour Linux utilise ip pour rajouter l'adresse, ou crée des alias avec ifconfig si ip n'est pas installé. Donc non.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 2.
On est en 2012. Toute interface physique à au moins une adresse IPv6 link-local, même lorsqu'on à pas de connéctivité IPv6. Lorsqu'on à une connéctivité IPv6, on à deux adresses. On peut même en avoir plus que deux si l'admin le décide. T'a vraiment envie de te panner 2 alias pour une connéctivité normale ? Oui, j'ai dit connéctivité normale, t'aura peut-être besoin des deux pour que ça marche.
avahi-autoipd c'est une blague, c'est l'équivalent des adresses link-local d'IPv6, pour IPv4. Tu peux toujours crier sur l'implémentation qu'est avahi-autoipd (l'implem, c'est du lennart, mais l'algorithme/protocole, c'est normalisé IETF), mais tu pourra pas crier longtemps sur le principe. Sache que ton linux chéri n'a pas attendu avahi-autoipd pour rajouter des adresses IPv6 link local à tes interfaces. Oui, tu en a maintenant. Il faudra vivre avec, tu en aura besoin pour récupérer des adresses globales...
[^] # Re: Ça sent le réchauffé…
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 5.
Tu à déjà essayé d'utiliser nmcli ? Réellement ?
Simple test : montre moi comment me connecter sur un réseau Wi-Fi sécurisé (paramètres exacts inconnus, sauf pour le SSID et la passphrase) avec une IPv4 fixe. En chronométrant le temps que t'a mis pour lire la doc. Parce que moi je n'ai pas lu la doc pour utiliser nm-applet, ni pour éditer /etc/network/interfaces.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 4.
C'est quoi la méthode de configuration "normale" pour IPv6 dans le monde UNIX, déjà ?
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 3.
J'ai pas envie d'endormir NetworkManager, j'ai envie qu'il arrête temporairement de toucher à une certaine interface, de manière dynamique, en continuant à utiliser les autres.
[^] # Re: Ça sent le réchauffé…
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 2.
Tout le monde n'est pas administrateur sur sa machine. Et même si tu l'est, tu n'est peut-être pas non plus tout seul à utiliser la machine.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 3.
Oui, ça résoud le problème dans ce cas ... Encore faut-il en être au courant, une option dans l'interface graphique, ça serait trop demander ?
Mais de manière générale, j'aurai bien envie d'un moyen pour dire à NetworkManager d'arrêter de toucher à une interface, parce que je vais y faire des choses en dehors de sa portée. Le problème, c'est que, généralement, ces "choses" détruisent des interfaces et en créent d'autres avec des MAC différentes ou inexistantes ...
Sauf que pour moi et pour beaucoup d'autres utilisateurs, la méthode la plus simple reste trop souvent de purger NetworkManager...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 4.
ifconfig c'est le MAL. Il faut utiliser ip maintenant. C'est d'autant plus vrai lorsque tu passera tout ton réseau en IPv6. ifconfig ne supporte pas d'avoir plusieurs adresses IP sur une interface, alors que c'est nécessaire pour avahi-autoipd. Non ça va pas rentrer en conflit avec tout le reste, Le noyau à tout prévu pour, et de manière bien (pas du Lennart); il n'avait pas le choix de toute façon, s'il ne voulait pas rendre l'utilisation d'IPv6 trop chiante. Du coup ça marche en IPv4 aussi. Que demande le peuple ?
Pareil pour route : utilisez ip route à la place, vous serez moins surpris lorsque le noyau prendra des adresses sources bizarres pour aller sur le net, en IPv4 ou en IPv6...
Après, avahi-autoipd pourrait faire autre chose que créer un alias d'interface (encore un de ces trucs vieillots) lorsqu'il se rend compte qu'un truc vieillot lui à pété toute sa conf, mais ça c'est du Lennart tout craché : "Il faut que le programme marche, que l'utilisateur le veuille ou non !".
et dhclient pourrait disparaître lorsqu'on à plus besoin de lui ... mais bon, l'ISC est trop occupé à le récrire en espérant que le code soit moins horrible, puis à le récrire pour la même raison, parce que le code est toujours aussi horrible...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 6.
Et si eth0 n'est pas spécifié explicitement, mais via un mapping (exemple : t'utilise guessnet pour faire de l'autodétéction via requête ARP. Encore l'un des trucs tout bêtes que network-manager ne supporte pas), ça continue à marcher ? Ah non. Et encore, y a pas si longtemps que ça, NetworkManager était très tatillon sur le format possible de /etc/network/interfaces, en interdisant par exemple la combinaison d'espaces et de tabs pour l'indentation ou pour séparer les options de leurs valeurs...
Et savait tu qu'avec les derniers ifupdown tu pouvait désormais splitter ton /etc/network/interfaces en plusieurs fichiers ? Ah ben non, NetworkManager le supporte pas...
[^] # Re: ...
Posté par Batchyx . En réponse au message Spécifier une interface réseau à un processus. Évalué à 3.
Pourquoi ne pas mettre simplement le VPN dans le second namespace ? comme ça y a une configuration classique sans VPN d'un coté et une configuration classique avec VPN de l'autre. Ça serait plus simple à gérer je pense.
[^] # Re: Belle déformation
Posté par Batchyx . En réponse au journal Être propriétaire d'un logiciel libre. Évalué à 3.
Dans le cas matériel c'est pareil : Pour la bouffe en tout cas, je n'ai pas le droit d'enlever l'étiquette de l'emballage, de mettre la mienne et de la revendre. Ni de revendre l'emballage avec la même étiquette mais avec un contenu différent, Ni de changer d'emballage et de revendre.
Est ce que je suis plus propriétaire de la quasi-totalité de ma bouffe ?
# Iptables + ip rule
Posté par Batchyx . En réponse au message Spécifier une interface réseau à un processus. Évalué à 5.
Il te faut une règle iptables qui va matcher tout le trafic de transmission.
Le plus simple, c'est d'exécuter tes applis qui doivent passer dans le VPN avec un utilisateur spécial, et d'utiliser le module 'owner' d'iptables. Ou d'utiliser un wrapper qui va marquer les paquets. Ou quoi que ce soit d'autre...
Pour les paquets que tu veut faire passer par ton VPN, marque tes paquets dans une chaîne OUTPUT avec
-j MARK --set-mark 0x42, par exemple. Ou avec n'importe quelle marque... Il faut être dans la table mangle pour pouvoir modifier des marques.Après, tu peux créer une table de routage spéciale qui va faire passer tout le trafic sur ton VPN, du genre
ip route add default via la_bonne_gateway_de_ton_vpn table 42. Puis créer une règle pour dire d'utiliser cette table de routage avec les paquets marqués :ip rule add type unicast fwmark 0x42 table 42. Il faudra peut-être une règle pour le retour aussi, pour dire que tes paquets qui viennent de l'interface de ton vpn utilisaient cette table de routage, sinon le reverse path filtering va jeter tes paquets parce qu'ils sont censé venir de ton interface filaire...Fin bref, ça doit être drôle à expérimenter, tout ça. Après il faudra le sécuriser ;) Le noyau linux peut faire des choses bizarre, comme répondre à une requête ARP qui concerne l'IP que tu à sur le vpn, mais depuis ton interface filaire publique. Du coup c'est facile pour un espion avec le même FAI que le tiens de te trouver s'il cherche qui est derrière le VPN...
[^] # Re: La vrai question
Posté par Batchyx . En réponse au journal Debian et le multi-arch. Évalué à 2.
À économiser de la bande passante, quand t'en a pas.
C'était la raison n°1 qui m'a fait installer une Debian x86 sur un PC qui supportait le 64bit : je voulais réutiliser les 20Go de paquets x86 du cache d'apt-proxy/cacher-ng, parce que 1Go à 60 ko/s, c'est lent.
[^] # Re: À quoi sert la standardisation?
Posté par Batchyx . En réponse au journal Le futur du langage ISO C++ : les nouvelles librairies PCL. Évalué à 3.
Ah bon ? pourquoi ?
Qu'est ce qui empêche de sérialiser vers du XML ou vers une ribambelle de formats de sérializations tout aussi bizarres les uns que les autres ?
Et de toute façon, tu peux de toute façon pas dumper un objet dans un fichier à cause de tes pointeurs... Alors autant sérialiser avec Boost::Serialization en utilisant/écrivant le backend de tes rêves.
[^] # Re: Mais pourquoi...
Posté par Batchyx . En réponse au journal Le futur du langage ISO C++ : les nouvelles librairies PCL. Évalué à 4. Dernière modification le 04 février 2012 à 20:05.
En ce que tu veux, du moment qu'il y a plusieurs implémentations par des acteurs indépendants, de telle sorte que le langage ne meure pas si un acteur principal tombe.
Si il n'y a qu'un seul acteur qui décide de la bibliothèque standard et qui lui ajoute des fonctionnalités tout les 4 matins sans que les autres puissent suivre, j'ai un peu moins confiance.
[^] # Re: Mais pourquoi...
Posté par Batchyx . En réponse au journal Le futur du langage ISO C++ : les nouvelles librairies PCL. Évalué à 7.
C'était beaucoup moins contestable lorsque Sun était en train de faire faillite et de se faire racheter par Oracle. J'ai aussi vus des articles de dev C# qui se disaient "abandonnés par microsoft" qui délaissait Silverlight et d'autres trucs, pour faire du HTML5...
Avoir un langage et des implémentations indépendantes, ça à ses avantages.
[^] # Re: Mais pourquoi...
Posté par Batchyx . En réponse au journal Le futur du langage ISO C++ : les nouvelles librairies PCL. Évalué à 5.
Quand on regarde les langages avec une grosse bibliothèque standard, on fini souvent par tomber soit sur des langages ou il n'y a qu'une seule implémentation utilisée par la majorité, soit sur un langage qui nécessite une bibliothèque ou il n'y a qu'une seule implémentation écrite dans le langage lui-même. Ça veut généralement dire que le langage n'est pas indépendant.
Aujourd'hui tu à plusieurs implémentations indépendantes et conformes de C++ et sa bibliothèque standard. J'ai pas suivi pour Java et C#, mais il me semble que au mieux il y avait deux ou trois implémentation qui tiennent la route, dont une majoritaire. Pour Python, c'est un peu mieux, parce que la bibliothèque standard est en grande partie écrite en Python, et c'est d'ailleurs quand ça l'est pas qu'on se paye les incompatibilités dans les autres implémentations.
Après il faut choisir : grosse bibliothèque ou langage durable dans le temps ?
[^] # Re: motard
Posté par Batchyx . En réponse au journal La légalisation de l'interfile : démagogie maximum. Évalué à 5.
En tant qu'automobiliste, je ne suis pas d'accord. Entre les gens qui ne savent pas ce qu'est une distance de sécurité, ceux qui me doublent comme un sauvage quand je roule à la vitesse légale, ceux qui forcent lors d'un rétrécissement 2 voie -> une voie parfaitement fluide, sans parler des clignotants dans un rond point chargé ou de l'impréssion générale "course de dragster" dans une 2*2 voie limitée à 90 ...
La plupart des automobilistes en ont autant rien à foutre des motards que des autres automobilistes.
[^] # Re: le pourquoi du signal
Posté par Batchyx . En réponse au message Signaux C PHP UID et permissions. Évalué à 3.
Tu à largement le choix, mais attention ! les trolls veillent ;)
Tu à le choix entre :
[^] # Re: IPV6, intérêts et conséquences pour le grand public
Posté par Batchyx . En réponse à la dépêche Activation mondiale de l'IPv6 (World IPv6 Launch). Évalué à 2.
Pour les salariés d'EDF, peut être. Pour les autres, c'est hors de prix, vu que ce n'est pas gratuit. Qui est prêt à payer un service sur Internet aujourd'hui ?
Personnellement, quand je dit à des michus que le PC doit faire un memtest pendant une journée, ça rale, non pas parce qu'il ne pourront pas utiliser le PC (vu qu'il marche pas), mais parce que ça consomme, et c'est eux qui payent.