Ad un certo punto, in alcuni materiali didattici (dalla Linux Foundation) su Linux che ho incontrato, viene menzionato quanto segue:

ipIl comando è più versatile ed efficiente rispetto al ifconfigfatto che utilizza socket netlink anziché chiamate di sistema ioctl .

Qualcuno può approfondire un po 'questo perché non riesco a capire cosa sta succedendo sotto il cofano?

PS Sono a conoscenza di questo argomento su quegli strumenti ma non affronta questa differenza specifica su come funzionano

Il ifconfigcomando su sistemi operativi come FreeBSD e OpenBSD è stato aggiornato in linea con il resto del sistema operativo. Al giorno d'oggi può configurare tutti i tipi di impostazioni dell'interfaccia di rete su quei sistemi operativi e gestire una vasta gamma di protocolli di rete. I BSD forniscono ioctl()supporto per queste cose.

Questo non è accaduto nel mondo Linux. Esistono, oggi, tre ifconfigcomandi:

• ifconfigda GNU inetutils

  jdebp% inetutils-ifconfig -l
  enp14s0 enp15s0 lo
  jdebp% inetutils-ifconfig lo
  lo Link encap: Local Loopback
        inet addr: 127.0.0.1 Bcast: 0.0.0.0 Maschera: 255.0.0.0
        UP LOOPBACK RUNNING MTU: 65536 Metrico: 1
        Pacchetti RX: 9087 errori: 0 rilasciati: 0 sovraccarichi: 0 frame: 0
        Pacchetti TX: 9087 errori: 0 rilasciati: 0 sovraccarichi: 0 portante: 0
        collisioni: 0 txqueuelen: 1000
        Byte RX: 51214341 Byte TX: 51214341
  jdebp%

• ifconfigda NET-3 net-tools

  jdebp% ifconfig -l
  ifconfig: l'opzione --help 'fornisce informazioni sull'utilizzo.-l' not recognised.
  ifconfig:
  jdebp% ifconfig lo
  lo: flags = 73 <SU, LOOPBACK, RUNNING> mtu 65536
      inet 127.0.0.1 netmask 255.0.0.0
      inet6 :: 1 prefixlen 128 scopeid 0x10 <host>
      inet6 :: 2 prefixlen 128 scopeid 0x80 <compat, global>
      inet6 fe80 :: prefixlen 10 scopeid 0x20 <link>
      loop txqueuelen 1000 (Local Loopback)
      Pacchetti RX 9087 byte 51214341 (48,8 MiB)
      0 errori RX 0 rilasciati 0 sovraccarichi 0 frame 0
      Pacchetti TX 9087 byte 51214341 (48,8 MiB)
      Errori TX 0 rilasciati 0 sovraccarichi 0 collettori 0 collisioni 0
  jdebp%

• ifconfigdalla (versione 1.40 di) il set di strumenti nosh

  jdebp% ifconfig -l
  enp14s0 enp15s0 lo
  jdebp% ifconfig lo
  Lo
      collegamento loopback in esecuzione
      indirizzo link 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00 
      indirizzo inet4 127.0.0.1 prefisso 8 bdaddr 127.0.0.1 
      indirizzo inet4 127.53.0.1 prefisso 8 bdaddr 127.255.255.255 
      inet6 address :: 2 scope 0 prefixlen 128 
      indirizzo inet6 fe80 :: prefisso 1 prefisso 10 
      indirizzo inet6 :: 1 ambito 0 prefisso 128
  jdebp% sudo ifconfig lo inet4 127.1.0.2 alias
  jdebp% sudo ifconfig lo inet6 :: 3/128 alias
  jdebp% ifconfig lo
  Lo
      collegamento loopback in esecuzione
      indirizzo link 00: 00: 00: 00: 00: 00 bdaddr 00: 00: 00: 00: 00: 00 
      indirizzo inet4 127.0.0.1 prefisso 8 bdaddr 127.0.0.1 
      indirizzo inet4 127.1.0.2 prefisso 32 bdaddr 127.1.0.2 
      indirizzo inet4 127.53.0.1 prefisso 8 bdaddr 127.255.255.255 
      indirizzo inet6 :: 3 scope 0 prefixlen 128 
      inet6 address :: 2 scope 0 prefixlen 128 
      indirizzo inet6 fe80 :: prefisso 1 prefisso 10 
      indirizzo inet6 :: 1 ambito 0 prefisso 128 
  jdebp% 

Come puoi vedere, i GNU inetutils e NET-3 net-tools ifconfigpresentano alcune marcate carenze, rispetto a IPv6, rispetto alle interfacce che hanno più indirizzi e rispetto a funzionalità simili -l.

Il problema IPv6 è in parte del codice mancante negli strumenti stessi. Ma principalmente è causato dal fatto che Linux (come altri sistemi operativi) non fornisce funzionalità IPv6 attraverso l' ioctl()interfaccia. Permette solo ai programmi di vedere e manipolare gli indirizzi IPv4 attraverso le reti ioctl().

Linux invece fornisce questa funzionalità attraverso un'interfaccia diversa send()e recv()su una famiglia di socket speciale e un po 'strana AF_NETLINK.

GNU e NET-3 ifconfigs potrebbero sono stati rettificati per utilizzare questa nuova API. L'argomento contro questo modo è stata che non era portabile su altri sistemi operativi, ma questi programmi erano in pratica già non portabile in ogni caso in modo che non era molto di un argomento.

Ma non sono stati adattati e rimangono come anticipati fino ai giorni nostri. (Alcune persone hanno lavorato su di essi in vari punti nel corso degli anni, ma i miglioramenti, purtroppo, non sono mai entrati nei programmi. Ad esempio: Bernd Eckenfels non ha mai accettato una patch che aggiungesse alcune funzionalità API di netlink a NET-3 net-tools ifconfig, 4 anni dopo la stesura della patch.)

Invece, alcune persone hanno reinventato completamente il set di strumenti come ipcomando, che utilizzava la nuova API Linux, aveva una sintassi diversa e combinava molte altre funzioni dietro un'interfaccia alla moda .command subcommand

Avevo bisogno di uno ifconfigche avesse la sintassi della riga di comando e lo stile di output di FreeBSD ifconfig(che né GNU né NET-3 ifconfighanno, e che ipcertamente non ha). Quindi ne ho scritto uno. Come prova che si potrebbe scrivere un ifconfigche utilizza l'API netlink su Linux, lo fa.

Quindi la saggezza ricevuta ifconfig, come quella che citi, non è più vera. Ora non è vero affermare che " ifconfignon usa netlink". La coperta che copriva due non ne copre tre.

È sempre stato falso affermare che "netlink è più efficiente". Per le attività che si svolgono con ifconfig, non c'è davvero molto in esso quando si tratta di efficienza tra l'API netlink e l' ioctl()API. Uno fa praticamente lo stesso numero di chiamate API per ogni dato compito.

In effetti, ogni chiamata API è due chiamate di sistema nel caso netlink, a differenza di una nel ioctl()sistema. E probabilmente l'API netlink ha lo svantaggio che su un sistema molto utilizzato incorpora esplicitamente la possibilità che lo strumento non riceva mai un messaggio di riconoscimento che lo informi del risultato della chiamata API.

È, inoltre, falso dire che ipè "più versatile" di GNU e NET-3 ifconfigs perché utilizza netlink . È più versatile perché svolge più attività, facendo cose in un unico grande programma che si farebbe con programmi separati diversi da ifconfig . Non è più versatile semplicemente a causa dell'API che utilizza internamente per eseguire quelle attività extra. Non c'è nulla di inerente all'API al riguardo. Si potrebbe scrivere uno strumento all-in-one che ha utilizzato il FreeBSD ioctl()API, ad esempio, e altrettanto bene stato che è "più versatile" che i singoli ifconfig, route, arp, e ndpcomandi.

Si potrebbe scrivere route, arpe ndpcomandi per Linux che hanno usato l'API netlink, anche.

Ulteriori letture

• Jonathan de Boyne Pollard (2019). ifconfig. Guida di nosh . Software.
• Eduardo Ferro (16-04-2009). ifconfig: riporta un indirizzo IP / patch iniziale errati . Bug Debian # 359676.

Lo standard ifconfigche abbiamo in molte distribuzioni è deprecato per diversi motivi. Parla in modo obsoleto e limitato con il kernel e, di fatto, non comprende più tutte le configurazioni di rete. Non sarai in grado di manipolare alcune configurazioni di rete di tali ifconfigversioni con cui sei in grado di fare ip. Inoltre, il ifconfigsupporto per gli spazi dei nomi di rete è limitato.

Come racconto aneddotico, ho trovato l'alias IP dell'interfaccia visibile solo ipe non in SuSE ifconfig.

Per quanto riguarda le differenze sottostanti: da ifconfig vs ip: qual è la differenza e confrontare la configurazione di rete

Anche se ippotrebbe sembrare un po 'complesso al primo sito, ma ha funzionalità molto più ampie di ifconfig. È funzionalmente organizzato su due livelli di stack di rete, ovvero livello 2 (livello di collegamento), livello 3 (livello IP) e svolge il lavoro di tutti i comandi sopra menzionati dal pacchetto net-tools.

Sebbene ifconfigmostri o modifichi principalmente le interfacce di un sistema, questo comando è in grado di svolgere le seguenti attività:

• Visualizzazione o modifica delle proprietà dell'interfaccia.

• Aggiunta, rimozione di voci della cache ARP durante la creazione di una nuova voce ARP statica per un host.

• Visualizzazione degli indirizzi MAC associati a tutte le interfacce.

• Visualizzazione e modifica delle tabelle di routing del kernel.

Uno dei punti salienti principali che lo separa dalla sua antica controparte ifconfig è che quest'ultimo utilizza ioctl per la configurazione della rete, che è un modo meno apprezzato di interazione con il kernel mentre il primo sfrutta il meccanismo del socket netlink per lo stesso che è un successore molto più flessibile di ioctl per l'inter-comunicazione tra kernel e spazio utente usando rtnetlink (che aggiunge funzionalità di manipolazione dell'ambiente di rete).

Informazioni sull'uso / i vantaggi di netlink: Da LJ - Kernel Korner - Perché e come utilizzare Netlink Socket

Il socket Netlink è un IPC speciale utilizzato per il trasferimento di informazioni tra i processi del kernel e dello spazio utente. Fornisce un collegamento di comunicazione full-duplex tra i due tramite API socket standard per i processi dello spazio utente e un'API kernel speciale per i moduli kernel. Il socket Netlink utilizza la famiglia di indirizzi AF_NETLINK.

.....

Perché le funzionalità di cui sopra usano netlink invece di chiamate di sistema, ioctls o filesystem proc per la comunicazione tra mondi utente e kernel? È un'attività non banale aggiungere chiamate di sistema, ioctls o file proc per nuove funzionalità; rischiamo di inquinare il kernel e danneggiare la stabilità del sistema. Il socket Netlink è semplice, tuttavia: solo una costante, il tipo di protocollo, deve essere aggiunta a netlink.h. Quindi, il modulo del kernel e l'applicazione possono parlare immediatamente usando le API di tipo socket.

....

Il socket Netlink è un'interfaccia flessibile per la comunicazione tra applicazioni dello spazio utente e moduli del kernel. Fornisce un'API socket di facile utilizzo sia per le applicazioni che per il kernel. Fornisce funzionalità di comunicazione avanzate, come full-duplex, I / O bufferizzate, comunicazione multicast e asincrona, assenti in altri IPC kernel / spazio utente.