bonjour,  
j'essaye de comprendre comment je dois configurer mon beaglebone.
 
voici mon /etc/network/interfaces:

 
La 3G c'est sur le terrain, les 2 eth0 c'est pour le connecter à l'internet pendant le dépannage et  usb0, c'est pour rentrer dedans directement pendant le dépannage (finalement c'est la méthode la plus stable, le connecteur pour tty0 est perdu sous le cape).
 
Parfois je perds mon accès aux noms de domaine, et en allant voir mon resolv.conf, il y avait ça dedans:

qui semble être arrivé par un coup de DHCP sur eth0 (ça semble l'explication la plus logique, c'est bien le réseau dans lequel je l'ai branché, et j'avais mis les DNS google en dur dans /etc/resolv.conf avant).
 
Comment se fait-il qu'il n'écrase pas le resolv.conf avec les autres interfaces quand eth0 n'a pas de câble ?
 
Comment je peux faire pour qu'il mette ce que le DHCP lui dit s'il dit quelque chose, et les DNS google sinon ?
 
mon uname:

 
merci pour votre aide.

T'aurais pas le paquet resolvconf d'installé et d'activé sur ton système des fois ?

Et sinon, tu utilises quel client dhcp sur ton système ? (nom et version de la distrib si disponible ? )
Pour la distrib, un cat /etc/lsb-release ou un lsb_release -idrc  peut aider
 
EDIT : un lien qui donne des exemples (bcp) des endroits où peuvent se trouver les infos de version suivant les distribs

 
on est pas sortis du marrais.
 

ça t'aide ça ?
 
 

 
 
dans syslog, j'ai tout le temps des trucs comme ça:

je sais pas si ça répond exactement à la question d'identifier le client dhcp (je savais pas qu'on a le choix, WTF on a le choix, et je sais pas quel est le menu)

ok ... à priori, si resolvconf est pas dans le coup, faut regarder la conf du client dhcp, y'a de grandes chances qu'il y ait à activer désactiver/activer une option dans la config de celui-ci
Le client dhcp que tu utilises se base sur les deux paquets :
isc-dhcp-client
isc-dhcp-common
 
Par contre, udhcpd  ça contient plutôt le nécessaire pour exploiter un (mini) serveur dhcp sur ton beaglebone ...

A tout hasard ... tu as vérifié si quand le cable ethernet est débranché, ton interface ethxx récupère une addresse IP ? (si oui, du genre ?)

Je viens de voir un truc dans ta conf réseau ...
A priori, le

est pas nécessaire
 
Le

est suffisant pour que la conf auto de eth0 démarre quand on branche un câble dessus (tu dois avoir un service/démon ifplugd qui tourne et qui s'occupe de ça, va voir sa conf, y'a ptet des choses intéressantes pour toi dedans)
 
 
Le auto vérifie pas que l'interface est up (et la connectivité assurée) au niveau en dessous (1) et c'est pour ça que tu vois passer les DHCPDISCOVER dans ton syslog

Et à priori, ton interface eth0:1  est toujours montée, eth0 branchée ou pas

merci pour ton aide
 
 
cable débranché:  

 
je teste le changement au niveau de auto.

ok, maintenant, faut trouver qui écrase ton resolv.conf de façon auto

Des mans qui te seront utiles, AMHA
http://linux.die.net/man/8/ifplugd
http://linux.die.net/man/5/ifplugd.conf
http://linux.die.net/man/8/ifplugstatus

Regarde de préférence ceux correspondant aux paquets installés sur ton beaglebone (soit sur le beaglebone, soit chez Debian, directement)
histoire d'avoir les infos les plus exactes

en fait c'est pas exactement l'écrasement de resolv.conf qui m'ennuie (on peut imaginer que je le branche dans un réseau local qui a des dns intéressants), c'est surtout qu'il le remette pas comme il faut quand il a fini, mais peut-être que le allow-hotplug est la réponse (genre ce niveau croyait que le lien était toujours actif et donc a pas remis resolv.conf en état).
 
du coup, est-ce qu'il est malin de mettre  allow-hotplug à tout le monde ?

T'aurais pas un gestionnaire de connections genre NetworkManager qui tournerait en // des fois, non plus ?

c'est quoi ?

Tiré d'ici

En fait, ton cas de figure, c'est celui là.
Tu as besoin d'adapter ta conf réseau (la résolution de nom en particulier) en fonction des interfaces dispo et/ou qui montent descendent

Et pour ça faut utiliser un gestionnaire genre ifplugd (pour les plus anciennes versions) ou NetworkManager (par exemple, pour les versions plus récentes)
qui réagira comme tu l'auras spécifié, dans leurs fichiers de confs respectifs, aux évènement up/down sur les interfaces, et avec aussi un histoire de priorités entre
les différentes interfaces

Ce que tu décris (le fichier resolv.conf) me laisse penser que tu as un gestionnaire de connectivité installé et qui fonctionne
Reste plus qu'à déterminer lequel et le configurer pour qu'il fasse exactement ce que tu veux au niveau de ta conf réseau (dns, routage, etc ... )

Est ce que c'est possible que tu m'envoies la sortie de la commande ps ax (executée en tant que root)
si y'a pas de choses sensibles à dévoiler (tu peux me laisser ça en MP) ?
Je pense que j'arriverai à deviner assez vite ce qui tourne et gère/monitore tes connexions réseau

le seul indice que j'ai trouvé c'est un service "networking.service" dans systemctl
 
mais je trouve pas comment il se configure.

ok, alors déjà, rapidement ;

Tu dois gérer du WPA/WPA2 sur ton beaglebone ?
 

A priori, il a une bonne tête de coupable
wicd est un gestionnaire de connectivité (pour le wifi mais aussi pour les réseaux filiaires) alternatif à NetworkManager
Faut regarder du côté du/des paquets wicd / wicd-daemon (plutôt le deuxième  à priori) pour connaitre
la liste des fichiers du/des paquets et savoir où il(s) planque(ent) leur fichier de conf
 
Et y'a de grandes chances que on bonheur se trouve dedans

Par contre, je viens de me rappeler d'un truc ... je suis plus sur qu'il soit encore développé/maintenu ...

EDIT : les dernières modifs datent de 2013
En plus wicd, de mémoire, j'utilisais ça à l'époque où je voulais un truc plus simple (et surtout qui fonctionnait ) que NetworkManager pour gérer la config réseau de mes pc portables

Mais depuis NetworkManager a bien évolué et j'ai laissé tomber wicd ...

Et je crois me rappeler qu'il stocke ses préférences/réglages (config réseau, différents profils filaires réseaux genre bureau, maison, café, etc ... ) au niveau du répertoire utilisateur, pas au niveau système

Si c'est bien lui qui gère la connectivité réseau du beaglebone, je suis pas persuadé que ce soit le meilleur outil pour ça
EDIT2 : J'ai ptet dit des bêtises pour l'emplacement des fichiers de config de wicd
A voir comment c'est avec Wheezy

merci, je vais aller voir ce truc (jamais entendu parler)

(pour répondre sur WPA: autant que je sache y'a pas de wifi sur le BB, ça doit être pour les gens qui mettent une clef wifi USB)

De toutes façons, quand j'ai vu wicd après avoir vu wpa_supplicant, j'ai compris la raison de sa présence
Ils vont toujours ensemble ces deux là, wicd ayant été conçu comme une alternative plus simple/légère/qui fonctionne à NetworkManager pour les utilisateurs nomades, et plus particulièrement pour gérer le wifi et tous les réseaux associé
wicd s'occupe de tout, sauf de tout ce qui concerne WEP/WPA/WPA2, c'est le rôle de wpa_supplicant, wicd lui passe la main lors des négociations de clés (il les stocke notamment) & co

https://wiki.debian.org/fr/WiFi/HowToUse#Wicd
 
http://manpages.ubuntu.com/manpage [...] onf.5.html
http://manpages.ubuntu.com/manpage [...] onf.5.html
http://manpages.ubuntu.com/manpage [...] onf.5.html
 
C'est tiré de Ubuntu, mais ça doit être à peu de chose près pareil pour Debian Wheezy
 
Faut que tu regardes cette partie là, entre autres, pour tes histoire de dns :

 
Sinon, de mémoire, doit y'avoir des outils en ligne de commande ( wicd-cli )et une interface texte ( wicd-curses ) pour configurer le bordel sans passer par les fichiers

'tain j'y capte rien tout à l'air par défaut dans wicd, et la doc du fichier de conf est succincte : http://manpages.ubuntu.com/manpage [...] onf.5.html
 

Les dns sont différents quand tu branches ethernet et quand tu branches l'usb ?

je viens de regarder, y'a comme une valve: eth0 écrase le DNS dans /etc/resolv.conf , mais brancher le GPRS ne remet pas le DNS de google.

wicd ne voit pas le GPRS, même quand il est connecté.

définit les dns du grps comme dns globaux
 
genre ces paramètres là dans  wicd-manager-settings.conf  

 
et tu lui dis dans  wicd-wired-settings.conf  d'utiliser temporairement les dns renvoyés par le dhcp

 
wicd rétablira les dns globaux, ceux du gprs donc, une fois la connexion filaire coupée
 
Est ce que c'est un fonctionnement satisfaisant ou pas ?

je regarde, merci pour ton aide en tout cas.
 
C'est un peu long à tester, genre là j'ai branché le cable eth0, mais on dirait que personne d'intéressant n'a reçu le mémo:

 
aucune trace de dhclient, de wicd ou de ifup

en fait y'a rien de hot plug, eth0 est tout le temps up (sans adresse IPv4), et quand je branche le cable, il prend pas d'adresse.
 
le gprs non plus, si je boot sans gprs, rien ne se connecte tout seul.

tu vois bien wicd-daemon.py et monitor.py dans la liste des processus, après avoir booté ?
 
Si oui, le fichier /etc/resolv.conf a quelle tête ?

'tain des fois ça voit le hot plug et des fois ça le voit pas
 
c'est un cauchemar
 
 

(j'ai pas remis google à la depuis quelques temps, donc il reste comme ça)

avahi ...  arf ...
vous avez pas besoin de mDns/rendez vous and co dans vos éoliennes, non ?  parce que sinon, tu peux le virer ou juste désactiver du démarrage
 
Mmmm   un doute m'habite .... quel est le contenu du fichier /etc/nsswitch.conf (notamment de la ligne  hosts: ..... ) ?
Ce fichier désigne l'ordre de préférence pour choisir la méthode de résolution de noms (fichiers genre /etc/hosts, dns, mdns, etc ... )
Ca peut avoir son importance, surtout si mdns est devant tout le monde

 
j'ai l'impression de jouer un jeu de table contre un gamin de 3ans, il invente tout le temps une nouvelle règle

et pour le hotplug, je pense pas que ce soit wicd qui le gère, lui il est à l'autre bout de la chaine, et reçoit les évènement de "hotplug"
 
je pense que ifplugd doit être lancé (ça ou autre chose qui reçoit les évènements de hotplugs renvoyés par le kernel, et monte la/les interfaces correspondantes,  ça peut être fait via udev aussi je pense)
 
en fait là il manque le lien entre l'évènement généré par le kernel  et l'évènement "interface up" qu'attend wicd, le petit bout de glue
Soit hotplugd, soit via udev

mdsns sur de l'embarqué mouais
 
Vire moi cette cochonnerie de  mdns4_minimal [NOTFOUND=return]  (et même le mdns4 final   si vous en avez pas besoin )  
Il foutait bien la grouille déjà, il empêchait une résolution dns classique  (en gros si le sous ensemble mdns répondait "not found" à une requête dns, il passait même pas la main au" vrai dns" )

je sais pas quoi faire de cette info.