Verbindungsabbruch CUNO <=> FHEM

[Guest]

Originally posted by: <email address deleted>

Es gibt in der culfw einen Fehler, der auftritt, wenn ein TCP-Paket
retransmittet werden soll. Er führt dazu, dass die culfw meint, dass die
Verbindung tot ist und diese dann schließt.
Der Fehler liegt *NICHT* am TCP/IP-Stack, sondern an der Verwendung des
Stacks in den Dateien tcplink.c/h.
 
Der TCP/IP Stack erwartet im Fall eines Rexmits, dass die App die Daten
erneut kopiert und über die Funktion *uip_send()* die Längenvariablen (*
uip_slen*) korrekt setzt.
Im der App wird im Falle eines Rexmit die Funktion *senddata()* aufgerufen,
die sofort returned, weil beim vorherigen Aufruf, mit dem die Daten das
erste Mal versendet werden sollten, der Offset auf 0 zurückgesetzt wurde.
Werden während der 8 Rexmits (8 lt. Define) neue Daten mit Hilfe der
Funktion *tcp_putchar()* in den Puffer gelegt, werden bei einem Rexmit die
neuen Daten versendet (da Offset !=0). Dies hat zur Folge, dass der TCP/IP
Stack die Rexmit-Schleife wieder verlässt und die ürsprünglichen Daten
nicht übertragen werden (da beim Rexmit ja die neuen Daten kopiert wurden).
Werden aber während der Rexmits keine neuen Daten kopiert, werden auch
keine TCP-Pakete versendet, aber der TCP/IP Stack zählt seinen
Rexmit-Counter herab, bis schließlich die Verbindung für tot erklärt und
geschlossen wird.
uip.c[739] = Rexmits sind erforderlich
uip.c[745] = Sind alle Rexmits "fehlgeschlagen" wird die Verbindung
geschlossen.
uip.c[790] = Hier wird die App aufgerufen, die die Daten wieder kopieren
und die zurückgesetzen Len-Variablen (uip.c[722+733]) setzen müsste (über *
uip_send()*)
uip.c[1707] = Ist die Längenvariable == 0 wird das Paket in Zeile 1723
verworfen und es findet in Wirklichkeit gar kein Rexmit statt!
 
 
 
Meine Lösung kostet etwas RAM, aber es ist die beste mit wenig Eingriffen
in bestehenden Code. Evtl. hat Jmd auch eine bessere Lösung...
 
In tcplink.h die Struktur erweitern:
*struct tcplink_state {
  u8_t state;
  u8_t offset;
  char buffer[250];
  u8_t offsetlast;
  char bufferlast[250];
};*
 
 
In tcplink.c die Funktion *tcplink_appcall()* wie folgt ändern:
*  if(uip_rexmit() ||
    uip_newdata() ||
    uip_acked() ||
    uip_connected() ||
    uip_poll()) {
      senddata(uip_rexmit());
  }*
 
Und die geänderte Funktion senddata() einfügen:
*static void
senddata(u8_t rexmit)
{
  struct tcplink_state *s = (struct tcplink_state *)&(uip_conn->appstate);
 
  if (rexmit != 0) {
    if(s->offsetlast == 0)
      return;
    // in case of rexmit, use bufferlast and offsetlast
    // do not touch current data in s->buffer
    memcpy(uip_appdata, s->bufferlast, s->offsetlast);
    uip_send(uip_appdata, s->offsetlast);
   
  } else {
    if(s->offset == 0)
      return;
    memcpy(uip_appdata, s->buffer, s->offset);
    uip_send(uip_appdata, s->offset);
    // copy current offset and data to bufferlast to be able rexmit
identical data
    memcpy(s->bufferlast, s->buffer, s->offset);
    s->offsetlast = s->offset;
    s->offset = 0;
  }
}*
 
Zusätzlich natürlich Zeile 23 anpassen:
*static void senddata(u8_t rexmit);*
 
Mit dieser Änderung werden die Daten immer in einen zweiten Puffer für den
Rexmit Fall zwischengespeichert.
Tritt ein Rexmit-Fall auf, werden die alten Daten erneut kopiert und evtl.
neu in den Puffer eingefügte Daten müssen warten, bis alle Rexmits
abgeschlossen sind.
 
 
 
 
 
 

Am Sonntag, 29. Juli 2012 14:18:32 UTC+2 schrieb Olaf:

> Hi und guten Tag,
>
> kannst Du den Fehler benennen und sagen, wie Du ihn gefixt hast ?
> Dann k�nnen wir anderen das auch testen, bevor wir es final in die
> Firmware einbauen.
>
> Danke,
> Gru�,
> Olaf
>
> Am 28.07.2012 09:12, schrieb doubh:
> > Ich konnte den Fehler bei meinem Aufbau finden und fixen. Seit >48h
> > keine Reconnects!
> > *Es gibt einen Fehler im Netzwerkcode der culfw.*
> > Aktuell habe ich nur einen dirty-hack zum Testen bei mir eingef�gt,
> aber
> > eine sch�ne L�sung sowie genaue Erkl�rung wird die n�chsten Tage
> folgen
> > (wenns mal wieder regnet u nicht so sch�nes Wetter ist .
> >
> ------------------------------------------------------------------------
> Prof. Dr. Olaf Droegehorn
> General Manager              Tel.  : +49-2244-918-4080
> DHS - Computertechnik GmbH   Fax.  : +49-2244-918-4082
> Wilhelm-Liebertz-Str. 2c     E-Mail: O.Droegehorn@dhs-
>                                         computertechnik.de
> D-53639 Koenigswinter        WEB:    www.dhs-computertechnik.de
> ------------------------------------------------------------------------
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich hatte ganz vergessen zu erwähnen, dass ich den Fix zusammen mit v1.46
(SVN rev 303) für CUNO2 kompiliert und getestet habe.
 

Am Sonntag, 29. Juli 2012 20:30:19 UTC+2 schrieb doubh:

> Es gibt in der culfw einen Fehler, der auftritt, wenn ein TCP-Paket
> retransmittet werden soll. Er führt dazu, dass die culfw meint, dass die
> Verbindung tot ist und diese dann schließt.
> Der Fehler liegt *NICHT* am TCP/IP-Stack, sondern an der Verwendung des
> Stacks in den Dateien tcplink.c/h.
>  
> Der TCP/IP Stack erwartet im Fall eines Rexmits, dass die App die Daten
> erneut kopiert und über die Funktion *uip_send()* die Längenvariablen (*
> uip_slen*) korrekt setzt.
> Im der App wird im Falle eines Rexmit die Funktion *senddata()*aufgerufen, die sofort returned, weil beim vorherigen Aufruf, mit dem die
> Daten das erste Mal versendet werden sollten, der Offset auf 0
> zurückgesetzt wurde.
> Werden während der 8 Rexmits (8 lt. Define) neue Daten mit Hilfe der
> Funktion *tcp_putchar()* in den Puffer gelegt, werden bei einem Rexmit
> die neuen Daten versendet (da Offset !=0). Dies hat zur Folge, dass der
> TCP/IP Stack die Rexmit-Schleife wieder verlässt und die ürsprünglichen
> Daten nicht übertragen werden (da beim Rexmit ja die neuen Daten kopiert
> wurden).
> Werden aber während der Rexmits keine neuen Daten kopiert, werden auch
> keine TCP-Pakete versendet, aber der TCP/IP Stack zählt seinen
> Rexmit-Counter herab, bis schließlich die Verbindung für tot erklärt und
> geschlossen wird.
> uip.c[739] = Rexmits sind erforderlich
> uip.c[745] = Sind alle Rexmits "fehlgeschlagen" wird die Verbindung
> geschlossen.
> uip.c[790] = Hier wird die App aufgerufen, die die Daten wieder kopieren
> und die zurückgesetzen Len-Variablen (uip.c[722+733]) setzen müsste (über
> *uip_send()*)
> uip.c[1707] = Ist die Längenvariable == 0 wird das Paket in Zeile 1723
> verworfen und es findet in Wirklichkeit gar kein Rexmit statt!
>  
>  
>  
> Meine Lösung kostet etwas RAM, aber es ist die beste mit wenig Eingriffen
> in bestehenden Code. Evtl. hat Jmd auch eine bessere Lösung...
>  
> In tcplink.h die Struktur erweitern:
> *struct tcplink_state {
>   u8_t state;
>   u8_t offset;
>   char buffer[250];
>   u8_t offsetlast;
>   char bufferlast[250];
> };*
>  
>  
> In tcplink.c die Funktion *tcplink_appcall()* wie folgt ändern:
> *  if(uip_rexmit() ||
>     uip_newdata() ||
>     uip_acked() ||
>     uip_connected() ||
>     uip_poll()) {
>       senddata(uip_rexmit());
>   }*
>  
> Und die geänderte Funktion senddata() einfügen:
> *static void
> senddata(u8_t rexmit)
> {
>   struct tcplink_state *s = (struct tcplink_state *)&(uip_conn->appstate);
>  
>   if (rexmit != 0) {
>     if(s->offsetlast == 0)
>       return;
>     // in case of rexmit, use bufferlast and offsetlast
>     // do not touch current data in s->buffer
>     memcpy(uip_appdata, s->bufferlast, s->offsetlast);
>     uip_send(uip_appdata, s->offsetlast);
>    
>   } else {
>     if(s->offset == 0)
>       return;
>     memcpy(uip_appdata, s->buffer, s->offset);
>     uip_send(uip_appdata, s->offset);
>     // copy current offset and data to bufferlast to be able rexmit
> identical data
>     memcpy(s->bufferlast, s->buffer, s->offset);
>     s->offsetlast = s->offset;
>     s->offset = 0;
>   }
> }*
>  
> Zusätzlich natürlich Zeile 23 anpassen:
> *static void senddata(u8_t rexmit);*
>  
> Mit dieser Änderung werden die Daten immer in einen zweiten Puffer für den
> Rexmit Fall zwischengespeichert.
> Tritt ein Rexmit-Fall auf, werden die alten Daten erneut kopiert und evtl.
> neu in den Puffer eingefügte Daten müssen warten, bis alle Rexmits
> abgeschlossen sind.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Selbstverständlich gehört dieser Fehler in das TCP/IP-Schichtenmodell, den
so genannten TCP/IP-Stack.

Lies hier: https://learningnetwork.cisco.com/thread/5769

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Selbstverständlich gehört dieser Fehler in das TCP/IP-Schichtenmodell, den
> so genannten TCP/IP-Stack.

Mag sein, dass es _nach der reinen Lehre_ dahin gehoert, diese TCP/IP
Implementation (uIP) geht aber ungewohnliche Wege, und erfordert aktiven
Support vom user-level Programm.  Dafuer laeuft es auf einem 8-bit Controller
mit wenig RAM (<= 1kb) und Programmspeicher.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hier ein Auszug aus der Beschreibung des uIP TCP/IP-Stacks (1.6.1.5
Retransmitting Data):
 
*The application must check the uip_rexmit() flag and produce the same data
that was previously sent. From
the application's standpoint, performing a retransmission is not different
from how the data originally was
sent. Therefor, the application can be written in such a way that the same
code is used both for sending data
and retransmitting data. Also, it is important to note that even though the
actual retransmission operation is
carried out by the application, it is the responsibility of the stack to
know when the retransmission should
be made. Thus the complexity of the application does not necessarily
increase because it takes an active
part in doing retransmissions*
 
 

Am Montag, 30. Juli 2012 12:31:10 UTC+2 schrieb Prof. Dr. Peter A. Henning:

> Selbstverständlich gehört dieser Fehler in das TCP/IP-Schichtenmodell, den
> so genannten TCP/IP-Stack.
>
> Lies hier: https://learningnetwork.cisco.com/thread/5769
>
> LG
>
> pah
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Soso, da gibt es einen unvollständigen TCP/IP-Stack, und darum gehört ein
Fehler im TCP/IP-Stack doch nicht zum Stack ?
Meine Güte, sonst keine Probleme ?

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Puschel74]

                                               

Hallo,

hauptsache behoben und wieder gut hier.

Grüße

Am Montag, 30. Juli 2012 22:00:39 UTC+2 schrieb Prof. Dr. Peter A. Henning:
>
> Soso, da gibt es einen unvollständigen TCP/IP-Stack, und darum gehört ein
> Fehler im TCP/IP-Stack doch nicht zum Stack ?
> Meine Güte, sonst keine Probleme ?
>
> pah
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Soso, da gibt es einen unvollständigen TCP/IP-Stack, und darum gehört ein
> Fehler im TCP/IP-Stack doch nicht zum Stack ?

Genau, da das Problem in diesem Fall im User-Level behandelt werden muss. Da
der Stack die Daten nicht merkt (um kein RAM zu verschwenden), muss ein Resend
im User-Level geloest werden, da man hier mehr Moeglichkeiten Daten
platzsparend zu regenerieren.  
Ich weiss das, ich habe den User-Level Code verbockt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Guten Morgen!

Kann man diese Lösung auch für HMLAN nehmen, da ich das gleiche problem bei
meinem HMLAN habe?!
Mfg Steffen

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich habe ja kein Problem damit, dass so etwas gemacht wird - auch ich habe
schon Mikro-Webserver auf 8-Bit-Prozessoren implementiert. Aber patziges
Verhalten gehört in den Kindergarten...

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> Aber patziges Verhalten gehört in den Kindergarten...
Na endlich, doch noch Selbstkritik nach dem ganzen "Bockmist".
Weiter so!

Am Dienstag, 31. Juli 2012 12:42:32 UTC+2 schrieb Prof. Dr. Peter A.
Henning:
>
> Ich habe ja kein Problem damit, dass so etwas gemacht wird - auch ich habe
> schon Mikro-Webserver auf 8-Bit-Prozessoren implementiert. Aber patziges
> Verhalten gehört in den Kindergarten...
>
> LG
>
> pah
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Sehr guter inhaltlicher Beitrag.

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,
betrifft dies auch den CUN?
Wenn ja, würde ich mich über einen Bugfix freuen. Ich habe meinen CUN seit
längerem außer Betrieb gestellt da ich öfters Verbindungsabbrüche hatte.
Nach einem Neustart war's dann immer wieder gut.
Grüße
Domi

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> betrifft dies auch den CUN?

Sehr wahrscheinlich betrifft es alle culfw geraete mit Netzwerk, also CUN, CUNO
und CUNO2.

> Wenn ja, würde ich mich über einen Bugfix freuen.

Im Moment fuehlt sich niemand Zustaendig den Fix einzuspielen.  Das Problem ist
auch nicht das Einspielen/Uebersetzen, sondern das Testen, und ich teste
ausschliesslich mit CULs. Waer nett wenn jemand sich melden wuerde, ich kann
bei Bedarf gerne SVN Schreibrechte vergeben.

Btw. das ist ein Thema fuer die cul-fans Gruppe.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Mittwoch, 18. Juli 2012, 01:37:40 schrieb doubh:
> [...]
> ich habe hin und wieder (ca. 5-10 pro Tag) Verbindungsabbrüche zwischen
> CUNO und FHEM-Server. Dies hat zur Folge, dass nicht alle CUNO Meldungen
> empfangen werden.

mittlerweile hat es auch mich erwischt, allerding mit einem CUN.

CUNO ist noch nicht betroffen..

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com