Mensajes

No es necesario que uses sockets no bloqueantes. Los sockets no bloqueantes lo unico que hacen es no esperar a que se realiza la operacion, es decir, que si usas `read(socket, buf, size)` en el momento en el que la llamada vaya a bloquear porque tiene que esperar al otro peer entonces retorna un -1 con errno = EAGAIN o EWOULDBLOCK.

Estoy de acuerdo contigo en que para la funcionalidad normal de mi programa no es necesario usar sockets NO BLOQUEANTES, lo que me genera la duda es lo que dice la respuesta del link que adjunto con el tema. En esa respuesta explica que debido a la implementación en LINUX, usar sockets BLOQUEANTES y select en principio no deberían generar problemas la mayoría de las veces, sin embargo menciona que puede succeder un caso en el que SELECT notifique que un socket esta como READY para leer, pero sin embargo el mensaje que llega puede ser descartado por la proxima comprobación del CHECKSUM, esto haciendo que realmente el recv que supone que no debería ser tan tardado debido a que SELECT nos notifico que estaba listo, bloque finalmente todo el hilo esperando a que realmente llegue una información valida y se cree un pequeño deficit. Claro que si las cosas son así esto puede crear un BUG en casos donde el socket es de tipo DATAGRAM(UDP) debido a que no se tiene la certeza de un mensaje va llegar pronto creando que el hilo solo este esperando un recv de un cliente y este ignorando todos los demas que han sido adjuntados al SELECT.En el caso de TCP se tiene la certeza de que va ser un plazo no tan largo debido a que se detecataria el paquete rechazado y se reenviaria en un plazo de tiempo finito.

A lo mejor tendrias que mirar epoll. Epoll a parte de ser mas rapido, a mi manera de ver las cosas es mas facil de usar.

He visto un poco sobre el, le voy a dar una checada, gracias.

La verdad no estoy del todo seguro de que esto realmente pueda succeder, o que realmente valga la pena intentarlo evitar pensando en que es muy poco posible que se presente.

Hola a todos, resulta que tenía la duda de si era necesario ajustar el socket para que fuera no bloqueante antes de suscribirlo a una llamada select. Buscandome me encontre con esto:
https://stackoverflow.com/questions/16628743/should-socket-be-set-non-blocking-before-it-is-polled-by-select

Me queda claro la razón por la cual debe ser no bloqueante pero realmente vale la pena seguir ese consejo, al menos en el caso de conexiones TCP. Es decir:

Yo tengo un select a la espera de que varias conexiones TCP esten listas para ser leidas, me surte el problema de que se me notifica de que el socket esta listo para lectura, entonces prosigo a intentar hacer la lectura con el respectivo método, sin tener conocimiento de que fue un fallo y el contenido fue descartado por algo como que fallo el checksum(situación que menciona la respuesta del link), esto me va ocasionar distintos comportamientos dependiendo si el socket es bloqueante...
1. Si es bloqueante, entonces mi hilo estara bloqueada esperando que realmente la conexión tenga información entrante, pero este tiempo bloqueado creo que es aceptable debido a que es TCP, entonces tengo la certeza de que habrá una retransmisión en un rango de tiempo relativamente corto. Sin embargo se podría presentar el mismo problema de que el siguiente envio tuviera el mismo problema, ¿acaso se tiene la seguridad de que el kernel va ser capaz de quitar la información entrante erronea(que no cumplio con el checksum) antes de que la función recv recolecte los datos?, agregando a esta solución si quisiera asegurar que el tiempo de bloquea no sea mayor a N porción de segundo, podria agregar:

Código (c) [Seleccionar] Expandir

setsockopt(socket, SOL_SOCKET, SO_RCVTIMEO, (const char*)&timeout, sizeof timeout);
Al final podría decidir que si pasa el timeout, entonces vuelva a bloquearme en el select.
Nota. Aquí surge una duda de como es que select se da cuenta que un socket esta listo. Puede ser que lo determine conforme solo a si tiene alguna actividad relacionada con el, sin que esto realmente tenga como consecuencia que algo se este poniendo en la cola de entrada, esto respondería la pregunta de por que se notifica como que el socket esta listo cuando realmente no se ha terminado de confirmar la información entrante.

2. Si no es bloqueantes, entonces es cierto que una llamada recv no me bloquearía pero ¿no tendría que hacer todo un mecanismo para asegurarme de recolectar todo el contendio de esa petición?  a través de algo como recibe hasta que no encuentres el final de la respuesta, mientras no encuentres el final de la respuesta repite:

Código (c) [Seleccionar] Expandir


recv(....);
sleep(algunos_milisegundos);

sin embargo me da la sensación de que se degradaría mas el desempeño de la aplicación por ese sleep, debido a que ese hilo no tendría ninguna otra tarea que hacer, seria algo parecido a una espera ocupada deficiente.

Vi una implementación en python que lo hace es suscribir los sockets como NO_BLOQEUANTES al select, posterior a eso cuando se le notifica que alguno esta listo, lo cambia para que sea BLOQUEANTE pero finalmente creo que se llega al mismo problema, realmente es una condición de carrera que en algunos casos puede resultar en lo mismo que si siempre fuera BLOQUEANTE. ¿Alguna alternativa u opinión de cual seria la solución ideal?

Retroalimentando la situación. He seguido viendo cosas relacionadas con el tema y me he topado con una posible respuesta a la pregunta de ¿Como hacer un proxie generico?, es decir, que no tenga que estar modificando las configuraciones de cada aplicación.

He encontrado que se puede lograr crear un buffer o cola intermedia entre los paquetes que estan entrando y saliendo de mi interfaz mediante el siguiente comando:

Código (bash) [Seleccionar] Expandir

iptables -I INPUT -j NFQUEUE --queue-num 0

Código (bash) [Seleccionar] Expandir

iptables -I OUTPUT -j NFQUEUE --queue-num 0

He hecho algunas pruebas en Python(Adjunto el código al final) y he visto que efectivamente parece funcionar en el sentido de que esta capturando todos los datos y me permite procesarlos antes de que salgan o entren. ¿Ahora mi pregunta es si esta implementación es la que realizan los VPN o proxies? y ¿Qué pasa si la cola llega a su limite de capacidad? , ¿Donde esta definido dicho limite en Linux?. Ademas si alguien cuenta sobre que información un poco mas detallada sobre como esta afectado iptables el funcionamiento del stack de TCP/IP debido a que la fuente que estoy siguiendo no habla mucho al respecto y simplemente se limita a explicar la abstracción.

Código (python) [Seleccionar] Expandir


import netfilterqueue

# Vinculación de los paquetes de entrada y salida con la cola
# iptables -I INPUT -j NFQUEUE --queue-num 0
# iptables -I OUTPUT -j NFQUEUE --queue-num 0


def process_packet(packet):
  # Procesamiento de paquete antes de salida
  print(f"Proceso entrante: {packet}")
  # Reenvio del paquete hacia su destino
  packet.accept()


def main():
  queue = netfilterqueue.NetfilterQueue()
  queue.bind(0, process_packet)
  queue.run()


if __name__ == "__main__":   
  main()

He estado siguiendo dos libros basicos de hacking (Black Hat Python y Attacking Networks Protocols) y en ambos llevo rato trabajando en todo lo relacionado principalmente con proxies. He practicado un poco con los ejercicios que contempla principalmente el libro de Python para poder construir mis limitados proxies que simplemente consisten principalmente en un socket que reenvía contenido a su destino únicamente por un puerto. Ademas he estado leyendo un poco sobre la variedad de proxies que existen, como son:

1. Proxies basados en Socks4, 4a y 5
2. Proxies HTTP
3. Forwarding Port( Es el primero que vi y con el que he podrido interactuar más con Python)

Me queda clara la idea de un proxy a grandes rasgos y entiendo un poco las diferencias entre cada uno de manera no muy detallada:

1. Sockes4, 4a, 5. El 5 es muy bueno en el sentido de que ofrece autenticacion por varios mecanismos, se puede adaptar a las aplicaciones sin tanto esfuerzo, etc.
2. Proxies HTTP. Especifico para transmision de datos mediante el protocolo HTTP
3. Forwarding Port. Una instancia de este programa se encarga simplemente de abrir un puerto y reenviar los datos entrantes hacia una dirección destino.

Mi principal problema es cuando intento verlo desde el punto de vista de programación. Es decir:

1. Forwarding Port. A nivel de programación lo puedo ver como un socket TCP o UDP que simplemente se encarga de atender a un único cliente y reenviar lo que le llega a la dirección que se le fue especificada como dirección final. Creo que la principal dificultad es que las aplicaciones que lo utilizan deben tener la opción para especificar la dirección y puerto de destino , ademas que se complica si las peticiones que lanza la aplicación aveces varian de objetivo., haciendo practicamente imposible hacer un proxie casero de esta manera que sea generico y que de paso a transmitir la información sin tener que modificar el programa cliente o el programa que esta utilizando el proxie.

2. Proxie HTTP. Entiendo que es una especie de proxie destinado para tráfico del protocolo HTTP pero no me termina de quedar claro como trabaja. Es decir, yo puedo configurar mi Navegador para que use un Proxie HTTP y el proxy se va encargar de retransmitir toda la comunicación existente pero ¿Como lo hace?. Acaso hay algunas estandar para la construcción de Proxie HTTP entre otros que me diga algo al estilo:
PASOS PARA SINCRONIZAR INICIO ENTRE UN NAVEGADOR Y UN PROXIE HTTP.
1. El navegador se va encargar de crear una conexión al proxie HTTP.
2. Hacen un procedimiento de Handhsake
3. El navegador envia mensajes con un formato HTTP , en donde exista una Cabecera DESTINO_FINAL que tendra la IP hacia donde debe ser enviado ese paquete

NOTA. He visto y como era de esperarse, que el navegador usa varios puertos para despachar las peticiones de paginas que hacen cada pestaña e intuyo que de alguna manera una vez sincronizado el navegador con el proxy deben crear un mecanismo para permitir tener varios SUB_CLIENTES (Pestañas virtuales) para cada navegador,  para que sea posible que si hay 3 pestañas haciendo peticiones desde una misma computadora, entonces el proxy puede generar 3 sockets o conexiones auxiliares para darle seguimiento a cada petición, esto debido a que incialmente el navegador esta enviando peticiones HTTP al servidor como si el fuera el servidor web pero como le dice cual es el verdadero destino para cada petición.

3. Finalmente tengo los proxies SOCK..., he visto que estos los que mas facilmente pueden adaptarse a las aplicaciones de manera génerica y he visto que tienen un estandar al estilo como el inventado de HTTP de unos parrafos arriba. Pero entonces esto me esta implicando que cada aplicación que quiera usar este tipo de proxie debe tener un mecanismo dentro de ella que permita la comunicación con un proxie de este estilo, o es posible que realmente la aplicación siga haciendo las mismas cosas que hace comunmente y jamas sepa que realmente primero se esta comunicando con un proxie SOCK.

Por último solo quiero recalcar que mi principal duda esta en que tan genericos se supone que deben ser los proxies en especifico el SOCK, es decir, en todos los casos la aplicación debe tener una opción para habilitar la comunicación con este tipo de proxies o como se logra que aplicaciones que no soportan estas opciones se puedan adaptar. ¿Se supone que puedo utilizar un proxie Socks para redirigir todo el tráfico que sale de mi interfaz de red, como si a gran nivel tuviera un cliente del proxie que prácticamente dijera SOY EL REPRESENTANTE LOCAL DEL PROXIE Y DE ALGUNA FORMA ESCUCHO TODO LO QUE SALE POR LA INTERFAZ DE RED Y ME ENCARGO DE PASARSELO AL PROXIE Y RETORNAR LAS RESPUESTAS? o ¿ debo ir aplicación por aplicación activando la configuración de proxie para que la aplicación se encargue de individualmente conectar su puerto de salida a la dirección del servido?

Buenas, he estado el funcionamiento del protocolo ARP y me he encontrado con unas de sus vulnerabilidades que es el 'ARP Spoofing'. Mi duda parte de que he visto que la vulnerabilidad se presenta a partir de que el protocolo ARP acepta paquetes REPLY de una resolucion de una dirección aún cuando el no hizo la respectiva REQUEST. ¿ Por qué se da esto ?, ¿ Por que no es posible que solo se acepte resoluciones de direcciones a las cuales se hizo anteriormente un REQUEST?.

A demas he visto que este tipo de ataque se plantea en un entorno en el cual estas conectado a la misma red que el objetivo, intuyo que la primera razón para tener que cumplir con este requisito es que realmente no te puedes poner enmedio del ROUTER y del OBJETIVO por que simplemente no estas autenticado con el ROUTER pero que problemas hay con el OBJETIVO, es decir, yo estoy en un rango físico cercano al ROUTER y al objetivo, hago un ataque de 'ARP Spoofing' con el objetivo y el me reconoce como su router, entonces a partir de este momento el Router enviara correctamente los datos al OBJETIVO pero el objetivo me enviara los datos de su salida a mi y finalmente yo podría enviarlos al destino final por una red auxiliar. ¿Esto es posible o que incovenientes hay?. Finalmente estaria redirigiendo todo el trafico a la red auxiliar pero me gustaria saber en que punto llegaria a un conflicto

Mira, que curiosamente hace un par de días una persona abrió un tema en los foros de arch y encontró que eran las fuentes de MS que necesitaban ser instaladas.

https://bbs.archlinux.org/viewtopic.php?id=252313

Quizás este paquete te sirva para Debian 10:

https://packages.debian.org/buster/ttf-mscorefonts-installer

Listo. He instalado el paquete y el problema sigue igual, sin embargo he conseguido una solución y la posible respuesta a por que había ocasiones en las cuales la ventana de Login se cerraba sin afectar la ventana de trabajo. Resulta que al iniciar el programa se me fue el internet momentaneamente y dio como resultado la aparación de solo la ventana de trabajo, volví a repetir el proceso ahora desactivamente el wifi por completo y el resultado es siempre el mismo, intuyó que internamente genera una exepción que solo afecta  el proceso que maneja dicha ventana y que requiere conexión a internet( dando explicación a por que en situaciones exporadicas succedia esto).

Finalmete he llegado al mismo problema que tenía en la otra distribución. Al momento de guardar el archivo el navegador de archivos se congela al intentar nombrar al archivo con un nombre que tiene un matching con un archivo existente en la carpeta destino, es decir, Yo ingreso: Ped.... y la ventana me intenta autocompletar con el nombre de un archivo existente (Pedro) y en ese momento se congela. Creo que la solución momentanea es no escribir nombres que se solapen con algun existente pero momentaneamente ya puedo trabajar sin problemas. Gracias

[./PakcerTracer7]

He checado a más detalle el script que inicializa la aplicación:

Código (bash) [Seleccionar] Expandir


#!/bin/bash

echo Starting Packet Tracer 7.2.2

PTDIR=/opt/pt2
export LD_LIBRARY_PATH=$PTDIR/bin
pushd $PTDIR/bin > /dev/null
./PacketTracer7 "$@"  > /dev/null 2>&1
popd  > /dev/null


Resulta que esta es la versión donde observe que ocurria el error de que la pantalla de Login se cerraba y me permitia trabajar en la ventana de trabajo, sin embargo yo lo hacia ejecutando directamente el comando ./PakcerTracer7 sin argumentos y directamente desde el respectivo directorio bin/. He notado que cuando ejecuto el script incializador, es decir el que exporta LD_LIBRARY, cambia de directorio y ejecuta finalmente el binario, da como resultado NADA, literalmente ni aparece ningun error, incluso cuando quito el redireccionamiento hacia /dev/null, pareciera que se ejecutara en segundo plano pero realmente no veo el motivo debido a $@ se expande a nada por que no se le pasa ningun parametro y ademas no abre ninguna ventana. En contraparte, cuando ejecuto directamente el binario ./PacketTracer7 minimo tiene como efecto la aparación de las dos ventas:

1. Ventana de Login
2. Ventana de trabajo

Que es donde finalmente la ventana de login se sobrepone a la de trabajo y no permite trabajar hasta que se realice el inicio de sesión. Aquí es donde al dar clic al botón de inicar aparece la excepción de: Floating point exception.

Nota 1. Tengo el PacketTracer en otra computadora con otra distribución que se inicia sin error(Sin embargo congela totalmente la GUI al intentar guardar, jaja creo que es peor) y efectivamente en ella solo fue necesario realizar el login la primera vez, tal vez por eso no sea facil recordar que tenia login.

Nota 2. He probado con la version 7.1.1 y en dicha versión si arroja más informacion en la terminal sobre lo que esta pasado sin embargo esta versión no tiene problemas con el login como tal, el problema recurre a que esta versión lanza una exepción de tipo: Segmentation Fault al intentar mostrar las ventanas y he visto que cada 1/10 de veces muestra correctamente las ventanas y se puede trabajar normal sobre la aplicación.

Finalmente no he tenido mucho tiempo para seguir haciendo pruebas y ver si arroja una salida extra cuando logro cerrar la ventana de Login sin afectar la del área de trabajo. Recalco que en la versión donde he encontrado esta situación extraña ha sido en la versión 7.2.2 sobre Debian 10 y un entorno de escritorio gnome.

Hola a todos, resulta que tengo un buen rato intentando instalar Packet Tracer para Debian 10, con la novedad de que en todas las versiones encuentro fallos en dependencias obsoletas, en fin.. Finalmente he probado con la versión 7.2.2 , la cual he podido solucionar una dependencia y me he llevado la sorpresa que al iniciar el programa abre inicialmente dos ventanas:

1. Ventana de Login. Esta se sobrepone a la segunda
2. Ventana del entorno del trabajo.

Hasta aquí todo bien. El problema surge cuando doy el botón para iniciar sesión, dando como resultado una exepción de tipo Floating point exception y provocando el cierre de ambas ventanas. Actualmente no he dado solución con este problema en concreto pero ha manera de curiosidad he intentado matar la ventana de Login que se sobrepone a la ventana de entorno de trabajo sin conseguir ningun resultado al menos con los pocos conocimiento que tengo sobre el x-window-system y el manejo del comando wmctrl, debido a que al matar a la ventana de login, la ventana de trabajo tambien es cerrada.

Sin embargo, he ocasionado en dos situaciones muy aisladas lograr cerrar la ventana de login y permanacer con la ventana del entorno de trabajo abierta. Esto a sucedido cuando por repetidas ocasiones di clic sobre la ventana de trabajo lo que ocasiono que inesperadamente la ventana de login se cerrara y permitiera trabajar en la ventana de trabajo sin ningun problema(Incluso he guardado un archivo). ¿Qué pudo haber ocasionado esto?. No he conseguido determinar que secuencia de acciones me podrían dar como resultado esta reacción pero estoy seguro de que es posible debido a que ya ha sucedido 2 veces.

[Nota. En ultimo caso sé que podría crear una nueva clase que herede de REQUEST y agregar lo que requiero.]

Buenas a todos. Estoy haciendo una aplicación de comunicación remota con sockets y desearia usar el protocolo HTTP para el formato de mis mensajes, el problema es que me gustaria crear un objecto REQUEST y RESPONSE que me ayuden con el agrupamiento de los datos y finalmente que permitan convertir todos los atributos de dicho objeto en su representación cruda, es decir, en una representacion de texto plano.

He visto los objetos RESPONSE y REQUEST del modulo requests de python y al menos he observado que el objeto REQUEST lo podría utilizar para este proposito pero con la única desventaja de que no he encontrado un metodo que me haga la conversion del objeto a su representación de str con formato de petición HTTP.

¿ Alguien sabe donde se encuentra dicho método ? o conoce algun modulo que me presente una abstracción de dichos objetos con lo que requiero.

Divagando un poquito mas sobre el tema...  ¿ El modulo Request debe estar obligado a tener algun sinonimo de dicha función ?. Yo intuyo que dicha funcion debe estar en alguna parte del modulo requests debido a que no habria otra forma de comunicar un REQUEST o un RESPONSE debido a ese modulo no exige a que del otro lado de la comunicación exista un programa usando el mismo modulo en python(caso en el que se podria hacer una serializacion del objeto). ¿ Estoy equivocado o hay algo que estoy ignorado ?

Nota. En ultimo caso sé que podría crear una nueva clase que herede de REQUEST y agregar lo que requiero.

En LINUX encontré la solución a mi situación con chroot .