Forum Linux.debian/ubuntu problème réseau étrange, fonctionne que sur certains sites

Posté par  (site web personnel, Mastodon) .
Étiquettes :
1
19
août
2010
Bonjour,

J'ai un problème des plus étranges. Depuis ce matin, j'ai des problèmes de réseau.
J'ai une carte ethernet eth0 et une carte wifi wlan0.

Quand j'allume mon pc, nm-applet se connecte et me récupère une ip pour eth ainsi que pour wlan si il trouve le réseau. une fois que c'est fait, j'ai l'impression que je peux naviguer normalement quelques instants, quoi que pas toujours…

En tout cas à un moment, j'ai une ip, des routes/passerelle normales, je ping linuxfr.org par contre impossible d'aller sur le site. Si je fais wget par exemple il se connecte et au moment de télécharger il reste à 0% (comme les bio de danone)

Chose encore plus étrange, j'ai accès à certains sites ! par exemple google marche à tous les coups (même en faisant une recherche qui est assurément pas dans le cache) de même que gmail et google actualités, j'ai trouvé aussi zdnet et reuters.fr mais pas facebook, ni linuxfr (je suppose que ce sont des sites qui sont rarement down, avec france.fr ou voyages-sncf j'aurais pu croire que c'était pas de ma faute)

Je suis très certainement pas clair du tout, mais je ne sais pas comment expliquer, tellement je trouve ça bizarre.

J'ai penché pour un problème ipv6, mais je vois pas trop en quoi, j'ai essayé de le désactiver mais cela ne change rien.

Ça le fait à partir d'au moins deux endroits, à chaque fois chez free mais avec des versions de box différentes.

Là j'ai débranché le cable, avec nm-applet j'ai désactivé/réactivé le réseau et ça fonctionne en wifi. j'avais testé de mettre une ip fixe sur eth0 mais ça marchait pas mieux.

je vais faire plus de recherches, j'ai pas pensé à désactiver la carte wifi au niveau du pc par exemple, mais je vois pas pourquoi, hier soir cela marchait, ce matin cela ne marchait plus. Au passage, j'ai deux débian sur le pc qui diffèrent très peu (un 2.6.32-5 et un 2.6.32-trunk si je ne m'amuse) et les deux font pareil.

À part une personne qui aurait spotté le même bug, je ne suis pas sûr de trouver de l'aide là comme ça, mais on sait jamais, peut-être un indice ?
Au final c'est peut-être évident, le ping marche mais pas l'accès ! rien que de l'écrire ça me trou le Q :/

en début d'après-m ça a fonctionné, je sais plus quelles bidouille j'ai fait, mais en gros j'avais fait un dhclient en console… peut-être que killer nm-applet et faire un dhclient suffit, je testerai.

Merci pour toute aide ou soutien psychologique ^^

  • # à noter que :

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    dhclient est silencieux, avant il disait un peu de blabla, du genre serveur machin t'as donné telle ip.

    redémarrer avec le wifi désactivé et eth0 en auto dans le fichier interfaces fait pareil, google debian.org fonctionnent, pas linuxfr… (avec le ping qui fonctionne)

    j'ai réactivé ma carte wifi, il s'est connecté en wifi et là j'ai du réseau.


    au cas où, un bout de syslog :
    Aug 19 01:19:10 sarah dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
    Aug 19 01:19:11 sarah kernel: [ 18.660041] eth0: mii ext = 0000.
    Aug 19 01:19:11 sarah kernel: [ 18.684033] eth0: mii lpa=41e1 adv=01e1 exp=0001.
    Aug 19 01:19:11 sarah kernel: [ 18.684038] eth0: link on 100 Mbps Full Duplex mode.
    Aug 19 01:19:11 sarah kernel: [ 18.716033] eth0: mii ext = 0000.
    Aug 19 01:19:11 sarah NetworkManager[1335]: (eth0): carrier now ON (device state 1)
    Aug 19 01:19:11 sarah kernel: [ 18.740026] eth0: mii lpa=41e1 adv=01e1 exp=0001.
    Aug 19 01:19:11 sarah kernel: [ 18.740031] eth0: link on 100 Mbps Full Duplex mode.
    Aug 19 01:19:11 sarah kernel: [ 18.740333] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Aug 19 01:19:13 sarah avahi-daemon[1254]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::290:f5ff:fe87:bcac.
    Aug 19 01:19:13 sarah avahi-daemon[1254]: New relevant interface eth0.IPv6 for mDNS.
    Aug 19 01:19:13 sarah avahi-daemon[1254]: Registering new address record for fe80::290:f5ff:fe87:bcac on eth0.*.
    Aug 19 01:19:14 sarah avahi-daemon[1254]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::290:f5ff:fe87:bcac.
    Aug 19 01:19:14 sarah avahi-daemon[1254]: Joining mDNS multicast group on interface eth0.IPv6 with address 2a01:e35:8aab:7aa0:290:f5ff:fe87:bcac.
    Aug 19 01:19:14 sarah avahi-daemon[1254]: Registering new address record for 2a01:e35:8aab:7aa0:290:f5ff:fe87:bcac on eth0.*.
    Aug 19 01:19:14 sarah avahi-daemon[1254]: Withdrawing address record for fe80::290:f5ff:fe87:bcac on eth0.
    Aug 19 01:19:15 sarah sm-notify[888]: DNS resolution of euthania failed; retrying later
    Aug 19 01:19:17 sarah dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
    Aug 19 01:19:17 sarah dhclient: DHCPOFFER from 192.168.0.1
    Aug 19 01:19:17 sarah dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
    Aug 19 01:19:17 sarah dhclient: DHCPACK from 192.168.0.1
    Aug 19 01:19:17 sarah avahi-daemon[1254]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.45.
    Aug 19 01:19:17 sarah avahi-daemon[1254]: New relevant interface eth0.IPv4 for mDNS.
    Aug 19 01:19:17 sarah avahi-daemon[1254]: Registering new address record for 192.168.0.45 on eth0.IPv4.
    Aug 19 01:19:17 sarah dhclient: bound to 192.168.0.45 -- renewal in 377783 seconds.

    • [^] # Re: à noter que :

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      j'avance un peu (pas beaucoup) dans ifconfig, j'ai ça :
      RX packets:3552 errors:1249

      mais pourquoi j'aurais des erreurs sur certains sites seulement ?

      • [^] # Re: à noter que :

        Posté par  . Évalué à 2.

        De ce que j'ai compris:
        - en wifi: tout fonctionne
        - en ethernet: comportements bizarres

        T'es relié directement à ta box ? T'as des équipements intermédiaires (switch, routeur) ?
        T'as essayé avec un autre câble ? Un autre port ethernet sur ta box ?
        Tu résous correctement les noms de domaine pour les sites qui ne fonctionnent pas ?

  • # Plus de détails

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

    Salut,

    Plus de détails serait intéressant. Tu pourrais passer un coup de sniffer au moment où tu vas sur les sites qui posent problème ?

    Il y a plein de pistes qui pourraient poser un dysfonctionnement de ce type : MTU mal choisi (bien qu'étonnant vu que tu récupères les informations depuis un DHCP censé être bien configuré -- d'autant plus qu'en wifi tu dis ne pas avoir de problème), un signe de faiblesse au niveau de la carte réseau (est-elle vieille ?), éventuellement un problème de driver au niveau du noyau ?
    Visiblement t'as un problème de paquets qui arrivent corrompus, mais je ne sais pas dans quel environnement tu es.

    Tu peux aussi essayer des pings avec une (très) grosse taille de paquet, histoire de voir si ta carte supporte des paquets plein.

    Tu peux essayer le mode half-duplex (# ethtool -s eth0 speed 10 duplex half) pour voir si ta carte ne fatiguerait pas.

    Après ce ne sont que quelques pistes, mais j'espère pouvoir t'aider.

    • [^] # Re: Plus de détails

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      je vais essayer de voir ce que cela donne avec wireshark dès que j'arrive au taf.

      Le MTU me semblait bon, je viens de revérifier et j'ai un doute (1500 pour wlan0 et 1480 pour eth0)

      la carte réseau a 1an et demi (c'est un un portable clevo) j'ai essayé avec deux noyaux différents, j'en essaierai d'autres au cas où.

      il va être l'heure que je parte au taf donc j'essaierai là-bas les gros ping et le half-duplex

  • # Quelques pistes…

    Posté par  . Évalué à 2.

    Les sites qui ne fonctionnent pas ne seraient-ils pas « https » ?

    Es-tu derrière un proxy ?

    As-tu changé de DNS ?

    As-tu essayé avec un autre navigateur ? (Actuellement je sais qu’il y a des problèmes avec Konqueror>=4.4.5 de squeeze qui se comporte mal avec les sites en « https »)

    En espérant faire avancer le schmilblick… :)

    • [^] # Re: Quelques pistes…

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Non les sites ne sont pas en https (enfin j'ai essayé les deux)
      Pas de proxy.
      J'ai essayé différents DNS ceci dit je ne pense pas que cela vienne de là vu que tous les ping sont bons.
      J'ai essayé plusieurs navigateurs oui, chromium, firefox, iceweasel et wget

      merci de votre aide à tous en tout cas ^^

  • # là ça marche

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    le message que j'ai posté tout à l'heure n'est pas passé >_< mais en dehors de ça, cela fonctionne niquel, j'ai stoppé network-manager, fait un dhclient et ça marche… Bon je touche du bois mais je ne doute pas que cela va revenir (et puis surtout c'est relou si je peux pas utiliser nm-applet)

  • # mtu

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

    finalement c'est bien un problème de mtu ! Il était à 1500, en le passant à 1492 cela fonctionne impécable, j'en reviens pas ! Je comprends pas pourquoi, ni d'où vient le bug d'ailleurs…

    En tout cas merci à tous (sauf à celui qui a moinsé évidemment ;) )

    • [^] # Re: mtu

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

      Le bug peut venir du serveur DHCP (mais j'en doute puisqu'en wifi ça marche apparemment ; d'ailleurs t'as quoi comme MTU pour le wifi ?), soit de ton client DHCP qui ne configure pas le bon MTU (merci NM ?) ou encore un MTU configuré en dur (pas bien)...

      • [^] # Re: mtu

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        le serveur dhcp, il y en a un c'est une freebox qui fonctionne très bien, l'autre c'est une debian qui fonctionne très bien, donc je ne pense pas.
        Le MTU n'est pas en dur (en tout cas je ne l'ai pas fait et je pense pas que debian le fasse ^^)

        le mtu du wifi il est à 1500 là mais je suis sur le câble donc je ne sais pas si il fonctionne faudra que je vérifie chez moi.

Suivre le flux des commentaires

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