Onderwerp: TCP verbinding tussen 2 laptops

In Sailing Performance Dashboard (SPD) wil ik ook de mogelijkheid inbouwen om via TCP NMEArecords van een NMEAbron te ontvangen.
Er schijnen apparaten te bestaan die geen UDP maar alleen TCP doen (Vesper, bijvoorbeeld).

SPD doet nu serieel (COM of USB) en UDP. Dat gaat prima.

Om TCP te testen draait er op 1 laptop een klein beetje Python dat een NMEAlogfile leest en record voor record uitzendt over TCP.

Op de andere laptop SPD of een andere NMEA-ontvanger (miniplex3 configuratietool, bijvoorbeeld)
Allemaal weigeren ze connectie te maken met de zendende laptop.

(over UDP gaat dat wel prima, geen connect nodig.)

Als beide programma's op 1 laptop samen draaien gaat het wel goed.
Iets in het netwerk dus....
Ook met (beide laptops) de firewalls geheel uitgeschakeld werkt het niet.

Iemand een idee?

Bekijk eens met tcpview of je python ook de poort heeft gepakt. Als dat zo is, dan zou je daarna met Wireshark kunnen bekijken wat er met het opzetten van de TCP sessie gebeurt.

Ik ga dit volgen. Sinds w10 alleen maar problemen met kleine netwerkjes tussen pc's gehad.

Gepost met de officiële Zeilersforum-app

Ik weet hier ongeveer niets van, maar ik zou zo simpel mogelijk beginnen. Dus niet gaan verbinden met een zelfgebouwde TCP server, maar een standaard server. Dan wéét je in elk geval dat je je alleen op de client kant hoeft te concentreren (SPD wordt ook client toch?)

Ik zou dus met NavMonPC een TCP server aanmaken en deze een NMEA logfile -die van koko uiteraard - laten streamen.

Volgende stap is hiermee verbinden vanuit dezelfde PC met putty als TCP client. Is gratis. Werkt dat goed, dan met putty vanuit de tweede PC.

En dán pas met Python hetzelfde proberen vanuit die tweede PC. Je weet dan zeker dat er geen firewall issues zijn en dat er in principe verbinding gemaakt kán worden...

UDP werkt anders dan TCP, maar als UDP werkt mogen we veronderstellen da je kabeltje OK is.
UDP is simpel gezegd heel hard in de rondte schreeuwen wat je kwijt wilt. Waarbij TCP meer is van aanbellen, vragen bent u meneer xxx en dan de boodschap overdragen.

Voor TCP moeten beide computers elkaars IP adress weten. Dit kan je of handmatig doen, of automatisch, maar dat betekent dat één computer een server wordt waarop een dhcp server moet draaien. De client kan dan aan de server vragen welk IP adress moet ik voor mezelf gaan gebruiken. Maar als jij met je python scriptje vervolgens een TCP verbinding wilt maken, moet je eerst uitvogelen (De server vragen) wat het toegewezen IP adress is. Voor simpel recht toe recht aan netwerkje zijn vaste handmatig ingestelde IP adressen vaak simpeler.

In jouw geval: Eerst verbinding maken, dan op beide computers het IP adress controleren en vervolges in de programmas die je gebruikt het juiste IP adress gebruiken.

Pasop een automatisch toegewezen IP kan iedere keer anders zijn.

Dat toewijzen van IP adres hoeft SPD toch niet voor te zorgen!? Die hele PC zou al een IP adres toegewezen hebben moeten krijgen, lang voordat de gebruiker SPD start...

Kan je pingen tussen de twee?

Mijn ervaring is dat zonder gateway dat 1:1 UDP of TCP niet lukt, ook niet met een crosslink. Broadcast UDP werkt wel altijd.
Ik sluit niet uit dat ik iets verkeerd doe?

1:1 (peer-to-peer) is lastig idd; heb ik wel gedaan tijdens verblijf in buitenland: had wel laptop en RPi mee (was iets headless aan het ontwikkelen op die Pi...) maar geen router. Op de Windows laptop moet je dan een gratis DHCP server installeren, dan werkt het. Wordt niet dtandaard bij Windows meegeleverd.

Aan boord zal een Vesper meteen Access Point zijn en de verbonden apparaten een IP adres uitdelen. De apparaten kunnen elkaar dan via de Vesper benaderen als het goed is. Niet getestvoverigens - ik verwacht dit, net zoals bij mijn eerdere B&G GoFree access point. Om deze situatie na te bootsen (en geen ingewikkelder peer-to-peer koppeling te maken) zou BK beide PC’s met z’n router laten verbinden. Ik neem aan dat ie dat al zo doet trouwens.

Straks aan boord draait de TCP server in de Vesper (het IP adres van de gateway); bij de testopstelling thuis draait die TCP NMEA server op de andere PC...

Nog even wat verduidelijking....

Het gaat over wifi, niet over een kabeltje. (ik heb ook geen cross-ethernet-kabel).
Beide laptops verbonden met dezelfde router.
3 verschillende routers (1 Fritzbox, 1 Experia en 1 Linksys) geprobeerd. Alle 3 zelfde probleem.

In alle gevallen doet de router de DHCP; elke laptop heeft keurig een IPadres. Daar ligt het niet aan.

TCP met een NMEA-zendend programma op dezelfde laptop als een ontvangend programma (in dit geval de Miniplex3 configuratie sw) werkt goed, met op de ontvangende kant 127.0.0.1 (de localhost) poort 5000 en op de zendende kant ook localhost en 5000.

TCP met hetzelfde zendende programma op een 2e laptop is geen verbinding mee te maken.
Zendende PC is 192.168.178.25, poort 5000
Ontvangende is 192.168.178.22 poort 5000 (zelfde IP range, dus zelfde router)

De ontvanger (nu even Miniplex3 sw) proberen te connecten met 192.168.178.25 : 5000 geeft 'connection timed out'.

Ga eerst nog even met 2 kabeltjes proberen, beide laptops aan één router, geen wifi.

Als dat niet werkt dan wordt het tcpview en/of wireshark.....

Het feit dat het binnen 1 OS (windows) met localhost (of 127.0.0.1) wel werkt betekent m.i. dat het niet aan de programma's zelf ligt maar aan iets in het netwerk dat de zaak blokkeert.

WiFi of kabeltje zou geen verschil mogen maken.

Ping-test al gedaan tussen beide PC’s? Als het goed is laat je router de apparaten aan de veilige kant van de firewall met elkaar praten. Heb je andere netwerkapparaten (NAS met webserver, printer...) waarbij dat lukt? Of wordt dit de eerste toepassing?

Lijjt erop dat je router verkeer tussen apparaten verbiedt en alleen naar buiten (internet...) toestaat?

Nachtvlinder schreef :
ping naar de zendende PC:

ping andersom (van zender naar ontvanger) time out......

En andersom?

PS: niet relevant nu, maar ik heb begrepen dat cross-ethernet kabeltjes niet meer vereist zijn tegenwoordig; moderne netwerkkaarten herkennen zelf wanneer er een 1:1 verbinding gemaakt wordt

Nachtvlinder schreef :
time out...

Kijk! Da’s nie goed

Kunnen beide PC’s wel de gateway pingen? Als je ipconfig intypt zie je dit adres

Nachtvlinder schreef :
Nee. Maar hoe komt dat....

Op beide PC’s staat firewall uit? Als je inlogt in je router hebben beide PC’s dezelfde status?

In he router staat alles open aan de binnenkant?

Als je een roeter hebt, heb je een gateway, dan lukt alles.
Mogelijk firewall probleem?

www.google.nl/amp/s/www.urtech...omputers-on-network/

Anti-virus wordt ook nog genoemd...

De asymmetrie zit denk ik niet in je access point maar in de pc die de ping niet beantwoordt. Zelfde OS als de andere? Trek anders je WAN stekker er even uit en zet ook de antivirus eens uit?

Op je smartphone kun je ook een ping app installeren, ben benieuwd of die ook geblocked wordt door diezelfde PC...

On Windows security (weet niet of datcrelevantbis als je Windows firewall uitvstaat...) staan beide netwerken als “trusted zone” ingesteld? Niet “public”?

Die Enable ping oplossing had ik ook gevonden, maar dat Allow Incoming Echo Request is daar nergens te vinden.....

Beide laptops W10 met dezelfde (meest recente) upgrades.
Beide zelfde firewall en AV.

En toch een kant op wel en andere kan op niet.....

TCP, ik had er al een hekel aan en dat wordt niet minder.

Dit is vast gewoon een Windows dingetje ergens. Nooit issues gehad met NavmonPC TCP server naar VSPE TCP client of OpenCPN TCP client op zelfde PC of op RPi...

Één PC van je is iets te veilig ingesteld Staat mss wel los van TCP: werkt filesharing wel bv?

firewall op de ontvangende PC uit, dan kan ik hem wel pingen.

Maar nog steeds een time out op de TCP-verbinding...

Stukje verder weer dus

Hoe zou je kunnen testen of een poort beschikbaar is/open staat?

Wordt tijd dat een capabel persoon zich er eens mee gaat bemoeien. Mijn ideeën raken op - voor zover ze al nuttig waren

Het is beter om te controleren of je ARP-entries hebt aan beide kanten, cmd.exe -> arp -an

Verder kan het zijn dat een poort aan 127.0.0.1 gebonden is en niet aan 0.0.0.0 (alle interfaces) Voor TCP is het verder niet nodig om de source-port in te stellen, dat doet het OS wel voor je.

Jappe schreef :
In de ontvangende laptop GEEN ip-adres van de zendende.

Andersom wel.
Dus degene die de ping beantwoordt kent de ping-zender wel, andersom niet....