Micropython python-socket

[Oltronix]

Har just hackat ihop en socket för kommunikation mellan en ESP8266 med micropython och en linuxburk. Just nu hände något underligt: Linuxburken hade ställt om sin IP-adr från routeradr (192.168.1.1) till ESPns AccessPunkt adr (192.168.4.1). Det händer så ibland. Jag antar att WiFi-signalen droppar i nivå och då plockas en annan starkare AP-upp av linuxburken. (även många grannar med WiFi här) Trots detta så fortsatte kommunikation mellan socket-server och -klient snurra. Jag blev något häpen. I min klientkod står tydligt att server-addr=192.168.1.176. Jag ställde tillbaka IPadr på linuxburken till min routeradr (192.168.1.1). Socketenkommuntikation for fortsatte att snurra!!

Server: ESP8266, micropython
Klient: Linuxburk, ubuntu, Python3
Kommunikation. WiFi

[mrfrenzy]

ESP måste stänga av sin DHCP-server och accesspunkt när den är ansluten som wifi-klient till din ordinarie router.

[sodjan]

> Trots detta så fortsatte kommunikation mellan socket-server och -klient snurra.

IP adresserna används nog bara för att koppla upp en förbindelse över en socket.
Sedan så används MAC adresser för själva kommunikationen fram till att socket'en stängs.
Så länge som MAC adresserna är samma, så kommer kommer nog kommunikationen att rulla.

Om jag har fattat korrekt hur det fungerar...

[Oltronix]

ESP måste stänga av sin DHCP-server och accesspunkt när den är ansluten som wifi-klient till din ordinarie router.

Det är lite intressant att både Station och AccesPoint är "aktiva" även om spänningen vart avslagen

Kod: Markera allt

>>import port_diag
Networking:
STA ifconfig: ('192.168.1.176', '255.255.255.0', '192.168.1.1', '192.168.1.1')
AP ifconfig: ('192.168.4.1', '255.255.255.0', '192.168.4.1', '192.168.1.1') 

Kod: Markera allt

import network 
ap_if = network.WLAN(network.AP_IF)
ap_if.active(False) 
>>>import port_diag
Networking:
STA ifconfig: ('192.168.1.176', '255.255.255.0', '192.168.1.1', '192.168.1.1')
AP ifconfig: ('0.0.0.0', '0.0.0.0', '0.0.0.0', '192.168.1.1')

Done!

IP adresserna används nog bara för att koppla upp en förbindelse över en socket.
Sedan så används MAC adresser för själva kommunikationen fram till att socket'en stängs.
Så länge som MAC adresserna är samma, så kommer kommer nog kommunikationen att rulla.

Tack för det. Det förklarar det hela. Jag kliade mig i huvudet och trodde jag var ute och cycklade, men eftersom jag skrev ut vilken IP-adr som kontakade server hade jag svårt att förskjuta det hela.
Jag har en klientloop som startar en socket och skickar över c:a 20 byte till serven som svarar med andra 20 byte. Ilband kan jag köra loopen hela natten. Ibland bara några timmar, minuter innan det hänger sig på olika sätt. Jag får försöka sytematisera felen och återkomma.

[sodjan]

Hm. Något som kallas ARP (Address Resolution Protocol) är också inblandat.
Det är där som uppslagningen av IP adress till hårdvaru (MAC) adress sker.
Sedan finns det vanligtvis en "ARP-cache" för att slippa "slå upp" IP adressen
varje gång. Denna cache kan även tömmas med lämpligt kommando.

Sen så är det ju inte säkert att allt detta implementeras i embedded lösningar.

Exempel från min P:

Kod: Markera allt

C:\Users\Janne>arp -a

Interface: 192.168.1.209 --- 0x2
  Internet Address      Physical Address      Type
  192.168.1.1           38-a6-59-86-ad-83     dynamic
  192.168.1.207         48-9e-bd-5b-96-84     dynamic

(Hur 17 får man bort färgkodningen från code-taggarna?)

1.1 är routern och 1.207 är skrivaren.
Så för dessa två så används MAC adressen direkt från ARP tabellen.

[Jan Almqvist]

Ilband kan jag köra loopen hela natten. Ibland bara några timmar, minuter innan det hänger sig på olika sätt. Jag får försöka sytematisera felen och återkomma.

Jag tror det är viktigt med en stabil strömförsörjning till ESP8266, den kan dra mycket ström kortvarigt.

[rvl]

Kod: Markera allt

C:\Users\Janne>arp -a

Interface: 192.168.1.209 --- 0x2
  Internet Address      Physical Address      Type
  192.168.1.1           38-a6-59-86-ad-83     dynamic
  192.168.1.207         48-9e-bd-5b-96-84     dynamic

(Hur 17 får man bort färgkodningen från code-taggarna?)

Hmm... duger det med mono?

C:\Users\Janne>arp -a

Interface: 192.168.1.209 --- 0x2
  Internet Address      Physical Address      Type
  192.168.1.1           38-a6-59-86-ad-83     dynamic
  192.168.1.207         48-9e-bd-5b-96-84     dynamic

Edit: [code='text'] verkar funka.

Kod: Markera allt

C:\Users\Janne>arp -a

Interface: 192.168.1.209 --- 0x2
  Internet Address      Physical Address      Type
  192.168.1.1           38-a6-59-86-ad-83     dynamic
  192.168.1.207         48-9e-bd-5b-96-84     dynamic

[Nerre]

IP-adresserna och MAC-adresserna används på olika nivå.

IP-adresserna används för att skicka IP-paket. Dessa förpackas i ethernet-paket som skickas till MAC-adresserna.

En klient som tar emot ett ethernet-paket adresserat till sin MAC-adress packar upp det och tittar på IP-adressen. Är det en IP-adress som klienten har tar den emot paketet, annars skickar den det vidare (det är detta som är routing).

[MadModder]

Instruktioner för code finns här viewtopic.php?t=94199

[ code lang=språk]
Beroende på vilket språk man väljer så blir det olika färgkodning.
Väljer man ett språk som inte finns blir det bara svart text.
Man kan t.ex skriva inget eller none som språk.
Eller vad som helst. Apostrofer eller citattecken ska inte användas. De gör bara att inget känns igen så det blir samma resultat som att skriva lkjhsdflkjh.

[sodjan]

> Dessa förpackas i ethernet-paket som skickas till MAC-adresserna.

Jo, men hela poängen är att från början så är inte MAC adressen känd och behöver "slås upp".
Och när den är känd ("cache'ad") , så behöver den inte slås upp igen, den finns då i ARP tabellen.

> Är det en IP-adress som klienten har tar den emot paketet, annars skickar den det vidare (det är detta som är routing).

Det tror jag inte alls. Vanliga klienter har ingen routing funktion. Den kastar bara paketet.
Det är *routern* som utför "routing", inte vilken klient som helst.
Och det är sändarens ansvar att skicka ett paket utanför det egna sub-nätet till sin definierade "default router".

[Oltronix]

Ilband kan jag köra loopen hela natten. Ibland bara några timmar, minuter innan det hänger sig på olika sätt. Jag får försöka sytematisera felen och återkomma.

Jag tror det är viktigt med en stabil strömförsörjning till ESP8266, den kan dra mycket ström kortvarigt.

Dålig kraft är modern till alla skumma intermitenta fel. Hur kollar ni intermittenta störningar på 5Vkraften? Jag har inget minnesskåp bara ett gamalt Textronic. Jag har även haft omsändning pga korrumpta TCP-paket enligt Wireshark.

[rvl]

Tillräcklig kondensator nära ESPen borde vara en bra början.

[Nerre]

Jo, men hela poängen är att från början så är inte MAC adressen känd och behöver "slås upp".

Ja, det är sant, men det ligger som sagt var på Ethernet-nivå och inte IP-nivå.

Det tror jag inte alls. Vanliga klienter har ingen routing funktion. Den kastar bara paketet.
Det är *routern* som utför "routing", inte vilken klient som helst.

Alla klienter har stöd för att agera router. Med enbart ett nätverksinterface så är funktionen dock väldigt rudimentär. Men en routing-tabell finns det.

Har du en Windows-dator kan du prova kommandot "route print" som visar aktuella routingregler. Under linux räcker "route" (men man behöver troligen vara root).

[sodjan]

> Ja, det är sant, men det ligger som sagt var på Ethernet-nivå och inte IP-nivå.

Hela diskussionen handlar om varför en socket stannade "öppen" även efter att
en av end-points hade bytt IP adress. Och det tror jag att den kan göra eftersom
att då en socket väl är öppnad så sker all kommunikation på MAC adress nivå.

Har du något bättre förklaring till det observerade fenomenet?

> Alla klienter har stöd för att agera router.
> Med enbart ett nätverksinterface så är funktionen dock väldigt rudimentär.

Nja, OK. Min Windows laptop kan routa trafik mellan Wifi ("dela ut Wifi")
och det fasta nätverket, det stämmer ju. Men i de allra flesta fallen (som t.ex.
i fallet som är aktuellt i tråden), så sker det ingen routing på klientnivå.
Och min Windows laptop listar 7 olika "inerface"...

Hur som helst, vi halkade in i det här träsket efter att du skrev:
"Är det en IP-adress som klienten har tar den emot paketet, annars skickar den det vidare (det är detta som är routing)."

Det låter som att det alltid är så, vilket som sagt är totalt fel. Det är i princip bara burken som är en "router" som gör det.

[Nerre]

Kommunikationen på ethernetnivå (d.v.s. den som använder MAC-adresser) har såvitt jag vet ingen form av handskakning. Den är "fire and forget". Avsändaren skickar ett paket och har ingen aning om ifall det kommer fram eller inte. Samma sak på IP-nivå, IP-trafik har ingen "sessionshantering", det ligger på högre nivå, t.ex. TCP.

TCP numrerar paketen och mottagaren skickar kvittens, om avsändaren inte får kvittens på ett visst paket skickas det om.


Även en enhet med bara ett nätverksinterface kan såvitt jag vet routa paket, dock är det sällan man utnyttjar det eftersom den bara kan skicka paket till klienter på samma ethernetsegment, och där ska ju alla klienter kunna skicka direkt till varandra. Dock kan det antagligen utnyttjas som penetrerande teknik för att ta sig förbi t.ex. MAC-filtrering.

Sen kanske man ofta sätter upp "brandväggsregler" som säger att paket som inte är adresserade till nån av mina IP-adresser ska droppas.