Seguridad Wireless - Wifi
Suite Seguridad Wireless => Colaboracion y desarrollo de nuestras lives => Mensaje iniciado por: USUARIONUEVO en 24-07-2014, 09:23 (Jueves)
-
Habia actualizado hace una o dos semanas el sistema xorg ..
con sus drivers y tal, todo va oerfecto , pero ayer me puse a trastear con los drivers ati oficiales..y
no se muy bien por que ... tanto firefox como chrome , al quere ejecutarlos el sistema se sale, y se va a la pantalla tipica de login de acceso.
es raro , puesto que incluso hashcat funciona bien ... solo tengo problema con los navegadores ,,,
de momento volvere al sistema xorg que tenia... que se que es estable , y ya ire mirando este tema con calma...
deberia mirar con los drivers nvidia , para descartar que sea realmente algo del sistema...
puede ser el xorg ... o el driver ati ... probe incluso el driver ati beta mas nuevo , y me petaba igualmente , con el xorg viejo todo perfecto.
_________________________
y en otro orden pero relacionado con lo comentado ...
he escrito un "mecanismo" , ... DE MOMENTO SOLO DRIVERS ATI , ... para que el mismo modulo de drivers ati , valga para siempre .... ( o al menos mientras hashcat no pida de uno mas nuevo ) , ... independientemente del kernel , o incluso si lo actualizais,
este es el code , ..ahora os lo explico mejor...
##### Function by USUARIONUEVO -->> www.seguridadwireless.net
# Para modulos extras de drivers
# ATI
kernel_ati=/lib/modules/$(uname -r)/kernel/drivers/char/drm/fglrx.ko
if [ ! -f $kernel_ati ]; then
if [ -f /usr/bin/aticonfig ]; then
echo "[1;37m[[1;32m+[1;37m][0m [1;37mDetectado driver[1;31m ATI[1;37m ... intentando crear fichero fglrx.ko[0m"
ati_rebuild &>/dev/null
fi
fi
if [ -f /etc/X11/xorg.conf ]; then
if grep -wq fglrx /etc/X11/xorg.conf ; then
rm -r /etc/X11/xorg.conf
fi
fi
if [ ! -f $kernel_ati ]; then
if [ -f /etc/modprobe.d/blacklist-fglrx.conf ]; then
rm -r /etc/modprobe.d/blacklist-fglrx.conf
fi
fi
if [ -f $kernel_ati ]; then
echo "[1;37m[[1;32m+[1;37m][0m [1;37mDetectado driver[1;31m ATI[1;37m ... reconfigurando sistema[0m"
aticonfig --initial &>/dev/null
cat > /etc/modprobe.d/blacklist-fglrx.conf << "EOF"
blacklist radeon
EOF
fi
bueno ..pues, el sistema empieza a cargar drivers, justo en ese punto donde en el arranque veis lo de udev trigering..y se autoajusta la resolucion de pantalla...
mi handicap ,estaba en que el sistema se diera cuenta antes de ese momento, de la existencia del modulo de driver ati ,,, y entonces on the fly .. compilar el fichero fglrx.ko ... ese es el name del driver ..se genera al vuelo ...se blacklistea el radeon que es el basico de sistema ... y se genera el org.conf ... por ultimo ya el sistema llama a udev ..
voy a intentar explicar facil, el asunto ..
se mira si el fichero .ko ya existe ... SI NO ES ASI
se mira si existe el aticonf --> si esto existe el modulo esta cargado ..con lo que debera intentar generar el driver al vuelo
el driver para funcionar usa dos ficheros de configuracion , uno es el xorg.conf y el otro es blacklist para driver basico radeon
con lo que si el fichero .ko no existiese pero esos ficheros si , se eliminarian,por que si no el sistema no arranca..al estar configurado con esos ficheros para fglrx y el sistema no tenerlo e intentra usar el basico radeon.
en casi de la SI EXISTENCIA DEL FICHERO fglrx.ko .. en ese caso ..se genera de nuevo el xorg.conf ,con el comando
aticonfig --initial
eso genera el xorg.conf
y esto regenera el blacklist del radeon para funcionar el fglrx
cat > /etc/modprobe.d/blacklist-fglrx.conf << "EOF"
blacklist radeon
EOF
es la primera vez que enlazo un if ..dentro de otro if, y la verdad es bastante util.
con esto ,como el .ko se genera a cada arranque ...( si ya existe no lo regenra ni toca nada de nada ) ..funcionara sea el kernel que sea...
¿ como sabe el sistema, a cada vez y momento el kernel que va a usar y si el fichero esta dentro ?
/lib/modules/$(uname -r)/kernel/drivers/char/drm/fglrx.ko
lo unico que varia en la ruta de los kernels es su name y numero ..en rojo , esta el argumento , que descubre cual se va a usar ...
-
resumido para quien no se haya enterao de na..
si yo tengo un kernel 3.12.25 y me actualizao a un 3.12.27 , el MISMO MODULO DE DRIVER ATI , seguira funcionando ... ;D
en algun moemnto el driver no servira POR SER OBSOLETO , para hascat o por que falle ante una rama de kernel mas alta..
solo en ese punto , se necesitara generar un nuevo xzm del driver ati. ( en el cual en realidad solo guardamos las librerias ,ya que el driver se genera limpio a cada vez que sea necesario)
ahora la cuestion es si podre hacer lo mismo para el nvidia... ;D
hasta ahora era una lacra , que el modulo solo sirviera para una unica version ... con esto como digo ,..servira hasta la necesidad de una version nueva de driver. >:( >:( >:(
-
y el script ati_rebuilder
que es el que intentara generar el fglrx al vuelo ...
tenia implementada la funcion de incluso generar el xzm ... pero solo serviria para confundir ..
si es live , se genera a cada arranque ( penalizacion de unos 3-5 segundos ) ... no es mucho penalizacion me refiero a que tarda unos 3 segundos mas en arrancar por este tema.
si esta en hdd ... pues se verificara al arranque ... el kernel..y en caso de cambios por update , el script entrara al trapo ..generara el .ko y no notaremos absolutamente nada..habremos actualizado el kernel y no perderemos el driver oficial ati.
#!/bin/bash
NAME=ati
KERNEL=$(uname -r)
DESTDIR=$HOME/Desktop/$NAME-$KERNEL/lib/modules/$KERNEL/kernel/drivers/char/drm
DRIVER=/lib/modules/fglrx/build_mod/2.6.x/fglrx.ko
# Primero limpiamos
cd /lib/modules/fglrx/build_mod/2.6.x/
make clean
rm -Rf /lib/modules/fglrx/build_mod/fglrx.ko
rm -Rf /lib/modules/fglrx/*ko
rm -Rf /lib/modules/fglrx/*log
# Recompilamos driver e instalamos
cd /lib/modules/fglrx/build_mod &> /dev/null
./make.sh
cd /lib/modules/fglrx/ &> /dev/null
./make_install.sh
#mkdir -p $DESTDIR &> /dev/null
#cp $DRIVER $DESTDIR &> /dev/null
#echo "Generando modulo xzm ..."
#dir2xzm $HOME/Desktop/$NAME-$KERNEL $HOME/Desktop/$NAME-$KERNEL.xzm -n &> /dev/null
#rm -Rf $HOME/Desktop/$NAME-$KERNEL &> /dev/null
#exit 0
creo que NO HAY NINGUN OTRO SISTEMA LINUX , con un mecanismo similar ...
-
creo que sobra decirlo ,pero
SI NO SE DETENTA EL MODULO XZM DE DRIVER ATI , TODO ESTO ES TRASPARENTE ... Y FUNCIONARA TODO COMO SIEMPRE
el mecanismo solo entra a juego con la certeza de estar el driver ati.
¿ que ocurre con la opcion de arranque vesa?
eso sigue trasparente ..ya que en la linea de arranque se dice que aunque exista el modulo xzm de ati , no se cargue, con lo que el mecanismo no entrara al trapo. ;D
siento daros la chapa, con mis movidas .. 8) 8) 8) 8)
-
bueno , pues después de 3 días hechandole muchas horas , y tras muchos cabreos con ganas de reventarlo todo , ... he dado con el asunto.
es un poco largo de explicar , pero intentare ser breve ,,,
en el sistema como sabeis , hay varios xzm , y van cargando uno tras otro en cierto orden NECESARIO , ..por eso llevan números.
pues por ejemplo ..
001 tiene el fichero CADENAME
y a lo mejor en el
003 tengo el mismo fichero , pero retocado por algo ... (el modulo wifislax-desktop) , es casi exclusivo de ficheros ajustados y salvados lejos de updates y demás...
un fichero , puede sobreescribir un fichero
un enlace simbolico puede sobreescribir un enlace simbolico
pero ni un fichero puede sobreescribir un enlace ni un enlace sobreescribir un fichero
al igual con carpetas...
si tienes un fichero en 001 solo puede ser sobreescrito por un fichero llamado igual
si tienes un simbolico en 001 solo puede ser sobreescrito por un simbolico llamado igual
si tienes una carpeta en 001 solo podría ser sobreescrito por una carpeta igual
___________________________________________________________
¿ queda claro lo anterior ?
pues la aceleración 3d (librería mesa) tiene los siguientes ficheros
libGL.so.0 -->> simbolico hacia libGL.so.1
libGL.so.1 -->> simbolico hacia libGL.so.1.2.0
libGL.so.1.2.0 -->> FICHERO REAL FINAL
Y el driver ati intentada hacer esto
libGL.so.0 -->> simbolico hacia libGL.so.1
libGL.so.1 -->> simbolico hacia libGL.so.1.2.0
libGL.so.1.2.0 -->> SIMBOLICO HACIA UNA DE SUS LIBRERIAS
Y ES HAY en el 1.2.0 estaba el fallo ... al ser un simbolico no se podía hacer y entonces el simbolico
libGL.so.1
seguía apuntando hacia el fichero real del sistema 1.2.0
¿ solución ?
en el driver ati ...
coger el simbolivo 1.2.0 y borrarlo ..
ese apuntaba hacia /usr/lib/fglrx/fglrx-libGL.so.1.2.0
pues directamente del tiron
copiamos fglrx-libGL.so.1.2.0 en /usr/lib
renombrándola como la original del sistema
fglrx-libGL.so.1.2.0 copiada a /usr/lib ,eliminamos el original 1.2.0 y renombramos la fglrx, como el original
fglrx-libGL.so.1.2.0 -->> libGL.so.1.2.0
con lo que al ser FICHERO , podrá SOBREESCRIBIR EL ORIGINAL DEL SISTEMA ... >:D >:(
esta jilipollez me ha tenido amargado 3 días , instalando slackwares al hdd y viendo que allí funcionaba bien ..
después instalando wifislax al hdd e instalándole el driver funcaba bien
en modo live NO ...por el royo este de un simbolico que intentaba sustituir un fichero real... :-\ :P
claro , en el hdd no hay problema...por que el driver al instalarse , ... elimina el fichero original , y después crea el enlace..asi si ... en live la historia es diferente. 8)
____________________________________________________
además de eso , ya por fin puedo decir que tengo 100x100 funcional ,el tema del driver que servirá para mas de una versión ( hasta que hashcat pida un driver mas nuevo y haya que reconstruir el modulo, servirá el mismo aunque actualiceis kernel)
en live me funcionaba bien ,por que el initrd monta el sistema como rw ( read write , lectura/escritura ) ..
cuando la instalaba a disco duro , NO FUNCIONABA ,por que el grub de los coj0nes , mete en el arranque "ro"
ro = Read Only
con lo que no podía escribir sobre la marcha ...
no encontré como eliminar que el grub añada eso ...y necesitaba rw
con lo que el grub , de una forma no muy elegante después de ro vga=788 ,añade un rw , con lo que como la ultima orden en rw queda como lectura/escritura y ya si entonces funciona todo.
resumiendo , .. movidas de las que no se ven , y me tienen atrapado durante días
estoy subiendo una iso ... pero no os vale la pena bajarla, por que no hay nada nuevo en ella ... solo se mantiene el xorg-server nuevo ... los scripts updaters esta todo parado , por que estuve con este royo estos 3 días.
Miedo me da , el driver nvidia ;D ... aunque sabiendo donde esta el problema, la solución es fácil.
-
Muy buena! Menudo lince, no son cosas fáciles de ver... jajajaja
Salu2
-
tema zanjado , cierro el post ,y dejo la chapa, para quien quiera leer. ;)