[dhcp] Pas d'adresse réseau au démarrage [résolus]

[luri]

Salut à tous,

J'ai une machine (architecture x86-64) avec un seul port réseau connecté en filaire.
Au démarrage, la partie networking met beaucoup de temps pour démarrer et n'arrive pas à me donner une adresse ip.
Par contre, lorsque que je me loggue (en console) et que je fait 'dhcpcd eth0' ça fonctionne (l'adresse ip est attribué.)

Le rc.conf me semble correct :

Code : Tout sélectionner

HOSTNAME="xxxx"

interface=eth0
address=

NETWORK_PERSIST="no"

DAEMONS=(syslog-ng hwclock dbus network crond @sshd @samba @acpid)

D'où est-ce que ça peut venir ?

Merci d'avance pour votre aide.

[FoolEcho]

Salut,

Je ne sais pas trop. Tu as bien rajouté le hostname à ton /etc/hosts ?
Il faudrait voir du côté de /var/log/everything.log ce qu'il se passe...

[luri]

Merci pour ta réponse.

Je m'y suis remis ce matin et voilà ce que je trouve dans le everything.log :
-correspondant au démarrage du service network :

Code : Tout sélectionner

Jul 11 07:18:32 localhost dhcpcd[376]: version 5.5.6 starting
Jul 11 07:18:32 localhost dhcpcd[376]: eth0: waiting for carrier
Jul 11 07:18:36 localhost dhcpcd[376]: eth0: carrier acquired
Jul 11 07:18:36 localhost kernel: [   16.954205] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Jul 11 07:18:36 localhost dhcpcd[376]: eth0: broadcasting for a lease
Jul 11 07:19:02 localhost dhcpcd[376]: timed out

-lorsque que j'ai lancé dhcpcd eth0 :

Code : Tout sélectionner

Jul 11 07:31:00 localhost dhcpcd[571]: version 5.5.6 starting
Jul 11 07:31:00 localhost dhcpcd[571]: eth0: broadcasting for a lease
Jul 11 07:31:00 localhost dhcpcd[571]: eth0: offered 172.20.1.136 from 172.20.1.25
Jul 11 07:31:00 localhost dhcpcd[571]: eth0: acknowledged 172.20.1.136 from 172.20.1.25
Jul 11 07:31:00 localhost dhcpcd[571]: eth0: checking for 172.20.1.136
Jul 11 07:31:05 localhost smbd[582]: [2012/07/11 07:31:05.529866,  0] printing/print_cups.c:110(cups_connect)
Jul 11 07:31:05 localhost smbd[582]:   Unable to connect to CUPS server /var/run/cups/cups.sock:631 - Aucun fichier ou dossier de ce type
Jul 11 07:31:05 localhost smbd[471]: [2012/07/11 07:31:05.530085,  0] printing/print_cups.c:487(cups_async_callback)
Jul 11 07:31:05 localhost smbd[471]:   failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
Jul 11 07:31:06 localhost dhcpcd[571]: eth0: leased 172.20.1.136 for 691200 seconds
Jul 11 07:31:06 localhost dhcpcd[571]: forked to background, child pid 598

Lorsque je lance la commande manuellement, j'ai une réponse immédiate.

Pour info, j'ai réinstallé ifconfig. J'ai aussi essayé de désactivé ipv6 avec les conseils du wiki (français) mais lorsque je lance ifconfig, la carte a toujours une adresse ipv6.

Le serveur dhcp est un serveur windows, probablement le même qui gère le domaine windows. Peut-être que celà induit une configuration spéciale ?

Voici quelques fichiers de confs :
/etc/rc.conf :

Code : Tout sélectionner

#
# /etc/rc.conf - Main Configuration for Arch Linux
#
# See 'man 5 rc.conf' for more details
#

# LOCALIZATION
# ------------
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Paris"
KEYMAP="fr-pc"
CONSOLEFONT="lat9w-16"
CONSOLEMAP=
LOCALE="fr_FR.UTF-8"
DAEMON_LOCALE="yes"
USECOLOR="yes"

# HARDWARE
# --------
MODULES=()
USEDMRAID="no"
USEBTRFS="no"
USELVM="no"

# NETWORKING
# ----------
HOSTNAME="infogene-test"

interface=eth0
address=


NETWORK_PERSIST="no"

# DAEMONS
# -------
#
DAEMONS=(syslog-ng hwclock dbus network crond @sshd @samba @acpid)

/etc/dhcpcd.conf

Code : Tout sélectionner

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Inform the DHCP server of our hostname for DDNS.
#hostname
# To share the DHCP lease across OSX and Windows a ClientID is needed.
# Enabling this may get a different lease than the kernel DHCP client.
# Some upstream DHCP servers may also require a ClientID, such as FRITZ!Box.
#clientid

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname
noipv4ll
#désactivation ipv6
noipv6rs

(j'ai essayé de commenté la ligne hostname comme trouvé sur un forum, mais ça n'a en rien changé quoi que ce soit.)

/etc/hosts

Code : Tout sélectionner

# /etc/hosts: static lookup table for host names
#

#<ip-address>   <hostname.domain.org>   <hostname>
127.0.0.1       localhost.localdomain   localhost infogene-test
::1             localhost.localdomain   localhost

# End of file

[luri]

Bon, ça fonctionne de nouveau en ajustant le timeout à 90s : le serveur met environs une minute à répondre. Du coup, le démarrage est super long mais ça démarre au moins, c'est un mieux.

Le comportement est tout de même très étrange : Au démarrage ça met 1 minute à répondre alors que lorsque que je lance la commande dhcpdcd manuellement (les fois où je n'avais pas d'adresse), le résultat est très rapide.

Qu'est-ce que fais le système en plus lors du démarrage ?

Edit : je viens de faire le test suivant : démarrage avec une adresse ip statique bidon puis lancement en root : dhcpcd eth0. L'adresse est obtenu très rapidement. J'ai remis ensuite la configuration "normal" (dhcpcd lancé par network) et de nouveau, il faut 1 minute pour obtenir l'adresse.

[benjarobin]

Rien d'autre, 2 possibilités : Serveur DHCP foireux, ou problème avec le driver Ethernet.
Il serait intéressant de faire ce test :
- Enlève network des DAEMON du rc.conf
- Redémarre
- Une fois connecté en root, lance simplement cette commande:

Code : Tout sélectionner

ifconfig eth0 up; dhcpcd eth0

[luri]

Je suis en réseau local, je veux bien que ce soit le driver de la carte réseau qui a un problème mais certainement pas le driver internet (inexistant sur la machine) (et le serveur dhcp foireux, c'est bien possible)

J'ai branché un analyseur réseau pour visualiser les trames.

J'ai testé ce que tu m'a dit, sauf que je me suis gouré dans la commande. (du coup eth0 était up avant le lancement de dhpcd.)
Dans ce cas, je vois bien les 4 trames dhcp dans la capture réseau.

J'ai voulu recommencer avec cette fois ci la bonne ligne de commande en un coup mais il y a visiblement un mécanisme de "cache" pour éviter les requêtes trop rapproché.
A l'analyseur, on se rend compte qu'aucune requète dhcp n'est échangé avec le serveur. Le client fait simplement 3 ARP sur son adresse ip et la prend d'office. (le bail doit être de une semaine)

Il faut donc que je trouve comment supprimer cet espèce de mécanisme pour pouvoir faire correctement ton test.

[benjarobin]

Le cache se trouve ici /var/lib/dhcpcd/, il suffit donc de faire ceci:

Code : Tout sélectionner

killall dhcpcd
rm /var/lib/dhcpcd/*

Attention dhcpcd est un daemon donc il faut bien penser à le killer avant de relancer la commande

Sinon désolé mais le correcteur orthographique m'avais modifié Ethernet en internet (J'avais fait une faute de frappe à la base)

[luri]

Merci.
J'ai découvert aussi dhcpcd -k eth0 (ça rend l'adresse IP proprement)

Bon, les boitiers "espion", c'est de la daube (je voyais de temps en temps les deux sens, de temps en temps un seul), rien ne vaut un bon vieux hub.

Donc après test :
- Si pas network de lancé puis lancement en même temps eth0 et dhcpcd (ton test), ça fonctionne rapidement
- Si network est lancé au démarrage, il y a toujours ce gros délais MAIS sur la capture réseau, les 4 trames DHCP se suivent rapidement (discover / offer / request / ack)

Donc soit le système est lent à réagir, soit il se bloque mais il y a bel et bien un problème de perfo avec ce démon. (je suis en 64 bits)

Est-ce qu'il y a un endroit où je pourrais ajouter ta commande (ifconfig eth0 up; dhcpcd eth0) avant l'écran de login ?

[benjarobin]

Je suis perplexe si tu regarde le code de "network"

Code : Tout sélectionner

network_up() {
  have_interface "$interface" || return 1

  ip link set dev $interface up || return 1

  if [[ $address ]]; then
    ip addr add $address/${netmask:-24} broadcast ${broadcast:-+} dev $interface || return 1
    [[ $gateway ]] && { ip route add default via $gateway || return 1; }
  else
    dhcpcd $DHCPCD_ARGS $interface || return 1
  fi
}

Ce qui donne sachant que pour moi

Code : Tout sélectionner

grep DHCPCD_ARGS /etc/conf.d/*
/etc/conf.d/dhcpcd:DHCPCD_ARGS="-q"

=>

Code : Tout sélectionner

network_up() {
  ip link set dev eth0 up
  dhcpcd -q eth0 
}

Donc presque la même chose que ce que tu lances via mon test... Tu peux le refaire avec

Code : Tout sélectionner

ip link set dev eth0 up; dhcpcd -q eth0 

Si tu as un hub, je serais intéressé d'avoir la sortie brute de wireshark quand cela fonctionne et quand cela ne fonctionne pas

[luri]

c'est exactement celà. cette dernière commande est super longue à exécuter

[benjarobin]

Il y a une différence entre (Toujours avec le daemon network non lancé) ?

Code : Tout sélectionner

ip link set dev eth0 up; dhcpcd -q eth0

et

Code : Tout sélectionner

ifconfig eth0 up; dhcpcd -q eth0 

Si c'est le cas, c'est intéressant comme problème

[luri]

Tient, c'est très étrange. Maintenant, je n'ai plus guere de différence de temps entre

Code : Tout sélectionner

ip link set dev eth0 up; dhcpcd -q eth0

Code : Tout sélectionner

ifconfig eth0 up; dhcpcd -q eth0

Code : Tout sélectionner

ifconfig eth0 up; dhcpcd eth0

entre 50s et 60s.

Le plus étrange est la sortie de la dernière commande : Comparé au début d'aprem ou tout allair très vite, là elle bloque sur l'attente de la porteuse (enfin carrier ou un truc du genre), le discover dhcp puis (mais beaucoup moins) à la vérif.
Bref, j'y comprend que dale et je crois que je suis bon pour rebrancher mon hub.

[luri]

Ha!!! je crois que j'ai trouvé quelque chose :

Je suis repassé du switch gigabit au switch 100 que j'avais utilisé pour les test avec le boitier et le temps (des 2 commandes mais sans le switch quiet du dhcpcd) est passé à environs 10s.
Je vais retester avec le service network

[benjarobin]

Le temps moyen pour obtenir une IPv4 est de 4/5 secondes, car il vérifie que l'IP obtenu n'est pas déjà présente/utilisée sur le réseau.

[luri]

Je confirme que ça provient bien du switch cisco gigabit ou plus probablement d'une incompatibilité quelconque entre ce switch (ou les switchs giga) et ma carte réseau (PC Acer X3812, carte réseau gigabit intégré sur carte mère donc fournis sans doute par le chipset : Intel® G43 Express).

Lorsque je branche mon pc sur un switch classique 10/100, je met entre 5 et 10s a obtenir une adresse ip (manuellement ou au démarrage de la machine), donc un délais normal et classique.
Par contre une fois branché sur le switch giga, il faut environ 1 minute pour obtenir l'adresse. Avec le timeout classique (30s), je démarre sans adresse ip et une fois en ligne de commande, un dhcpcd eth0 fonctionne immédiatement. (reproduit il y a quelques minutes)

Je confirme que je n'ai aucune différence de performance entre

Code : Tout sélectionner

ip link set dev eth0 up; dhcpcd -q eth0

et

Code : Tout sélectionner

ifconfig eth0 up; dhcpcd -q eth0 

ce qui s'est passé est que la première fois que j'ai testé

Code : Tout sélectionner

ifconfig eth0 up; dhcpcd eth0 

j'étais passé sur le switch 100 un peu avant pour brancher mon boitier espion (qui ne fonctionne pas en gigabit)

Tandis que lorsque j'ai testé l'autre commande, j'avais enfin réussi à faire mes captures réseau (sur lequels il n'y avait aucun problème) et je m'étais donc rebranché sur le switch giga (censé être mieux vu qu'il va plus vite.)

Je suis désolé pour tous ces messages. (et j'enrage un peu d'avoir passé deux jours à cause d'un switch foireux ou mal configuré)

Merci beaucoup pour toute l'aide fournis