Pas de 127.0.0.1 quand pas de réseau

Bonjour,

j’ai un rasp 3 dans une armoire en métal, j’ai donc désactivé le wifi ( j’ai tenté en arrêtant le service ou dans le fichier config du /boot) . Je n’ai pas de connexion réseau car c’est une machine qui est autonome… j’ai un programme qui tourne, en l’occurrence domoticz, sur le 127.0.0.1.

quand il n’y a pas de câble réseau de branché, je n’ai pas accès au 127.0.0.1, je ne peux même pas le ping

Quand je fais un ip a j’ai

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

sur le netstat -nat, j’ai bien le service de domoticz en écoute

dès que je branche le câble réseau ( je le branche sur mon PC par exemple) , je retrouve l’accès au localhost. Je peux le ping et je peux utiliser domoticz

dans mon fichier /etc/hosts j’ai :

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1               raspberrypi

du coup si je ping localhost j’ai une réponse… Par contre c’est l’adresse en IPv6 qui répond.

je suis sur bullseye

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian

Si quelqu’un a un idée, je suis intéressé :slight_smile:

hello,

la commande ds un terminal pour gérer le wifi c’est rfkill
sudo apt install rfkill
pour connaître l’état des réseaux wifi et bluetooth:
rfkill list
pour stopper le wifi :
rfkill block 0 // 0 étant le 0: phy0: Wireless LAN issue du list
pour le reactiver
rfkill unblock 0

pour le reste ça se complique …

là c’est possible que tu aies changé un truc qui fallait pas ! ( le service networking peut être )
sudo systemctl status networking.service
normalement ça doit répondre un truc comme ça :
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor pr>
Active: active (exited) since Fri 2022-12-30 06:00:23 CET; 13h ago
Docs: man:interfaces(5)
Process: 551 ExecStart=/sbin/ifup -a --read-environment (code=exited, statu>
Main PID: 551 (code=exited, status=0/SUCCESS)

sinon
sudo systemctl enable networking.service
et reboot

normalement au démarrage de la machine tu as au minimum l’adresse localhost (127.0.0.1) que tu peux pinguer uniquement depuis cette machine ( en fait un réseau interne à la machine )

quand tu branches un câble ça doit réveiller un service ( peut être ifupdown-pre.service) qui active le localhost…

enfin comme ds ton /etc/hosts tu as le même nom localhost pour ipv4 et ipv6 ( c’est normal ) il choisi de répondre sur ipv6… ( ping -4 localhost te répondra sur l ip v4 )

hello,

merci pour ton retour

pour arreter le wifi et le BT, j’ai mis ça dans le fichier config.txt mais j’avais testé avant avec le même resultat.

dtoverlay=disable-wifi
dtoverlay=disable-bt

je suis revenu à la situation initiale et j’ai joué avec rfkill ( comment j’ai pu oublier cette commande :))

0: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

au niveau service réseau a priori c’est bon car j’ai toujours mon eth qui fonctionne, donc normalement le probleme ne devrait pas venir de la

● networking.service - Raise network interfaces
     Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: e>
     Active: active (exited) since Sat 2022-12-31 08:07:48 CET; 5min ago
       Docs: man:interfaces(5)
   Main PID: 362 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 1596)
        CPU: 0
     CGroup: /system.slice/networking.service

du coup je recommence mes tests :

  • avec le cable reseau branché sur eth je peux ping le 127.0.0.1 et le localhost en v4 et v6
  • quand le cable reseau est debranché, je ne peux pas ping le 127.0.0.1 mais je peux ping le localhost uniquement en V6 , le v4 ne répond pas …

j’ai un autre rasp, je vais repartir d’une install de base pour voir si j’ai le même comportement