SailPi Navegando con Raspberry Pi

[gilinas]

Y mucho ojo con cómo se utiliza el nombre localhost

"localhost" es el nombre asignado a la dirección IP 127.0.0.1.
Esta dirección IP solamente puede ser utilizada para comunicaciones internas de la máquina. Esto es, para comunicar procesos que residen en la misma máquina.

Cualquier comunicación a/desde "localhost" no va a salir de nuestra máquina.
De hecho ni siquiera llega a ninguno de los interfaces de red.

[R.Santana]

Ya tengo la pi. a esperar que llegue desde kong fu.

[gilinas]

Respecto de las comunicaciones con UDP:

En este caso no existen conexiones y por lo tanto identificar al servidor y al cliente no es tan trivial como en el caso de TCP.
Al no haber conexion, el servicio de transferencia no es fiable (como lo es en el caso de TCP). Es posible que se pierdan datos.

Como contrapartida, permite la difusión de los mismos datos a varios receptores en un solo envío utilizando direcciones IP de difusión (que son de la forma a.b.c.255, a.b.255.255, ó incluso 255.255.255.255 [todos]).
Los receptores recibirán los datos si se encuentran escuchando en el puerto correspondiente.

Utilización mediante kplex:

Para salida de datos
[broadcast]
direction=out
device=<interface>
address=<address>
port=<port>

<interface> será (wlan0 ó eth0) el interface de red por el que se transmitirán los datos.
<address> es la dirección IP de difusión
<port> es el puerto donde deben estar escuchando los receptores (si no, ellos se lo pierden)

Para entrada de datos
[broadcast]
direction=in
port=<port>

cuantas menos restricciones mejor, así recibiremos todo lo que llegue por el puerto especificado en cualquiera de los interfaces de red y para cualquier dirección de difusión que nos incluya.

Para entrada/salida de datos
[broadcast]
direction=both
device=<interface>
address=<address>
port=<port>

Creo que para este caso es mejor defnir uno de entrada y otro de salida, ya que direction=both nos restringe el tráfico de entrada a la interface especificada y además solo recibiremos el tráfico dirigido a la dirección de difusión especificada.

Originalmente publicado por gilinas

Respecto de las comunicaciones con UDP:

En este caso no existen conexiones y por lo tanto identificar al servidor y al cliente no es tan trivial como en el caso de TCP.
Al no haber conexion, el servicio de transferencia no es fiable (como lo es en el caso de TCP). Es posible que se pierdan datos.

Como contrapartida, permite la difusión de los mismos datos a varios receptores en un solo envío utilizando direcciones IP de difusión (que son de la forma a.b.c.255, a.b.255.255, ó incluso 255.255.255.255 [todos]).
Los receptores recibirán los datos si se encuentran escuchando en el puerto correspondiente.

Utilización mediante kplex:

Para salida de datos
[broadcast]
direction=out
device=<interface>
address=<address>
port=<port>

<interface> será (wlan0 ó eth0) el interface de red por el que se transmitirán los datos.
<address> es la dirección IP de difusión
<port> es el puerto donde deben estar escuchando los receptores (si no, ellos se lo pierden)

Para entrada de datos
[broadcast]
direction=in
port=<port>

cuantas menos restricciones mejor, así recibiremos todo lo que llegue por el puerto especificado en cualquiera de los interfaces de red y para cualquier dirección de difusión que nos incluya.

Para entrada/salida de datos
[broadcast]
direction=both
device=<interface>
address=<address>
port=<port>

Creo que para este caso es mejor defnir uno de entrada y otro de salida, ya que direction=both nos restringe el tráfico de entrada a la interface especificada y además solo recibiremos el tráfico dirigido a la dirección de difusión especificada.

esta mañana hemos trasteado algo Diavolo y yo acerca del tema de enviar datos AIS a servidores como Marinettrafic o shippingexplorer.

Hay que añadir que hemos logrado enviar datos con éxito a Marinettrafic a través de una conexión tcp.

Pero con shippingexplorer no ha sido posible. Con una conexión tcp no funciona y hemos intentado con una UDP [broadcast] pero no hemos terminado de aclararnos.

Lo que mas me machaca es que los de shippingexplorer nos dan un puerto y una dirección como si fuera una conexión tipo tcp, pero al intentar configurar kplex como broadcast no acepta la direccion que nos dan si no que parece exigir una dirección bcast interna tipo X.X.X.255.

Si ponemos la interna bien sea 255.255.255.255 o 192.168.1.255, no tira error pero los datos no llegan. Y si ponemos la que ellos nos dan kplex da error y se niega a trabajar.

Lo hemos intentado tanto como usuario normal como administrador.

¿Que se nos escapa?

¿Nos podríais aclarar algo de esto?

¿O es que las conexiones de kplex de tipo UDP solo funcionan en la red interna?

[gilinas]

Originalmente publicado por pinguino

esta mañana hemos trasteado algo Diavolo y yo acerca del tema de enviar datos AIS a servidores como Marinettrafic o shippingexplorer.

Hay que añadir que hemos logrado enviar datos con éxito a Marinettrafic a través de una conexión tcp.

Pero con shippingexplorer no ha sido posible. Con una conexión tcp no funciona y hemos intentado con una UDP [broadcast] pero no hemos terminado de aclararnos.

Lo que mas me machaca es que los de shippingexplorer nos dan un puerto y una dirección como si fuera una conexión tipo tcp, pero al intentar configurar kplex como broadcast no acepta la direccion que nos dan si no que parece exigir una dirección bcast interna tipo X.X.X.255.

Si ponemos la interna bien sea 255.255.255.255 o 192.168.1.255, no tira error pero los datos no llegan. Y si ponemos la que ellos nos dan kplex da error y se niega a trabajar.

Lo hemos intentado tanto como usuario normal como administrador.

¿Que se nos escapa?

¿Nos podríais aclarar algo de esto?

¿O es que las conexiones de kplex de tipo UDP solo funcionan en la red interna?

Parece ser que kplex solamente admite UDP con boadcast (a la red local) o con multicast (sobre IPv6).

Es una pena que no admita transferencias UDP a IPs sencillas, y me parece un error de concepto.
Las conexiones TCP solamente son útilies cuando se requiere una alta fiabilidad en que los datos van a llegar a su destino, la contrapartida es que estos se pueden demorar en llegar un tiempo arbitrario, y retrasar los datos que van a continuación, que tienen que esperar a que se transmitan los anteriores.
Con UDP las transferencias de datos son independientes entre si. Se puede enviar una lectura de viento y posteriormente una de corredera y llegar con el orden cambiado o no llegar alguna de ellas, lo que no afecta a esas lecturas ni al resto de lecturas.

En mi opinión UDP sería el protocolo más adecuado para la transferencia de datos NMEA, pero con kplex solamente lo tenemos disponible para direcciones de broadcast o de multicast.



Nota: el permitir que se utilice UDP broadcast sobre una red remota podría habilitar el realizar atakes de tipo UDP flooding

[sailoog.com]

Originalmente publicado por gilinas

Parece ser que kplex solamente admite UDP con boadcast (a la red local) o con multicast (sobre IPv6).

Es una pena que no admita transferencias UDP a IPs sencillas, y me parece un error de concepto.
Las conexiones TCP solamente son útilies cuando se requiere una alta fiabilidad en que los datos van a llegar a su destino, la contrapartida es que estos se pueden demorar en llegar un tiempo arbitrario, y retrasar los datos que van a continuación, que tienen que esperar a que se transmitan los anteriores.
Con UDP las transferencias de datos son independientes entre si. Se puede enviar una lectura de viento y posteriormente una de corredera y llegar con el orden cambiado o no llegar alguna de ellas, lo que no afecta a esas lecturas ni al resto de lecturas.

En mi opinión UDP sería el protocolo más adecuado para la transferencia de datos NMEA, pero con kplex solamente lo tenemos disponible para direcciones de broadcast o de multicast.

mmmmmm si y no....

supongo que se pensó en las salidas UDP broadcast para tener algún aparato escuchando conectado diretamante por ethernet o wifi a la fuente donde prima la inmediatez y vigencia de esos datos y donde hay mas probabilidad que lleguen debido a los escasos intermediarios.

Pero para el caso que nos ocupa que es mandar posicines AIS remotamente TCP seria el sistema mejor ya que llevan incorporada la fecha/hora y da igual cuando lleguen, lo que importa es que lleguen.

digo yo....

[sailoog.com]

Originalmente publicado por pinguino

esta mañana hemos trasteado algo Diavolo y yo acerca del tema de enviar datos AIS a servidores como Marinettrafic o shippingexplorer.

Hay que añadir que hemos logrado enviar datos con éxito a Marinettrafic a través de una conexión tcp.

Pero con shippingexplorer no ha sido posible. Con una conexión tcp no funciona y hemos intentado con una UDP [broadcast] pero no hemos terminado de aclararnos.

Lo que mas me machaca es que los de shippingexplorer nos dan un puerto y una dirección como si fuera una conexión tipo tcp, pero al intentar configurar kplex como broadcast no acepta la direccion que nos dan si no que parece exigir una dirección bcast interna tipo X.X.X.255.

Si ponemos la interna bien sea 255.255.255.255 o 192.168.1.255, no tira error pero los datos no llegan. Y si ponemos la que ellos nos dan kplex da error y se niega a trabajar.

Lo hemos intentado tanto como usuario normal como administrador.

¿Que se nos escapa?

¿Nos podríais aclarar algo de esto?

¿O es que las conexiones de kplex de tipo UDP solo funcionan en la red interna?

seguro que shippingexplorer os ha dado una UDP?, lo dudo debido a los problemas de seguridad que comenta gilinas.

En cuanto a las salidas UDP broadcast, si queremos que funcionen hemos de ejecutar kplex como root porque si no fallará pero lo hará en silencio sin devolver error. Igual cuando lo habeis probado no os llegaban datos porque kplex = error siencioso y sudo kplex = va a buscar el archivo de config a etc y no al home de pi.

otras cosas que se me ocurren:

- falla shippingexplorer como TCP porque hay algún firewall por enmedio de software o hardware o puertos cerrados en el router....
- contactar con shippingexplorer y que especifiquenb si es una TCP o una UDP

[gilinas]

Originalmente publicado por sailoog.com

seguro que shippingexplorer os ha dado una UDP?, lo dudo debido a los problemas de seguridad que comenta gilinas.

En cuanto a las salidas UDP broadcast, si queremos que funcionen hemos de ejecutar kplex como root porque si no fallará pero lo hará en silencio sin devolver error. Igual cuando lo habeis probado no os llegaban datos porque kplex = error siencioso y sudo kplex = va a buscar el archivo de config a etc y no al home de pi.

otras cosas que se me ocurren:

- falla shippingexplorer como TCP porque hay algún firewall por enmedio de software o hardware o puertos cerrados en el router....
- contactar con shippingexplorer y que especifiquenb si es una TCP o una UDP

Yo creo que se lo han dado correctamente.
Las IP's son las direcciones de red que identifican a los dispositivos conectados a la red, y se pueden enviar/recibir datos de/hacia esos dispositivos (IPs) utilizando protocolo TCP (lento, fiable y con órden entre los datos) o UDP (rápido, no-fiable y sin órden entre los datos)
Los puertos son "los enchufes" donde están esperando las aplicaciones para enviar/recibir. Hay 65536 puertos TCP (del 0 al 65535) y 65536 puertos UDP (del 0 al 65535).

Originalmente publicado por sailoog.com

seguro que shippingexplorer os ha dado una UDP?, lo dudo debido a los problemas de seguridad que comenta gilinas.

En cuanto a las salidas UDP broadcast, si queremos que funcionen hemos de ejecutar kplex como root porque si no fallará pero lo hará en silencio sin devolver error. Igual cuando lo habeis probado no os llegaban datos porque kplex = error siencioso y sudo kplex = va a buscar el archivo de config a etc y no al home de pi.

otras cosas que se me ocurren:

- falla shippingexplorer como TCP porque hay algún firewall por enmedio de software o hardware o puertos cerrados en el router....
- contactar con shippingexplorer y que especifiquenb si es una TCP o una UDP

sailoog he estado controlando yo el tema por VNC, y sí lo he ejecutado tanto como root como usuario normal. Como root especificando el archivo de config adecuado con su parámetro correspondiente.

Y si, dan puerto, dirección y especifican que en su servidor hay que escoger protocolo UDP.

Primero nos hemos limitado a echárselos a comer por tcp para probar a ver si comían, pero no.

Opino que Gilinas tiene razón y el UDP en kplex es local y por eso, el creador de kplex, insiste en su ejemplo de marinetraffic en usar tcp en vez de udp que es lo que recomiendan.

Desde luego podría ser también un problema de cortafuegos a nivel de router, pero marinetraffic ha ido a la primera una vez todas las cosas estaban en su sitio.

[sailoog.com]

pues descartadas todas esas posibilidades seguramente sean esos los motivos.

La ultima prueba de confirmación podria ser una salida UDP de OpenCpn y descartar kplex como mltiplexor en este caso.

[Diavolo]

Originalmente publicado por sailoog.com

seguro que shippingexplorer os ha dado una UDP?, lo dudo debido a los problemas de seguridad que comenta gilinas.

En cuanto a las salidas UDP broadcast, si queremos que funcionen hemos de ejecutar kplex como root porque si no fallará pero lo hará en silencio sin devolver error. Igual cuando lo habeis probado no os llegaban datos porque kplex = error siencioso y sudo kplex = va a buscar el archivo de config a etc y no al home de pi.

otras cosas que se me ocurren:

- falla shippingexplorer como TCP porque hay algún firewall por enmedio de software o hardware o puertos cerrados en el router....
- contactar con shippingexplorer y que especifiquenb si es una TCP o una UDP

Con ShippingExplorer he hablado y mas que hablado, que solo acepta conexiones UDP, no TCP. Ya le comenté a ellos, que un servidor puerto de serie, puedo enviar datos a varias IP en modo TCP o UDP, pero Todas con el mismo tipo de conexion, por ello usaba un servidor de serie unica y exclusivamente para mi como servidor de serie TCP, para IPad, PC, y de mas, otro para enviar UDP como cliente a Marinetraffic, ShippingExplorer y el de Localizatodo aparte para ellos.

Ahora voy a poner la Fresa, y el servidor de Localizatodo, y todo lo demás va a ir fuera.

Al final voy a optar por poner Kplex TCP en modo server a la fresa, y Marinetraffic (que ya hemos probado que funciona), y desde casa a ShippingExplorer. Localizatodo voy a mantener el Servidor de ellos (Micro-Pc), de todas formas es el mas pequeño que tengo y fácil de ocultar.

[gilinas]

Originalmente publicado por Diavolo

Con ShippingExplorer he hablado y mas que hablado, que solo acepta conexiones UDP, no TCP. Ya le comenté a ellos, que un servidor puerto de serie, puedo enviar datos a varias IP en modo TCP o UDP, pero Todas con el mismo tipo de conexion, por ello usaba un servidor de serie unica y exclusivamente para mi como servidor de serie TCP, para IPad, PC, y de mas, otro para enviar UDP como cliente a Marinetraffic, ShippingExplorer y el de Localizatodo aparte para ellos.

Ahora voy a poner la Fresa, y el servidor de Localizatodo, y todo lo demás va a ir fuera.

Al final voy a optar por poner Kplex TCP en modo server a la fresa, y Marinetraffic (que ya hemos probado que funciona), y desde casa a ShippingExplorer. Localizatodo voy a mantener el Servidor de ellos (Micro-Pc), de todas formas es el mas pequeño que tengo y fácil de ocultar.

Hola
He estado pensando un poco y la solución podría ser:

1. Poner el kplex para que envíe por TCP como server
2. hacer un programa que se conecte como cliente al TCP del kplex y que lo reenvíe por UDP a la dirección y puerto de ShippingExplore

El programa (en python) podría ser algo así:

#!/usr/bin/python 

import socket
import argparse

parser = argparse.ArgumentParser(description='Reenvia por UDP lo que recibe por TCP')
parser.add_argument('UDPhost', 
                   help='host destino del UDP')
parser.add_argument('UDPport', type=int,
                   help='puerto UDP')
parser.add_argument('--TCPhost', default='localhost', 
                   help='host fuente TCP (localhost por defecto)')
parser.add_argument('--TCPport', type=int, default=10110,
                   help='puerto TCP (10110 por defecto)')
args = parser.parse_args()

tcps = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
tcps.connect((args.TCPhost, args.TCPport))
tcpin=tcps.makefile()
udps = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while 1:
    lineaNMEA=tcpin.readline()
    udps.sendto(lineaNMEA, (args.UDPhost, args.UDPport))
tcpin.close
tcps.close
udps.close

lo salvas a un fichero.py (ShippingExplore.py por ejemplo)
y lo invocas como:

>python ShippingExplore.py UDPhost UDPport
donde:
UDPhost es el servidor de ShippingExplore y
UDPport el puerto de ShippingExplore

El programa supone por defecto que puede conectarse a kplex en localhost y el puerto 10110, si no es así, admite cambiarlos con
--TCPhost <dirección_servidor_TCP>
--TCPport <puerto_servidor_UDP>




Espero que te sirva
Se podría mejorar añadiendo gestión de excepciones ...