2013-04-18

‎Sin eth0 con Atheros AR9485: Actualizar

← Older revision

Revision as of 21:06, 18 April 2013

(3 intermediate revisions by one user not shown)

Line 110:

Line 110:

== Interfaces de red ==

== Interfaces de red ==



=== Nombres
permanentes para
los dispositivos ===

+

=== Nombres
de
los dispositivos ===



Para las placas base que
tienen
tarjetas de red integradas, es importante
saber cuál es considerada la NIC primaria (por ejemplo {{ic|eth0}}) y cuál es considerada la NIC secundaria (por ejemplo, {{ic|eth1}})
. Muchos de
los problemas
son causados ​​por
la configuración incorrecta cuando
los
usuarios establecen la red para {{ic|eth0}}, cuando, en realidad, tienen su cable Ethernet conectado a {{ic|eth1}}
.

+

Para las placas base que
tengan
tarjetas de red integradas, es importante
contar con el nombre fijo del dispositivo
. Muchos
problemas
de
configuración
son causados ​​por los
nombres cambiantes de las interfaces
.



[[
Udev (Español)|
Udev]] es responsable de
asignar
qué nombre se dé a cada dispositivo.
Con udev y
los
controladores
de
red modulares, la numeración
de
la interfaz de red no permanece la misma entre cada reinicio
,
ya
que los
controladores se cargan
en
paralelo y
,
por lo tanto
,
en orden aleatorio. La configuración
de
la conexión a la red es difícil
,
si no se sabe si su tarjeta se llama
{{ic|
eth0
}}
o {{ic|eth1}}. Para poder solucionar este problema use {{ic|ifrename}}. Véase [[Rename network interfaces|Renombrar interfaces de red]]. También es posible crear manualmente reglas udev que asignen nombres a las interfaces basadas en la dirección MAC de la interfaz. Véase [[Udev_(Español)#Dispositivo_Network|Dispositivo de red]]
.

+

[[Udev]]

es responsable de qué nombre se dé a cada dispositivo.
Systemd v197 introdujo
los
[http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Nombres Predecibles
de
las Interfaces
de
Red]
, que
asigna automáticamente nombres estables a
los
dispositivos de red. Los nombres de las interfaces estarán precedidos por
en
(ethernet)
,
wl (WLAN)
,
o ww (WWAN) seguidos
de
un identificador generado automáticamente
,
creando una entrada como
{{ic|
enp0s25
}}.



{{Nota|Systemd v197 introduce [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Nombres de Interfaces de Red Predecibles], que asigna automáticamente nombres estáticos para los dispositivos de red. Las interfaces empiezan ahora con el prefijo en (ethernet), wl (WLAN), o ww (WWAN) seguido de un identificador generado automáticamente, creando una entrada como {{ic|enp0s25}}.
Este comportamiento puede
desactivarse si añade
un enlace simbólico:

+

Este comportamiento puede
ser desactivado mediante la adición de
un enlace simbólico:

# ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

# ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules



Los usuarios que actualicen desde una versión de systemd
anterior
tendrán un archivo de reglas en blanco creado automáticamente.}}

+

Los usuarios que actualicen desde una versión
anterior
de systemd tendrán un archivo de reglas en blanco creado automáticamente
. Así que, si desea utilizar los nombres permanentes de los dispositivos, basta con borrar dicho archivo.

+

+

==== Cambiar el nombre de dispositivo ====

+

Puede cambiar el nombre del dispositivo mediante {{ic|ifrename}} del paquete {{Pkg|wireless_tools}}.

+

+

Ejecute ifrename directamente:

+

+

# ifrename -i eth0 -n lan

+

+

o cree un archivo de configuración ({{ic|/etc/iftab}}), por ejemplo:

+

+

lan mac 00:0C:6E:C6:94:81

+

internet mac 00:0C:6E:C6:94:82

+

+

y ejecute

+

+

# ifrename -c /etc/iftab

+

+

Si utiliza ppp, añada en el script {{ic|/etc/ppp/ip-up}} las siguientes líneas:

+

+

IF=$1

+

ip link set dev $IF down

+

/usr/sbin/ifrename -i $IF -n

+

ip link set dev
up

+

+

donde
es el nuevo nombre para la interfaz ppp.

+

+

===== Regla Udev =====

+

Otra forma es definir el nombre manualmente con una regla de udev. Por ejemplo:

+

{{hc|/etc/udev/rules.d/10-network.rules|2=

+

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net1"

+

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="net0"}}

+

Algunas consideraciones:

+

+

* Para obtener la dirección MAC de cada tarjeta, utilice esta orden: {{ic|cat /sys/class/net/'''device-name'''/address}}
udevadm info -a -p /sys/class/net/
| grep address | tr [A-Z] [a-z]
}} -->

+

* Asegúrese de utilizar los valores hexadecimales en minúsculas en las reglas de udev. No use mayúsculas.

+

{{Nota|Al elegir los nombres permanentes '''se debe evitar el uso de nombres con el formato "eth''X''" y "wlan''X''"''', ya que esto puede conducir a conflictos entre el kernel y udev durante el arranque. En cambio, es mejor utilizar nombres de interfaces que no sean utilizados por el kernel por defecto, por ejemplo:  {{ic|net0}}, {{ic|net1}}, {{ic|wifi0}}, {{ic|wifi1}}. Para más detalles, consulte la documentación de [http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames systemd]
.}}

=== Conocer el nombre actual de los dispositivos ===

=== Conocer el nombre actual de los dispositivos ===

Line 535:

Line 571:

==== ¿Cómo arreglarlo? (El método correcto) ====

==== ¿Cómo arreglarlo? (El método correcto) ====



Simple: Deshabilita Window Scaling. Si bien el Window Scaling es una buena característica TCP, puede resultar mala, especialmente si no puedes reparar tu router dañado. Hay varias formas de deshabilitar Window Scaling, y parece que la mejor (la que funcionará en la mayoría de los kernels) es añadir las siguientes líneas
al
/etc/
rc
.
local:

+

Simple: Deshabilita Window Scaling. Si bien el Window Scaling es una buena característica TCP, puede resultar mala, especialmente si no puedes reparar tu router dañado. Hay varias formas de deshabilitar Window Scaling, y parece que la mejor (la que funcionará en la mayoría de los kernels) es añadir las siguientes líneas
a {{ic|
/etc/
sysctl
.
conf}} (véase también [[sysctl]])



echo 0 > /proc/sys/
net
/
ipv4
/
tcp_window_scaling

+

net
.
ipv4
.
tcp_window_scaling
= 0

==== ¿Cómo arreglarlo? (El método óptimo)====

==== ¿Cómo arreglarlo? (El método óptimo)====

Line 671:

Line 707:

La conexión ethernet (eth0) para Atheros AR9485 no está funcionando una vez instalada (con el soporte de instalación de marzo de 2013). La solución para que funcione es instalar el paquete [https://aur.archlinux.org/packages/compat-drivers-patched/ compat-drivers-patched] desde AUR.

La conexión ethernet (eth0) para Atheros AR9485 no está funcionando una vez instalada (con el soporte de instalación de marzo de 2013). La solución para que funcione es instalar el paquete [https://aur.archlinux.org/packages/compat-drivers-patched/ compat-drivers-patched] desde AUR.

+

+

=== Sin transporte/sin conexión después de la suspensión ===

+

Después de suspender la RAM nos encontramos sin ​​conexión aunque el cable de red esté enchufado.

+

Esto puede ser causado por la administración de energía PCI. Cuál es la salida de:

+

+

# ip link show eth0

+

+

si la línea contiene "NO-CARRIER" a pesar de que hay un cable conectado a su puerto eth0, es posible que el dispositivo se haya autosuspendido y la característica de detección de medios no funciona. Para solucionar esto, primero es necesario encontrar la direccione PCI del controlador ethernet con:

+

+

# lspci

+

+

debe ser similar a esto:

+

+

...

+

00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06)

+

...

+

+

En este caso la dirección es 00:19.0.

+

Ahora comprobaremos el estado de PM del dispositivo mediante la emisión de:

+

+

# cat "/sys/bus/pci/devices/0000:00:19.0/power/control"

+

+

sustituyendo 00:19.0  con la dirección obtenida de lspci.

+

Si en la salida se lee "auto", puede tratar de abrir el dispositivo después de la suspensión con:

+

+

# echo on > "/sys/bus/pci/devices/0000:00:19.0/power/control"

+

+

No olvide sustituir la dirección otra vez.

+

+

{{Nota|1=Esto parece ser un error en el kernel 3.8.4.1: [https://bbs.archlinux.org/viewtopic.php?id=159837&p=2 discusión del foro.] Otra solución podría ser [https://lkml.org/lkml/2013/1/18/147 este camino.] Mientras tanto, lo anterior es una solución adecuada.}}

Show more