Mensajes

Intentaste hacerlo manualmente con wpa_supplicant? Quiza así tengas menos problemas. Por ahi el front-end te tira wpa_supplicant a correr como daemon, o lo tenés configurado como default y entonces intenta conectarse de nuevo y se cuelga con las solicitudes DHCP. Siempre es mejor hacer el intento a mano a ver qué dice.

Depende el modelo de broadcom que tengas, podrías intentar con el driver b43. Supongo que tendrías que quitar algunos módulos incompatibles antes, pero b43 tiene buen soporte.

De cualquier forma... podés revisar esta página. Al final hay una lista con dispositivos USB, PCI, etc... ahi podés ver con qué driver corren y elegir uno con el que ni necesites drivers parcheados. Me refiero a que no necesitas comprar una lap por la tarjeta de red, basta que tengas una plaquita compatible con algún driver. Adicionalmente, Back|Track YA TRAE todos los drivers parcheados (si vas a elegir una tarjeta atheros, deberías ver lan notas de compatibilidad de madwifi).

Acordate de hacer los tests de modo Monitor e inyección de paquetes (tanto en modo Monitor como Managed, algunas placas soportan inyección en ambos modos) inmediatamente para verificar que la placa tiene todo el soporte que necesitas.

Estos tests se hacen POR PLACA Y POR DRIVER. Significa que con una placa broadcom (por ejemplo) debes hacer más de un test, puesto que hay más de un driver. Observa este comentario de aircrack:

"Users whom use broadcom linux_sta driver (otherwise known as wl) should note that there are no monitor/injection modes with such driver. Broadcom deliberately removed the functionality out of their proprietary binary blob"

Más información del driver b43 para Broadcom aca (agrego ->) y acá también, obvio.

Saludos

Qué tarjeta traen los acer? Hay tarjetas que funcionan con drivers propietarios (broadcom ejem....). Drivers que, de más está decir, suelen NO funcionar bien, y no tienen opciónes que nos gustaría usar, como activar el modo monitor para usar airodump.

Pega el lspci, intenta con una tarjeta USB, busca un driver abierto... y dinos ejemplos de lo que quieres hacer, y qué mensaje(s) obtienes.

Saludos

En realidad, direct connection solo saltará el proxy del trabajo, ¿cierto? Pero eso no asegura el acceso a ciertas webs, que pueden estar bloqueadas por firewall, o por lo que sea. Métodos más eficientes.

Quizá la pregunta más tonta pero no por ello menos útil, sea: probaste poner "https://www.facebook.com"?

He tenido el agrado de encontrarme más de una vez con que se filtra http, pero https pasa de largo. Si eso no funciona, entonces vas por algo más complejo, pero si eso funciona no hay porqué hacerse tanto lío.

La otra opción son sitios como the-cloak, y navegar a través de ellos como proxys.

Saludos

Una sola cosa para agregar. UNICS viene de MULTICS, que era el proyecto real de AT&T (este sistema experimental que mencionas). Lo realmente interesante de Ritchie es que para poner a funcionar el juego empezó a usar las cosas que traia de MULTICS, pero solo algunas. No necesitaba un superentorno, solo necesitaba que el juego funcione.

A eso el apodo del sistema fue UNICS, por ser un MULTICS castrado. De ahi viene Unix. Luego fue rehacerlo escrito en C.

Cuando AT&T privatiza UNIX, impidiendo a las universidades enseñar mostrando el código fuente, es cuando Tanembaum escribe MINIX, y el resto es historia, incluso para el lado de los BSD, NetBSD y la extraña personalidad de Theo de Raadt, etc...

Saludos

Creo que intentaba interpretar pero entré en un bucle.

A nivel web, puedes ir por ahi sabiendo lo básico de HTML, pero no harás más que lo básico sabiendo lo básico. Es un poco obvio que aprender lo básico sirve de poco.

En el caso de SQL me quedé anonadado. ¿Piensas hacer SQL injection sin conocer SQL a fondo, y consideras que 'injection' es de lo básico que podrías aprender? Uno inyecta SQL cuando sabe de SQL y del lenguaje que lo genera, como puede ser PHP, como para burlarlo un poco.

Desde mi punto de vista, la primer respuesta es obvia y la segunda pregunta no es razonable. No tiene mucho sentido, es como que me preguntaras: ¿Necesito aprender química, o solo me basta con saber química nuclear?

Saludos

[Que haga lo que debe]

A ver, algo de información...

Por ahora le puse SAFA, no se si vaya a quedar así, pero me sonó bien y viene a "Simple-And-Fast-Alternative", y da juego a "Simple and fast alternative VCS", etc... el resto, por lo pronto pensé varios conceptos, varias ideas, todos a discutir y flexibilizar para que sea lo mejor según todos y para todos (o la gran mayoría):

Que haga lo que debe:
Mi idea principal es enfocarme en lo que queremos que haga bien. La filosofía UNIX es lo primero (simplicidad y modularización), lo segundo es "¿es sensato aplicarlas a este caso?", y la regla para elegir entre 1 y 2 es la de la menor sorpresa. Lo mismo para las features y elecciónes. Si una funcionalidad no primaria en cuanto a nuestros objetivos interfiere con una primaria, no se hará, o se pondrá como opcional, a menos que eso determine la utilización más intuitiva.

En distributed VCS, el historial es un concepto LOCAL:
Simplemente eso. A cualquiera le cansa la necesidad de estar horas descargando el kernel de LINUX via GIT ¿Porque querría yo tener el desarrollo de LINUX desde que debutó en el repo de GIT? Es realmente tedioso saber que gran cantidad del tiempo y espacio en disco perdido es para cosas que no vas a utilizar... NUNCA. Mi idea es un historial donde podamos adjuntar o desprender partes antiguas, quizá almacenarlas, quizá no.

Las buenas operaciones no se ponen en un programa, se ponen en una API:
La idea es tener una buena API en C, un wrapper en C++, y de ahi a Ruby, Python, etc... para que programar sobre la base del core del versionador sea sencillo sin importar en que programes. Uno no tiene porqué hacer una horrenda cañeria con PIPES para trabajar con el versionador. El concepto de plomería debería ser un poco más refinado que eso.

La sincronizacion es una buena idea, pero es mejor la actualización asíncrona:
Me ha pasado, en GIT, que no puedo hacer una sincronización via "clone", "push", "fetch", etc... por temas de red. Cuando esto pasa, nos sentimos tentados a enviar un patchset. El problema es que de esta forma los commits ya no conservaran el SHA-1, porque al aplicarse un parche se hace un nuevo commit. Poder empaquetar una sincronización es ilusorio, porque sincronizar requiere trabajo de ambas partes, pero la actualización asíncrona es algo factible. Podemos empaquetar una actualización desde el commit A al B, y dejarla guardada, enviarla por e-mail, etc, sin destruir el contenido exacto, y por lo tanto las huellas criptográficas del historial.

Los commits no son los cambios reales:
Los commits son piezas de información referentes a un árbol, que nos ayudan a comprender lo que ha cambiado respecto al anterior, son partes del log. Entonces podría anidar commits para sumarizar información en niveles. Hablando del modelo ITIL, un release puede incluir varios cambios, algunos grandes y otros chicos. Si el log fuera como nuestro "changelog", podríamos mejorarlo haciendo que se puedan anidar los cambios grandes como muchos commits dentro de un commit, entonces los 2 niveles pueden expandirse, hasta que llegamos a los commits que apuntan a los árboles. Esto me indica que puedo ver la información en perspectiva, "granulada" o no.

La decisión de cómo almacenar es un concepto local:
Un usuario puede preferir hacer un blob nuevo cada vez que cambia un archivo, o puede decidir grabar diffs entre release y release. Estas decisiónes influiran en la velocidad de checkout, el consumo de disco, etcetera. Al armar un paquete de sincronización, siempre se elegirá hacer deltas para disminuir la cantidad de información enviada, así que el almacenamiento queda como una elección para el usuario.

A demás, un sistema distribuido con un un repo central puede configurarse para ser (pseudo)centralizado, donde se agregan acciones de bloqueo y desbloqueo, con varias metodologías posibles, desde privilegios hasta autobranching (esa palabra la acabo de inventar, pero creo que se entiende).


Aunque hay muchos más, la rigidez en conceptos no es compatible 100% con el desarrollo en grupo.

Por ahora estoy usando GoogleGroups y Trello, que me parece práctico, pero estoy prácticamente solo. Hice algunos scripts de shell (bash) aunque planeo que todo el core termine siendo traducido a C inicialmente para la API y luego llevada esta hacia el programa.

Deje el ultimo fuente en trello, pero se puede usar GIT hasta que SAFA sea capaz de auto-hospedarse.

Como para que se copen, les dejo algunos pedazos de código que pueden ver, uno es la biblioteca de funciones del shell, que es sencilla y les permitirá ver algunas de las premisas que tengo para programar:

Código (bash) [Seleccionar] Expandir

# DEBUG FLAG: 0/1
test -z $DEBUG_ && DEBUG_=0

DEBUG() {
test $DEBUG_ -eq 1 && $*;
}

ERROR_print() {
echo "[error] $*"
}

DEBUG_print() {
DEBUG echo "[debug] $*"
}

DIE() {
DEBUG_print "DIE ($*)"
ERROR_print $*
exit 1
}


El otro, un pequeño comando en PERL para obtener los permisos octales de un determinado archivo. Usaría la salida de este comando para armar los objetos 'index' y 'tree':

Código (perl) [Seleccionar] Expandir

#!/usr/bin/perl
# Created by Rodriguez Dario A. on Thu Nov 10 07:57:12 AST 2011

# not using -w in shabang due to warnings about things we don't care
# unless we are really debugging, such as Fcntl.pm mistakes

use strict;
use File::stat;
use Fcntl ':mode';

my $stat_mode;
my $octal_perm;
my $user_rwx;
my $group_read;
my $other_execute;

unless (@ARGV) {
print "Usage: ls.pl <file 1> ... <file n>\n";
exit 1;
};

foreach (@ARGV) {
die "file $_ doesnt exist" unless -f $_;
};

foreach (@ARGV) {
$stat_mode=stat($_)->mode or die "cannot stat file $_";
$octal_perm=S_IMODE($stat_mode);
printf "%04o\t%s\n", $octal_perm, $_;
};

exit 0;


Y finalmente, el script que agrega archivos al index para el proximo commit, para que vean que conociendo el modelo, algunas operaciónes son realmente simples (sujeto a cambios, pero no se va a complicar mucho):

Código (bash) [Seleccionar] Expandir


#!/bin/bash

. safa-shelllib

if test $# -lt 1; then
echo "incorrect usage"
echo "usage: safa-addfiles <file 1> ... <file n>"
else
for myFile in $@; do
if test -f "$myFile"; then
# verify if the file changed from the last tree
DEBUG_print "safa-diff-from-tree --quiet HEAD \"$myFile\""
safa-diff-from-tree --quiet --perm -- HEAD "$myFile"
if test $? -ne 0; then
echo " o $myFile"
DEBUG_print "nothing changed"
else
echo " + $myFile"
echo "$myFile" >> .safa/addindex
fi
fi
done
fi



Obvio que, por dar un ejemplo, safa-diff-from-tree es un script algo más complejo. Espero que se copen.


Saludos

Hola Foreros,

Solamente paso para escribirles sobre un proyecto que estoy empezando. Tras bastante tiempo de uso de GIT, hay algunas cosas que me planteo diferentes. No es porque GIT sea malo, ni quiero volver esto una discusión sobre la necesidad de otro controlador de versiónes.

Se que muchos aficionados a Shell, C y Perl, pueden estar entusiasmados por trabajar en un proyecto así, y espero llegue a ser competente.

Quienes sepan trabajar en equipo y de una forma respetuosa, son bienvenidos.

Escriban MPs y/o correo a soft.d4rio (en) GMail para recibir alguna instrucción sobre qué hacer.

Saludos

PD: El proyecto se escribe en inglés, aunque la organización de las tareas la estoy haciendo en castellano. Cualquiera puede participar porque siempre habrá alguien dispuesto a traducir y explicar.

¿Un novato en qué área? indagas en pipes y control de procesos, usando llamadas al sistema.

Yo me preguntaría si es necesario todo ese "dirty code", existiendo una forma limpia como popen (http://www.manpagez.com/man/3/popen/) para hacer exactamente lo mismo.

A demás, considera usar la etiqueta de código correcta para que veamos el resaltado de sintáxis, así es más fácil leer.

Saludos

Despues de muchos muchos meses leo esto.

Por un lado, ya habia revisado esas configuraciones.
Por otro, cambié esa partición por un Backtrack 5, así que creo que este es un

T E M A   C E R R A D O

Algun MOD please, cerrarlo

No ustilicé ramdisk, pero tampoco es necesario. Compilando con genkernel siempre se genera un ramdisk, pero el mismo handbook de gentoo indica que no es necesario ramdisk para los que prefieran compilar el kernel a mano.

Uso GRUB2, que es el default de Ubuntu, pero no creo que sea el problema. He leído por ahí que el problema suele ser el kernel.

Podría compilar otro kernel, el default de Gentoo, pero por ahora no tengo tiempo (laburo)

Cuando lo haga te comento,
Gracias