Network configuration (Italiano)

Primo controllo

Molte volte, l’installazione di base ha già creato una configurazione di rete funzionante. Per verificare, utilizzare il seguente comando:

$ ping -c 3 www.google.com

PING www.l.google.com (74.125.224.146) 56(84) bytes of data.
64 bytes from 74.125.224.146: icmp_req=1 ttl=50 time=437 ms
64 bytes from 74.125.224.146: icmp_req=2 ttl=50 time=385 ms
64 bytes from 74.125.224.146: icmp_req=3 ttl=50 time=298 ms

--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 298.107/373.642/437.202/57.415 ms

Tip: L'opzione -c 3 esegue ping 3 volte. Vedereman ping per maggiori informazioni.

Se funziona, si possono personalizzare le impostazioni con le opzioni che seguono.

Impostare il nome del PC

Un hostname è un nome univoco creato per identificare un pc in rete. Con Arch Linux, l’hostname del pc è impostabile in /etc/rcconf o, fino a quando non si riavvia, con il comando hostname. Per gli hostnames si possono utilizzare solo caratteri alfanumerici. Il trattino (-) può essere utilizzato, ma né all’inizio né alla fine dell’hostname. La lunghezza di quest'ultimo è limitata a 63 caratteri.

Editare /etc/rc.conf ed impostare HOSTNAME con il nome desiderato (archlinux nell'esempio):

HOSTNAME="archlinux"

Dopo aver impostato l’hostname, è una buona idea includere lo stesso in /etc/hosts. Questo aiuterà i processi che fanno riferimento al computer attraverso il suo hostname per trovarne l’indirizzo IP.

Editare /etc/hosts ed aggiungere lo stesso HOSTNAME che è stato inserito in /etc/rc.conf:

127.0.0.1      archlinux.domain.org   localhost.localdomain      localhost    archlinux

Per impostare l’hostname temporaneamente (fino al successivo riavvio), utilizzare il comando hostname da root:

# hostname archlinux

Caricare il modulo del dispositivo

Udev dovrebbe riconoscere il modulo dell’interfaccia di rete (NIC) e caricarlo automaticamente al boot. Se ciò avviene, saltare questa sezione. Altrimenti bisogna individuare il modulo necessario al funzionamento della scheda:

# hwdetect --show-net

Individuato il modulo, lo si può caricare con:

# modprobe <modulename>

Se udev non individua e carica il modulo giusto automaticamente durante la fase di boot, si può inserirlo tra gli array di MODULES in /etc/rc.conf, in modo tale da non doverlo caricare manualmente ad ogni boot con modprobe. Ad esempio, se il modulo di rete è tg3:

 MODULES=(... tg3 snd-cmipci ...)

Altri moduli comuni sono 8319too per le schede con chipset Realtek e sis900 per quelle con chip Sis.

Configurazione indirizzo IP

È importante sapere che si può avere un indirizzo ip dinamico utilizzando DHCP, o un ip statico, impostando l’indirizzo su "static". (Vedere Wikipedia:DHCP per maggiori informazioni)

Nota: Per le schede madri con schede di rete NICs integrate, è importante conoscere quale NIC è considerata primaria (ad esempio, "eth0") e quale NIC è considerata secondaria (ad esempio, "eth1"). Molti problemi di configurazione sono causati da utenti che non impostano correttamente la configurazione di "eth0" nel file /etc/rc.conf, quando in realtà, hanno il cavo Ethernet collegato in "eth1"!

DHCP

In questo caso è necessario il pacchetto dhcpd (già disponibile nella maggior parte delle installazioni). Inoltre, è necessario editare /etc/rc.conf in questo modo:

interface="eth0"
address=
netmask=
gateway=

Va definita solo l'interfaccia, le altre opzioni saranno impostate tramite DHCP..

Se si utilizza DHCP e non si vuole che i server DNS vengano automaticamente assegnati ogni volta che si avvia la rete, assicurarsi di aggiungere all'ultima sezione del file /etc/dhcpcd.conf quanto segue:

nohook resolv.conf

Quindi aggiungere il proprio server DNS in /etc/resolv.conf.

Assicurarsi di testare le nuove impostazioni arrestando e riavviando il demone di rete /etc/rc.d/network, anziché disattivare la propria interfaccia e avviare DHCP manualmente. Per riavviare il demone di rete:

# /etc/rc.d/network restart

Si può utilizzare il pacchetto openresolv per controllare molti processi tramite /etc/resolv.conf (ad esempio dhcpcd ed un client VPN). Per utilizzare openresolv, non è necessaria alcuna configurazione aggiuntiva per dhcpcd.

{{Nota|1=È possibile avere un indirizzo IP statico utilizzando dhcpcd. È sufficiente modificare il file /etc/conf.d/dhcpcd e cercare qualcosa simile a (dove xxxx è l’indirizzo IP desiderato):

DHCPCD_ARGS="-q -s x.x.x.x"

Indirizzo IP Statico

Ci sono vari motivi per cui si potrebbe voler assegnare indirizzi IP statici alla rete. Per esempio, si può ottenere un certo livello di prevedibilità. Inoltre, se si condivide la connessione internet con un pc Windows senza un router, assicurarsi di utilizzare indirizzi IP statici su entrambi i computer. Altrimenti si avranno problemi con la LAN.

In questo caso è necessario conoscere:

• l'ip statico che ci è stato assegnato,
• la subnet mask,
• l'indirizzo di broadcast,
• l'indirizzo IP del gateway,
• il nome dei server DNS,
• il nome del dominio (se non si tratta di una LAN locale, nel qual caso si può mettere up).

Se la rete è privata, è sufficiente utilizzare un indirizzo IP del tipo 192.168.*.'*, una subnet mask 255.255.0.0 e un indirizzo di broadcast 192.168.255.255. A meno che non si utilizzi un router l'indirizzo IP del gateway non è necessario. A questo punto, editare Template:Filename in questo modo, sostituendo indirizzo IP, netmask, broadcast e gateway:

interface=eth0
address=192.68.0.2
netmask=255.255.255.0
gateway=192.168.22.1

Editare il file /etc/resolv.conf, inserendo l'indirizzo IP del proprio name server ed il proprio dominio locale:

nameserver 61.23.173.5
nameserver 61.95.849.8
search example.com

{{Nota|Attualmente è possibile inserire massimo 3 righe di nameserver.

Assegnazione manuale

Si può assegnare l’indirizzo IP dalla console:

# ip addr add <ip address>/<netmask> dev <interface>

Ad esempio:

# ip addr add 192.168.1.2/24 dev eth0

Per altre opzioni, vedere: man ip

Aggiungere il proprio gateway in questo modo:

# ip route add default via <ip address>

(Sostituire <ip> con il proprio indirizzo IP del gateway

Ad esempio:

# ip route add default via 192.168.1.1

Caricare la configurazione

Per testare le configurazioni, riavviare il computer o, da root, eseguire:

# /etc/rc.d/network restart

Provare a pingare il gateway, il server DNS, l’ISP e altri siti Internet, in questo ordine, per rilevare eventuali problemi di collegamento lungo la strada, ad esempio:

$ ping -c 3 www.google.com

Impostazioni aggiuntive

Abilitare/disabilitare l'interfaccia

Si può attivare o disattivare l’interfaccia di rete:

# ip link set <interface> up/down

Firewall

E' possibile installare/configurare un firewall per proteggersi.

Configurazioni wireless

Per ulteriori informazioni, consultare la pagina Wireless Setup.

Portatili, 'ifplugd'

Si può installare un demone che configura automaticamente il dispositivo Ethernet quando viene collegato il cavo e che sconfigura il dispositivo quando il cavo viene scollegato. Ciò è utile su portatili con schede di rete integrate, così verrà creata una configurazione solo quando si collegherà il cavo. Questo sistema può essere utilizzato anche quando si vuole riavviare la rete, senza riavviare il computer e senza utilizzare la shell.

L'installazione è molto semplice da quando ifplugd è nei Repository Ufficiali: Template:Cli

Di default è configurato per funzionare per il dispositivo eth0. Questa ed altre impostazioni come i ritardi, possono essere configurati in /etc/ifplugd/ifplugd.conf.

Avviare il demone ifplugd ed aggiungere ifplugd al proprio DAEMONS array di modo da farlo partire automaticamento all'avvio del sistema.

Jumbo Frames

Consultare la pagina Jumbo Frames per ulteriori informazioni.

Bonding o LAG

È possibile installare ifenslave per fare il bind di due interfacce 'reali' con un unico indirizzo ip. Dopo l'installazione, sarà necessario modificare ciascuno dei seguenti file:

/etc/conf.d/bonding:

bond_bond0="eth0 eth1"
BOND_INTERFACES=(bond0)

/etc/modprobe.d/modprobe.conf:

Nota: module-init-tools > 3.8 cambia il percorso del file di configurazione: /etc/modprobe.conf non è più disponibile, è sotituito da /etc/modprobe.d/modprobe.conf. link

options bonding miimon=100

/etc/rc.conf:

MODULES=(... bonding ...)
interface=bond0
address=192.168.1.1
netmask=255.255.255.0
gateway=192.168.1.255

Per rendere effettive le modifiche, riavviare la rete:

# rc.d restart network

IP aliasing

Se si vogliono utilizzare più indirizzi IP su di un'interfaccia, occorrerà utilizzare netcfg ed i comandi POST_UP e PRE_DOWN sul profilo dell'interfaccia di rete per configurare manualmente gli indirizzi IP aggiuntivi. Vedere qui per maggiori dettagli.

Esempio

Sarà necessario netcfg, disponibile nei Repository Ufficiali

Preparare la configurazione

/etc/network.d/mynetwork

 # CONNECTION='ethernet'
 # DESCRIPTION='Five different addresses on the same NIC.'
 # INTERFACE='eth0'
 # IP='static'
 # ADDR='192.168.1.10'
 # GATEWAY='192.168.1.1'
 # DNS=('192.168.1.1')
 # DOMAIN=''
 # POST_UP='for i in 11 12 13 14 ; do ip addr add 192.168.1.$i/24 brd 192.168.1.255 dev eth0 ; done'
 # PRE_DOWN='for i in 11 12 13 14 ; do ip addr del 192.168.1.$i/24 dev eth0 ; done'

/etc/rc.conf

NETWORKS=(mynetwork)

...

DAEMONS=(... net-profiles ...)

Cambiare MAC/hardware address

Non è più possibile cambiare il proprio MAC address tramite /etc/rc.conf. Vedere MAC Address Spoofing per maggiori dettagli.

Risoluzione dei problemi

Errore DHCP al boot

Per prima cosa, controllare tutti i vari step che il computer esegue all’avvio, per individuare quale di essi fallisce.

Gli step sono:

1. Individuazione dispositivo di rete e caricamento dei relativi driver.
2. Attivazione dell’interfaccia.
3. Esecuzione dhcp

Step 1

Controllare la riga "Ethernet controller" nell’output del comando lspci -v. Essa dovrebbe indicare in quale modulo del kernel è contenuto il driver della propria scheda di rete. Ad esempio:

$ lspci -v

 02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)
 	...
 	Kernel driver in use: atl1
 	Kernel modules: atl1

Dopodichè, assicurarsi che il driver sia caricato, attraverso il comando dmesg | grep <module name>. Ad esempio:

$ dmesg |grep atl1
   ...
   atl1 0000:02:00.0: eth0 link is up 100 Mbps full duplex

Step 2

Controllare che l’interfaccia ottenuta dall’output di dmesg sia associata alla scheda di rete ed attivarla con (da root)

# ip link set <interface> up

Controllare il risultato con ip addr show dev eth0. Ad esempio:

$ ip addr show dev eth0

   2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc vboxnetflt state UP qlen 1000
   [...]

Step 3

Per andare sul sicuro, disattivare l’interfaccia con dhcpcd --release, quindi riattivarla con dhcpcd. Visualizzare la pagina man dhcpcd per maggiori informazioni.

Se tutto è andato a buon fine si vedrà una cosa del genere:

# dhcpcd --release eth0

 dhcpcd: dhcpcd not running 

# dhcpcd eth0

 dhcpcd: version 5.1.1 starting
 dhcpcd: eth0: broadcasting for a lease
 ...
 dhcpcd: eth0: leased 192.168.1.70 for 86400 seconds

Ed ora ip addr show dev <interface> dovrebbe mostrare l’indirizzo inet. Probabilmente alcune delle cose descritte in questi step non funzioneranno, altrimenti la rete si sarebbe avviata automaticamente al boot.

Se dhcp funziona utilizzando la procedura descritta sopra, ma non si avvia al boot, aggiungere al file /etc/rc.local quanto segue:

dhcpcd -k eth0 
dhcpcd -nd eth0

Vedere http://bbs.archlinux.org/viewtopic.php?id=63940 per maggiori informazioni.

Per molti, il pacchetto dhclient (disponibile in [extra]) ha funzionato dove dhcpcd ha fallito.

Scambio computer/modem via cavo

La maggior parte degli ISP (videotron for example) ha il modem via cavo configurato per riconoscere un solo PC client, attraverso il MAC Address della sua interfaccia di rete. Una volta che il modem via cavo ha acquisito il MAC Address del primo PC, o della relativa periferica, non risponderà in alcun modo ad un altro MAC Address. Pertanto, se si cambia un PC con un altro (o router), il nuovo PC (o router) non funzionerà con il modem via cavo, in quanto ha un MAC Address diverso dal precedente. Per effettuare il reset del modem via cavo in modo che riconosca il nuovo PC, è necessario spegnerlo e riaccenderlo. Una volta che il modem via cavo si è riavviato ed è ritornato completamente in linea (le spie luminose sono stabili), riavviare il nuovo computer in modo da effettuare una nuova richiesta DHCP, o effettuarla manualmente.

Se questo metodo non funziona, è necessario clonare il MAC Address del pc originario. Vedere quindi Cambiare MAC/hardware address.

Il problema del TCP Window Scaling

I pacchetti TCP contengono nell'header un campo "window" che indica la quantità di dati che deve restituire l'altro host. Questo campo è di 16 bit, dato che la dimensione della finestra è al massimo 64kb. I pacchetti TCP vengono mantenuti in cache per un certo tempo e, se la memoria è (o era) limitata, è probabile che l'host la finisca rapidamente.

Nel 1992, quando cominciò ad essere disponibile molta memoria, per migliorare la situazione, fu scritta la RFC 1323: fu introdotto in "Window Scaling". Il valore "window", presente in tutti i pacchetti, viene modificato da uno "Scale Factor" definito una sola volta all'inizio della connessione. Questo campo, di 8 bit, permette alla finestra di essere fino a 32 volte più grande dei 64Kb iniziali.

Sembra che alcuni router e firewall riscrivano lo Scale Factor a 0 che causa "incomprensioni" tra gli host.

Il kernel 2.6.17 ha introdotto un nuovo algoritmo che genera Scale Factors più alti, in modo tale da rendere il problema di questi router e firewall virtualmente più visibile.

La connessione, in questi casi, si interrompe o è, al più, molto lenta.

Come diagnosticare questo problema?

Prima di tutto chiariamo: è molto difficile. In alcuni casi, non sarà possibile effettuare connessioni TCP (HTTP, FTP, ...), in altri sarà possibile comunicare solo con alcuni host (molto pochi).

Quando si ha questo problema, l'output di dmesg è ok, i log sono puliti e ip addr riporta una configurazione corretta, quindi sembra tutto normale.

Se non è possibile raggiungere nessun sito Web, ma è possibile pingare alcuni host, probabilmente si è incappati in questo problema: il ping utilizza il protocollo ICMP e non è affetto da problemi TCP.

Si può provare ad utilizzare Wireshark. Si possono vedere comunicazioni UDP e ICMP che avvengono correttamente e le connessioni TCP che non vanno a buon fine (solo verso host 'esterni').

Come risolverlo? (La strada sbagliata)

Per risolvere il problema, si può cambiare il valore tcp_rmem, su cui si basa il calcolo dello Scale Factor. Sebbene dovrebbe funzionare per la maggior parte degli host, non è sicuro che funzioni in tutti i casi, specialmente per host molto distanti.

echo "4096 87380 174760" > /proc/sys/net/ipv4/tcp_rmem

Come risolverlo? (Il metodo corretto)

Semplicemente, disabilitare il Window Scaling. Anche se è una caratteristica carina, può rivelarsi scomoda se non si può sistemare il router malfunzionante. Ci sono diversi metodi per disabiltare il Window Scaling, e sembra che il più sicuro (che funziona sui kernel più recenti) sia aggiungere la seguente linea in /etc/sysctl.conf: (vedere anche sysctl)

net.ipv4.tcp_window_scaling = 0

Come risolverlo? (Il metodo migliore)

Questo problema è causato da router/firewall malfunzionanti, quindi vanno cambiati.

Ulteriori informazioni

Questa sezione si basa sull'articolo LWN TCP window scaling and broken routers e sull’articolo di Kernel Trap : Window Scaling on the Internet.

Altre discussioni pertinenti sono presenti su LKML.

Nomi delle interfacce differenti

A volte le schede di rete assumono nomi differenti tra un riavvio e l’altro. Configurare la connessione di rete è difficile se non si se la scheda verrà chiamata eth0 o eth1.

È possibile ovviare utilizzando ifrename, vedere Rename network interfaces

È anche possibile creare manualmente le regole di udev per assegnare all’interfaccia i nomi basandosi sui relativi MAC Address.

/etc/udev/rules.d/10-network.rules

SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"

Per maggiori informazioni riguardo gli ultimi due metodi, consultare la guida originale di udev, vedere la pagina wiki di Udev.

Udev#Ordinamento delle periferiche, schede di rete/audio che cambiano ordine ad ogni avvio

Problema No Link / WOL schede Realtek

Gli utenti che hanno schede di rete con chipset Realtek 8168/8169/8101/8111 possono avere il problema che l'interfaccia sembri disabilitata in fase di avvio e il led sia spento. Questo, di solito, accade in caso di dual boot insieme a Windows. Sembra che il problema sia dovuto all' utilizzo dei driver ufficiali Relatek (qualsiasi versione successiva al Maggio 2007) in ambiente Windows. Questi driver disabiltano il Wake-on-Lan in fase di spegnimento di Windows, lasciandola in questo modo finchè Windows non viene riavviato. Per verificare se il problema affligge anche la nostra scheda semplicemente notando che il led dell'interfaccia rimane spento a meno che non si avvii Windows. In condizioni normali il led dovrebbe essere sempre acceso finchè il Pc è acceso, anche durante il POST. Questo problema affliggerà tutti i sistemi che non hanno driver aggiornati (esempio i live CD). Ecco alcune possibili soluzioni al problema:

Metodo 1 - Ripristino driver Windows

E' possibile fare un ripristino del driver Windows alla versione fornita da Microsoft (se disponibile), o ripristinare una versione del driver Realtek a precedente al Maggio 2007 (che probabilmente si trova sul CD di installazione dell'hardware).

Metodo 2 - Abilitare il Wake on Lan nel driver Windows

Probabilmente il metodo migliore e più veloce è cambiare questa impostazione nel driver Windows. Questo metodo dovrebbe anche risolvere il problema non soltanto per Arch, ma anche per altri sistemi, come Live CD ed altri. In Windows, sotto "Gestione Periferiche", trovate la scheda Realtek e selezionatela. Nella scheda "Avanzate" abilitate "Wake-on-lan after shutdown".

In Windows XP (example)
Right click my computer
--> Hardware tab
  --> Device Manager
    --> Network Adapters
      --> "double click" Realtek ...
        --> Advanced tab
          --> Wake-On-Lan After Shutdown
            --> Enable

Nota: I nuovi driver Realtek di Windows (testato con Realtek 8111/8169 Driver LAN v5.708.1030.2008, datato 2009/01/22, disponibile da GIGABYTE) potrebbero fare riferimento a questa opzione in modo leggermente diverso, come Shutdown Wake-On-LAN --> Enable. Sembra che cambiare in Disable non produca alcun effetto (si noterà che la luce Link rimarrà accesa fino alla chiusura di Windows). Una soluzione, non proprio pulitissima, è avviare Windows e semplicemente resettarlo (eseguendo un brutale riavvio/spegnimento), non dando quindi al driver di Windows la possibilità di disabilitare la LAN. La luce Link rimarrà accesa e l’adattatore LAN rimarrà accessibile dopo il POST – cioè fino a quando non si avvierà Windows e lo si spegnerà correttamente.

Metodo 3 - Aggiornare il driver Linux Realtek

Scaricare ed installare una nuova versione del driver dal sito ufficiale Realtek. (non testato ma dovrebbe risolvere il problema).

Metodo 4 - Abilitare LAN Boot ROM nel BIOS/CMOS

Sembra che abilitando nel BIOS/CMOS l’impostazione Integrated Peripherals --> Onboard LAN Boot ROM si riattivi il chip Realtek LAN all’avvio del sistema, nonostante il driver di Windows lo disabiliti allo spegnimento.
Ciò è stato testato più volte e con successo con una GIGABYTE GA-G31M-ES2L su un BIOS versione F8 rilasciato il 2009/02/05. Formato data YMMV.

Problema con DLink G604T/DLink G502T DNS

Gli utenti che posseggono un router DLink G604T/DLink G502T, utilizzano DHCP ed hanno un firmware v2.00+ (in genere utenti con firmware AUS), possono avere problemi con alcuni programmi nel risolvere i DNS. Uno di questi programmi, sfortunatamente, è pacman. Fondamentalmente il problema è che il router, in certe situazioni, non invia correttamente i DNS al DHCP, ciò fa sì che i programmi provino a connettersi al server con IP 1.0.0.0 ricevendo un errore di connessione scaduta.

Come diagnosticare il problema

Il metodo migliore per diagnosticare il problema è utilizzare Firefox/Konqueror/links/seamonkey ed abilitare wget per pacman. Se questa è una nuova installazione di Arch Linux, allora si può prendere in considerazione l’idea di installare links attraverso il live CD.

Prima di tutto, abilitare wget per pacman (in modo da ricevere informazioni inerenti il download dei pacchetti da parte di pacman). Aprire /etc/pacman.conf con l’editor di testo che si preferisce e decommentare la seguente linea (eliminare il cancelletto #):

XferCommand=/usr/bin/wget --passive-ftp -c -O %o %u

Mentre si edita il file /etc/pacman.conf controllare che il mirror predefinito che pacman utilizza per il download dei pacchetti.

Ora aprire il mirror predefinito in un browser Internet per verificare se esso funziona. Se funziona, eseguire pacman -Syy (altrimenti scegliere un altro mirror ed impostarlo come predefinito di pacman), se si ottiene qualcosa di simile a quanto segue (notare 1.0.0.0):

ftp://mirror.pacific.net.au/linux/archlinux/extra/os/i686/extra.db.tar.gz                                                            
           => `/var/lib/pacman/community.db.tar.gz.part'
Resolving mirror.pacific.net.au... 1.0.0.0

allora molto probabilmente si tratta di questo problema. 1.0.0.0 significa che non è stato possibile risolvere i DNS, perciò essi vanno aggiunti a /etc/resolv.conf.

Come risolvere il problema

Fondamentalmente bisogna aggiungere manualmente i server DNS al file /etc/resolv.conf, il problema è che DHCP elimina automaticamente e sostituisce il file all'avvio, perciò è necessario editare /etc/conf.d/dhcpcd e modificare i flag per impedire che ciò accada:

Quando si apre il file /etc/conf.d/dhcpcd, si dovrebbe vedere qualcosa di simile a quanto segue:

DHCPCD_ARGS="-t 30 -h $HOSTNAME"

Aggiungere il flag –R agli argomenti, ad esempio:

DHCPCD_ARGS="-R -t 30 -h $HOSTNAME"

Nota: Se si utilizza dhcpcd >=4.0.2 il flag –R è obsoleto. Si prega di vedere la sezione #DHCP per informazioni su come utilizzare e modificare il file /etc/resolv.conf

Salvare e chiudere il file, poi aprire /etc/resolv.conf. Si dovrebbe visualizzare un singolo nameserver (molto probabilmente 10.1.1.1). Questo è il gateway al router, a cui è necessario per ottenere i server DNS del proprio ISP. Incollare l'indirizzo IP nel browser ed effettuare il login al proprio router. Andando nella sezione DNS si dovrebbe vedere un indirizzo IP alla voce Primary DNS Server (Server DNS preferito), copiarlo ed incollarlo come voce nameserver, SOPRA il gateway corrente.

Ad esempio, il file /etc/resolv.conf dovrebbe essere simile a:

nameserver 10.1.1.1

Se il proprio DNS primario è 211.29.132.12, cambiare /etc/resolv.conf in:

nameserver 211.29.132.12
nameserver 10.1.1.1

Ora riavviare il demone di rete eseguendo /etc/rc.d/network restart e pacman -Syy. Se si sincronizza correttamente con il server, allora il problema è risolto.

Maggiori informazioni

Questo è il forum whirlpool (Comunità Australiana ISP) che parla del problema e suggerisce la medesima soluzione

http://forums.whirlpool.net.au/forum-replies-archive.cfm/461625.html

IP da errato DHCP collegato (tramite VPN) al router

Si ha una rete in cui sono collegati insieme tramite VPN due router. Un router è a casa e l’altro in un altro luogo completamente diverso. In alcuni casi, sembra che il router connesso tramite VPN assegni un indirizzo IP al pc. Non si sa se c’è un metodo per prevenire che ciò accada, ma c’è un modo per risolvere il problema. In una console, da root, eseguire:

dhcpcd -k
dhcpcd

La prima riga azzera l’indirizzo IP e la seconda ne richiede uno nuovo. Affinché ciò funzioni, è necessario eseguire questi comandi più volte, anziché aspettarsi un risultato positivo già dopo la prima esecuzione. Nel caso in cui non dovesse funzionare, potrebbe essere necessario scollegare la connessione VPN e provare nuovamente con i comandi di cui sopra.

Questo metodo funziona anche quando è installato NetworkManager.

Realtek 8111E perde molti pacchetti packets/dmesg è pieno di messaggi

Questo problema interessa attualmente la rev6 del modello 8111. Per verificare se si dispone di questo chip, visualizzare l'output del comando seguente:

lspci | grep 8111

Se si ottiene qualcosa simile a questo:

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

e nel dmesg sono presenti svariate linee contenenti:

r8169 0000:03:00.0: eth0: link up

si sta utilizzando un driver non corretto. Per risolvere, installare da AUR il pacchetto r8168^AUR, inserire in blacklist il modulo del kernel r8169, e riavviare per applicare le modifiche.

Presumibilmente questo problema sarà fixato in Linux 3.0

Fonte: http://forums.gentoo.org/viewtopic-t-881217-start-0.html

Wiki Correlati

Samba