Pas de wifi si pas d'ethernet

[piper]

bonjour à tous, je tombe sur un os qui m'énerve pas mal (voir le titre)
J'ai ressorti pour un projet, un vieux Raspberry Pi2, une SD Card neuve, je lui ai installé bullseye, sans bureau
Je me lance dans le dev du projet, tout est ok (il est basé sur un socket TCP donc le réseau est primordial)

Là tout fonctionne et puis je me dis : c'est chiant le câble ethernet mais au fait, j'ai un dongle wifi qui traine !

Je branche mon dongle, je paramètre le wifi, tout est ok :
L'ethernet fonctionne et le Wifi aussi

Je débranche le câble réseau et c'est le drame :
Le wifi ne fonctionne que si le câble réseau est branché !

Christian Clavier, dirait "C'est quoi ce binz" ?

Pour être plus précis :
Je boote le Pi avec son câble réseau
Je me connecte en ssh avec le nom du pi
ifconfig me dit :
eth0 a l'ip 192.168.1.58
wlan0 a l'ip 192.168.1.76

Je quitte ssh
Je relance une connexion ssh avec l'ip wifi : 192.168.1.76, tout est OK

Je débranche le câble réseau et je perds aussitôt toute connexion avec le Pi (qui utilisait le wifi, puisque j'avais une session ssh vers l'ip wifi du pi)) !!!!
Je rebranche le câble réseau du pi et je retrouve ma connexion ssh via le wifi du pi !! (suffit de faire un restart de la session putty, même pas besoin de redonner un username)

Une recherche sur google m'a démontré que ce problème n'est pas nouveau !

Mais la solution proposée date du monde des dinosaures (kernel 4.x, et mon bullseye est en kernel 6.1 !)
Pour être plus précis, la solution que j'ai trouvé sur google exploite un fichier interface (de l'époque de jessie... il y a ... au moins 10 ans ) qui n'est plus du tout utilisé sur bullseye.

Quelqu'un a une solution ?

Si quelqu'un remande : les routes me semblent bonnes (et je n'y ai pas touché)

Code : Tout sélectionner

 route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    202    0        0 eth0
0.0.0.0         192.168.1.254   0.0.0.0         UG    303    0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0

[jelopo]

Bonjour,

visiblement, lorsque eth0 n'est plus connecté, les paquets tentent quand même de sortir par là !
J'ai trouvé cet page sur le net proposant l'approche d'un pont peut être une piste ?)

https://unix.stackexchange.com/question ... me-network

A tester.

A+

[piper]

Bonjour,
Effectivement, vous avez, semble-t-il mis le doigt sur la cause :

Si je me connecte à un wifi dont la classe d'ip est différente de celle de eth0 alors tout est opérationnel

Mais la solution proposée, basées sur des routes orientée "IP" ne convient pas : en effet, dans mon contexte, il faut que cela fonctionne quelques soit la classe d'ip que la box fournira
Je veux dire que je ne peux pas écrire des règles en dure sur 192.168.0 (ou 1 ou 2).0

Et créer un bridge n'est pas une solution non plus car si l'utilisateur connecte à la fois eth0 et wlan0 à son réseau, cela pourrait générer une boucle locale catastrophique (comme ils seront sur la même classe d'ip)

[Artemus24]

Salut Pipper.

J'ai fait le test avec une carte Micro SD contenant Buster et bien sûr ma vieille Raspberry Pi 2B.
J'ai un dongle WiFi de la marque Ourlink pour faire le même test que tu rencontres.
Chez moi, ça fonctionne parfaitement, mais il faut être patient.

Si ta RPi 2B est branchée via un câble éthernet, le WiFi est immédiat, et c'est ce que tu as constaté.
Enfin tout est relatif car c'est quand même plus long qu'avec mes RPi 4B sous BookWorm.

Il se trouve que le démarrage réseau commence toujours par le câble éthernet.
Si tu ne l'as pas branchée, la connexion réseau va mettre un temps plutôt long avant de constater qu'elle ne se fera pas.
Après disons 2 minutes (ben oui, c'est long), la connexion va se poursuivre sur le dongle WiFi.
Elle va se mettre à clignoter et enfin tu auras une connexion réseau.

Je n'ai pas mis les adresses IP en dure dans Buster et tout se fait via ma BOX 8 SFR, donc par le DHCP IPv4 & IPv6.
Je constate depuis que j'ai cette nouvelle BOX 8 SFR (depuis février 2024), je n'ai plus d'instabilité WiFi.

@+

[destroyedlolo]

Salut,

Si je me connecte à un wifi dont la classe d'ip est différente de celle de eth0 alors tout est opérationnel

Je ne sais pas ce que tu entend par "classe d'IP". Les classes d'IP (A,B,C ...) indiquent le nombre d'IP qui te sont réservées en fonction de ton adresse : 10.x.x.x est une classe B donc le masque de sous réseau est par défaut 255.255.0.0 alors que 192.168.x.x est une classe C donc 255.255.255.0.

Bref, je pense que vous parlez tous ici de réseau où 192.168.0.x est différent de 192.168.1.x comme tu l'indiques dans :

Mais la solution proposée, basées sur des routes orientée "IP" ne convient pas : en effet, dans mon contexte, il faut que cela fonctionne quelques soit la classe d'ip que la box fournira
Je veux dire que je ne peux pas écrire des règles en dure sur 192.168.0 (ou 1 ou 2).0

Bref, si tu es sur le même réseau, c'est normal que ca ne marche pas ... temporairement : les trames vont passer par le chemin le moins couteux, donc le filaire et ne basculeront sur le WiFi que lorsqu'il aura détecté que le filaire n'est plus fiable.

2 solutions :

• Rebooter avec seulement le wifi
• rafraichir la table de routage

Je pense (donc je suis, hahaha), que un simple :

Code : Tout sélectionner

ipdown eth0

ou truc du genre devrait suffire à dévalider les routes vers le filaire.

A tester donc.

[Artemus24]

Salut DestroyedLolo.

Bref, je pense que vous parlez tous ici de réseau où 192.168.0.x est différent de 192.168.1.x comme tu l'indiques dans :

Ce n'est pas les adresses qui déterminent les sous-réseaux mais les masques.
Si tu utilises cet unique masque "192.168.0.0/16" alors tes deux adreses font parties du même sous-réseau.
Si maintenant tu utilises "192.168.0.0/24" et "192.168.1.0/24" alors tes deux adresses ne sont pas dans le même réseau.

les trames vont passer par le chemin le moins couteux, donc le filaire et ne basculeront sur le WiFi que lorsqu'il aura détecté que le filaire n'est plus fiable.

C'est ce que j'ai testé sans branché mon câble éthernet et après disons deux minutes, j'ai pu obtenir enfin le WiFi.

Oui, tu peux aussi désactiver par "ipdown eth0" les accès par le câble éthernet.

[destroyedlolo]

Yo !

https://fr.wikipedia.org/wiki/Classe_d%27adresse_IP

Et le "masque par défaut" n'était pas anodin

[piper]

Bref, si tu es sur le même réseau, c'est normal que ca ne marche pas ... temporairement : les trames vont passer par le chemin le moins couteux, donc le filaire et ne basculeront sur le WiFi que lorsqu'il aura détecté que le filaire n'est plus fiable.

Ben non : je ne parle pas d'accès par internet mais d'accès par le réseau local !

Depuis des années, j'ai des postes en wifi + filaire accessible sur la même classe en ssh par l'un et l'autre (ex : 192.168.0.4 et 192.168.0.5 et même masque)
Seuls certains Pi rechignent à l'accepter
Pariculièrement si on met une carte ethernet en USB sur un Pi Zéro en plus de son Wifi
Ou si un met un dongle Wifi sur un Pi2
Alors que sur un Pi3,4,5 : pas de soucis
Sur un PC portable (wifi + filaire) sous Fedora : pas de soucis
Sur un PC fixe filaire + dongle Wifi sous Fedora : pas de soucis