Forum Linux.débutant Défaut d'accès réseau filaire en changeant de LAN

Posté par balzane le 15 septembre 2009 à 13:22.

Étiquettes :

sept.

2009

Bonjour,

L'interface réseau filaire (eth0) de ma Debian unstable est configurée sur une IP statique pour l'utilisation sur mon lan.

Mon fichier /etc/network/interfaces est le suivant :

auto lo

iface lo inet loopback



# The primary network interface

allow-hotplug eth0

auto eth0



iface eth0 inet static

address 192.168.50.12

netmask 255.255.255.0

gateway 192.168.50.1



#iface eth0 inet dhcp

(La ligne DHCP commentée est là suite à mes essais infructueux).

route me renvoie

Table de routage IP du noyau

Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface

192.168.50.0    *               255.255.255.0   U     0      0        0 eth0

link-local      *               255.255.0.0     U     1000   0        0 eth0

default         tux-server      0.0.0.0         UG    0      0        0 eth0

Le nom d'hôte tux-server correspond à 192.168.50.1, défini dans /etc/hosts.

Je suis sur un autre réseau domestique derrière un routeur dont l'IP est 192.168.50.1, donc la même que celle de ma passerelle habituelle. L'IP 192.168.50.12 n'est pas attribuée à une autre machine du réseau.
Je n'arrive pas :
- à pinguer le routeur
- à pinguer une autre machine du lan
- à pinguer ma machine depuis une autre machine du lan
- à récupérer une adresse IP par DHCP en modifiant commentant la configuration statique sur eth0, dé-commentant la config d'eth0 en DHCP, et relançant le réseau par un /etc/init.d/networking restart :

Reconfiguring network interfaces...RTNETLINK answers: No such process

Internet Systems Consortium DHCP Client V3.1.2p1

Copyright 2004-2009 Internet Systems Consortium.

All rights reserved.

For info, please visit http://www.isc.org/sw/dhcp/



Listening on LPF/eth0/00:0b:97:a0:bc:1f

Sending on   LPF/eth0/00:0b:97:a0:bc:1f

Sending on   Socket/fallback

DHCPRELEASE on eth0 to 192.168.50.1 port 67

send_packet: Network is unreachable

send_packet: please consult README file regarding broadcast address.

Internet Systems Consortium DHCP Client V3.1.2p1

Copyright 2004-2009 Internet Systems Consortium.

All rights reserved.

For info, please visit http://www.isc.org/sw/dhcp/



Listening on LPF/eth0/00:0b:97:a0:bc:1f

Sending on   LPF/eth0/00:0b:97:a0:bc:1f

Sending on   Socket/fallback

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14

No DHCPOFFERS received.

No working leases in persistent database - sleeping.

mount error(113): No route to host

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

done.

(L'erreur de montage vient de l'absence du NAS, je ne pense pas qu'elle influe sur mes soucis de réseau).

Là où je ne comprends vraiment pas, c'est que l'interface réseau du XP installé en dual boot sur mon portable utilise les mêmes paramètres. Aucun souci pour pinguer le routeur et accéder à Internet.

Auriez-vous une idée de ce qui cloche ou de ce que je dois modifier dans cette configuration afin de pouvoir accéder au LAN parce que là je sèche un peu complétement.

Merci beaucoup.

# Arp?

Posté par maxix le 15 septembre 2009 à 14:43. Évalué à 3.

Un problème de cache arp peut être, si tu saute de réseau en réseau rapidement?

Je dis aussi ça parce que ça m'est souvent arrivé : retire le bout de papier qui traine au fond de la prise ethernet.

Truc intéressant selon le driver de ta carte réseau :
http://forum.ubuntu-fr.org/viewtopic.php?pid=342044#p342044
- [^] # Re: Arp?
  
  Posté par NeoX le 15 septembre 2009 à 15:49. Évalué à 3.
  
  en effet, ta machine a du conservé l'association
  
  192.168.50.1 => mac address : 00.11.22.33.44.55
  
  hors si l'ip reste la meme entre les 2 passerelles, la mac address elle a changée
  
  man arp
  doit pouvoir te donner une option pour "purger" le cache
  - [^] # Re: Arp?
    
    Posté par balzane le 15 septembre 2009 à 16:28. Évalué à 1.
    
    Merci pour la piste, elle permet d'éliminer la mise en cause du cache ARP : le fichier /proc/net/arp est vide, est les commandes arp -d 192.168.50.1 et arp -d tux-server me retournent Pas d'entrée ARP pour 192.168.50.1, resp. tux-server.
    
    Le déchargement /rechargement du pilote r8169 du noyau suivi d'un /etc/init.d/networking start ne fonctionne pas non plus.
    - [^] # Re: Arp?
      
      Posté par nono14 (site web personnel) le 15 septembre 2009 à 16:58. Évalué à 1.
      
      Tu captes des trames avec un tcpdump ?
      Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
      - [^] # Re: Arp?
        
        Posté par balzane le 15 septembre 2009 à 19:52. Évalué à 1.
        
        Ci-dessous le résultat du tcpdump pendant une tentative de ping de la passerelle.
        
        tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 17:26:40.259468 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28 17:26:41.259467 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28 17:26:42.259469 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28 17:26:43.275497 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28 17:26:44.275465 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28 17:26:45.275471 ARP, Request who-has 192.168.50.1 tell cf51.[...].homeip.net, length 28 ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel
        
        Si je lis bien, la passerelle ne renvoie pas de réponse... ou la réponse n'arrive pas.
        L'envoi de la requête en utilisant le nom d'hôte de la machine et non son IP est-il la cause de cette absence de réponse, ma machine n'étant pas dans le domaine [...].homeip.net. Si oui, la solution est-elle simplement de commenter la ligne
        192.168.50.12 cf51.[...].homeip.net
        dans le fichier /etc/hosts ?
        
        [^] # Re: Arp?
        
        Posté par balzane le 15 septembre 2009 à 20:06. Évalué à 1.
        
        L'envoi de la requête en utilisant le nom d'hôte de la machine et non son IP est-il la cause de cette absence de réponse, ma machine n'étant pas dans le domaine [...].homeip.net. Si oui, la solution est-elle simplement de commenter la ligne 192.168.50.12 cf51.[...].homeip.net dans le fichier /etc/hosts ?
        
        Heu, j'ai dit une connerie là, non ? La réponse est envoyée vers l'adresse MAC à l'origine de la requête ?
        
        [^] # Re: Arp?
        
        Posté par benoar le 15 septembre 2009 à 20:53. Évalué à 2.
        
        Tcpdump t'affiche le nom car c'est lui qui fait la requête DNS. Ça ne vient pas de ping ou de la requête ARP (qui est toujours faite avec une IP et pas un nom).
        
        [^] # Re: Arp?
        
        Posté par nono14 (site web personnel) le 15 septembre 2009 à 20:08. Évalué à 1.
        
        Aucun rapport, d'après le dump tu envoie des trames mais ne recoit rien.
        
        Le lien est down, le cable ethernet hs ou la carte en reception seulement ???
        
        arping pour tester, aussi ethtool ou miidiag comme souligné plus bas.
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
    - [^] # Re: Arp?
      
      Posté par NeoX le 15 septembre 2009 à 18:29. Évalué à 3.
      
      arp -an
      pour voir le contenu du cache arp
      
      arp -d 192.168.50.1
      pour effacer l'entrée correspondant à cette IP
      - [^] # Re: Arp?
        
        Posté par balzane le 15 septembre 2009 à 20:01. Évalué à 1.
        
        J'avais bien purgé le cache suite à ton commentaire précédent.
        Après mes nouvelles tentatives, arp -an me renvoie :
        ? (192.168.50.1) at [incomplete] on eth0
        Tu avais raison, le problème semble bien se situer au niveau d'ARP, mais pas au niveau cache.
        
        * Incomplete est entre < et >, et semble trop ressembler à une balise html pour passer tel quel.
        
        [^] # Re: Arp?
        
        Posté par nono14 (site web personnel) le 15 septembre 2009 à 20:25. Évalué à 2.
        
        ip neigh show
        
        Ta machine n'obtient pas l'addresse mac de la passerelle.
        Essaie en la mettant en dur pour tester.
        Sinon, c'est sent le bug côté passerelle.
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
        
        [^] # Re: Arp?
        
        Posté par nono14 (site web personnel) le 15 septembre 2009 à 20:26. Évalué à 2.
        
        keskonrix:~# ip neigh show
        192.168.0.254 dev wifi lladdr 00:07:cb:36:ab:f5 REACHABLE
        
        Reachable la passerelle est joignable
        CQFD
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
        
        [^] # Re: Arp?
        
        Posté par nicolasi le 15 septembre 2009 à 20:48. Évalué à 1.
        
        Ca, on dirait que c'est ton réseau WIFI en 192.168.0 pas ton LAN en 192.168.50.
        Est-ce que tu pourrais envoyer tout ton fichier "interfaces" complet ainsi que le résultat de la commande "ip addr show"
        
        [^] # Re: Arp?
        
        Posté par nono14 (site web personnel) le 15 septembre 2009 à 20:54. Évalué à 1.
        
        Tu as zappé une ligne, ce n'est qu'un exemple.
        
        No soucis.
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
        
        [^] # Re: Arp?
        
        Posté par balzane le 16 septembre 2009 à 00:26. Évalué à 2.
        
        Bonsoir,
        
        J'ai forcé avec la MAC du routeur :
        arp -s 192.168.50.1 MA:C:du:r:ou:te:ur
        
        du coup, ip neigh show me retourne
        192.168.50.1 dev eth0 lladdr MA:C:du:r:ou:te:ur
        
        Mais le routeur ne réponde toujours pas à mes pings, et impossible d'accèder à son interface de gestion.
        :(
        
        [^] # Re: Arp?
        
        Posté par nono14 (site web personnel) le 16 septembre 2009 à 00:38. Évalué à 1.
        
        arping @Macrouteur fonctionne?
        
        A partir d'une autre machine ça donne quoi ?
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# ethtool

Posté par nicolasi le 15 septembre 2009 à 18:10. Évalué à 2.

Salut,

Qu'est-ce que te renvoie la commande:
ethtool eth0
- [^] # Re: ethtool
  
  Posté par balzane le 15 septembre 2009 à 19:53. Évalué à 1.
  
  cf51:/home/balzane# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes
  - [^] # Re: ethtool
    
    Posté par nicolasi le 15 septembre 2009 à 21:36. Évalué à 2.
    
    bon, ça me parait bien si ton routeur est lui aussi en 100 full
    Est-ce que tu peux regarder les erreurs (ip -s link)
    - [^] # Re: ethtool
      
      Posté par balzane le 15 septembre 2009 à 23:55. Évalué à 2.
      
      Voilà :
      cf51:/home/balzane# ip -s link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped overrun mcast 8010 112 0 0 0 0 TX: bytes packets errors dropped carrier collsns 8010 112 0 0 0 0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0b:97:a0:bc:1f brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 5589 41 0 0 0 0 TX: bytes packets errors dropped carrier collsns 42700 337 0 0 0 0 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 00:12:f0:49:b0:2b brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 7190 44 0 0 0 0
      - [^] # Re: ethtool
        
        Posté par nicolasi le 16 septembre 2009 à 00:07. Évalué à 1.
        
        Je vois que t as une 2nde interface eth.
        Est-ce qu'elle est utilisée pour autre chose?
        Est-ce que tu peux passer sur eth1?
        
        [^] # Re: ethtool
        
        Posté par balzane le 16 septembre 2009 à 00:20. Évalué à 2.
        
        C'est mon interface wifi.
        Pour tester en filaire, c'est moyen ;-)
        
        [^] # Re: ethtool
        
        Posté par nicolasi le 16 septembre 2009 à 00:27. Évalué à 2.
        
        ah d'accord :)
        Par contre, on voit que tu reçois des trucs sur eth0, est-ce que tu peux laisser traîner le tcpdump un peu plus longtemps pour voir ce que c'est?
        
        [^] # Re: ethtool
        
        Posté par balzane le 16 septembre 2009 à 18:23. Évalué à 2.
        
        Un tcpdump un peu plus long : http://linuxfr.org/comments/1066041.html#1066041.
# A quoi correspond la route vers link-local ?

Posté par benoar le 15 septembre 2009 à 20:57. Évalué à 2.

Tout est dans le titre. Je trouve bizarre cette route, elle ne devrait pas être là.
Tu peux aussi filer le contenu de ton /etc/hosts, ça nous aidera à décrypter les noms de machines.
- [^] # Re: A quoi correspond la route vers link-local ?
  
  Posté par NeoX le 15 septembre 2009 à 23:30. Évalué à 2.
  
  chez moi ca donne ca :
  
  ~$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 1 0 0 eth0 link-local * 255.255.0.0 U 1000 0 0 eth0 default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
  ~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
  
  link-local serait donc le reseau 169.254....
  qui est géré par avahi si je ne me trompes pas
  (reseau zeroconf, avahi, bonjour, il porte plusieurs nom suivant le fournisseur)
  - [^] # Re: A quoi correspond la route vers link-local ?
    
    Posté par benoar le 16 septembre 2009 à 05:20. Évalué à 2.
    
    Ha oui, c'est bien ça. C'est sur quel distro qu'il configure ça comme ça ? Je n'avais encore jamais vu de conf "par défaut" (je suppose) avec deux IPs (qui dans ce cas sont bien pratique, je veux dire, la route mise par avahi permet de communiquer avec les machines qui auraient du mal avec le DHCP ... ça me fait penser à la conf IPv6 : une adresse link-local, et une adresse publique).
- [^] # Re: A quoi correspond la route vers link-local ?
  
  Posté par balzane le 15 septembre 2009 à 23:48. Évalué à 1.
  
  Chez moi c'est un peu pareil :
  route
  Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.50.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1000 0 0 eth0 default 192.168.50.1 0.0.0.0 UG 0 0 0 eth0
  route -n
  Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 0.0.0.0 192.168.50.1 0.0.0.0 UG 0 0 0 eth0
  /etc/hosts
  127.0.0.1 cf51.[...].homeip.net localhost.[...].homeip.net cf51 localhost #127.0.1.1 cf51.[...].homeip.net cf51 192.168.50.12 cf51.[...].homeip.net cf51 # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts #Local network 192.168.50.1 tux-server
  - [^] # Re: A quoi correspond la route vers link-local ?
    
    Posté par benoar le 16 septembre 2009 à 05:21. Évalué à 2.
    
    Bon, comme c'est pareil que NeoX, je suppose que c'est normal. En tous cas je préfère largement la version sans résolution de nom, c'est plus clair (mais le mieux serait "ip route" ;-))
# On sais jamais...

Posté par maxix le 16 septembre 2009 à 03:08. Évalué à 2.

Tu a essayé de rebooter la passerelle ? Est tu sur de sa configuration?

Tu est VRAIMENT sur que ça marche sur le même pc avec un autre OS? (sans bidouiller la prise)
Il n'a pas de firewall qui pourrait gêner la communication?

Est ce que ca le fait avec un autre noyau? Ta debian est a jour?

Est ce que tu pourrais faire un tcpdump sur la passerelle? (on peut toujours espérer !)
- [^] # Re: On sais jamais...
  
  Posté par benoar le 16 septembre 2009 à 05:24. Évalué à 2.
  
  Ha oui, le coup du firewall, c'est pas la première fois que je vois ça.
  Un coup de :
  iptables -F ; iptables -t nat -F iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT; iptables -P FORWARD ACCEPT
  (bon je fais pas le pre/post-routing, mais bon si tes règles sont niquées à ce point là c'est qu'il y a un gros problème)
  - [^] # Re: On sais jamais...
    
    Posté par nono14 (site web personnel) le 16 septembre 2009 à 12:10. Évalué à 1.
    
    En laissant, un tcpdump assez longtemps, on devrait voir des trames arp firewall ou non ?
    Encore plus tordu, il y a du filtrage niveau 2 ( ebtables )
    
    iptables -L -nv
    iptables -t nat
    
    Ou pire ipsec est peut etre activé ? cad tout traffic non chiffré ne passe pas
    
    setkey -DP
    
    Conseil fait un tcpdump avec l'option -n ( tu n'as pas de resolution dns )
    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
  - [^] # Re: On sais jamais...
    
    Posté par nono14 (site web personnel) le 16 septembre 2009 à 12:24. Évalué à 1.
    
    On verrait au moins les trames de niveau 2, si un firewall etait actif, non ?
    
    iptables -L -nv
    iptables -L -nv -t nat
    
    Ipsec:
    setkey -DP
    
    Filtrage niveau 2: ?
    ebtables
    
    Si tu fais un tcpdump joute l'option -n pour oter les requetes dns...
    
    Installe arping pour avoir un outil qui permet de tester la couche 2
    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
    - [^] # Re: On sais jamais...
      
      Posté par balzane le 16 septembre 2009 à 18:19. Évalué à 2.
      
      Ci-dessous un tcpdump -n un peu plus long.
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:50:57.756036 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:52:01.262570 IP 192.168.50.100 > 224.0.0.1: ICMP echo request, id 0, seq 0, length 40 15:52:50.760030 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:52:51.760034 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:52:52.600286 IP6 fe80::20b:97ff:fea0:bc1f.5353 > ff02::fb.5353: 0 [3q][|domain] 15:52:52.600458 IP 192.168.50.12.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _http._tcp.local. PTR (QM)? _ftp._tcp.local.[|domain] 15:52:52.760038 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:54:50.760032 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:54:50.760663 ARP, Reply 192.168.50.1 is-at 00:22:b0:89:05:68, length 46 15:54:50.760675 IP 192.168.50.12.34861 > 192.168.50.1.80: Flags [P.], seq 3738846783:3738847180, ack 2458630106, win 46, options [nop,nop,TS val 131189 ecr 24647403], length 397 15:56:50.756083 IP 192.168.50.12.34861 > 192.168.50.1.80: Flags [P.], seq 0:397, ack 1, win 46, options [nop,nop,TS val 161189 ecr 24647403], length 397 15:56:51.756039 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46 15:56:51.756060 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28 15:56:51.756688 IP 192.168.50.1.80 > 192.168.50.12.34861: Flags [.], ack 397, win 5792, options [nop,nop,TS val 24691451 ecr 161189,nop,nop,sack 1 {0:397}], length 0 15:57:08.604273 IP6 fe80::20b:97ff:fea0:bc1f.5353 > ff02::fb.5353: 0 [3q][|domain] 15:57:08.604444 IP 192.168.50.12.5353 > 224.0.0.251.5353: 0 [3q] PTR (QM)? _http._tcp.local. PTR (QM)? _ftp._tcp.local.[|domain] 15:57:32.019943 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 309 15:57:33.013433 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 380 15:57:33.119433 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 380 15:57:33.673531 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 362 15:57:33.779309 IP 192.168.50.1.2053 > 239.255.255.250.1900: UDP, length 362 15:59:01.864257 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 2430655162:2430656610, ack 3392990277, win 5792, options [nop,nop,TS val 24704564 ecr 50338], length 1448 15:59:01.864350 IP 192.168.50.12.34860 > 192.168.50.1.80: Flags [.], ack 1448, win 175, options [nop,nop,TS val 193966 ecr 24704564,nop,nop,sack 1 {4344:7240}], length 0 15:59:02.074165 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 1448:2896, ack 1, win 5792, options [nop,nop,TS val 24704585 ecr 193966], length 1448 15:59:02.074238 IP 192.168.50.12.34860 > 192.168.50.1.80: Flags [.], ack 2896, win 198, options [nop,nop,TS val 194018 ecr 24704585,nop,nop,sack 1 {4344:7240}], length 0 15:59:02.284121 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 2896:4344, ack 1, win 5792, options [nop,nop,TS val 24704606 ecr 194018], length 1448 15:59:02.284195 IP 192.168.50.12.34860 > 192.168.50.1.80: Flags [.], ack 7240, win 220, options [nop,nop,TS val 194071 ecr 24704606], length 0 15:59:06.864030 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:59:07.864035 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:59:08.864031 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:59:28.949563 IP 192.168.50.1.80 > 192.168.50.12.34860: Flags [.], seq 7240:8688, ack 1, win 5792, options [nop,nop,TS val 24707273 ecr 194071], length 1448 15:59:28.952034 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:59:29.952036 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 15:59:30.952033 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 16:00:05.823102 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46 16:00:05.823124 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28 16:00:57.573932 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46 16:00:57.573954 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28 38 packets captured 38 packets received by filter 0 packets dropped by kernel
      
      Je vais installer arping et voir ce que ça me raconte...
      Merci.
      - [^] # Re: On sais jamais...
        
        Posté par benoar le 16 septembre 2009 à 18:37. Évalué à 4.
        
        Arping ne changera rien, on voit ce que ça donne dans ce log :
        T'as changé quelque chose au cours de ce tcpdump, non ?
        On voit d'abord des requêtes ARP qui n'aboutissent à rien :
        
        15:50:57.756036 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        15:52:50.760030 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        15:52:51.760034 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        
        Et puis d'un coup :
        
        15:54:50.760032 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        15:54:50.760663 ARP, Reply 192.168.50.1 is-at 00:22:b0:89:05:68, length 46
        
        Ou alors un truc le change dans ton dos. Déjà, quand je fais du test réseau, je désactive toujours systématiquement NetworkManager. Il fout la merde dès qu'on fait des trucs à la main.
        Pour être sur de pas avoir de pb de firewall et d'autres programmes, je te conseille déjà de rebooter ta machine en mode single user (rajoute " single" à la fin des paramètres à filer au noyau). Déjà ça évitera d'avoir des comportements aléatoires comme on voit là.
        
        Si en single c'est toujours comme ça, je ne vois que deux solutions : un problème de driver, ou un problème hard.
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 16 septembre 2009 à 19:03. Évalué à 2.
        
        En single-user : je vois la passerelle, mais le ping reste aléatoire (1 à 3 paquets sur 5), et parfois très long ( > 1 s).
        J'accède aux DNS de la passerelle et à sortir, mais lentement après le tcpdump j'avais la page d'accueil de debian.org, renommée pour sa lourdeur ;), sans css ni images.
        
        16:47:05.939797 IP 192.168.50.12.43894 > 213.129.232.18.80: Flags [F.], seq 447400385, ack 1204617074, win 227, options [nop,nop,TS val 10829 ecr 502396089,nop,nop,sack 2 {5761:7201}{1441:4321}], length 0 16:47:06.012929 IP 213.129.232.18.80 > 192.168.50.12.43894: Flags [.], ack 1, win 54, options [nop,nop,TS val 502418747 ecr 10829,nop,nop,sack 1 {0:1}], length 0 16:47:07.099679 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 1, length 64 16:47:08.105925 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 2, length 64 16:47:08.106974 IP 192.168.50.1 > 192.168.50.12: ICMP echo reply, id 3338, seq 2, length 64 16:47:09.107094 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 3, length 64 16:47:10.113902 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 4, length 64 16:47:11.121897 IP 192.168.50.12 > 192.168.50.1: ICMP echo request, id 3338, seq 5, length 64 16:47:13.783794 IP 192.168.50.12.43893 > 213.129.232.18.80: Flags [F.], seq 439056781, ack 1191831842, win 115, options [nop,nop,TS val 12790 ecr 502399606], length 0 16:47:15.090378 ARP, Request who-has 192.168.50.12 tell 192.168.50.1, length 46 16:47:15.090395 ARP, Reply 192.168.50.12 is-at 00:0b:97:a0:bc:1f, length 28 16:48:02.847794 IP 192.168.50.12.43889 > 213.129.232.18.80: Flags [F.], seq 152404176, ack 913552227, win 137, options [nop,nop,TS val 25056 ecr 502396640], length 0 16:48:07.180401 IP 192.168.50.12.49977 > 192.168.50.1.53: 8942+ A? www.debian.org. (32) 16:48:07.180450 IP 192.168.50.12.49977 > 192.168.50.1.53: 44564+ AAAA? www.debian.org. (32) 16:48:07.202770 IP 192.168.50.12.54310 > 192.168.50.1.53: 8853+ A? www.w3.org. (28) 16:48:07.202954 IP 192.168.50.12.54310 > 192.168.50.1.53: 36915+ AAAA? www.w3.org. (28) 16:48:07.203288 IP 192.168.50.12.57857 > 192.168.50.1.53: 62188+ A? jigsaw.w3.org. (31) 16:48:07.203376 IP 192.168.50.12.57857 > 192.168.50.1.53: 8406+ AAAA? jigsaw.w3.org. (31) 16:48:07.280480 IP 192.168.50.1.53 > 192.168.50.12.57857: 8406 0/1/0 (82) 16:48:07.847786 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 16:48:08.847786 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 16:48:09.847836 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 16:48:12.187788 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 16:48:13.187793 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28 16:48:13.188406 ARP, Reply 192.168.50.1 is-at 00:22:b0:89:05:68, length 46 16:48:13.188415 IP 192.168.50.12.54310 > 192.168.50.1.53: 8853+ A? www.w3.org. (28) 16:48:13.188418 IP 192.168.50.12.54310 > 192.168.50.1.53: 36915+ AAAA? www.w3.org. (28) 16:48:13.188422 IP 192.168.50.12.57857 > 192.168.50.1.53: 62188+ A? jigsaw.w3.org. (31) 16:48:13.719078 IP 192.168.50.100.137 > 192.168.50.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 16:48:17.188664 IP 192.168.50.12.33302 > 192.168.50.1.53: 16715+ A? www.debian.org. (32) 16:48:17.188704 IP 192.168.50.12.33302 > 192.168.50.1.53: 44952+ AAAA? www.debian.org. (32) 16:48:17.208801 IP 192.168.50.12.50629 > 192.168.50.1.53: 52536+ A? www.w3.org. (28) 16:48:17.208840 IP 192.168.50.12.50629 > 192.168.50.1.53: 2890+ AAAA? www.w3.org. (28) 16:48:17.208973 IP 192.168.50.12.57857 > 192.168.50.1.53: 62188+ A? jigsaw.w3.org. (31) 16:48:22.189852 IP 192.168.50.12.33302 > 192.168.50.1.53: 16715+ A? www.debian.org. (32) 16:48:22.189891 IP 192.168.50.12.33302 > 192.168.50.1.53: 44952+ AAAA? www.debian.org. (32) 16:48:22.212889 IP 192.168.50.12.50629 > 192.168.50.1.53: 52536+ A? www.w3.org. (28) 16:48:22.212925 IP 192.168.50.12.50629 > 192.168.50.1.53: 2890+ AAAA? www.w3.org. (28) 16:48:22.214062 IP 192.168.50.12.52300 > 192.168.50.1.53: 62445+ A? jigsaw.w3.org. (31) ^C 39 packets captured 39 packets received by filter 0 packets dropped by kernel
        
        [^] # Re: On sais jamais...
        
        Posté par nono14 (site web personnel) le 16 septembre 2009 à 19:12. Évalué à 1.
        
        16:48:07.847786 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        16:48:08.847786 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        16:48:09.847836 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        16:48:12.187788 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        16:48:13.187793 ARP, Request who-has 192.168.50.1 tell 192.168.50.12, length 28
        16:48:13.188406 ARP, Reply 192.168.50.1 is-at 00:22:b0:89:05:68, length 46
        
        C'est très long 5sec pour une réponse arp.
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
        
        [^] # Re: On sais jamais...
        
        Posté par nicolasi le 16 septembre 2009 à 20:12. Évalué à 2.
        
        OK, donc pour résumé:
        - tu reçois aléatoirement des réponses à tes paquets
        - ça marche sous windows
        - ça marche sur un autre réseau avec la même config
        
        Peux-tu envoyer le résultat de la commande:
        ethtool -S eth0
        ethtool -t eth0
        ethtool -i eth0
        
        Peut-être un pb de nego, tu peux essayer de fixer la vitesse aux 2 extrémités?
        Est-ce qu'il y a moyen de mettre à jour le noyau?
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 16 septembre 2009 à 22:31. Évalué à 2.
        
        Le résumé est parfait.
        
        ethtool -S eth0
        NIC statistics: tx_packets: 42 rx_packets: 1 tx_errors: 0 rx_errors: 5 rx_missed: 0 align_errors: 655 tx_single_collisions: 0 tx_multi_collisions: 0 unicast: 1 broadcast: 0 multicast: 0 tx_aborted: 0 tx_underrun: 0
        
        ethtool -t eth0
        Cannot test: Operation not supported
        
        ethtool -i eth0
        driver: r8169 version: 2.3LK-NAPI firmware-version: bus-info: 0000:02:01.0
        
        Peut-être un pb de nego, tu peux essayer de fixer la vitesse aux 2 extrémités ?
        Pas sur le routeur, sur ma machine je pense que oui. Je vais googler.
        
        Est-ce qu'il y a moyen de mettre à jour le noyau ?
        Sans réseau ça risque d'être difficile. J'ai installé quelques utilitaires manquants nécessaires à vos diagnostics en récupérant le paquet sur clé usb et en installant par un dpkg -i, pour une màj du noyau ça risque d'être plus coton...
        
        [^] # Re: On sais jamais...
        
        Posté par nicolasi le 16 septembre 2009 à 23:46. Évalué à 2.
        
        OK, on avance!
        Alignment Error:
        Alignment Error happens in IEEE 802.3(Ethernet) networks. It is an error that occurs when the total number of bits of a received frame is not divisible by eight. Alignment errors are usually caused by frame damage due to collisions and by misaligned reads and writes. For example, a two-byte read where the memory address is not an even multiple of two bytes is an alignment error. Alignment errors are caused by a software bug.
        
        source: http://www.javvin.com/networkingterms/AlignmentError.html
        
        Donc, à priori, il reçoit des paquets corrompus et n'en tient pas compte.
        Ça pue! y a un bug soit dans le driver (peut-être résolu dans une version plus récente du noyau) soit dans le firmware du d-link (voir si il y a une version plus récente).
        
        Essaie de désactiver l'autoneg et de forcer la vitesse en 10half avec ethtool.
        Ça va ramer mais ça peut pas être pire...
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 17 septembre 2009 à 00:10. Évalué à 2.
        
        Oups, j'étais passé à côté de ta réponse.
        Je retiens la piste, comme dit plus bas je creuserai lundi.
        Merci.
        
        [^] # Re: On sais jamais...
        
        Posté par benoar le 17 septembre 2009 à 03:58. Évalué à 2.
        
        Bien vu le coup du diagnostic de la carte ...
        
        Ça pue! y a un bug soit dans le driver (peut-être résolu dans une version plus récente du noyau) soit dans le firmware du d-link (voir si il y a une version plus récente).
        Effectivement, on se rapproche du problème ...
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 22 septembre 2009 à 14:26. Évalué à 1.
        
        Bonjour,
        
        J'ai désactivé l'autoneg et forcé la vitesse en 10half :
        ethtool -s eth0 autoneg off speed 10 duplex half
        Les temps de réponse au ping sont de l'ordre de la milliseconde, je n'ai toujours pas 100% de réponse (de 1 à 3 réponses par série de 5 pings).
        
        Je vais chercher si je trouve un driver plus récent.
        
        [^] # Re: On sais jamais...
        
        Posté par benoar le 16 septembre 2009 à 21:23. Évalué à 3.
        
        Bon bah en voyant ça, j'en arrive aux deux conclusions précédentes :
        - soit c'est un problème de driver. Un petit dmesg | grep eth pourrait peut-être en dire plus sur le modèle, voir des erreurs
        - soit c'est un problème hard, mais si ça marche "bien" sous windows. D'ailleurs, as-tu ces problèmes de lenteur sous windows ? Le ping marche-t-il bien ?
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 16 septembre 2009 à 22:54. Évalué à 2.
        
        dmesg | grep eth
        [ 1.644866] eth0: RTL8110s at 0xf8012800, 00:0b:97:a0:bc:1f, XID 04000000 IRQ 9 [ 16.446749] r8169: eth0: link up [ 27.440026] eth0: no IPv6 routers present [ 46.704033] eth1: no IPv6 routers present
        Sous Windows, aucun problème de lenteur : 100% de pings reçus, réponse en 1 ms.
        
        [^] # Re: On sais jamais...
        
        Posté par benoar le 16 septembre 2009 à 21:33. Évalué à 2.
        
        Je suis pris d'un doute, du fait de tes explications vagues ("vois" la passerelle, "accède" aux DNS) : t'as utilisé quoi pour aller sur le site de debian ?
        
        (j'avoue que c'est un peu pour sonder ton niveau de connaissances, parce que là un problème comme ça, soit c'est un truc bête qu'on a pas vu et que t'as pas dit, soit c'est un problème très sioux qu'il faudrait remonter upstream).
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 16 septembre 2009 à 22:48. Évalué à 2.
        
        t'as utilisé quoi pour aller sur le site de debian ?
        Epiphany sous la session single-user.
        
        j'avoue que c'est un peu pour sonder ton niveau de connaissances
        Aucun problème. Clairement, vos conseils vont bien au delà de mes connaissances en réseaux.
        
        soit c'est un truc bête qu'on a pas vu et que t'as pas dit
        Je pencherai plutôt pour ça :)
        Ce que je n'ai pas dit (il n'est jamais trop tard) : en wifi je n'ai jamais eu de problème pour me connecter à d'autres réseaux (chez des amis, à l'hôtel...). J'utilise de préférence l'interface graphique Wicd, mes modifs ci-dessus furent faites à la mano dans le fichier concerné et suivies d'une relance du service.
        
        [^] # Re: On sais jamais...
        
        Posté par benoar le 16 septembre 2009 à 23:07. Évalué à 2.
        
        Epiphany sous la session single-user.
        Ha ok ... quand je disait single-user, c'est du single de chez single en console. Une sessions graphique te lance plein de trucs qui peuvent modifier le comportement brut de ta machine.
        Quand tu es dans grub, (de mémoire) tape e, ensuite encore e, ajoute single à la fin de la ligne, et tu devrais démarrer en mode console minimal. Là, tu lances un "dhclient eth0", déjà on verra si ton client DHCP marche. Ensuite, si tu dois faire du statique, n'utilises pas le fichier interfaces, fais le à la main :
        
        ip link set eth0 up
        ip addr add 192.168.50.12/24 dev eth0
        
        et ping ta passerelle.
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 17 septembre 2009 à 00:05. Évalué à 2.
        
        quand je disait single-user, c'est du single de chez single en console.
        OK, désolé.
        
        En single de chez single en console :
        - le client DHCP obtient rapidement une adresse,
        - j'ai 2 réponses à 5 pings, dans des délais corrects (maxi qq millisecondes)
        - en statique, même résultat : de 1 à 3 réponses sur 3 x 5 pings, délais de 1 ms à quelques millisecondes.
        
        => Le client DHCP marche, moins de 50 % de réponse aux pings, temps de réponse de 1 à 4 ms.
        
        PS : merci du temps passé à m'aider à solutionner le problème jusqu'ici. Je serai en déplacement jusqu'à lundi, donc guère actif jusque là. N'en déduisez pas que je me désintéresse de la solution et de la résolution du problème que je vous propose :).
        
        [^] # Re: On sais jamais...
        
        Posté par benoar le 17 septembre 2009 à 04:05. Évalué à 2.
        
        Bon, c'est assez étrange que ça aille mieux, mais pas encore complètement bien ...
        À la vue du diagnostic plus haut et de l'interprétation de nicolasi, je vote pour un bug du driver, vu que si tu vois une différence de ton côté entre single user et "full desktop", c'est que ça ne vient probablement pas du d-link.
        
        Après, trouver d'où ça vient exactement .... houlala.
        
        Le truc ce serait de tester avec un noyau plus récent, voir si ça a pas déjà été corrigé (ce serait con, on aurait l'air malin avec notre discussion de 3km ...)
        
        Ha, et puis d'avoir le modèle de ta carte, ainsi que le driver utilisé.
        
        À lundi.
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 22 septembre 2009 à 14:13. Évalué à 1.
        
        Hello !
        
        La carte est une Realtek RTL8169/8110 family gigabit ethernet NIC.
        dmesg | grep eth retourne :
        eth0: RTL8110s [...]
        Ce s final me surprend un peu.
        
        Le driver : ethtool --driver eth0 retourne :
        driver: r8169 version 2.3 LK-NAPI firmware version: bus-info: 0000:02:01.1
        
        Mon noyau est un 2.6.30-1.
        
        Je vais googler voir si je trouve d'autres discussion ailleurs signalant des problèmes avec cette configuration.
        
        [^] # Re: On sais jamais...
        
        Posté par benoar le 22 septembre 2009 à 19:33. Évalué à 2.
        
        Tant qu'on y est, faudrait peut-être que tu testes avec une autre distro, un système "propre", ou un live. Et plus de détails sur ta config (carte-mère ? etc)
        
        [^] # Re: On sais jamais...
        
        Posté par balzane le 24 septembre 2009 à 23:50. Évalué à 1.
        
        Bonsoir,
        
        Aucun problème avec une Ubuntu 9.04 en live-CD. J'ai également essayé avec la dernière version du system rescue cd qui ne voyait pas d'interface eth0 alors qu'une version précédente m'a par le passé déjà sauvé la mise.
        
        Suite à ta question, la carte-mère de la machine (portable Panasonic) :
        Manufacturer: Matsushita Electric Industrial Co.,Ltd. Motherboard: CF-51ECKDRLF
        En googlant j'ai trouvé trace de bugs affectant liés au driver de la carte réseau liés aux mêmes symptômes.
        Je pense que je vais chercher à procéder à la mise à jour du pilote depuis chez moi (où la connexion filaire fonctionnait), ou depuis ailleurs en wifi. Je n'ai pas spécialement envie de réinstaller une Debian from scratch, donc si ma configuration continue à fonctionner chez moi (puisque, pour rappel, le problème se posait dans un autre LAN), j'aurais toute latitude pour expérimenter.
        
        Encore merci de tes explications... et merci aux autres intervenants pour les leurs : il semble maintenant clair que l'origine du problème est liées aux pilotes de la carte et non à la configuration de mon système.
        
        [^] # Re: On sais jamais...
        
        Posté par benoar le 25 septembre 2009 à 17:35. Évalué à 2.
        
        Si ça marche avec une Ubuntu "récente", ya une problème chez Debian, et il faudrait le signaler (bizarre qu'avec un 2.6.30 ça déconne ...)
- [^] # Re: On sais jamais...
  
  Posté par balzane le 16 septembre 2009 à 18:10. Évalué à 2.
  
  Bonjour,
  
  Je n'ai pas essayé de rebooter la passerelle. Les deux machines Win XP installées derrière ont l'accès sans problème : depuis la machine d'où j'écris j'ai un ping 1ms, 100 % de réussite.
  
  Ça marche vraiment sur le même PC avec un autre OS, sans toucher à rien.
  Le pare-feu n'a pas de raison de poser problème. Il est en configuration par défaut, et « chez moi ça marche » : dans mon LAN habituel où la configuration réseau est la même, aucun souci. La session Win accède au net sans avoir touché à la config IP statique.
  
  Ma Debian est mise à jour régulièrement. Contrairement à ce que j'indiquais plus haut, c'est une testing (squeeze) avec quelques morceaux de unstable. Ces morceaux sont normalement des programmes desktop, pas des outils systèmes ou d'administration.
  
  Je viens de tester avec un noyau 2.6.22 : j'ai d'abord eu 3 ping reçu sur 5, durée moyenne 330 ms, mini 1 ms, maxi : 1 s !
  
  Pour la passerelle, c'est un routeur domestique D-Link, donc le tcpdump de la passerelle, il faut oublier :(
  
  Merci !
  - [^] # Re: On sais jamais...
    
    Posté par benoar le 16 septembre 2009 à 18:39. Évalué à 3.
    
    Le pare-feu n'a pas de raison de poser problème. Il est en configuration par défaut, et « chez moi ça marche »
    On parle du pare-feu de ta machine, pas de ta passerelle, parce que si "c'est toi ça marche" on ne serait pas en train de parler autour de ce thread ...
# Pause...

Posté par balzane le 17 septembre 2009 à 00:07. Évalué à 2.

Bonsoir à tous,

Merci du temps passé à m'aider à solutionner le problème jusqu'ici.
Comme je serai en déplacement jusqu'à lundi, ne vous attendez pas à ce que je sois très actif d'ici là.

N'en déduisez pas que je me désintéresse de la solution et de la résolution du problème que je vous pose :).

Bonne fin de semaine.
- [^] # Re: Pause...
  
  Posté par maxix le 24 septembre 2009 à 03:24. Évalué à 2.
  
  Pas de nouvelles?

Suivre le flux des commentaires

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