Problème d'Accès par Câble Ethernet

[Artemus24]

Salut à tous.

Je tiens à signaler que je n'ai aucun problème avec le Wifi.
Quand j'utilise mon câble éthernet, je rencontre un problème de connexion, que voici :

a) ma RPi est branchée directement sur mon Windows. L'accès se fait par l'adresse Ipv4 déclarée dans "cmdline.txt".
ou bien :
b) ma RPi est branchée sur ma Box SFR. Le serveur DHCP attribue les adresses IPv4 & IPv6 à l'interface eth0.

Le problème se situe dans le fichier "cmdline.txt" quand j'ajoute "ip=169.254.1.1" ou pas.

Si l'adresse IPv4 est présente alors a) fonctionne et b) ne fonctionne pas.
Si l'adresse IPv4 est absente alors a) ne fonctionne pas et b) fonctionne.

Pour contourner ce problème, j'ai supprimer l'adresse IPv4 dans "cmdline.txt".
J'ai créé une règle udev qui attribue une adresse de lien IPv6 dans l'interface eth0.
Cette astuce fonctionne sous BullsEye mais plus sous BookWorm.

Si je branche ma RPi sur mon Switch qui est relié à mon windows ainsi qu'à ma Box SFR, je n'ai plus aucun problème.
Sauf que je ne veux pas utiliser mon switch pour résoudre cela.

Je cherche une solution pour obtenir une adresse IP connue (APIPA) et résoudre mes deux accès ci-dessus.
Ou bien trouver une autre façon de procéder pour me connecter.

@+

[dyox]

Bonsoir Artemus24

Pour ceux qui veulent en savoir plus sur APIPA.

Je n'ai rien trouvé de flagrant dans les options de NetworkManager, puisque c'est lui qui fait maintenant la pile réseau.

Le plus plus simple est alors de charger un cmdline.txt spécifique en appuyant sur un bouton lors de la séquence de boot avec les filtres conditonnels.
Tu mets un cavalier de carte mère sur le GPIO3 et sa masse en face et on en parle plus. Le GPIO3 à une résistance de pull-up donc c'est bon.

[Artemus24]

Salut Dyox et merci de t'intéressé à mon problème.

On va prendre le problème à l'envers au lieu de tenter de résoudre quoi que ce soit.
Il est bien question des adresses APIPA quand ma raspberry Pi est branché directement sur mon Windows.
Je rappelle que le Wifi fonctionne mais que la connexion est instable.
Interroger par un "ping raspberrypi" permet de connaitre les adresses disponibles pour se connecter.
Sauf que je ne désire pas me connecter en Wifi mais bien par éthernet puisque plus rapide et plus stable.

Si je passe par putty en mettant "RaspberryPi" comme adresse IP, j'ignore celle qui sera prise, à savoir le wifi ou l'éthernet.
A la limite, si je pouvais utiliser l'adresse de lien IPv6 qui se crée entre windows et La raspberry Pi, ça serait bien.
Sauf que j'ignore comment la récupérer et en plus, elle change selon le matériel que j'utilise, puisque j'ai seize Raspberry Pi.

L'idée était alors de mettre dans le fichier "cmdline.txt", l'option "ip=169.254.1.1" comme adresse APIPA.
Cela permet d'avoir toujours la même adresse APIPA quelque soit la Raspberry Pi que j'utilise.
Sauf que, je ne peux plus brancher ma Raspberry Pi à ma Box et accéder par l'adresse IPv4 ou IPv6 qui a été attribuée par le serveur DHCP car l'attribution ne se fait pas et surtout je ne sais pas pourquoi j'ai ce problème.

Je me suis dit que le mieux était de mettre une adresse de lien IPv6 "fe80::f001" dans l'interface eth0, et de supprimer "ip=169.254.1.1" de "cmdline.txt".
Ca fonctionne très bien sous BullsEye or sous BookWork, cette astuce ne fonctionne plus du tout. Là aussi, je ne sais pas pourquoi.

Comme je l'ai dit, si je branche la Box, mon Windows et ma Raspberry PI sur le même Switch, ça fonctionne !
Oui mais, je ne vais pas utiliser mon Switch juste pour me connecter en headless car le but est d'accéder a la Raspberry Pi sans avoir internet.
Donc le switch ne résout en aucune façon mon problème d'accès en headless depuis windows.

Comme ce lien l'indique, cela aurait été simple si à l'avance nous connaissions l'adresse APIPA qui est utilisée pour se connecter en headless à la Raspberry Pi.

Une remarque concernant le lien vers APIPA, le sujet date de 2018 et l'OS à l'époque était Stretch et depuis, il y a eu Buster puis BullsEye où cette astuce fonctionnait parfaitement, mais plus sous BookWorm, d'où mon sujet pour tenter de trouver une autre façon de faire.

A l'époque, j'avais attribué une adresse IPv4 du genre "192.168.1.80", sauf que cela ne fonctionne pas puisque seul des adresses APIPA permettent un accès direct à la Raspberry Pi
L'idée était alors d'attribuer une adresse de lien IPv6 "fe80::f001" à l'interface eth0 par une règle udev.
Cette astuce fonctionnait bien puisque je pouvais utiliser ma Raspberry Pi aussi bien branchée à mon windows et à ma Box sous Buster et sous BullsEye.
Mais cela ne fonctionne plus sous BookWorm car l'adresse de lien n'apparait pas quand je n'ai pas "ip=169.254.1.1" dans le fichier "cmdline.txt".

Je ne suis pas très expérimenté en ce qui concerne les aspects réseaux mais le sujet m'intéresse.
Je cherche à créer une interface indépendante de eth0 où je pourrais accéder en headless par une adresse connue à l'avance.
Cela me permettra de ne pas perturber l'attribution des adresses IP du serveur DHCP de la Box à l'interface eth0.

En l'état, c'est-à-dire sans installer quoi que ce soit d'autre dans ma Raspberry PI, comment créer une interface pour accéder en headless ?
Sous Debian, j'utilise NetworkManager à partir du bureau GNOME.
Il faut dire que le problème est totalement différent car Debian se trouve sur un disque externe branché à mon Asus.
Asus est le seul ordinateur portable que j'utilise aussi bien avec mes windows 10 & 11 ainsi qu'avec Debian.
Alors qu'avec mes Raspberry Pi, j'accède depuis Windows en Headless avec Putty.

C'est NetworkManager que je dois utiliser pour trouver ma solution, si elle est possible.
Et non pas "networking", pour configurer les aspects réseaux dans "/etc/network/interfaces.d".

Je n'avais pas pensé à ta solution, utiliser un cavalier qui va conditionner le démarrage par l'intermédiaire des filtres conditionnels.
A vrai dire, ce n'est pas ce que je recherche car je ne désire plus avoir l'option "ip=169.254.1.1" dans le fichier "cmdline.txt".
Mais de trouver une astuce qui fonctionne comme celle en udev. Pourquoi ?
Parfois je branche ma Raspberry PI directement sur mon Windows alors que celle-ci était déjà branché à ma Box.
Je perds la connexion à l'internet en éthernet mais avec la règle udev, l'attribution de l'adresse de lien ipv6 se fait automatiquement.
Et je peux ainsi me connecter en headless sans problème, d'où la souplesse d'utilisation que je recherche.

Qu'est-ce qui fait qu'une règle udev ne fonctionne pas si aucune adresse IP n'a été attribuée sous BookWorm ?

Ou une autre solution totalement réseau si possible.

Merci.
@+

[Artemus24]

Je dois utiliser NetworkManager.

1) je supprime le "id=169.254.1.1" du fichier "cmdline.txt" qui n'a plus aucune raison d'être. D'ailleurs, sous BullsEye, je ne l'utilisais plus à cause de ma règle udev qui attribuait une adresse de lien IPv6.

2) Je vais dans realvnc/vnc viewer sous windows et je me connecte au bureau pour le compte root. En haut et à droite, je clique sur l'icône correspondant aux réseaux. Je sélectionne "advanced options" puis sur "Modifier les connexions". Si j'ai quelque chose dans éthernet, je le supprime. Je crée une nouvelle configuration, en donnant un nom parlant et en mettant pour IPv4 & IPv6 connexion "Automatique (DHCP)". J'ajoute pour l'IPv6, dans "Adresse Statique Supplémentaire", mon adresse de lien IPv6 "fe80::f001/128". J'enregistre et je sors de VNC Viewer. Je reboote la Raspberry et je fais le test.

--> branchement à la Box SFR, j'ai bien mes deux adresses IPv4 & IPv6 qui sont fournies par le serveur DHCP.
--> branchement à Windows, je peux me connecter en utilisant mon adresse de lien IPv6 "fe80::f001".

Après quelques tests, je constate que j'ai beaucoup de pertes de connexion, même si ma Raspberry PI est branchée à mon Windows. Je constate que mon adresse de lien IPv6 "fe80::f001" disparait au bout de quelques secondes d'utilisation. J'ai supprimé les règles udev pouvant supposer qu'elles seraient perturbatrices, mais rien n'y fait, elle disparait quand même. Je débranche mon câble éthernet et je le rebranche et je constate que l'adresse de lien réapparait, puis disparait. Je ne comprends pas.

Edit: j'ai scindé en deux configurations différentes mes deux accès par l'interface eth0 dans NetworkMananger :
--> Ethernet_1 : branché à la Box SFR avec adresses automatiques IPv4 & IPv6 au serveur DHCP.
--> Ethernet_2 : branché à mon windows avec adresses manuelles IPv4 "169.254.1.1" et IPv6 "fe80::f001".

Ca à l'air de mieux fonctionner quand je suis branché à Windows (Ethernet_2).
Je n'ai plus les pertes de connexions ni les lenteurs.
Mon adresse de lien IPv6 ne disparait plus au bout de quelques secondes.

Ca ne fonctionne pas quand je suis branché à ma Box SFR (Ethernet_1).
Je n'ai aucune adresses IP et je constate que ce sont celles de Ethernet_2 que j'ai.
NetworkManager prend la première configuration dans la liste sous VNC Viewer et il se trouve que c'est Ethernet_2.
Si je fais en sorte d'avoir Ethernet_1 en premier, mon problème est inversée.

Du coup, je ne sais pas comment résoudre mon problème avec NetworkManager.

[Artemus24]

Je possède des clefs USB/RJ45 de la marque StarTech que je vais utiliser pour me connecter en headless sur mes Raspberry Pi. J'ai créé une configuration pour l'interface eth0 avec une connexion "automatique (DHCP)" sans mettre l'adresse de lien IPv6. Je l'ai testé en branchant ma Raspberry Pi sur ma Box SFR et ça fonctionne .

J'ai créé une configuration pour chacune de mes clefs SarTech où j'attribue uniquement l'adresse de lien IPv6 "fe80::f00x" où x prend un chiffre de 1 à 2. J'ai fait le test en headless et j'arrive tout le temps à me connecter avec Putty. La connexion est rapide et stable et c'est ce que je recherhce. C'est une solution qui nécessite de changer mes habitudes puisque je n'utilise pas les StarTech pour me connecter à mes Raspberry PI. Je les ai acheté pour mes RPi ZERO v1.3 sans wifi et sans ports RJ45 mais avec une prise micro-USB.

Tout ça à cause de quoi ? De la Wifi où j'ai des ralentissements ainsi que des coupures de connexions. Dans ces conditions, il est difficile de travailler !

Jusqu'à présent, le seul moyen pour travailler sans problème est de faire un branchement directement de la Raspberry Pi vers mon windows. Cette astuce a été mise en place depuis Jessie ! Je suppose que le passage à NetworkManager a dû changer quelques fonctionnalités dans la Raspberry PI.

Si vous savez comment rendre les connexions Wifi plus stables, je suis preneur. Ce qui est bizarre, mes connexions Wifi sous windows ou sous Debian sont stables. Est-ce dû à la puce Wifi de la Raspberry Pi ?

[dyox]

salut,

Merci pour tes retours.

Pour améliorer ton wifi :
- changer de canal en commençant par le 1 (si c'est possible)
- désactiver le BT
- changer de driver si c'est possible. C'est Broadcom le fabricant ?

C'est tout ce qui me vient à l'esprit.

Bons essais !

[Artemus24]

Je viens de remonter un vieux sujet où je poursuis ma recherche sur l'instabilité du Wifi de la Raspberry PI !

[dyox]

autres choses :
- fait tes essais en 2.4 GHz
- choisis Singapour comme country. C'est le pays sans restrictions sur les normes, tout est à fond.

[Artemus24]

Merci pour tes idées.

Où est-ce que je renseigne le pays dans Network Manager ?
Je n'utilise plus du tout "wpa_supplicant" dans BookWorm.

[dyox]

Regarde dans raspi-config
Et il y a plusieurs choix pour l'insérer si tu analyses le script.

Code : Tout sélectionner

get_wifi_country() {
  CODE=${1:-0}
  if is_installed crda && [ -e /etc/default/crda ]; then
    . /etc/default/crda
  elif grep -q "cfg80211.ieee80211_regdom=" "$CMDLINE"; then
    REGDOMAIN="$(sed -n 's/.*cfg80211.ieee80211_regdom=\(\S*\).*/\1/p' "$CMDLINE")"
  elif systemctl -q is-active dhcpcd; then
    REGDOMAIN="$(wpa_cli get country | tail -n 1)"
  else
    REGDOMAIN="$(iw reg get | sed -n "0,/country/s/^country \(.\+\):.*$/\1/p")"
  fi
  if [ -z "$REGDOMAIN" ] \
     || ! grep -q "^${REGDOMAIN}[[:space:]]" /usr/share/zoneinfo/iso3166.tab; then
    return 1
  fi
  if [ "$CODE" = 0 ]; then
    echo "$REGDOMAIN"
  fi
  return 0
}

do_wifi_country() {
  if [ "$INTERACTIVE" = True ]; then
    value=$(sed '/^#/d' /usr/share/zoneinfo/iso3166.tab | tr '\t\n' '/')
    oIFS="$IFS"
    IFS="/"
    #shellcheck disable=2086
    REGDOMAIN=$(whiptail --menu "Select the country in which the Pi is to be used" 20 60 10 ${value} 3>&1 1>&2 2>&3)
    IFS="$oIFS"
  else
    REGDOMAIN=$1
  fi
  if ! grep -q "^${REGDOMAIN}[[:space:]]" /usr/share/zoneinfo/iso3166.tab; then
    if [ "$INTERACTIVE" = True ]; then
      whiptail --msgbox "$REGDOMAIN is not a valid ISO/IEC 3166-1 alpha2 code" 20 60
    fi
    return 1
  fi
  sed -i \
    -e "s/\s*cfg80211.ieee80211_regdom=\S*//" \
    -e "s/\(.*\)/\1 cfg80211.ieee80211_regdom=$REGDOMAIN/" \
    "$CMDLINE"
  if is_installed crda && [ -e /etc/default/crda ]; then
    # This mechanism has been removed from Bookworm and should no longer be used
    rm -f /etc/default/crda
  fi
  if ! ischroot; then
    iw reg set "$REGDOMAIN"
  fi

  IFACE="$(list_wlan_interfaces | head -n 1)"
  if [ "$INIT" = "systemd" ] && [ -n "$IFACE" ] && systemctl -q is-active dhcpcd; then
    wpa_cli -i "$IFACE" set country "$REGDOMAIN" > /dev/null 2>&1
    wpa_cli -i "$IFACE" save_config > /dev/null 2>&1
  fi

  if [ "$INIT" = "systemd" ] && ! ischroot && systemctl -q is-active NetworkManager; then
    nmcli radio wifi on
  elif hash rfkill 2> /dev/null; then
    rfkill unblock wifi
  fi
  if is_pi; then
    for filename in /var/lib/systemd/rfkill/*:wlan ; do
      if ! [ -e "$filename" ]; then
        continue
      fi
      echo 0 > "$filename"
    done
  fi
  if [ "$INTERACTIVE" = True ]; then
    whiptail --msgbox "Wireless LAN country set to $REGDOMAIN" 20 60 1
  fi
}