Activation interfaces réseau


#1

OMA-64 finale.
Dans ce ordi, il y a deux interfaces réseau filaires :slight_smile:
—l’une intégrée à la carte mère : via-rhine
—l’autre sur connecteur pci : RTL 8139C
Elles sont toutes deux raccordées à un adaptateur CPL.
Je souhaire que seule la RTL 8139C soit activée au démarrage.
Dans Configurer votre ordinateur; Réseau et Internet, Centre réseau :slight_smile:
—la carte via-rhine intégrée à la carte mère, l’option “Lancer la connexion au démarrage” est désactivée
—la RTL 8139C est activée au démarrage.

Mais quand le sytème démarre, les deux interfaces sont activées, alors que seule la carte RTL 8139C devrait l’être.
Est-ce un bug? Que faire pour éviter ce problème? Je précise mon souhait : —que ce soit automatique (pas de désactivation manuelle)
—ni débrancher un câble réseau.
Merci.

Edit : je n’ai pas ce problème dans Magei 5 sur ce même ordinateur.


#2

Hier quelques mises à jour concernant la gestion du réseau : j’en attendais la résolution de ce problème.
Je ne me souviens plus du nom des paquets mis à jour, mais que deux “symlinks” ont été supprimés puis recréés.
Ce problème peut être considéré comme mineur, mais j’aimerais en être débarrassé.
J’ai cherché dans /etc ce qui est releatif au réseau, notamment les fichiers de configuration des deux interfaces réseau, mais je n’ai pas trouvé.
Je suis prêt à mettre les mains dans le cambouis (ce ne sera pas la première fois).
Les fichiers de configuration dans Unix/Linux sont des fichiers textes. C’est donc facile à modifier.
Merci de me renseigner sur “le cambouis”.


#3

Salut,
si ta connexion est gérée par le “network manager” (l’appliquette réseau de la barre des tâches), tu dois pouvoir la configurer pour qu’elle ne se connecte pas automatiquement :
– clic sur l’icône réseau / clé hexagonale / nom de la connexion / onglet “général” / décocher " se connecter automatiquement"
Au pire, si ça ne fonctionne pas, attribue à cette connexion une adresse d’un réseau inexistant et sans passerelle.


#4

Merci jcl.
Pour la connexion que je souhaite désactivée (enp0s18) j’ai entré ces paramètres light_smile:
IP : 10.10.10.10
MSR : 255.255.255.0
Passerelle : rien

Mais voici l’état après redémarrage :slight_smile:

[root@localhost jjm]# ifconfig -a
enp0s18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.3  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::2e0:4dff:fe41:66d4  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4d:41:66:d4  txqueuelen 1000  (Ethernet)
        RX packets 3098  bytes 665201 (649.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 695  bytes 88762 (86.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp4s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.4  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::208:54ff:fe51:fa8e  prefixlen 64  scopeid 0x20<link>
        ether 00:08:54:51:fa:8e  txqueuelen 1000  (Ethernet)
        RX packets 3074  bytes 1967040 (1.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3190  bytes 443774 (433.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Bien que Networkmanager soit activé, il n’apparaît pas dans LXQt, et est non disponible comme widget.
Dans Plasma, il y a une icône pour enp4s3 (RTL 8139C), mais pas pour la carte via-rhine.
Je vais essayer une idée pleine de finesse et de délicatesse : je vais supprimer la config de la carte intégrée.
Je me demande s’il ne faudrait pas “jouer” avec les “runlevel” pour régler ce problème, car j’ai l’impression que c’est écrit en dur quelquepart.

Edit : essai non réussi de supprimer enp0s18, car après suppression elle est de nouveau disponible!
Comment intervenir dans les “runlevel”?


#5

Bonsoir,

Avant OMA, j’ai recherché dans Mageia 5, avec des résultats posotifs me permettant d’espérer pour OMA. C’était dans les fichiers de config des interfaces du genre :slight_smile:

> ifcfg-enp0s18

> ifcfg-enp4s3

Ils sont situés dans le dossier :slight_smile:

/etc/sysconfig/network-scripts

Maintenant dans OMA :slight_smile:

Pour ifcfg-enp0s18

ifcfg-DEVICE=enp0s18
BOOTPROTO=static
IPADDR=10.10.10.10
NETMASK=255.255.255.0
ONBOOT=no
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
RESOLV_MODS=no
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=yes

Pour ifcfg-enp4s3

DEVICE=enp4s3
BOOTPROTO=dhcp
ONBOOT=yes
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=yes
RESOLV_MODS=no
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=yes
UUID=acd8c040-f4e0-9851-0140-8b92a579713d
NAME="Système enp4s3"
DHCP_CLIENT=dhclient
NEEDHOSTNAME=no
PEERDNS=yes
PEERYP=yes
PEERNTPD=no

Ces deux fichiers ont la configuration désirée, mais le problème subsiste!
Face à cette situation, j’envisage deux possibilités :slight_smile:

—les fichiers de config sont ignorés
—les réglages interviennent après lecture de ces fichiers

Avez-vous des idées à me proposer?
Merci.


#6

Suite aux mises à jour récentes, le problème est réglé.
C’est bien agréable!


#7

Tant mieux !


#8

J’ai annoncé cela trop rapidement, sans observation aucune dans le court temer / moyen terme!
Ce doit être une erreur du système, une distraction passagère :slight_smile:

[root@localhost jjm]# ifconfig -a
enp0s18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.6  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::2e0:4dff:fe41:66d4  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4d:41:66:d4  txqueuelen 1000  (Ethernet)
        RX packets 82  bytes 17692 (17.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 201  bytes 43395 (42.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp4s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.4  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::208:54ff:fe51:fa8e  prefixlen 64  scopeid 0x20<link>
        ether 00:08:54:51:fa:8e  txqueuelen 1000  (Ethernet)
        RX packets 189  bytes 42000 (41.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 107  bytes 29525 (28.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

#10

Petite question: quelle version utilises-tu : OMLx 3.0 ou 2014 ?[


#11

Oméga 3.0-64, utile pour mon LDL un peu au-dessus de la borne supérieure!

A toute fin utile, le problème existe aussi dans ROSA FRESH “RX”, et sylvainjc m"avait indiqué une ligne de commandes qui a résolu le problème, avec l’un de ces commandes :slight_smile:

systemctl ou systemd suivie de paramètres, sans résultat pour OMA 3.0.


#12

Je sui sun peu ennuyé car rien de ce qui est indiqué dans la doc ne foctionne. En particulier les commandes nmtui et nmcli qui ne donnent rien de plus de que l’interface graphique.
Par exemple, cette commande en tant que root :

nmcli d set enp4s3 autoconnect no

devrait créer un fichier un fichier de config pour NetworkManager mais woualou, nada, que dalle (en tout cas sur ma machine virtuelle de test.

Cela dit, les deux fichiers ifcfg_xxx montrent que les interfaces doivent être contrôlées par NetworkManager:

NM_CONTROLLED=yes

Si tu veux changer ce comportement pour une interface, mets

NM_CONTROLLED=no

L’interface ne devrait plus être connectée automatiquement. Pour l’activer, un bon vieux ifup fera l’affaire.
Toujours avec le même exemple :

ifup enp0s3


#13

Merci beaucoup, tu viens de m’apprendre des données intéressantes, car ma préférence va à la ligne de commandes, notamment pour le réseau et les màj.
Depuis Mageia 5 en #, je viens de modifier l’ifcfg de enp0s18 (carte intégrée cm) ainsi :slight_smile:

DEVICE=enp0s18
BOOTPROTO=static
IPADDR=10.10.10.10
NETMASK=255.255.255.0
ONBOOT=no
METRIC=10
MII_NOT_SUPPORTED=no
USERCTL=no
RESOLV_MODS=no
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=no
NM_CONTROLLED=no

Maintenant, je me rends dans OMA.


#14

De retour : nichts, keinen Nachrichten (rien, pas de nouvelles!).
Mon désir de chercher dans les “rc.d” semble pertinente, bien que cela me soit autant accessible que le chinois traditionnel crypté en AES 128!
Mais j’essaye. Dans :slight_smile:

/etc/rc.d/init.d/network-up

#! /bin/bash

BEGIN INIT INFO

Provides: $network $named

Should-Start: portreserve NetworkManager

Default-Start: 2 3 4 5

Short-Description: Wait for the hotplugged network to be up

Description: Wait for all network interfaces started asynchronously

at boot time.

END INIT INFO

Source function library.

. /etc/init.d/functions

NETWORKDELAY=20
DEFAULT_LINK_DETECTION_DELAY=2
MIN_LINK_DETECTION_DELAY=0
MAX_LINK_DETECTION_DELAY=$MIN_LINK_DETECTION_DELAY
ELAPSED_TIME=0
RESOLVCONF_FLAGFILE=/var/run/resolvconf/enable-updates
RESOLVCONF_DIR=/var/run/resolvconf/interface

source network configuration/etc/rc.d/init.d/network-up

. /etc/sysconfig/network

Check that networking is up.

[ “${NETWORKING}” = “no” ] && exit 0
cd /etc/sysconfig/network-scripts

. network-functions

find all the interfaces besides loopback.

ignore aliases, alternative configurations, and editor backup files

interfaces=$(/bin/ls ifcfg* |
LC_ALL=C sed -e “$__sed_discard_ignored_files”
-e ‘/(ifcfg-lo$|:|ifcfg-.*-range)/d’
-e ‘/ifcfg-[ A-Za-z0-9#._-]+$/ { s/^ifcfg-//g;s/[0-9]/ &/}’ |
LC_ALL=C grep -v ‘^ifcfg-’ |
LC_ALL=C sort -k 1,1 -k 2n |
LC_ALL=C sed -e ‘s/ ([0-9])/\1/’)

may_have_link() {
local DEVICE=$1
local LINKDELAY=0
! check_link_down ${DEVICE} || is_associating ${DEVICE}
}

is_associating() {
local DEVICE=$1
is_wireless_device ${DEVICE} || return 1
local AP=iwgetid -a -r ${DEVICE} 2>/dev/null
[ -n “$AP” ] && [ “$AP” != “00:00:00:00:00:00” ] && [ “$AP” != “44:44:44:44:44:44” ] && [ “$AP” != “FF:FF:FF:FF:FF:FF” ]
}

should_wait_network() {
for i in $interfaces; do
unset DEVICE TYPE BOOTPROTO MII_NOT_SUPPORTED PEERDNS DNS1 DNS2
unset REALDEVICE PARENTDEVICE NM_CONTROLLED
LINK_DETECTION_DELAY=$DEFAULT_LINK_DETECTION_DELAY
eval $(LANG=C grep -F “DEVICE=” “ifcfg-$i”)
eval $(LANG=C grep -F “REALDEVICE=” “ifcfg-$i”)
eval $(LANG=C grep -F “PARENTDEVICE=” “ifcfg-$i”)
eval $(LANG=C grep -F “TYPE=” “ifcfg-$i”)
eval $(LANG=C grep -F “BOOTPROTO=” “ifcfg-$i”)
eval $(LANG=C grep -F “MII_NOT_SUPPORTED=” “ifcfg-$i”)
eval $(LANG=C grep -F “LINK_DETECTION_DELAY=” “ifcfg-$i”)
eval $(LANG=C grep -F “PEERDNS=” “ifcfg-$i”)
eval $(LANG=C grep -F “DNS1=” “ifcfg-$i”)
eval $(LANG=C grep -F “DNS2=” “ifcfg-$i”)
eval $(LANG=C grep -F “NM_CONTROLLED=” “ifcfg-$i”)
[ -z “$REALDEVICE” -a -n “$PARENTDEVICE” ] && REALDEVICE=$PARENTDEVICE
[ -z “$REALDEVICE” ] && REALDEVICE=${DEVICE%%:*}
if [ $LINK_DETECTION_DELAY -lt $MIN_LINK_DETECTION_DELAY ]; then
LINK_DETECTION_DELAY=$MIN_LINK_DETECTION_DELAY
fi

    if [ -z "$DEVICE" ] ; then DEVICE="$i"; fi
    if [ "$BOOTPROTO" != "static" ] \
        && [ "$BOOTPROTO" != "dhcp" ] \
        && [ "$BOOTPROTO" != "bootp" ]; then
        continue
    fi
    # Ignore Wifi network files created by NetworkManager
    if [ "$TYPE" = "Wireless" ]; then
      continue
    fi
    # only check interfaces using ifplug, other interfaces are
    # started synchronously from the network service
    if [ "$MII_NOT_SUPPORTED" = "yes" ]; then
        continue
    fi
    # only check interfaces automatically launched
    if LANG=C grep -q -E "^ONBOOT=['\"]?[Nn][Oo]['\"]?" "ifcfg-$i"; then
        continue
    fi
    # ignore devices that are not present
    ip -o link show ${DEVICE} &>/dev/null || continue
    ! is_false $NM_CONTROLLED && is_nm_running && _use_nm=true
    # for NM controlled just ask NetworkManager
    if [ "$_use_nm" = "true" ]; then
        # Ignore disabled wifi h/w
        if is_nm_device_unavailable ${DEVICE}; then
            # Question: Is NM cleverer than us here? Does it do this delay
            # internally and mark it as disconnected until it knows better?
            # before configured delay, consider a lack of link beat
            # as not ready, and unplugged thereafter
            if [ $ELAPSED_TIME -lt $LINK_DETECTION_DELAY ]; then
                return 0
            fi
            # no need to wait for unplugged devices to come up/etc/rc.d/init.d/network-up  
            continue
        fi
        is_nm_active ${DEVICE} || return 0
        # The resolvconf check below uses a single generic "NetworkManager"
        # DNS file, rather than device specific ones, so fudge the device.
        DEVICE=NetworkManager
    else
        # check link beat
        if ! may_have_link ${DEVICE}; then
            # before configured delay, consider a lack of link beat
            # as not ready, and unplugged thereafter
            if [ $ELAPSED_TIME -lt $LINK_DETECTION_DELAY ]; then
                return 0
            fi
            # no need to wait for unplugged devices to come up
            continue
        fi
        # check address is set
        ADDR=`ip addr show scope global ${DEVICE} | awk '/inet/ {print $2;}'`
        if [ -z "$ADDR" ]; then
            return 0
        fi
    fi
    # wait for changes to be propagated by resolvconf if needed
    if [ -e $RESOLVCONF_FLAGFILE ]; then
        if [ "$BOOTPROTO" = "dhcp" -a "$PEERDNS" != "no" ] \
            || [ -n "$DNS1" -o -n "$DNS2" ]; then
            if [ ! -e $RESOLVCONF_DIR/$DEVICE ]; then
                return 0
            fi
            if [ $RESOLVCONF_DIR/$DEVICE -nt /etc/resolv.conf ]; then
                return 0
            fi
        fi
    fi
done
# all interfaces are ready
return 1

}

case “$1” in
start)
gprintf “Waiting for network to be up”

for i in $interfaces; do
    LINK_DETECTION_DEL/etc/rc.d/init.d/network-up  AY=$DEFAULT_LINK_DETECTION_DELAY
    eval $(LANG=C grep -F "LINK_DETECTION_DELAY=" "ifcfg-$i")
    if [ "$LINK_DETECTION_DELAY" -gt $MAX_LINK_DETECTION_DELAY ]; then
        MAX_LINK_DETECTION_DELAY=$LINK_DETECTION_DELAY
    fi
done
NETWORKDELAY=$(( NETWORKDELAY + MAX_LINK_DETECTION_DELAY ))
while should_wait_network && [ $ELAPSED_TIME -lt $NETWORKDELAY ]; do
    sleep 1
    let ELAPSED_TIME=$ELAPSED_TIME+1
done
[ $ELAPSED_TIME -ge $NETWORKDELAY ] && failure || success
echo
;;

stop)
;;
*)
gprintf “Usage: %s\n” "$(basename $0) {start|stop}"
exit 1
esac

exit 0

Nous sommes (peut-être) proches du but; mais comme tout cela est très limpide, je suis embarrassé par cette trop grande limpidité.
Dans /etc/rc.d, init.d me semble être le plus utile.


#15

De mon côté j’avance un peu. C’est bien du côté de NetworkManager qu’il faut regarder mais sa configuration n’est pas des plus intuitives. Après avoir lu les docs, ça va mieux :wink:

Ce que j’ai dit auparavant ne fonctionne pas comme attendu, puisque NM va créer une nouvelle interface, éventuellement avec le même nom.
Pour qu’une interface ne soit pas activée au démarrage, il faut regarder dans la page de manuel.

  1. annuler les modifs indiquées précédemment ( NM_CONTROLLED=no )
  2. créer un fichier dans /etc/NetworkManager/conf.d, par exemple 50-user.conf
  3. l’éditer et ajouter :

[keyfile]
unmanaged-devices=interface-name:enp0s3

J’ai repris le nom de l’exemple précédent.
En principe, au redémarrage, tu auras une interface connectée et l’autre non. Cette dernière sera toujours gérée par NM et pourra être activée d’un clic.


#16

J’ai refait quelques essais et force m’est de constater que ça ne marche pas à tous les coups. NM veut absolument activer l’interface.

On voit que enp0s9 est à la fois activée et prête à être connectée !
C’est très étrange. peut-être une question à poser aux développeurs de NM …


#17

Merci beaucoup pour avoir étudié ce problème.
A moins que j’ai mal compris ou mal appliqué, les deux interfaces sont activées :slight_smile:

[root@localhost jjm]# ifconfig -a
enp0s18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.6  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::2e0:4dff:fe41:66d4  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4d:41:66:d4  txqueuelen 1000  (Ethernet)
        RX packets 167  bytes 39747 (38.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 94  bytes 27798 (27.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp4s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.4  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::208:54ff:fe51:fa8e  prefixlen 64  scopeid 0x20<link>
        ether 00:08:54:51:fa:8e  txqueuelen 1000  (Ethernet)
        RX packets 95  bytes 29151 (28.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 192  bytes 42000 (41.0 KiB)                                                     
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0             

Création du fichier : /etc/NetworkManager/conf.d/50-user.conf

[keyfile]
unmanaged-devices=interface-name:enp0s18

et icfg-enp0s18 :slight_smile:

NM_CONTROLLED=yes
puis
NM_CONTROLLED=no

avec redémarrage à chaque fois : pas de changement.


#18

Je réessaie la proposition de sylvainjc :slight_smile:

systemctl disable systemd-networkd

[root@localhost jjm]# systemctl disable systemd-networkd 
Removed /etc/systemd/system/multi-user.target.wants/systemd-networkd.service.
Removed /etc/systemd/system/sockets.target.wants/systemd-networkd.socket.

Redémarrage : pas de changement!
Est-ce envisageable que ce problème puisse être lié aux contenus des “initrd”?


#19

À mon avis non. La même configuration fonctionne parfaitement bien sur la 2014.2 avec une version précédente de NetworkManager…


#20

Afin de savoir si Nwm est en cause, je l’ai désinstallé en ayant cherché d’abord à le désactiver (services syst., progr. au démarrage).
Avant de procéder, j’avais désactivé “enp0s18”, l’interface intégrée à la cm.
Après redémarrage, les deux interfaces sont activées!
Cela peut nous inspirer.


#21

Ce matin j’ai relancé la machine de test et seule l’interface “autorisée” a été activée. Tout se passe comme s’il y avait une sorte de cache temporaire pour la config et la connexion inactive n’apparaît plus dans la liste car déclarée comme “unmanaged”. Cependant je ne retrouve rien concernant sa config dans les fichiers.