Webserver U. Radig, ARP-Tabelle

[Bernd (Gast)]

Auf einem AVR-NETIO läuft der Webserver-Formware von U. Radig. Zum 
HTTP-Client der Firmware habe ich Fragen.

Nach dem Aufruf des Clients (Port 84) trägt die Firmware MAC & IP und 
einen Zeit von 100 s in die ARP-Tabelle (siehe Tabelle 3) ein. Warum 
wird so verfahren? Wo ist der Vorteil?

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?

Neben der ARP- gibt es noch eine TCP-Tabelle (siehe Tabelle 3). Welche 
Aufgabe erfüllt sie?


Aufruf von TCP 'erfolgreich':

Tabelle 1

client 4
HTTP_CLIENT : Start
Ready

HC 1: ARP-Request
HC 1: TCP-Verbindung angefragt auf Port 84
HC 2: Hergestellt! (1000)
HC 3: TCP-Verbindung erfolgreich.
Decoder: 4

HTTP/1.1 200 OK
Server: Netwave IP Camera
Date: Thu, 01 Jan 1970 08:37:16 GMT
Content-Type: text/plain
Content-Length: 89
Cache-Control: no-cache
Connection: close


var resolution=32;
var brightness=64;
var contrast=4;
var mode=2;
var flip=0;
var fps=0;

HC 4:->HTTP/1.1 200 OK<-
HC 4: Erfolgreich! (9783)
HC 5: TCP-Verbindung schließen
HC 5: OK: 15 / Gesamt: 19

Aufruf von TCP 'nicht erfolgreich':

Tabelle 2

client 3
HTTP_CLIENT : Start
Ready

HC 1: ARP-Request
HC 1: TCP-Verbindung angefragt auf Port 84
HC 2: Nicht erfolgreich
HC 5: TCP-Verbindung schließen
HC 5: OK: 15 / Gesamt: 20

ARP- und TCP-Tabelle nach einem Aufruf:

Tabelle 3

arp
00  MAC:00.0d.c1.d5.xx.xx  IP:192.168.xxx.xxx  Time:0097
01  MAC:00.00.00.00.00.00  IP:000.000.000.000  Time:0000
02  MAC:00.00.00.00.00.00  IP:000.000.000.000  Time:0000
03  MAC:00.00.00.00.00.00  IP:000.000.000.000  Time:0000
04  MAC:00.00.00.00.00.00  IP:000.000.000.000  Time:0000
Ready

tcp
00  IP:000.000.000.000  PORT:0000  Time:0000
01  IP:000.000.000.000  PORT:0000  Time:0000
02  IP:000.000.000.000  PORT:0000  Time:0000
03  IP:000.000.000.000  PORT:0000  Time:0000
04  IP:000.000.000.000  PORT:0000  Time:0000
Ready

[Jim M. (turboj)]

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.

[Sascha W. (sascha-w)]

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 (Gast)]

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? Es ist doch nicht sinnvoll 
den Port zu blockieren.

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.

Eure Vorschläge werde ich umsetzen und mich gegebenenfalls noch einmal 
melden.

[Sascha W. (sascha-w)]

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

[S. R. (svenska)]

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.