Onderwerp: TCP verbinding tussen 2 laptops

De wifi op beide laptops uitgezet.
Een Linksys router ernaast gezet (niet aan internet).
Beide laptops een ethernetkabel naar de Linksys router.
firewalls gewoon aan.

Ze zien elkaar direct, en de TCP-verbinding tussen de python-NMEA-zender op de ene en een ontvanger op de andere (wingps, miniplex config tool) werkt meteen.....

Via wifi ziet de ene de andere niet, via kabels wel.....

En dan via wifi met dezelfde Linksys: zien ze beide de ander niet.....

ARP werkt ongeveer als volgt:

Ik wil een verbinding opbouwen naar 10.10.10.10 op poort 5000
PC kijkt in de tabel of hij daar een mac-address heeft voor 10.10.10.10 (de cache, timeout verschilt per implementatie)
Als er geen entry is, dan verstuurt de PC een "who-has 10.10.10.10" broadcast naar het netwerk
de andere PC reageert dan met een "is-at de:ad:be:ef:12:34"

en dan weet de startende PC dus naar welk mac-address hij het pakket moet sturen voor poort 5000.

(Bij TCP gaat er dan een SYN naar die poort, waar de andere kant dan een SYN-ACK op terug geeft, daarna kan er data uitgewisseld worden)


Overigens doen de meeste multiplexers op UDP het verkeer broadcasten naar 255.255.255.255, zodat iedereen in dat netwerk het kan zien en dus kan laten zien.


(Ik doe linux en netwerk bij een cloud-provider)

thx @Jappe.

Even een vraag:
de laptop die TCP wil gaan zenden staat klaar en te luisteren en wachten op een accept. IP eindigt .25
Pas bij die accept krijgt hij het IP, port van de PC die verbinding wil maken. (IP .22)

De PC die verbinding wil maken (ip .22) heeft (arp /a) wel het IP van de wachtende ander (.25); dat wordt ook opgegeven bij het maken van de verbinding.
MAAR de .22 staat niet in zijn (ip .25) arp /a lijstje.
Dan zou de PC die staat te wachten op accept (de .25) dus een 'who has' moeten broadcasten zeg je, om erachter te komen wat de MAC van dat IP (.22) is?

Multiplexers die UDP uitzenden is prima te verwerken.
Het gaat om die ene (Vesper) die per sé alleen TCP doet

Baasklusje schreef :

Het is een cache, na verloop van tijd valt de entry dus weg. Er moet dus wel, een poging tot, verkeer geweest zijn om daar wat in te hebben staan, een ping doen (ook al werkt die zelf niet) voordat je arp bekijkt forceert dat al. De screenshots die je gisteren liet zien, waren ook gewoon goed. qua test is het dus voldoende om van 22 -> 25 (en andersom) te pingen en dan ARP te bekijken. Staan daar de correcte macs in, dan werkt dat deel van het netwerk gewoon. Ik vermoed ook wel dat dat het geval is (je kan op beide toch ook gewoon over de router naar internet toe?)

Kun je andersom proberen (server en client van zijde wisselen), of gaat dat niet?

Jappe schreef :
Beide kunnen naar de router en internet, zeker.

Ik heb nu in het programma op de NMEA-zender (die de andere IP niet zag) een stukje toegevoegd.
Hij opent nu ook een UDPsocket naar het missende adres (.22) en zendt daar wat heen.
Dat werkt, daarna staat het eerst missende IP er wel bij (arp /a).

Maar de TCP-connect erna: time out.....

Baasklusje schreef :

met tcpview kijken of de poort in open is, met wireshark bekijken wat er dan langs komt. zet dan wel "tcp.port == 5000" als filter.

Nachtvlinder schreef :
Alles kan

Andersom (.22 zendt NMEA over TCP)werkt het wel..... Miniplex3 configtool leest keurig alle records.

Meteen weer andersom gedaan: time out....

Jappe schreef :
Op de pc met tcpview:

proberen te connecten met miniplex3-config geeft even een groene regel in tcpview, 'syn sent'.

Na een paar seconden rood ipv groen, en de time out.

de andere partij pakt de accept (python) niet op, de syn is wel gestuurd.

Precies dezelfde 2 stukkies sw omgewisseld op de PC's en het werkt wel......

Baasklusje schreef :

tcpview laat ook zien welk proces aan welke poort hangt, ik ben vooral benieuwd of je python-proces daar tussen staat op poort 5000 en aan welk IP.

Als het andersom wel werkt, dan moet er al iets anders op die poort zitten of toch een firewall...

tcpview op de pc die nmea zendt met python en verbonden is met Gebruikers-PC (de luisteraar)



tcpview op de zelfde pc die dan luistert met miniplex config tool. Syn gezonden naar de juiste PC. Even later time out.

Baasklusje schreef :
De poort staat open (Listen) en de connectie is gemaakt (Established), dan moet het hogerop in de stack mis gaan. Waarschijnlijk in het programma en misschien in een verschil in verwachting wat/hoe er dan wat over de lijn gaat.

Jappe schreef :
En dan werkt het (die gele zijn de 'andersom' situatie).

De andere regel (wit) is een verzonden syn die nooit beantwoord wordt....

Baasklusje schreef :

Die zijn beide vanuit dezelfde laptop gezien?

Jappe schreef :
Yes.

Geel en werkend is de Python-zendende laptop, naar de andere met Miniplex-tool.

Wit is vanuit zelfde PC, die dan luistert, een syn verstuurt en nooit connect....

De sw is in beide situaties 100% identiek, alleen omgewisseld ...

Baasklusje schreef :

Wat zegt tcpview op de andere laptop?

Ik heb nergens gelezen dat je alle firewalls op beide macchines uitgezet hebt.

Doe dat anders eens??

Jappe schreef :
Zo'n broadcast is een multicast. Een multicast heeft een time to live (TTL). Dat is het aantal nodes in het netwerk welk het kan passeren voordat het gestopt wordt. Bij een bedraad netwerk is je hub blijkbaar geen switch = node voor de multicast. Het pakketje komt aan bij de aangesloten computer die dat nodig heeft. Bij een wifi verbinding is er wel een switch/node. De broadcast komt niet aan bij de juiste computer.
Met een derde systeem zou je kunnen met behulp van een netwerk sniffer kunnen kijken of de benodigde boardcast pakketjes de wifi node overleven.

Ik denk dat dit in de weg zit:
The AP Isolation is a feature of wireless routers that enables you to create a separate virtual network for each wireless client that is connected to a network name or SSID. When this feature is enabled, all wireless devices in the network will not be able to communicate with each other, preventing unwanted hacking.

(www.linksys.com/gb/support-article?articleNum=135098)

Kun je gewoon uitzetten.

Baasklusje schreef :
Die register gaat ook over SMB (gedeelde mappen). Dat zou niks moeten doen met wel of niet toestaan van TCP-verbindingen voor andere applicaties. Aan de andere kant is het Windows, dus je weet maar nooit.

Bij het instellen van een nieuwe netwerkverbinding in Windows moet je geloof ik kiezen welk type netwerk het is (openbaar, zakelijk, privé). Het kan zijn dat voor een van de laptops de instelling op 'openbaar' staat, en dat hij dan alle inkomende verbindingen blokkeert.

hanst schreef :
Dank voor de suggestie.
Het gaat om een Fritzbox. Daarin kun je op mac-adres apparaten wel of niet toelaten.
Ze staan er beide bij, dus dit is niet het probleem....

Menno schreef :
Beide in prive, van dezelfde Fritzbox...

Heb je die suggestie van Calidris' q&d-afdeling nog geprobeerd? Al is het maar om er achter te komen of het daar aan ligt, dan weet je in welke richting je moet zoeken voor een 'nette' manier.

Knoet schreef :
Nee.....
Register editen voor zoiets doe ik niet.

Ik heb het alleen nodig om in SPD (in Python) een TCP-verbinding naar een mux oid te maken en de data (NMEA) in te lezen.
Dat werkt prima binnen 1 machientje, dus daarmee kan ik ontwikkelen en testen.
Zelf (met python) NMEA verzenden over TCP is niet nodig, dat kan ook met NavMonPC etc.
En kijken of dat binnenkomt kan met WinGPS, Minplex3 configtool, en eigen Python.

Dat werkt dus ALLEMAAL op 1 machien (zender en ontvanger).

Op dit moment staat NavMonPC NMEA te verzenden over TCP op de ene machien, en ik probeer te connecten met de 3 genoemde progamma's op de andere machien.
Beide zien elkaar (arp /a), zitten in hetzelfde prive-netwerk, en geen van de drie ontvangers slaagt erin te verbinden met NavMonPC.

Ik stop met deze opzet; ik ga wel verder binnen 1 machien. Zenden met NavMonPC en ontvangen met van alles en nog wat.

Baasklusje schreef :
MAC adressen gaan over het toelaten van wifi apparaten op je wifi netwerk. Dat zegt nog niets over hoe dat netwerk functioneert.

Zie tick box onderaan dit scherm voor die isolation setting: