Voisinages réseau local

Je vous soumets un petit problème d’adresses dans un réseau local.
Configuration : une livebox, deux PCs portables sous Debian - Mate (Jessie :sweat_smile: oui, je sais…, mais j’attends d’avoir le temps), un téléphone portable sous android, des disques durs externes sur les PC ou la livebox, un disque réseau multimedia, une imprimante-scanner ethernet. Tout le monde en DHCP géré par la box, en interfaces ethernet ou wifi suivant les humeurs et les possibilités de chacun. Seule l’imprimante a eu droit à une adresse ip fixe, pour des raisons historiques et c’est plus simple pour le scan en particulier.
Les PCs ont des répertoires partagés CIFS via samba en mode utilisateur (mate gère en gros comme gnome), donc pas de montages réseau statiques via fstab.

1er cas de figure : livebox2 et Jessie. Tout baigne, les données partagées sont accessibles de partout, via samba pour les PCs et disques durs, via ftp pour Android. Je n’ai rien eu à faire concernant la résolution des noms, les adresses ip sont manifestement transmises en dynamique (ou statique si je le veux) par la box.

2ème cas de figure : Orange m’attribue une Livebox3 (livebox play) pour cause de passage à la fibre. Toute la partie protocoles http et ftp fonctionne à merveille, chacun retrouve son ip (4 et 6) les partages réseau CIFS sont en rade. Une tentative d’exploration du réseau à partir de Caja (le Nautilus de Mate) part en boucle infernale dans “gvfsd-smb-browse” qu’il faut tuer sauvagement pour reprendre la main. Les serveurs de dossiers partagés fonctionnent, comme j’ai pu le constater au cas suivant.

3ème cas : Livebox3 et un PC en live-DVD Stretch. Sans rien faire Caja retrouve son environnement réseau, l’autre PC toujours sous Jessie présente bien ses dossiers partagés via Samba, comme il se doit. La partie serveur fonctionne donc bien. Mais évidemment le PC sous Jessie ne voit pas l’autre, son client Samba est toujours dans les choux.

Le fait que dans le cas 2 la résolution des adresses ne se fait pas est confirmé par les outils en ligne de commande (smbclient, smbtree). J’accède péniblement aux dossiers partagés si je donne l’adresse ip du serveur, mais pas par le nom.
Un patch qui fonctionne, mais très “sale” : mettre l’adresse ip de la box en dur comme adresse de serveur wins dans smb.conf. Mais cela manque d’élégance et de portabilité si je vais chez un copain qui n’a pas une livebox !

Si quelqu’un a une piste d’explication je suis intéressé; je soupçonne une salade ipv4/ipv6, mais je ne suis pas sûr. Il va bien falloir migrer vers stretch quand j’aurai le temps.

À-priori, non.
Je pencherais plutôt pour une histoire de latence liée à IPv6. Comme tu as activé, il cherche à atteindre Samba sur IPv6, normalement en premier… avant d’interroger la couche IPv4.
Et, là, ça peut être très long.
Par contre, je ne sais pas si Samba gère l’IPv6 ?! à vérifier…

J’y arrive très bien, sur mon réseau @home, ayant un server OMV, et des partages Samba. Par contre, je cible l’adresse IP (IPv4), en passant par gigolo. Mes “clients” sont, soient sous Sid, soit sous OpenBSD.

Bon, ok, cela n’aide pas à résoudre ton problème… mais cela te permet de savoir que c’est possible assurément.

Question, juste pour ma culture : Mate se base-t-il sur gvfs pour accéder au partage Smb ?!
Ou ils ont réécrit une “lib” concurrente ?!

Je pense que tu as raison. Ma solution est bien de fournir l’adresse ipv4 du serveur wins. Mais tout cela est un peu “bricolesque”. Le plus drôle est que network-manager, que j’utilise pour tout, met bien à jour /etc/resolv.conf qui fournit en dynamique (à la connexion DHCP) les bonnes adresses en ipv4 et ipv6. Côté Samba j’ai sur mon PC une version 4.x alors que livebox (linux embarqué) en est à 3.y comme quoi… Mais pour être up to date ils ont du mettre le paquet sur ipv6, évidemment.

Oui, Mate a repris gvfs avec sa souplesse… et ses obscurités (un bon exercice d’enquête : comment accéder aux montages gvfs en ligne de commande ? Quand j’ai trouvé je me suis empressé de créer un lien qui va bien pour ne pas oublier). Mate est en fait un fork de gnome2.

1 J'aime