Bonjour,

J'ai un petit problème d'activation de wlan0 (wifi) au démarrage du système

Materiel : Dell Precision 4300 et carte 3945ABG

Système : 2.6.23.9-85 fc8 (Red Hat nash 6.0.19)

J'ai beau cocher la case activer au démarrage dans la configuration de wlan0 : l'activation au démarrage échoue sur la définition des infos IP avec 0 paquets reçus sur les pings
Je suis obligé d'activer après le login et là ca marche donc problème pas très grave mais est-ce normal ???

Merci d'avance pour un avis sur ce tout petit problème
Bonjour,

J'ai désactivé les services Network Manager et Network Manager Dispatcher et je l'active après le login via système>administration>controle du périphérique réseau etc...

Dans le panneau général de configuration du périphérique réseau j'ai coché les cases "ctiver au démarrage le périphérique au démarrage de l'ordinateur" et "ermettre à tous
les utilisateurs d'activer ou de désactiver le périphérique" (ce qui me permet de l'activer après le login sans avoir à etre root) : il semble simplement que la case activer au démarrage soit sans effet
salut

Comment est activé ton emetteur(la radio) de ton wifi?
peut etre qu'il ne s'active pas au demarrage, donc il ne peut resoudre les ip au boot
mais qu'ensuite la session active la radio et tu arrive alors a te connecter et activer l'interface reseau. la case activer au demarrage n'agit que si les parametres de la cartes sont ok, je crois
Tu as tenté de simplement désactiver le service network au démarrage et activer les 2 services NetworkManager? C'est le plus simple si u utilises le WiFi avec Gnome.
Bonjour,

Voici le bilan de quelques tests :

1 Network Manager arreté, périphérique pas controlé par Network Manager et pas activé au démarrage ===>
- pas d'activation dans la séquence de démarrage (c'est normal)
- le premier essai d'activation après login échoue avec "impossible d'activer..."
- mais un second essai d'activation réussit

2 Network Manager arreté, périphérique pas controlé par Network Manager et activé au démarrage ===>
- activation dans la séquence de démarrage au run level 5 juste après l'activation de eth0 avec échec du
ping sur (192.168.1.1) à partir de (192.168.1.3) donnant 100% loss
- le premier essai d'activation après login réussit

3 Network Manager et Network Manager Dispatcher activés, périphérique controlé par Network Manager et pas activé au démarrage
- pas d'activation dans la séquence de démarrage (c'est normal)
- la première tentative d'activation échoue par "impossible d'activer..."
- la seconde tentative aboutit à une demande de la clé mais, après entrée de la clé en hexadécimal precédée de 0x, ce panneau de
demande de la clé n'active jamais le bouton "se connecter"

2 remarques :
A - Pour réussir l'activation du périphérique j'ai du effacer le fichier .gnome2/keyrings/default.keyring car sinon il réclame
un mot de passe que je ne connais pas pour déverouiller le trousseau par défaut
B - Au niveau ou se trouve l'activation du périphérique wifi dans la séquence de démarrage au run level 5, beaucoup de
services ne sont pas encore lancés. Cette activation est peut-etre essentiellement hardware et elle n'est peut-etre pas
capable de fournir la clé WEP : dans ce cas il n'est peut-etre pas surprenant de voire le ping échouer si la liaison wifi
exige la clé WEP avant de répondre aux pings (Je ne connais rien au protocole wifi/WEP mais il me semble vraisemblable
que la liaison soit protégée contre des pings qui pourraient venir de n'importe ou)
Question peut-être stupide, mais t'as testé avec le nouveau kernel et NetworkManager sorti ces derniers jours?
Bonjour,

Non je n'ai pas testé le nouveau kernel. Par contre :

1 J'ai regardé un peu la séquence de démarrage et le contenu du fichier /etc/sysconfig/network-scripts/ifcfg-wlan0 me parait correct.
La clé WEP se trouve (en clair !!!) dans keys-wlan0 et elle est donc accessible

2 J'ai vérifié que Network Manager est lancé beaucoup plus tard et donc il ne faut pas compter sur lui pour l'activation au cours de
la séquence de démarrage

3 Je ne sais pas si l'adresse utilisée au cours du ping qui échoue dans la séquence de démarrage a été obtenue par dhcp. En effet
j'ai fait des tests en connectant sur le routeur "club internet box" ma machine sous fedora à la fois en ethernet et en wifi et une autre
machine sous windows XP connecté en ethernet (la "club internet box" a deux sorties ethernet). La conclusion de ce petit exercice
est la suivante : quel que soit l'ordre dans lequel on boot les machines et on active les liaisons les adresses sont toujours :
- 192.168.1.2 pour la machine sous windows XP
- 192.168.1.3 pour le wlan0 sur fedora
- 192.168.1.4 pour eth0 sur fedora
Ca me laisse perplexe parce que j'avais toujours cru que les adresses étaient distribuées par dhcp dans l'ordre des requetes...! J'avais tort...

Tout ceci n'est pas très grave puisqu'on peut s'en sortir en activant wlan0 après le login. Cependant je serais curieux de savoir si quelqu'un
a une machine qui active wlan0 complétement dans la séquence de démarrage et si oui avec quel FAI car l'echec du ping est peut-etre du
à une politique particulière de sécurité du FAI. Je remarque d'ailleurs que la machine sous windows XP ne répond pas aux pings depuis fedora sur son
adresse 192.168.1.2 alors que fedora répond bien aux pings depuis la machine XP et ceci sur ses deux adresses 192.168.1.3 et 192.168.1.4 lorsque
etho et wlan0 sont activés.
Bonjour, pour ma part je suis chez free (freebox v5) et tout marche nickel, en ethernet aucune configuration, c'est du plug en play. Pour le wifi,une fois que tu as les driver et configuré Network Manager, c'est pareil au démarrage, il s'allume, il se connecte en premier en ethernet, sinon il utilise le wifi.
ps: est que tu as un répertoire:
/proc/acpi/"marque_de_ton_ordi"
j'avais toujours cru que les adresses étaient distribuées par dhcp dans l'ordre des requetes...! J'avais tort...
Il est possible et même fréquent de modifier le comportement d'un serveur DHCP pour qu'il attribue toujours la même IP à la même machine. La durée du bail délivré est également un élément de conservation de l'IP entre 2 requêtes d'attribution.
la machine sous windows XP ne répond pas aux pings
Sous Fedora aussi cela se paramètre dans le firewall.
l'echec du ping est peut-etre du à une politique particulière de sécurité du FAI.
L'échec du ping peut aussi être lié à l'impossibilité d'obtenir une adresse IP par DHCP (si pas de couche IP, pas de ping) ou à une mauvaise définition des serveur DNS.
salut
le fixe que j'ai avec le chip wifi ralink ne s'active au demarrage QUE si j' ai prealablement desactivé et bloqué au demarrage l'activation de eth 0(ethernet)
le kernel 2.6.23.9-85 semble choisir par defaut l'ethernet plutot que le wifi quand il a le choix, (meme sans activer NM)
Quand au dhcp, ça marche avec le wifi, mais il faut specifier le ssid (dans mon cas et sur les deux machines fedora)

Tapioca, comment on peut faire que le dhcp conserve de façon bloquée la meme ip pour les machines du reseaux, le miens( SpeedTouch 716 ourni par tele2, un peu limité coté config; le routage de port est tres galere entre autre) me donne parfois des ip de façon anarchique pour peut que je connecte une becane invitée!
Bonjour et merci pour vos avis

Pour tapioca : oui ta remarque sur le bail est juste. Par contre le ping n' a rien a voir avec le DNS car on fait un ping sur l'adresse universelle (passerelle par défaut) 192.168.1.1
donc, éventuellement, avant le dhcp. D'ailleurs ce ping n'a aucun sens car j'ai eu la curiosité de voir ce qui se passait avec une mauvaise clé WEP ou meme avec la
club-internet.box éteinte (et il n'y en a pas d'autre dans les parages) : on obtient exactement les memes messages sur l'echec du ping au démarrage ce qui prouve
qu'on essaye le ping sans etre sur que la liaison wifi existe...

Au fond le truc un peu bizarre c'est que (sans NM)
- si on a coché "activer au démarrage" il faut ensuite activer manuellement après le login et ca marche du premier coup
- si on a pas coché "activer au démarrage" il faut ensuite activer au démarrage DEUX FOIS (la première tentative est un échec avec "impossible d'activer...." et la seconde tentative marche)
@SAGITARIUS : Si tu n'as pas la main sur ton serveur DHCP, tu ne pourras pas modifier la durée du bail ou réserver une adresse IP.

@talziary : Essayer un ping sur une connexion WiFi non établie parce que tu as volontairement saisi une mauvaise clé WEP ou encore parce que tu as éteint ton AP, ça n'a vraiment aucune valeur de test : ça ne peut JAMAIS marcher !

Au lieu de chercher n'importe quoi dans tous les sens, la bonne méthode et de se concentrer sur chacune des étapes indispensables à la connexion jusqu'à trouver celle qui ne fonctionne pas :
1°) le pilote matériel
2°) la liaison WiFi
3°) le cryptage WiFi
4°) le paramétrage IP
Et ce n'est pas parce que NetworkManager refuse de te connecter que la connexion ne fonctionne pas : le problème est peut-être tout simplement lié aux limitations de NM (je suis dans ce cas là, et c'est la même chose avec wicd !)
Bonjour,

@tapioca : Je ne suis pas idiot...(enfin j'espère...). Mon essai avait seulement pour but de savoir si le message d'echec du ping au démarrage
pouvait indiquer que la liaison était établie : il est clair qu'il n'en est rien et qu'on fait un ping sans avoir verifié l'existence de la liaison

Je te rappelle que ca marche et que ma question est seulement de savoir pourquoi, sans NM, il faut activer DEUX fois ?

As tu une idée pour connaitre la raison de l'echec de la première tentative ?

Dans les messages on a :
- la première fois :
localhost kernel ADDRCONF(NETDEV_UP) : wlan0 : link is not ready
localhost dhclient: wmaster0: unknown hardware address type 801
localhost dhclient: wmaster0: unknown hardware address type 801
localhost dhclient DHCPREQUEST on wlan0 etc....sur le port 67
la requete dhcp est faite alors que la liaison est not ready et elle échoue normalement

- la seconde fois:
localhost kernel ADDRCONF(NETDEV_UP) : wlan0 : link is not ready
localhost kernel ADDRCONF(NETDEV_CHANGE) : wlan0 : link becomes ready
localhost dhclient: wmaster0: unknown hardware address type 801
localhost dhclient: wmaster0: unknown hardware address type 801
localhost dhclient DHCPREQUEST on wlan0 etc...sur le port 67
et bien sur cette fois c'est ok

A propos de la durée du bail : c'est effectivement plus de 3 jours et il faut donc etre très patient pour voir changer les adresses
localhost kernel ADDRCONF(NETDEV_UP) : wlan0 : link is not ready
localhost kernel ADDRCONF(NETDEV_CHANGE) : wlan0 : link becomes ready
la seconde ligne est la confirmation de l'établissement de la liaison.
Quand l'association est longue à venir, on peut essayer d'accélérer les choses en "forçant" le BSSID de l'AP.
Bonjour,

Il y a plus de une minute entre les deux tentatives. Sur la seconde tentative l'association est immédiate. Il s'agit peut-etre d'une problème de
délai hardware lors de la première activation de la carte...
Tu peux toujours essayer de préciser le BSSID.
Adapte et ajoute IWCONFIG="AP 00:12:34:56:78:90" dans /etc/sysconfig/network-scripts/ifcfg-wlan0.
@tapioca Bonjour et merci pour ton aide. Ca marche effectivement en forcant le BSSID avec AP 00:19:15:24:6B:AF
Sinon on se retrouve avec la carte activée et l'association non réussie et il faut reactiver une seconde fois
un mois plus tard
J'ai le même souci. Lorsque je fais un "ifup wlan0" mon wifi marche nickel mais au démarrage il ne s'active pas. J'ai donc appliqué la solution de tapioca en mettant l'adresse MAC de mon point d'accès dans le fichier /etc/sysconfig/network-scripts/ifcfg-wlan0

Mais ça ne fonctionne toujours pas, j'ai le message d'erreur suivant dans les logs systèmes :

Mar 11 11:30:07 toto kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Mar 11 11:30:07 toto kernel: audit(1205231326.861:13): avc: denied { search } for pid=2005 comm="iwconfig" name="keys" dev=debugfs ino=5306 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:debugfs_t:s0 tclass=dir

Avez-vous une idée ?