Alors que je lisais tranquillement lwn qui parle de pleins de trucs intéressants liés au réseau sous linux, je suis tombé sur l'arrière train.
Il y a des problèmes aujourd'hui avec la mobilité dans le réseau. En gros, tant que le réseau est filaire, stable et qu'il n'y a pas d'inconnu, alors ça roxe et linux mérite bien son nom de bien mérité de "networking OS platinium gold" (ah, on me dit qu'on n'a toujours pas donné ce nom, c'est pas grave, continuons).
Dans la mobilité, ça chie dans la colle. En gros, pas moyen de savoir si on est connecté. Cas typique, vous êtes associé en wifi, mais le wifi sort pas, ou bien il y a un problème d'authent. Et là, les applis derrière qui veulent ouvrir leurs chaussettes TCP, eh bah [:bim] dans ta face.
Ensuite, lorsqu'on perd le réseau puis qu'on le retrouve, toutes les applications veulent se reconnecter, et patatras le bottleneck dans tes dents. Lorsqu'en plus tu as par malheur changé de timezone entretemps (on parle de mobilité, hein), eh bah pleins de trucs peuvent devenir catastrophique (oh la synchro de l'agenda qui droppe tout car les données du serveur sont plus récentes…).
Enfin, on ne sait jamais trop ou on se connecte, et on a pas envie que toutes les applis parlent tout le temps, genre dans le wifi de la boîte ou bien lorsqu'on est chez Marcel, le cyber cafetier avec un killerhacker du nom de Kevin à côté. Vous me direz firewall, mais bon actuellement il faut tout droppper pour recharger des règles ce qui laisse un gap pour un attaquant.
Bref, c'est le bronx, mais heureusement qu'il y a Marcel Holtmann (non, c'est son vrai nom) qui travaillent dessus pour que ça devienne mieux.
Le détail qui a toute son importance? Je le laisse en anglais, nous sommes trolldi:
To summarize the talk, there is a lot of work to be done to provide the best mobile networking experience with Linux. Happily, that work is being done and the pieces are falling into place. Lest anybody think that there will be nothing for anybody to complain about, though, it is worth noting an admonition that Marcel saved for the very end of the talk: in the future, the use of systemd and control groups will be mandatory to get good mobile networking with Linux.
# Tiens ça me rappelle un bug amusant
Posté par reno . Évalué à 8.
Zebra (l’ancêtre de Quagga) qui envoyait ses notifications de routes en utilisant un timer non-monotonique:
un retour en arrière dans le temps --> plus d'avertissement des routes --> plus de réseau --> bug report pour moi!
Il m'a fallu un certain temps pour comprendre l’enchaînement des évènements..
Sinon pour parler du (bon) article, c'est clair que passer d'un environnement stable et maîtrisé par un admin à un environnement dynamique où c'est le système qui doit se défendre de manière autonome, c'est très difficile.
En plus l'admin qui est dans l'environnement stable quand il va se prendre les bugs du code ajouté pour gérer l'environnement dynamique il ne va pas aimer..
# Re: et le trolldi d'aujourd'hui est à?
Posté par Gof (site web personnel) . Évalué à 7.
Rien à voir avec Linux… C'est purement un bug dans ton application d'agenda.
Oui, mais c'est normal: c'est au applications d'essayer de se connecter pour savoir si oui ou non le serveur qu'on veux joindre est joignable.
[^] # Re: et le trolldi d'aujourd'hui est à?
Posté par reno . Évalué à -4.
Pas tout à fait: le sous-système de gestion du temps devrait être plus robuste.
Hum, plutôt que d'avoir N-applications qui interrogent leur serveurs en permanence, je pense qu'il vaut mieux une application de supervision qui ping en permanence et que les applications elles utilisent des timers plus long.
[^] # Re: et le trolldi d'aujourd'hui est à?
Posté par Gof (site web personnel) . Évalué à 10.
Je suis pas d'accord. En quoi devrait-il être plus robuste ?
Si l'application utilise le temps local au lieu du temps UTC, c'est un bug de l'appli.
Si l'application ne réagis pas correctement aux changement d'horloges, c'est un bug de l'appli.
[^] # Re: et le trolldi d'aujourd'hui est à?
Posté par reno . Évalué à 6.
A la réflexion, je suis d'accord, l'article parle d'un problème de timezone induisant une erreur de synchronisation mais les applications ne devraient pas prendre en compte la timezone (à part pour l'affichage).
[^] # Re: et le trolldi d'aujourd'hui est à?
Posté par BAud (site web personnel) . Évalué à 3.
exactement et il y a de quoi faire avec ISO_8601 (yaura bien le bug de l'an 10000, mais je devrais être à la retraite depuis quelque temps).
[^] # Re: et le trolldi d'aujourd'hui est à?
Posté par neil . Évalué à 2.
Oui, comme ça dès que l’application de supervision retrouve le réseau,
:-) On peut toujours faire en sorte que le superviseur envoie des messages à des temps différents, pour retrouver le comportement normal où chaque application à un ping avec un timer différent, et donc déjà un bottleneck moindre.
Sans compter qu’on peut vouloir se connecter à différents services au travers de différents réseaux (genre deux interfaces, ou des VPNs). Et là, le superviseur qui ne checke qu’un seul serveur va dire que tout est down alors qu’une partie des applications pouvaient se reconnecter. On peut toujours faire en sorte que le superviseur vérifie différentes interfaces/VPNs, pour retrouver le comportement normal où …
En gros le seul intérêt de rajouter un superviseur c’est de créer des emplois en sécurité informatique. Mais c’est déjà pas mal.
[^] # Re: et le trolldi d'aujourd'hui est à?
Posté par Batchyx . Évalué à 6.
Ou sinon, on pourrai juste, pour une fois, respecter le modèle OSI et introduire une couche session qui permettrai aux application de se faire déconnecter sans perdre la session, et de se reconnecter sans devoir créer une nouvelle session avec tout l'overhead qui va avec. Si ça pouvait rendre les déconnexions moins catastrophiques aussi …
toute façon la mobilité, c'est comme IPv6, tout le monde trouve ça bien sur le réseau du voisin.
# Systemd powaaaa !
Posté par liberforce (site web personnel) . Évalué à 10.
Je songe à acheter un casque et un gilet pare-balles pour pouvoir continuer de fréquenter LinuxFR en toute sécurité la semaine prochaine.
[^] # Re: Systemd powaaaa !
Posté par Maclag . Évalué à 7.
Mais non voyons. La dépendance à systemd, c'est la couleuvre facile à avaler.
Le plus dur, ce sera quand il faudra avouer que ça dépend aussi de la moitié des outils Gnome, et que certains ne s'installent pas si le système a déjà trop de fonctionnalités.
Sérieusement, où est le problème là-dedans?
On a déjà dit que systemd, si les admins n'en veulent pas, et ben c'est pas grave. Je ne vois pas en quoi ceci change la donne.
Où alors faudra que vous m'expliquiez ce que vous foutez avec vos serveurs pour qu'ils aient besoin d'un bon support de la mobilité réseau…
[^] # Re: Systemd powaaaa !
Posté par Adrien . Évalué à 5.
Ça tombe bien les admins veulent de systemd, pour tout un tas de raison. Tu m'excuseras de faire le même raccourci que toi et de généraliser à outrance les « admins ».
# Précision
Posté par be_root . Évalué à 1.
Le tien ?
Il se prend pour Napoléon, son état empire.
# C'est tout ?
Posté par mum1989 . Évalué à 5.
J'en ai un meilleur :
ubuntu-spyware-what-to-do
Copyright 2012 Richard Stallman
Released under the Creative Commons Attribution Noderivatives 3.0 license
[^] # Re: C'est tout ?
Posté par navaati . Évalué à 1.
« and the Amazon "Kindle" product for virtual book burning » Hahaha :D.
# Tout va très bien madame la Marquise
Posté par Kaane . Évalué à 10.
En gros, pas moyen de savoir si on est connecté
Si c'est assez facile (enfin sauf avec systemd qui autorise toutes les connexions TCP de base avant de dire
pardonva te faire un peu plus tard). La carte réseau sait de base si le layer 2 est OK (toute seule comme une grande) ensuite en une commande arp et une commande TCP on peut savoir comment et ou on est connecté, si il y a l'internet derrière, si la route est stable etc.Cas typique, vous êtes associé en wifi, mais le wifi sort pas, ou bien il y a un problème d'authent
Une fois de plus on sait faire (un arping par exemple sur un réseau avec plus d'une machine - ou même une bête trame icmp qui ne renverra pas la même erreur suivant que le réseau soit inaccessible ou introuvable) mais on ne fait pas car le gain est minime (enfin sauf networkd qui ne sait pas faire mais qui fait quand même parce que bon c'est trop cool de créer des dizaines d'entrées dans IPTables pour se vautrer au final)
Ensuite, lorsqu'on perd le réseau puis qu'on le retrouve, toutes les applications veulent se reconnecter, et patatras le bottleneck dans tes dents.
Alors à part un très gros serveur avec une masse de client et un admin facétieux qui s'amuse à débrancher et rebrancher le switch de distribution "pour rire" je vois pas. J'ai un (petit) pandaboard capable d'ouvrir plusieurs centaines de connexion TCP par seconde. Bon c'est vrai que Firefox a un peu tendance à bourriner en cas de reconnexion. Mais c'est plus un problème du logiciel Firefox que de Linux (genre lancer d'abord une petite dizaine de demandes de reconnexions avant de passer en mode berserk ca serait mieux). Dans la plupart des cas c'est juste que le programme devrait envoyer quelques demandes TCP avant d'estimer que là c'est bon le tuyeau est ouvert et qu'il peut se lacher (enfin sauf pulseaudio qui massacre déjà tellement la latence son avec son archi chaotique que si en plus il devait faire des tests avant d'ouvrir les trombes de connexions dont il a besoin on écouterait sa musique en morse)
Lorsqu'en plus tu as par malheur changé de timezone entretemps
Déjà évoqué plusieurs fois : il faut bosser en UTC - et un Linux bien installé travaille en UTC même si l'heure du bios est forcée sur Trinidad et Tobago. Les protocoles eux mêmes ne sont généralement pas sensibles à la référence de temps - excepté mDNS qui sur certaines implémentations par des fabricants par très malins peut avoir tendance à s'appuyer sur l'heure locale affichée pour générer des clefs de sécurité. Fort heureusement mDNS est un protocole local ce qui limite grandement la casse (enfin sauf avec Avahi qui possède une implémentation "reflector" qui permet de router un protocole non routable entre plusieurs réseaux qui ont éventuellement des timezones différentes - fou-rires assurés)
Vous me direz firewall, mais bon actuellement il faut tout droppper pour recharger des règles ce qui laisse un gap pour un attaquant.
Si tu connais déjà tes règles tu peux les ajouter et flagguer ta connexion elle même (genre écrire des règles de type - si je suis sur le réseau de José alors laisser passer tel type de connexion) Je l'ai fait quelquefois (avant de décider que définitivement IPTables c'était trop chiant à configurer pour moi) je le fais encore sous FreeBSD/OpenBSD en quelques lignes avec pf. Ca marche depuis des années sous Linux et plutôt bien (enfin sauf encore si vous avez networkd - là on ne peut plus rien pour vous et le département d'état tralala tsoin tsoin).
Donc non pas de vrai problème de mobilité avec Linux.
# DIY
Posté par 2PetitsVerres . Évalué à -1.
Tu veux la même chose sans systemd ? Rien de plus simple. Suffit de lire le titre de mon commentaire.
;-)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: DIY
Posté par Jean Canazzi . Évalué à 7. Dernière modification le 10 décembre 2012 à 09:11.
J'ai lu le titre de ton commentaire et il ne se passe rien, dois-je rebooter ? Cordialement.
# Cas d'un réseau pourri.
Posté par Grunt . Évalué à 5.
Pour compliquer les choses, on peut aussi se retrouver avec un réseau qui semble fonctionner (du point de vue de l'OS), mais est en fait volontairement défectueux : portail captif, réseau filtré, pas d'IPv6..
Du coup, il n'y a pas vraiment de solution miracle : quand bien même l'OS pourrait croire qu'un accès à Internet est disponible (connection établie, route par défaut en place, DNS joignables..) ce n'est pas forcément le cas.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Cas d'un réseau pourri.
Posté par claudex . Évalué à 6.
Ce qui se fait avec Windows et Android, c'est de pinguer un serveur distant (respectivement ceux de MS et ceux de Google) pour vérifier que l'accès est bien possible. Ça fait reposer la connectivité réseau sur des serveurs tiers mais on peut tout à fait imaginer un service comparable configurable et c'est bien pratique pour afficher une connectivité Internet ou non.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.