Debian 9 (Utilisation Serveur) | Problème carte réseau

Support Debian
#1

Bonjour,

J’ai déjà tenté plusieurs recherches en français et en anglais par rapport à mon problème, mais rien de bien concluant (où alors je m’y suis mal pris… difficile de de résumer mon problème dans un moteur de recherche ^^ )
Je vais essayer d’être le plus clair possible !

J’ai installé Debian 9 sur un pc portable (eh oui on fait de la récup), pour tenter d’en faire un serveur (web entre autres), sans aucune prétention juste pour apprendre.
J’accède en SSH au pc portable.

J’ai voulu mettre en place un WakeOnLan, j’ai donc suivi plusieurs guides.
Lorsque mon “serveur” est allumé et que j’exécute cette commande :

sudo tcpdump -i eth0 port 9

Pour voir si je reçois bien les MagicPackets, cela marche parfaitement, depuis mon autre PC en local j’envois les packets qui sont bien reçu par le “serveur”.

Le problème survient au moment où je met le “serveur” en veille, puisque la carte réseau ne semble plus fonctionner, malgré les options activées/désactivées dans le BIOS en rapport avec la carte réseau.
Le plus étrange est lorsque je sors le “serveur” de veille, plus aucune connexion SSH possible, le serveur web ne marche plus, le ftp non plus, enfin bref c’est comme si le pc n’était plus connecté au réseau alors qu’en regardant avec l’interface graphique, elle me dit que je suis bien connecté (en ethernet je précise) au réseau…

J’espère avoir été assez clair.

Merci d’avance !

#2

Le réveil réseau en sortie de veille peut être capricieux selon la configuration effectivement.
Pour débroussailler dans un premier temps:

lspci -k | grep -A2 rnet
systemctl list-unit-files |egrep -i 'net|res' |grep enable
ls /etc/systemd/network/
1 J'aime
#3

Voilà donc la sortie de ces commandes :

lspci -k | grep -A2 rnet
03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)
    Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
    Kernel driver in use: r8169
    Kernel modules: r8169

systemctl list-unit-files |egrep -i 'net|res' |grep enable
network-manager.service                                                enabled
networking.service                                                     enabled
NetworkManager-dispatcher.service                                      enabled
NetworkManager-wait-online.service                                     enabled
NetworkManager.service                                                 enabled


ls /etc/systemd/network/
#Ne sort rien
#4

Normalement en faisant ceci (en root) après réveil:

 modprobe -r r8169
 modprobe r8169

ça doit réveiller le réseau. Tu peux tester, et reste à voir ou placer ça en script.
Par contre… NetworkManager, je suis certain que tu n’en as pas besoin, mais que tu aurais plus besoin de systemd-networkd

. + retour de:

ip -c a
1 J'aime
#5

Tout d’abord merci pour l’aide fournie :slight_smile:

Je ne comprends pas très bien la démarche que tu me donnes…
Si je dois rentrer ces commandes “après-réveil” c’est que le serveur est déjà en marche, mais si je ne peux justement pas le mettre en marche… Je suis un peu perdu excuse moi ^^

EDIT : Je n’avais pas compris la partie sous spoiler, maintenant j’ai compris ^^

_En tout cas si je lance _
modprobe -r r8169

ça a l’air de tourner en boucle, aucun résultat et ça m’a déconnecté en ssh au bout de 1-2min, impossible de se reco j’ai du reboot a la main sur le serveur

J’ai déjà essayé d’enlever network manager il y a quelques jours, mais ça m’a juste fait perdre ma connexion filaire & wifi, impossible de se reconnecter…

#6

Alors si tu fais les manips proposées “à distance” … ça me semble impossible.
Désolé, mais sans accès direct à ta machine, impossible pour moi de t’aider.

#7

Ah ! Si si, je peux accéder à la machine le temps de faire ces manips :slight_smile:

Edit : ce que je ne comprenais pas, c’est que le “script” avec modprobe etc, quel est son but direct? Je remarque que ça me déconnecte et reconnecte au réseau, mais par rapport au WakeOnLan, à quel moment du processus intervient -il ? (serveur éteint -> envoi du magicpacket -> récéption du magicpacket -> serveur allumé)

Retour de

ip -c a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
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
3: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether ce:e4:26:36:ac:75 brd ff:ff:ff:ff:ff:ff
4: enp3s0f2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether ac:22:0b:19:d4:07 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.21/24 brd 192.168.1.255 scope global dynamic enp3s0f2
   valid_lft 86289sec preferred_lft 86289sec
inet6 2a01:cb1d:195:2100:a890:7b61:1a65:9c7e/64 scope global temporary dynamic
   valid_lft 1763sec preferred_lft 563sec
inet6 2a01:cb1d:195:2100:ae22:bff:fe19:d407/64 scope global mngtmpaddr noprefixroute dynamic
   valid_lft 1763sec preferred_lft 563sec
inet6 fe80::ae22:bff:fe19:d407/64 scope link
   valid_lft forever preferred_lft forever
#8

Je n’y connais strictement rien en “magicpacket” .
Il faut séparer les variables:

Etape 1 - le réseau de ton serveur se réveille-t-il bien après une mise en veille ?
C’est d’abord ça qu’il faut clarifier.
Ensuite, pour le “magicpacket”, je ne peux rien faire.
Désolé.

Au fait, tu as deux cartes réseau ? Pas clair ta config wlp2s0 + enp3s0f2.

1 J'aime
#9

Non lors d’une sortie de mise en veille, le réseau ne se réveille pas

Si j’ai bien compris c’est ce qui est envoyé au serveur si je veux effectuer un “WakeOnLan”

Non pas du tout… Etrange

#10

Plus haut, tu parles de Wifi … tu en as besoin sur ton serveur ?
Bon, ça m’a l’aire embrouillé ta situation.
Concentre toi sur “Etape 1”, avant le magic bidule…

1 J'aime
#11

Non du tout, c’était juste pour faire remarquer que avoir enlevé network manager avait un peu “cassé” tout ça.

Yep je sais désolé, je cherche justement à résoudre le problème de cette étape 1

#12

Pour résumer, si j’ai bien compris, tu as 2 problèmes et non pas 1.

1 - ton BIOS est indifférent à l’envoi d’un “MagicPacket” qui serait bien envoyé de l’extérieur
=> gestion purement au niveau du BIOS, et Debian n’y peut strictement rien

2 - lorsque tu mets en veille ton PC (non pas à distance, mais directement), lors du réveil, le réseau n’est pas réactivé.
En supposant que tu t’obstines avec NetworkManager, as-tu au moins vérifié que la connexion réseau que tu choisis par défaut est bien configuré en “connexion automatique” par défaut dans le panel de contrôle de Network-Manager ?

3 - as-tu vérifié que la succession de “modprobe -r r8169” puis “modprobe r8169” réveille le réseau ou non ? (pas en ssh … mais sur le PC…).

De toute façon, même si le réseau de ton PC se réveille correctement, ça ne résoudra pas ton problème de MagicPacket / WakeOnLan au niveau du BIOS.

1 J'aime
#14

Oui c’est ça ^^

  1. Il semblerait ! J’irai voir plus en profondeur ce soucis
  2. Dans un premier temps : les commandes modprobe citées plus haut marchent et me permettent de retrouver mon réseau :slight_smile:
    Ensuite : Je ne veux pas m’obstiner avec NetworkManager, je vais essayer ce dont vous me parlez, mais si ça ne change rien, je veux bien que vous m’aidiez à m’en débarrasser ça ne me dérange pas ^^
    –> UPDATE : Oui la connexion réseau que je choisi est bien sur “connexion automatique”
    –> UPDATE 2 : J’ai trouvé sur cette page : https://doc.ubuntu-fr.org/network-manager#connexions_desactivees_en_sortie_de_veille
    Le problème, et une possible solution que je vais tester
  3. Répondu au 2. pour le coup
#15

Bien : In progress…
Le problème du WakeOnLan du BIOS, je ne peux rien y faire.

NetworkManager est une surcouche beaucoup trop lourde pour un serveur (à mon avis), et à risque puisque trop facilement bidouillable en mode utulisateur, donc pas sérieux pour un réseau fiable. Si tu dépatouilles ton NetkworkManager, tant mieux.

J’ai évoqué systemd-networkd que j’utilise sur mon PC fixe, mais je ne risquerai pas à commencer ce sujet un peu chatouilleux. Disons que je donne une idée.

$ systemctl list-unit-files --state=enabled|egrep -i 'net|resol'
dbus-org.freedesktop.network1.service  enabled        
systemd-networkd-wait-online.service   enabled        
systemd-networkd.service               enabled        
systemd-networkd.socket                enabled

Difficile pour moi de t’aider plus sans que tu y mettes les doigts (franchement pas facile à travers un forum).

1 J'aime
#16

Je vais peut être considérer une installation de systemd-networkd à la place networkmanager alors…

Merci beaucoup pour ce que vous avez déjà fait ! Je sais maintenant plus précisément quel est le problème et j’ai plusieurs pistes à suivre.
Notamment l’execution de modprobe à la sortie de veille automatiquement

#17

Allez, un petit coup de pouce pour voir:
=> tu crées un fichier /lib/systemd/system/network_wakeup.service qui contient:

​[Unit]
Description=Local system resume actions
After=suspend.target                                                            
                                                                            
[Service]                                                                       
Type=oneshot
ExecStart=/sbin/rmmod r8169 ; /sbin/modprobe r8169

[Install]
WantedBy=suspend.target

Puis:

sudo systemctl enable --now network_wakeup.service
1 J'aime
#18 
Failed to enable unit: File network_wakeup.service: Invalid argument

Je ne vois pas où se situe le problème dans [Unit]…

#19

pour vérifier ta création:

systemctl cat network_wakeup
grep -v '#' /lib/systemd/system/suspend.target

et fais un essai de stand-by.

#20

Le problème persiste :confused:

#21

Ces deux commandes ne retournent rien du tout ???
Elles disent quoi exactement ? Sois plus précis … (je n’ai pas de boule de cristal).

EDIT:
1 heure pour avoir le retour de 2 malheureuses commandes…
Désolé, mais bon courage.