Onderwerp: Sailing Performance Dashboard

Ik heb werkelijk geen idee.
Onder Windows werken TCP en UDP beide prima.

Hoe ziet je configuratie er precies uit?
Zitten zender en ontvanger in hetzelfde netwerk? (vast wel, maar toch...)

Ik maak een stukje Python waarmee je kan testen.
Dezelfde code als in SPD met wat meer prints etc erin.
Dat mail ik wel naar je.

Met het stukje Python van Thomas heb ik gevonden waar het lag, maar nog geen echte oplossing.
In signal k heb ik voor de udp-nmea plugin 172.17.255.255 als broadcast adres gebruikt. Dit is een default adres wat signal k voorstelt. 172.17.xxx.xxx is de range van IP adressen waar zowel signal k als SPD in zitten (beide in hun eigen docker container).

De voorbeeld code doet een bind op het locale IP adres van de container van SPD en zou de NMEA data vanuit signal k moeten ontvangen:
serverSock.bind((Thismachine_IP_addres,NMEA_PORT))

Dit werkt echter niet met de standaard signal k configuratie. Deze ontvangst werkt alleen als ik in signal k ook het IP adres van SPD in geef (172.17.0.7). Ik wil echter niet in signal k het IP adres van SPD opgeven omdat er meerdere clients kunnen zijn die de NMEA data via UDP willen opvangen. Alternatief om het werkend te krijgen is aan de SPD kant het lokale IP adres te vervangen door 172.17.255.255. Aan de SPD kant wil je echter ook geen ander IP adres omdat SPD niet hoeft te weten waar de NMEA data vandaan komt.

Verder gaat dit kwa netwerken mijn pet te boven. Wie kan aangeven hoe dit zou moeten werken?

Waarom draai je dit in 2 dockers. En niet simpelweg in 1 image?

Dat maakt voor UDP geen verschil als je het broadcast adres wil gebruiken in signal k. Ze draaien in 2 verschillende containers omdat we containers maken met een specifiek doel. SPD draait als desktop app in een container met vnc en signal k als web app. Netwerk, dns, firewall, nmea routeren is op de pi geregeld en de rest zit in losse images (signal k, avnav, spd etc).

UDP werkt prima. Met nc en een python testscript kan ik in de SPD container gewoon binden aan het broadcast adres 172.17.255.255 waar signal K zijn data naar toe stuurt (het IP adres van signal k is 172.17.0.8), terwijl SPD dit zelf alleen kan op localhost (172.17.0.7) omdat er anders een bind fout optreedt? @Thomas, kan jij hier misschien aangeven wat er dan mis gaat?

Als ik de volgende discussie lees, dan heb ik het idee dat 172.17.255.255 gewoon zou moeten werken als NMEA_IP bij een UDP verbinding in SPD:
stackoverflow.com/questions/22...st-packets-in-python

Voor het luisteren naar UDP is geen IP-adres nodig in SPD.
Er wordt naar een poort geluisterd, niet gebonden aan een IPadres.

Zie elke willekeurige UDP-viewer. Daar geef je voor ontvangst-only alleen een Port op.....

Als ik een bind() doe van een socket op een IP-adres buiten het eigen OS gaat het fout, de bind() kan dan niet (en moet ook niet). SPD zegt dan (in de except bij de bind() ):



De bind(), nodig om het OS te vertellen wie (SPD!) er naar de poort gaat luisteren, kan alleen binnen het OS, niet naar een extern IPadres.

Je broadcast-IP als NMEA_IP (het voor SPD externe NMEA-zendertje) zou gewoon moeten werken, met in de bind() het IP-adres van de host waarop SPD draait. Of 127.0.0.1 of localhost, allemaal hetzelfde.
In SPD opgelost door

Thismachine_name = socket.gethostname()
Thismachine_IP_addres = socket.gethostbyname(Thismachine_name)
serverSock.bind((Thismachine_IP_addres,NMEA_PORT)) # bind to local IP

Ipv Thismachine_IP_address daar NMEA_IP zetten (dat kan een gebruiker niet) geeft een fout van de bind.

Ik gebruik

[NMEAnetwork]
Type = UDP
NMEA_IP = 192.168.178.26 de nmea-zender
NMEA_PORT = 5000 en zijn port

Het moet echt zo werken, ik kan niet iets veranderen waardoorhet wel zou gaan.....

Baasklusje schreef :
Met dat IP adres gaat het ook inderdaad mis. Afhankelijk van je subnet mask (achterhalen met ipconfig) zou de bind op 192.168.178.255 of op 192.168.255.255 goed moeten gaan. Dat is wat ik in het python script anders heb gedaan. Het is dus niet een IP adres buiten je machine (bijvoorbeeld van signal k), maar een speciaal adres wat wel zou moeten werken (zie bijvoorbeeld deze info stackoverflow.com/questions/22...st-packets-in-python)

michaelh schreef :
Dat is het IP van een 2e laptop die NMEA staat te zenden.
Het werkt, met UDP zonder dat adres te gebruiken, met TCP heb je het wel nodig, voor de connect().
UDP ontvangen kan echt met alleen een poort.....

Voorbeeld van mijn telefoon, UDP viewer, alleen een poort, en allemaal MEA die van mijn PC gestuurd wordt naar 255.255.255.255 : 5000

Ja en nee. Interfaces hebben poorten. En op poorten kun je luisteren.
Je kunt 2 interfaces hebben met allebei een eigen webserver op poort 80.
In de config van de webserver stel je dan in op welke interfaces je wilt bind-en.

Zo ook met UDP. Je kunt dus bijv alleen op localhost/127.0.0.1 een listener hebben om zo alleen lokaal UDP verkeer te zien.

Ik vermoed dat SignalK niet op de externe interface bind en zo niet de broadcast traffic ziet.

Heb even wat geprobeerd met mijn Python-NMEA-zendertje (leest een logfile) welke IP:poort werken en welkeniet.
Ontvanger de UDP-viewer op mijn Windows-phone.

Als ik in de PC-zender de IP van de telefoon 192.168.178.27 specificeer en poort 5000 komt de NMEA keurig aan.
Als de PC zendt naar 192.168.178.255 : 5000 komt ook alles aan.
PC naar 255.255.255.255 idem. Full broadcast.

Maar 192.168.255.255 en 192.255.255.255 doen het beide niet......

@michaelh, gebruikte jij niet zo'n adres...?

hanst schreef :
In de opstelling van michaelh IS Signal K de broadcaster. Die hoeft niets te zien, alleen UDP-NMEA bytes de wereld in te slingeren.
Intern zal Signal K daarvoor wel een bind van zijn IP en de poort moeten doen, maar dat zal SPD worst wezen.

Dat komt door netmasks, die definieren broadcast address (en.wikipedia.org/wiki/Broadcast_address)

192.168.178.0 is netmask (class C) en dus 192.168.178.255 broadcast. Daarbuiten zal het naar je default gateway worden gerouteerd.
Je kunt met traceroute ook kijken welke interface wordt gebruikt.

hanst schreef :
Precies, en daar zit denk ik het probleem van michaelh...

Misschien is het handiger dit buiten het forum te troubleshooten?
Bijv Slack?
join.slack.com/t/slack-zjr6249...eXu5Mpee98s1R6gGdcMQ

Eerst nog even op de resultaten bij michaelh wachten?

Een compleet adres (geen broadcast), een volledige broadcast(alles 255) of alleen laatste level 255 zonder allemaal moeten werken.
Niet iets met 2 of 3 keer 255....
Dat instellen in SignalK zou het moeten doen voor Class C.

Een korte update wat er wel / niet werkt. Zie ook de bijlage. Een broadcast van 172.17.0.8 op 172.17.255.255 is af te luisteren op hetzelfde broadcast adres (die 2x 255 is het juiste broadcast adres bij dit subnet). Een udp pakket verzonden van 172.17.0.8 naar 172.17.0.2 is af te luisteren op 172.17.0.2. Lijkt logisch...

Een udp broadcast van 17.17.0.8 naar 172.17.255.255 komt niet aan op 172.17.0.2. Getest zowel met signal k als het python test script als SPD. Het lijkt dus geen signal k probleem, maar iets in docker. Als workaround kan ik tijdelijk in SignalK 172.17.0.2 (SailingPD opgeven), maar in de tussentijd zoeken we wat er in de docker configuratie verkeerd zit.

Uit verdere tests met het testscript blijkt dat bij een bind op "" (dus Thismachine_IP_addres = "") de broadcast wel binnenkomt. De data komt dus met een broadcast wel aan.

Met UDP heb je dus voor de bind ook een aantal keuzes voor de interfaces waar naar geluisterd wordt:
- Thismachine_IP_addres = socket.gethostbyname(Thismachine_name) - geeft alleen UDP data bestemd voor dit IP op de geselecteerde poort, geen broadcast
- Thismachine_IP_adres = "" - geeft alle data op alle interfaces op de geselecteerde poort
- Thismachine_IP_adres = <broadcast address gebaseerd op subnet/mask> - geeft alleen de broadcast data?

Thismachine_IP_adres zou dus in het geval van UDP iets moeten zijn als NMEA_INTERFACE oid.
Zou je SPD kunnen aanpassen zodat je bijvoorbeeld met NMEA_INTERFACE kan aangeven waar de bind op moet plaatsvinden?

IP zetten voor UDP heeft alleen toegevoegde waarde als je alleen op 1 interface (die van het IP) wilt luisteren. Je blockt dan dus ook het broadcast verkeer.
Het lijkt mij logischer om de IP config gewoon te hardcoden naar "". SDP luistert dan op alle interfaces op die poort naar packet voo het IP en ook naar broadcast verkeer.

Erg vreemd, met Windows werkt het prima zoals nu geprogrammeerd. Zowel met broadcast als met UDP naar het IP van SPD.
Een bind op '' is niets anders dan op localhost, toch?
Zal morgen proberen.

Even getest.
Met de code nu in SPD wordt het echte IP-adres van de machine gebruikt voor de bind() van de socket

Met 'localhost' wordt het 127.0.0.1 . Dat was te verwachten.
Met '' wordt het 0.0.0.0

Hoe doet zo'n docker dat????
Heeft die een eigen IP of gebruikt hij dat van het OS dat eromheen zit?

Maar zoals al eerder gezegd, het IP adress van SPD waarop hij luistert naar UDP is niet relevant.
Het wordt niet gebruikt in de communicatie, alleen in de bind() van de socket in SPD naar het OS.
De buitenwereld (de NMEA-zender) heeft er niets mee te maken.
Het is een intern dingetje aan de ontvangende kant.
En SPD luistert op een poort. Dat is de opening naar de buitenwereld.
Ik denk toch echt dat het een docker-linux issue is.
Bijvoorbeeld als de docker een ander IP gebruikt dan op OS-nivo gebruikt wordt.
Dan zal de bind() misschien niet goed gaan (die zit op de grens van docker en OS, denk ik....)
Ook omdat het tussen 2 windows machines perfect werkt is linux-docker de verdachte...

Docker/linux hebben we gisteren uitgesloten. Dat werkt.
Een docker container krijgt een lo0 van 127.0.0.1 en een eth0 op een ip in het netwerk.
Localhost werkt dus niet, want dan luister je alleen naar je eigen machine.
Als je het ip van eth0 gebruikt filter je daarmee voor alleen dat verkeer (in de linux python implentatie) en zie je geen broadcast verkeer.

Door geen ip te specificeren werkt het goed. Als het ook op windows goed werkt zijn we toch klaar?

hanst schreef :
dat ga ik zo proberen, 2e machine zendend, SPD met '' in de bind().

Andere optie is nog dat ik er een extra parameter van maak in de boatspecifics.
Dan kan een gebruiker zelf het IP voor de bind() opgeven.
Nadeel is dat dat het weer ingewikkelder maakt en dat het voor Windows helemaal niet nodig is.....

Hoezo heb je docker-linux uitgesloten?
Dat werkt immers niet als je een echt IP binnen de docker gebruikt (gekregen door naar de socket-specs te kijken).
Thismachine_name = socket.gethostname()
Thismachine_IP_addres = socket.gethostbyname(Thismachine_name)
serverSock.bind((Thismachine_IP_addres,NMEA_PORT)) # bind to local IP

Dat het met '' werkt wil niet zeggen dat er geen verwarring tussen linux en docker over een compleet IPadres bestaat, toch?

Geprobeerd.
Met een bind in SPD aan IP '' (dus 0.0.0.0) maakt geen enkel verschil met een bind() aan het echte IP adres waar SPD zit 192.168.178.22

Als de zender (andere windows PC) zendt naar:
192.168.178.22 (SPD) dan komt het keurig aan, met als afzender het echte IP van de zendende PC
192.168.178.255 komt ook aan. Afzender compleet IP
255.255.255.255 ook. Afzender compleet IP
Met 2 of 3 levels op 255 komt er niets aan. Precies hetzelfde resultaat met SPD bind() op 0.0.0.0 als SPD op 192.168.178.22

Geen effect dus van die andere bind. Niets. .

Ik zal een SPD v2.6.4 maken met de bind aan '' ipv echt IP.
Voor windows maakt het geen verschil (en terecht, dat IP is irrelevant bij het ontvangen van UDP)

Gaan we zien of linux en docker zich dan beter gaan gedragen.
Zou wel slecht zijn... dus ik denk dat het niet gaat helpen

Het is v 2.6.3.1 geworden. Staat klaar.
Enige verschil is:
bij gebruik van UDP als NMEA-bron doet SPD nu een bind() van de datagram-socket aan IP '' ipv aan het echte IP-adres van de SPD-machien.

Ben benieuwd of gedockerde SPD op Linux op Pi daar blijer van wordt.
Zo ja, dan is het een foutje in docker/linux
Zo nee, dan ook

In 2.6.3.1 komt de broadcast data van Signal K aan. Zo is de integratie met SPD een stuk makkelijker geworden. Ik weet niet of de gedockerde SPD op Linux op Pi daar blijer van wordt, maar ik wel
Of en waar een fout zit en wat precies de spec is durf ik niet te zeggen (zo erg ben ik niet thuis in netwerken), maar als je er blij van wordt om docker/linux de schuld wil geven, dan mag dat....

hanst bedankt voor je hulp! Thomas, bedankt voor het testscript en de aanpassing die sec voor Windows niet nodig was.

Mooi zo.
En op naar de volgende bug!

En voor je webserver-Node Red: er is een nieuwe key bijgekomen in de web-data, voor de filter van app wind. Zie de readme.