Webserver U. Radig, ARP-Tabelle

Bernd schrieb:
> Während die Zeit abläuft (100 s -> 0 s), kann über den Client keine neue
> Verbindung (siehe Tabelle 2) aufgebaut werden. Was ist die Ursache?

Bernd schrieb:
> HTTP/1.1 200 OK
> Server: Netwave IP Camera

Könnte auch an der Camera liegen. Deren TCP/IP/HTTP Stacks sehen 
mitunter recht gruslig aus - insbesondere bei der Fehlerbehandlung.

Ansonsten hilft in solchen Fällen ein Hub und Wireshark.

Hallo,

der Eintrag in die ARP Tabelle ist doch logisch. Um das Ethernetpaket zu 
senden brauchts die MAC Adresse. Also wird ein ARP Request an die 
Ziel-IP (wenn im LAN) oder an den Gateway (wenn extern) gesendet um die 
MAC zu bekommen. Das Ergebnis wird in die Tabelle eingetragen und für 
den anschließenden TCP-Verbindungsaufbau genutzt.
Der Eintrag kann aber eigentlich nicht dazu führen das du keine neue 
Verbindung aufbauen kannst.
Das "Problem" wird die Kamera sein. Nach dem schließen der 
TCP-Verbindung verbleibt der Eintrag meist noch eine gewisse Zeit im 
Stack gespeichert (auch bei Win). Versuchst du eine neue Verbindung 
aufzubauen wird die der alten Verbindung zugeordnet. Du musst vom 
Prinzip her wie jeder andere Stack ausgehend bei jeder Verbindung einen 
neuen Port nehmen - nicht immer wieder 84. Im übrigen verwendet man für 
ausgehende Verbindungen Ports >1024.
Also nach dem Ende der TCP-Verbindung den Client-Eintrag löschen und vor 
der nächsten Verbindung einen Client-Eintrag mit der nächst größeren 
Portnummer hinzufügen.

Sascha

Bernd schrieb:
> Vielen Dank für eure Antworten.
>
>> Du musst vom Prinzip her wie jeder andere Stack ausgehend bei jeder
>> Verbindung einen neuen Port nehmen - nicht immer wieder 84.
>
> Warum muss denn jedes mal ein neuer Port genommen werden? Wieso kann
> nicht über den gleichen kommuniziert werden?
Kann schon, aber erst nach einer gewissen Wartezeit. Falls die 
Verbindung nicht ordenlich geschlossen oder unterbrochen wird können so 
verspätet eintreffende Pakete noch zugeordnet werden.
> Es ist doch nicht sinnvoll
> den Port zu blockieren.
Der Port wird ja nur für die eine IP blockiert zu der die Verbindung 
bestand, und wenn der Client bei der nächsten Verbindung einen anderen 
Port nimmt ist das auch kein Problem.

> M. M. n liegt es mit größter Wahrscheinlich nicht an der Kamera, da nach
> dem Ablauf der ARP-Zeit im AVR-NETIO von 100 Sekunden, ein neues
> Kommando problemlos abgesetzt werden kann.
Wenn es tatsächlich daran liegt dann ist da ein Fehler in der Software. 
Beim Aufbau der Verbindung wird erst in der ARP-Tabelle geschaut ob für 
die IP ein Eintrag vorhanden ist und nur wenn dem nicht so ist wird ein 
neuer ARP-Request gestartet.
Du kannst doch die 100s mal auf 10s runtersetzen.

Sascha

Das Problem ist, dass nach dem Versenden eines verbindungstrennenden 
RST-Paketes die Verbindung formal nicht mehr besteht, dieses Paket aber 
dennoch bestätigt werden muss. Außerdem können ja auch noch andere 
Pakete über diese Verbindung eintrudeln, die vor der Trennung 
abgeschickt wurden. Daher hält jeder bessere TCP-Stack eine Verbindung 
nach ihrem Ende noch eine gewisse Zeit lang in einem "Verbindung tot, 
aber noch reserviert"-Zustand (TIME_WAIT), um solche Pakete schnell 
korrekt einordnen (und wegwerfen) zu können.

Eine Verbindung besteht aus (Source-IP, Source-Port, Destination-IP, 
Destination-Port). Wenigstens eines davon musst du ändern, um eine 
neue Verbindung aufbauen zu können, und das ist sinnvollerweise der 
Source-Port. Ansonsten bist du für den Empfänger nämlich nur das 
verrauschte, vorgeschichtliche Echo einer früheren Verbindung, die er 
erst nach TIME_WAIT vergessen wird.