#1159 Beehosts.ini y otras cuestiones.

[Abelardo A.M.]

Buenos días:

Creo que hay un problema en el diseño de la aplicación, en cuanto al uso de broacast en el fichero beehosts.ini . Según la documentación el fichero beehosts.ini debe tener las direcciones IP de los host y/o las redes con las que se quiere comunicar. En el caso de las redes es coger la dirección IP del host y cambiar el último número u octeto por 255. En este último caso, no siempre es correcto.

Las direcciones IP tienen asociada una máscara de red. Esta máscara de red identifica los ordenadores con los que se puede comunicar. Además, identifica la red y el broadcast que se debe de utilizar. Un ejemplo sería 192.168.1.1/24 o 192.168.1.1/255.255.255.0, ambas anotaciones son la misma y que a continuación voy a explicar.
a) Si convertimos 192.168.1.1 a binario sería 11000000.10101000.00000001.00000001
b) Si convertimos 255.255.255.0 a binario seria 11111111.11111111.11111111.00000000

La nomenclatura de la red, es decir, el nombre de la red, se debe de realizar una operación booleana AND entre a) y b) y daría:
11000000.10101000.00000001.00000001
11111111.11111111.11111111.00000000
=================================
11000000.10101000.00000001.00000000

                               192.                168.                    1.                     0

El nombre de la red, según la operación anterior sería 192.168.1.0 y debemos añadir la máscara de red que sería 255.255.255.0 o 24, que son el número de 1 que tiene la máscara. Resulta 192.168.1.0/24, que es la primera dirección IP del rango. Esta dirección no se usa para nada.

Ahora, la dirección de broadcast, se calcula invirtiendo la máscara de red y haciendo la operación booleana OR con a), y sería:
c) Inversión de la máscara de red: 00000000.00000000.00000000.11111111

La dirección de broadcast a) OR c):
11000000.10101000.00000001.00000001
00000000.00000000.00000000.11111111
=================================
11000000.10101000.00000001.11111111

                               192.               168.                     1.               255

En resumen, un equipo con dirección 192.168.1.1/24, su red es 192.168.1.0/24 y la dirección de broadcast es 192.168.1.255, que es la última dirección del rango. En este caso, si coincide con el formato que pide el fichero beehosts.ini.

Ahora yo puedo cambiar la máscara de red según mis necesidades porque quiera hacer redes más pequeñas o más grande. Por ejemplo, de la red anterior 192.168.1.1/24 puedo hacer subredes de 64 equipos con una máscara /26 y crear 4 subredes de ese rango:
192.168.1.0/26 o 255.255.255.192 , su dirección de broadcast es 192.168.1.63
192.168.1.64/26 su dirección de broadcast es 192.168.1.127
192.168.1.128/26 su dirección de broadcast es 192.168.1.191
192.168.1.192/26 su dirección de broadcast es 192.168.1.255

Puedo hacer redes más grandes como 192.168.0.0/23 y su dirección de broadcast sería 192.168.1.255

Hay webs que te hace estos cálculos, solo tienes que buscar "calculadora IP" en Google.

En resumen, según los 5 ejemplos anteriores, no se podría encajar las redes creadas con poner el valor "255" en la dirección IP en el fichero beehosts.ini porque no coincide con la dirección de broadcast. En el caso de la red 1921.68.0.0/23, habría que definir dos redes que serían la 192.168.0.255 y 192.168.1.255 y posiblemente el equipo 192.168.0.255 y 192.168.1.0 no se pueda conectar con nadie. Creo que en el fichero beehosts.ini, cuando sea una red hay que indicar IP/MÁSCARA para saber que es una red externa y que el programa actué en consecuencia intentando contactar con cada IP de dicho rango.

Otra cuestión que he podido ver en los foros es, cuando se utiliza un servidor RDP o de Escritorio Remoto, para que los usuarios se conecten, el uso de múltiples instancia Beebeep en el mismo equipo. Creo que no funciona bien porque la primara instancia de la aplicación abre los puertos por defectos y las instancias sucesivas, no pueden usar dichos puertos porque ya hay un usuario que los está usando. Desconozco el diseño de la aplicación pero una posible solución podría ser, que en el inicio compruebe si está los puestos en uso. En caso de que lo esté, comunicar con el cliente que lo tiene abierto y que funcione de proxy con las demás instancias para el envío y recepción de mensajes/ficheros/etc.. . Por seguridad, solo permitir la conexión desde localhost o 127.0.0.1 a este tipo de reenvío. También, hay que tener en cuenta que la aplicación que ha abierto los puertos por defectos, se cierra, otra instancia debe ocupar su lugar y funcionalidad.

Y por último agradecer el gran trabajo realizado en esta aplicación y espero ver una versión nueva muy pronto.

Saludos

[Marco Mastroddi]

Thank you very much for your detailed, rigorous, and well-structured analysis. It is a pleasure to read such a clear technical explanation regarding IP addressing and subnetting. Your observations are absolutely correct, and you hit the nail on the head regarding some historical limitations of the application.

Regarding the beehosts.ini configuration, I would like to clarify how the current implementation works behind the scenes.

The .255 value at the end of each address in that file is currently used merely as a convention to indicate "the last address of the network to scan." In fact, for all "extra" subnets outside of the main local one, BeeBEEP does not use UDP broadcast for the initial discovery. Instead, the first contact is made directly via a TCP connection on port 6475, scanning the addresses.

I deliberately had to avoid UDP broadcasting on external networks because routers and firewalls almost always block directed broadcasts across different subnets. While a direct TCP scan can be slower (since it attempts to connect to addresses one by one), it is far more reliable and likely to work in real-world scenarios. This choice was made keeping in mind that not all BeeBEEP users are network administrators or know how to properly configure routing for broadcasting.

However, your point is completely valid. Relying on a hardcoded .255 is an outdated design choice, and I am currently working on refactoring how the beehosts.ini file functions to implement a more professional, CIDR-compliant solution (like allowing IP/mask notation) that can dynamically calculate the proper ranges and optimize the scanning logic.

As for your second point regarding multiple instances in RDP (Terminal Server) environments, your analysis of the port binding issue is spot on. Your proposed architecture—using a local proxy/daemon model running on localhost where the first instance acts as a master router for the others—is an extremely elegant and ingenious solution. I am definitely taking note of it for the project's roadmap.

Feedback like yours is what drives open-source software forward. Thank you for your time, your expertise, and for helping improve BeeBEEP!

---

Muchas gracias por tu análisis tan detallado, riguroso y bien estructurado. Es un placer leer una explicación técnica tan clara sobre el direccionamiento IP y el cálculo de subredes. Tus observaciones son absolutamente correctas y has dado en el clavo con respecto a algunas limitaciones históricas de la aplicación.

En cuanto a la configuración del archivo beehosts.ini, me gustaría aclarar cómo funciona la implementación actual entre bastidores (de forma interna).

El valor .255 al final de cada dirección en ese archivo se utiliza actualmente solo como una convención para indicar "la última dirección de la red a escanear". De hecho, para todas las subredes "extra" fuera de la red local principal, BeeBEEP no utiliza el broadcast UDP para el descubrimiento inicial. En su lugar, el primer contacto se realiza directamente a través de una conexión TCP en el puerto 6475, escaneando las direcciones una a una.

Tuve que evitar deliberadamente el uso de broadcast UDP en redes externas porque los routers y cortafuegos (firewalls) casi siempre bloquean los "directed broadcasts" entre diferentes subredes. Aunque un escaneo directo por TCP puede ser más lento (ya que intenta conectarse a las direcciones una por una), es mucho más confiable y es más probable que funcione en escenarios del mundo real. Esta decisión se tomó teniendo en cuenta que no todos los usuarios de BeeBEEP son administradores de redes ni saben cómo configurar correctamente el enrutamiento para el broadcast.

Sin embargo, tu planteamiento es completamente válido. Depender de un .255 predefinido en el código es una opción de diseño obsoleta, y actualmente estoy trabajando en reformar el funcionamiento del archivo beehosts.ini para implementar una solución más profesional y compatible con CIDR (como permitir la notación IP/máscara) que pueda calcular dinámicamente los rangos correctos y optimizar la lógica de escaneo.

Respecto a tu segundo punto sobre las múltiples instancias en entornos RDP (Terminal Server), tu análisis sobre el problema del bloqueo (binding) del puerto es exacto. La arquitectura que propones —utilizar un modelo de proxy/demonio local que corra en localhost donde la primera instancia actúe como un router maestro para las demás— es una solución sumamente elegante e ingeniosa. Sin duda, tomo nota de ella para la hoja de ruta (roadmap) del proyecto.

Comentarios como el tuyo son los que impulsan el software de código abierto hacia adelante. ¡Muchas gracias por tu tiempo, tu experiencia y por ayudar a mejorar BeeBEEP!

[Abelardo A.M.]

Gracias por su comentario, tiempo y dedicación.
Saludos.