Journal Ubuntu is magic?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
8
27
avr.
2014

Bonjour,

comme vous le savez peut être, MacOSX en sortant de veille est capable de se reconnecter instantanément au réseau WIFI.

Tout est détaillé ici:
http://cafbit.com/entry/rapid_dhcp_or_how_do

J'avais testé rapidement Kubuntu 14.04 sans vraiment faire attention mais j'avais juste remarqué qu'en repassant sous Arch, tout cela me semblait très très lent…

J'ai réinstallé Kubuntu 14.04 hier, et non je n'avais pas rêvé, à la sortie de la veille (1 seconde), le wifi est disponible et fonctionnel…

Du coup, pourquoi ça fonctionne que sous Ubuntu, Arch possède une version plus récente de NetworkManager, du coup, c'est quoi, un patch? une option non activé par défaut? Et surtout, est ce que NM utilise la même ruse que MacOSX?

Si quelqu'un sait, je suis curieux.

  • # No ARP

    Posté par  (site web personnel) . Évalué à 10.

    Essaye de rajouter "noarp" dans /etc/dhcpcd.conf.

  • # acpi, pilote reseau tout ca

    Posté par  . Évalué à 3.

    à la mise en veille et à la sortie de veille, ce sont des scripts autour de l'acpi
    qui vont (des)activer les pilotes, relancer certains scripts…

    du coup entre les distribs il peut y avoir certains scripts qui gerent ou pas certaines options.

    • [^] # Re: acpi, pilote reseau tout ca

      Posté par  (site web personnel) . Évalué à 2.

      Je suis pas vraiment convaincu, cela ne faisait pas ça sous Ubuntu 13.10 par exemple et je n'ai pas vu le comportement ailleurs. Et pourtant, faisant toujours un backup de mon /etc entre deux installations, j'avais attentivement regardé la différence avec Arch sans trouver de réponse.

  • # Hmm

    Posté par  . Évalué à 8. Dernière modification le 27 avril 2014 à 16:46.

    Du coup, pourquoi ça fonctionne que sous Ubuntu, Arch possède une version plus récente de NetworkManager, du coup, c'est quoi, un patch? une option non activé par défaut? Et surtout, est ce que NM utilise la même ruse que MacOSX?

    Il faut un chouilla plus qu'une seconde pour que le wifi reconnect (disons 2 secondes), mais chezmoicamarche(TM). Arch aussi, avec NM, et avec cette petite modification: Speed up DHCP by disabling ARP probing.

    Edit: Grillé!

    • [^] # Re: Hmm

      Posté par  (site web personnel) . Évalué à 3.

      J'ai déjà joué avec cette option et je n'ai jamais remarqué une reprise du Wifi instantanée… On doit gagné 2 secondes avec et ce serait un peut oublié le temps pour ré associer la connexion avec la borne.

    • [^] # Re: Hmm

      Posté par  (site web personnel) . Évalué à 3.

      Et je rajoute que sous Arch en configurant une ip fixe, j'avais toujours 5 secondes de reconnexion au WIFI.

  • # /etc/dhcpcd.conf sous opensuse 13.1

    Posté par  . Évalué à -2.

    Je ne trouve pas le fichier /etc/dhcpcd.conf sous opensuse 13.1, quelqu'un connait-il la manip à effecuter sur cette ditrib car c'est un peu long en effet en sortie de veille.

  • # C'est pourtant simple

    Posté par  . Évalué à 10.

    C'est juste Upstart qui marche bien mieux que systemd.

    ----------------------------------> []

  • # Patch / option

    Posté par  . Évalué à -8.

    Tu te demandes, mais tu peux aller voir toi-même comment les paquets sont construits.

  • # Attaque possible?

    Posté par  (site web personnel) . Évalué à 3.

    S'il y a reconnexion Wifi, je me demande si une attaque n'est pas possible avec :

    Une méthode consiste à utiliser aireplay-ng et son attaque -0 (déauthentication) pour forcer la déconnexion du client et capturer le handshake lorsqu'il se reconnecte (le gestionnaire de réseau wifi de windows est reglé par défaut pour se reconnecter automatiquement à un point d'accès en cas de déconnexion, l'attaque -0 exploite cette faille).

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Attaque possible?

      Posté par  . Évalué à 3.

      S'il y a reconnexion Wifi, je me demande si une attaque n'est pas possible avec :

      Ta question ici est étrange.
      Que tu te connectes automatiquement en sortant de veille ou par action manuelle, le risque ou la fenêtre d'action sont les mêmes.

  • # Sur DamnSmalLinux sous iON4 en OCAML ça...

    Posté par  . Évalué à -6.

    … je rigole. :p

    comme vous le savez peut être, MacOSX en sortant de veille est capable de se reconnecter instantanément au réseau WIFI.

    Oui je le sais, sous Debian 6-7 (non-free contrib on), Ubuntu 13.xx (clés en main) ça marche sur mes portables pour l'un équipé d'une Intel WiFi N 5300 (année 2009-2010) et pour l'autre d'une Broadcom NetXtreme BCM5761 (année 2012-2013).

    Bref t'aurais pu comparer sur une distro Linux sérieuse au lieu de te laisser impressionné par un autre OS, aussi bon qu'il est, sur son propre matos soit dit en passant.

    Après, ce sont les même fuyant Linux pour OSX parce que Manjaro ou Maegia les gonflent. À utiliser des distros mineures, remarque non-péjorative ou condescendante, avec des préoccupations différentes (!=stabilité, !=QA), il ne faut pas s'étonner.

    Après, tout n'est pas rose sous Debian ou Ubuntu mais ça, c'est nulle part le cas.

    • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

      Posté par  . Évalué à -3.

      oui bon, tu parles de Kubuntu…

      Bref, pourquoi parler d'OSX? non, ce n'est pas interdit, c'est juste que journal traite d'un problème en mélangeant pommes et poires.

      bonne nuit. :p

    • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

      Posté par  (site web personnel) . Évalué à 3.

      Ben moi sur tous les portables que j'ai vu passé en 10 ans (50? 60?), je n'ai jamais vu cela fonctionner alors ta remarque me surprend… Surtout que j'ai à peut près tout utilisé: Fedora, Debian, Ubuntu, Arch, OpenSUSE…

      Et que la dernière fois qu'il y'a eu un journal sur le sujet sur DLFP, tout le monde disait que le comportement de MacOSX c'était de la merde et que c'était normal que ce soit lent sous Linux.

      • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

        Posté par  . Évalué à -2.

        Ben moi sur tous les portables que j'ai vu passé en 10 ans (50? 60?)

        10 ans, je ne m'avancerais pas sur cet intervalle de temps car je ne m'en souviens pas, j'ai eu pendant 6ans un thinkpad T41p (Atheros) dont on sait le support excellent, après, si je ne m'en souviens pas du comportement c'est que ce n'était pas un problème. :)

        Et j'utilise toujours la gamme pro que proposent les constructeurs: "Thinkpad", "Elitebook" et autres "Latitude".

        NB: ah, en fait, je me rend compte que j'ai oublié de citer un Toshiba Satellite entrée de gamme que j'utilise en mode serveur sans écran (récup :)), il est équipé d'une Intel 3945ABG sous Debian 7 (contrib non-free on) et là aussi, pas de problème, il passe en veille la nuit et je le rallume manuellement quand j'en ai besoin, réaquisition direct du wifi.

        • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

          Posté par  (site web personnel) . Évalué à 3.

          Genre ton portable il fait pas requete DHCP quand il sort de la veille? C'est bizarre quand même ton histoire…

          C'est bien ce que fait Ubuntu là mais si j'installe n'importe quelle autre distrib sur ce portable, ce ne sera plus le cas…

          • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

            Posté par  . Évalué à -1.

            Genre ton portable il fait pas requete DHCP quand il sort de la veille? C'est bizarre quand même ton histoire…

            Bien sûr que si.
            En gros, dans le syslog apparait:

            Apr 28 00:46:25 portable81 NetworkManager[2937]: waking up and re-enabling…
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (eth0): now managed
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (eth0): bringing up device.

            Apr 28 00:46:25 portable81 NetworkManager[2937]: (eth0): preparing device.
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (eth0): deactivating device (reason 'managed') [2]
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): now managed
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): bringing up device.
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): preparing device.
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): deactivating device (reason 'managed') [2]
            ….
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): supplicant interface state: starting -> ready
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42]
            Apr 28 00:46:25 portable81 NetworkManager[2937]: (wlan0): supplicant interface state: ready -> inactive
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Auto-activating connection 'Mon SSID'.
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0) starting connection 'Auto Mon SSID'
            Apr 28 00:46:28 portable81 NetworkManager[2937]: (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled…
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started…
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled…
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting…
            Apr 28 00:46:28 portable81 NetworkManager[2937]: (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0/wireless): access point 'Auto Mon SSID' has security, but secrets are required.

            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0/wireless): connection 'Auto Mon SSID' has security, and secrets exist. No new secrets needed.
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Config: added 'ssid' value 'Mon SSID'
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Config: added 'scan_ssid' value '1'
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Config: added 'key_mgmt' value 'WPA-PSK'
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Config: added 'psk' value ''
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
            Apr 28 00:46:28 portable81 NetworkManager[2937]: Config: set interface ap_scan to 1
            Apr 28 00:46:28 portable81 NetworkManager[2937]: (wlan0): supplicant interface state: inactive -> scanning

            Apr 28 00:46:32 portable81 dhclient: Internet Systems Consortium DHCP Client 4.2.2
            Apr 28 00:46:32 portable81 dhclient: Copyright 2004-2011 Internet Systems Consortium.
            Apr 28 00:46:32 portable81 dhclient: All rights reserved.
            Apr 28 00:46:32 portable81 dhclient: For info, please visit https://www.isc.org/software/dhcp/
            Apr 28 00:46:32 portable81 dhclient:
            Apr 28 00:46:32 portable81 NetworkManager[2937]: (wlan0): DHCPv4 state changed nbi -> preinit
            Apr 28 00:46:32 portable81 dhclient: Listening on LPF/wlan0/00:21:de:ad:be:ef
            Apr 28 00:46:32 portable81 dhclient: Sending on LPF/wlan0/00:21:de:ad:be:ef
            Apr 28 00:46:32 portable81 dhclient: Sending on Socket/fallback
            Apr 28 00:46:32 portable81 dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
            Apr 28 00:46:32 portable81 dhclient: DHCPACK from 192.168.10.254
            Apr 28 00:46:32 portable81 NetworkManager[2937]: (wlan0): DHCPv4 state changed preinit -> reboot
            Apr 28 00:46:32 portable81 NetworkManager[2937]: address 192.168.10.128
            Apr 28 00:46:32 portable81 dhclient: bound to 192.168.10.128—renewal in 18349 seconds.
            Apr 28 00:46:32 portable81 NetworkManager[2937]: prefix 24 (255.255.255.0)
            Apr 28 00:46:32 portable81 NetworkManager[2937]: gateway 192.168.10.254
            Apr 28 00:46:32 portable81 NetworkManager[2937]: hostname 'portable81'
            Apr 28 00:46:32 portable81 NetworkManager[2937]: nameserver '192.168.10.254'
            Apr 28 00:46:32 portable81 NetworkManager[2937]: nameserver '208.67.222.222'
            Apr 28 00:46:32 portable81 NetworkManager[2937]: domain name 'casal.lan'
            Apr 28 00:46:32 portable81 NetworkManager[2937]: Activation (wlan0) Stage 5 of 5 (IPv4 Configure Commit) scheduled…
            Apr 28 00:46:32 portable81 NetworkManager[2937]: Activation (wlan0) Stage 5 of 5 (IPv4 Commit) started…
            Apr 28 00:46:32 portable81 avahi-daemon[2892]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.10.128.
            Apr 28 00:46:32 portable81 avahi-daemon[2892]: New relevant interface wlan0.IPv4 for mDNS.
            Apr 28 00:46:32 portable81 avahi-daemon[2892]: Registering new address record for 192.168.10.128 on wlan0.IPv4.
            Apr 28 00:46:33 portable81 NetworkManager[2937]: (wlan0): device state change: ip-config -> activated (reason 'none') [70 100 0]
            Apr 28 00:46:33 portable81 NetworkManager[2937]: Policy set 'Auto Mon SSID' (wlan0) as default for IPv4 routing and DNS.
            Apr 28 00:46:33 portable81 NetworkManager[2937]: Activation (wlan0) successful, device activated.
            Apr 28 00:46:33 portable81 NetworkManager[2937]: Activation (wlan0) Stage 5 of 5 (IPv4 Commit) complete.

            etc…

            Bref, je reçois mon IP après 4 secondes, j'ai pas encore fini de taper mon mot de passe pendant ce temps. :)

            Je n'ai aucun intérêt à vous barratiner, d'autant que vous connaissez ma position, ou pouvez en prendre connaissance en lisant mes précédents messages, enjoliver le libre, très peu pour moi.

            Ah oui:

            Distributor ID: Debian
            Description: Debian GNU/Linux 7.4 (wheezy)
            Release: 7.4
            Codename: wheezy

            • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

              Posté par  (site web personnel) . Évalué à 6.

              Apr 28 00:46:25 portable81 NetworkManager[2937]: waking up and re-enabling…
              Apr 28 00:46:32 portable81 NetworkManager[2937]: address 192.168.10.128

              J'aime bien comment on passe de 1 seconde à 7 secondes… 7 secondes merci, c'est le comportement que j'ai toujours connu…

              • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

                Posté par  . Évalué à -2.

                J'aime bien comment on passe de 1 seconde à 7 secondes… 7 secondes merci, c'est le comportement que j'ai toujours connu…

                Était-ce sarcastique?
                1) Je n'ai pas parlé d'1 seconde,
                2) 7 secondes me semblent plus que raisonnable. Je fini à peine de taper mon mot de passe et de rejoindre le bureau.

                Je n'ai tout simplement pas compris votre délire.

                • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

                  Posté par  . Évalué à 6.

                  La question n'est pas de savoir si c'est raisonnable ou pas mais pourquoi une distribution arrive à le faire en une seconde alors qu'une autre (avec plus ou moins les mêmes versions) met 5 fois plus de temps sur le même matériel.

                  « 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

                • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

                  Posté par  (site web personnel) . Évalué à 2.

                  Moi sur mon laptop, je ne "lock" pas la session à la sortie de la veille et sous Arch, quand j'avais Firefox ouvert, à chaque fois je me retrouver avec un "Erreur de connexion" en voulant ouvrir une page parce que le wifi n'était pas encore reconnecté.

                  Avec Kubuntu, c'est beaucoup mieux. Ok, c'est pas grand chose 7 secondes mais j'avoue que c'est quand même plus confortable.

                • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

                  Posté par  . Évalué à 2.

                  2) 7 secondes me semblent plus que raisonnable. Je fini à peine de taper mon mot de passe et de rejoindre le bureau.

                  7 secondes pour taper un mot de passe, c'est pas très rapide. Je dois taper le mien en trois secondes au plus.

                  Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

                    Posté par  . Évalué à 2. Dernière modification le 02 mai 2014 à 09:47.

                    Ouh le mauvais avec son mot de passe non sécurisé.

                    « 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

                    • [^] # Re: Sur DamnSmalLinux sous iON4 en OCAML ça...

                      Posté par  . Évalué à 3.

                      Bah une dizaine de caractères (minuscules, capitales, chiffres et caractères spéciaux) pour un mot de passe local c’est quand même pas trop mauvais niveau sécurité je pense.

                      Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.