Webserver mit Capi over TCP/Anrufmonitor Fritzbox

Da hast Du Dir was vorgenommen; Du willst anscheinend CAPI over IP mit 
einem µC nachahmen, um eingehende Telephonanrufe detektieren zu können.

Das ist --gelinde gesagt-- sehr aufwendig.

Einfacher, viel einfacher, dürfte es sein, die Firmware der Fritzbox zu 
modifizieren, denn da gibt es entsprechende Open-Source-Modifikationen*.

Da die Fritzbox über eine (interne) serielle Schnittstelle verfügt, 
kannst Du einen ein Display ansteuernden µC daran anschließen und bist 
aus dem Schneider. Du musst nur ein bisschen Software auf die FB 
bekommen, das die Anrufinformation auf diese Schnittstelle ausgibt.

*) http://trac.freetz.org/

Rufus t. Firefly schrieb:
> Da hast Du Dir was vorgenommen; Du willst anscheinend CAPI over IP mit
> einem µC nachahmen, um eingehende Telephonanrufe detektieren zu können.

Genau das war es, an was ich gedacht habe.

Da sich der µc ja "nur" anmelden muß und dann auf eingehende Meldungen 
warten muß dachte ich nicht, das es so kompliziert ist.
Eine Vollständige Implementierung der Capi dürfte doch nicht notwendig 
sein...?

> Einfacher, viel einfacher, dürfte es sein, die Firmware der Fritzbox zu
> modifizieren, denn da gibt es entsprechende Open-Source-Modifikationen*.

Ich hatte mir freetz schon angesehen, leider funktioniert das nur mit 
Fritzboxen und nicht mit OEM Geräten wie meinem Speedport.

lg
Kay

Kay V. schrieb:
> Rufus t. Firefly schrieb:
>> Da hast Du Dir was vorgenommen; Du willst anscheinend CAPI over IP mit
>> einem µC nachahmen, um eingehende Telephonanrufe detektieren zu können.
>
> Genau das war es, an was ich gedacht habe.
>
> Da sich der µc ja "nur" anmelden muß und dann auf eingehende Meldungen
> warten muß dachte ich nicht, das es so kompliziert ist.
> Eine Vollständige Implementierung der Capi dürfte doch nicht notwendig
> sein...?

Du brauchst ueberhaupt keine CAPI. Der original 'FRITZ!Box Monitor' 
meldet sich auch nur (per TCP/IP) bei der Box an und erhaelt dann alle 
Infos (inkl. eingehender und ausgehender Anrufe) per TCP/IP bzw. UDP. 
Und fuer beides gibt es ja auf jeden Fall fertige Stacks.

Am besten installierst Du Dir den Monitor mal auf einem Windows-System 
und guckst Dir den Netzwerkverkehr zwischen Rechner und Box an.


Volker

Volker Schulz schrieb:

> Du brauchst ueberhaupt keine CAPI. Der original 'FRITZ!Box Monitor'
> meldet sich auch nur (per TCP/IP) bei der Box an und erhaelt dann alle
> Infos (inkl. eingehender und ausgehender Anrufe) per TCP/IP bzw. UDP.
> Und fuer beides gibt es ja auf jeden Fall fertige Stacks.
> Am besten installierst Du Dir den Monitor mal auf einem Windows-System
> und guckst Dir den Netzwerkverkehr zwischen Rechner und Box an.

Hallo Volker,

das habe ich bereits versucht, ich habe einen Ethernettrace vom 
Verbindungsaufbau und einer Anrufsignalisierung und einen "fertigen" (?) 
stack in der Software von UR.

Nur leider glotze ich "wie Schwein in Uhrwerk" in den Trace und den 
Stack.

Wie geschrieben, N00b in µC und C Kenntnisse nahe null.

lg
Kay

Kay V. schrieb:
> Ich hatte mir freetz schon angesehen, leider funktioniert das nur mit
> Fritzboxen und nicht mit OEM Geräten wie meinem Speedport.

Es soll möglich sein, Deinen SpeedPort mit AVM-Firmware zu betreiben.

Der von Volker genannte Weg ist aber wohl der sinnvollste. Das 
Schwein-im-Uhrwerk-Problem musst Du halt in den Griff bekommen, das aber 
ist bei dieser Variante noch sehr viel sauberer als wenn es darum ginge, 
CAPI over IP mal eben selbst zu implementieren.

Rufus t. Firefly schrieb:
> Kay V. schrieb:
>> Ich hatte mir freetz schon angesehen, leider funktioniert das nur mit
>> Fritzboxen und nicht mit OEM Geräten wie meinem Speedport.
>
> Es soll möglich sein, Deinen SpeedPort mit AVM-Firmware zu betreiben.
>
> Der von Volker genannte Weg ist aber wohl der sinnvollste. Das
> Schwein-im-Uhrwerk-Problem musst Du halt in den Griff bekommen, das aber
> ist bei dieser Variante noch sehr viel sauberer als wenn es darum ginge,
> CAPI over IP mal eben selbst zu implementieren.

Richtig, es soll möglich sein, es gibt im ip-phone forum eine Anleitung 
Speed2fritz, aber aus mir nicht bekannten Gründen funktioniert das nicht 
wie gewollt (Vermutlich fehlt doch ein bischen Hardware)...

Zudem ist ein direkt an den Speedport/Fritzbox angeschlossenes LCD nicht 
der wahre Jakob, da ich im Keller meine "IT-Ecke" stehen habe und 
beispielsweise im Wohnzimmer und im 1 Stock gewarnt werden möchte, wenn 
Schwiegermutter anruft :)

Und das halt ohne PC, Laptop oder Telefon befragen zu müssen, da ist 
doch ein AVR Webserver ideal...

Lg
Kay

Kay V. schrieb:
> Und das halt ohne PC, Laptop oder Telefon befragen zu müssen, da ist
> doch ein AVR Webserver ideal...

Eigentlich brauchst Du eher einen (Web-)Client als einen Server. Mit dem 
Trace kann ich Dir leider auch nicht helfen, habe damit noch nicht 
rumgespielt...


Volker

Volker Schulz schrieb:
> Kay V. schrieb:
>> Und das halt ohne PC, Laptop oder Telefon befragen zu müssen, da ist
>> doch ein AVR Webserver ideal...
> Eigentlich brauchst Du eher einen (Web-)Client als einen Server. Mit dem

Hallo Volker, der von mir beschriebene "Webserver" ist nur ein µC mit 
NEtzwerkanbindung, darauf kann programmiert werden, was man braucht, 
auch einen TCP Client.

Nur geht's das leider weit über meine fähigkeiten... :-/

lg
Kay

Kay V. schrieb:
> Volker Schulz schrieb:
>> Eigentlich brauchst Du eher einen (Web-)Client als einen Server. Mit dem
>
> Hallo Volker, der von mir beschriebene "Webserver" ist nur ein µC mit
> NEtzwerkanbindung, darauf kann programmiert werden, was man braucht,
> auch einen TCP Client.

War mir schon klar... "Webserver" ist halt nur das falsche Wort. Es gibt 
fertige TCP/IP-Stacks als Bibliotheken. Du musst aber so oder so erstmal 
das Protokoll von der Fritzbox kennen...


Volker

Volker Schulz schrieb:
> War mir schon klar... "Webserver" ist halt nur das falsche Wort. Es gibt
> fertige TCP/IP-Stacks als Bibliotheken. Du musst aber so oder so erstmal
> das Protokoll von der Fritzbox kennen...

Sorry, hatte ich wohl falsch verstanden.

Einen Link zur Protokollbeschreibung habe ich schon gefunden (siehe 
erstes Post), aber ich verstehe den Aufbau vom Ulrich Radig TCP Stack 
nicht... :/

lg
Kay

Hallo,

ich habe mir mal den Monitor und den Netzwerkverkehr mit Wireshark 
angeschaut. Ich kann auf einer FBOX7050 mir die Anrufe unter Windows XP 
wie folgt ausgeben lassen:

telnet IP_von_FBOX 1012

Ausgabe ist dann:

25.02.10 20:11:21;RING;0;0891234567890;089111111111;SIP2;
25.02.10 20:11:36;DISCONNECT;0;0;

25.02.10 20:12:21;RING;0;0891234567890;089111111111;SIP2;
(DATUM ZEIT;RING;0;Anrufer;MSN oder SIPnummer;Art des Anschlusses..;)

25.02.10 20:12:28;DISCONNECT;0;0;



Am Zeilende werden dann noch 0x0D und 0x0A hinzugefügt.

Um jetzt diese Events zu verarbeiten muss man nur von einem
AVR Board eine TCP Verbindung auf die Fritzbox Port 1012 aufbauen
(also TCP Client auf AVR Board)
und dann diesen String mit dem Semikolon in einzelne Teile zerlegen.

Alles nicht sonderlich schwer.

Aber das auf dem AVR Board umzusetzen musst schon ein wenig selbst tätig 
werden....

Gruß Sven

Sven K. schrieb:
> Hallo,
>
> ich habe mir mal den Monitor und den Netzwerkverkehr mit Wireshark
> angeschaut. Ich kann auf einer FBOX7050 mir die Anrufe unter Windows XP
> wie folgt ausgeben lassen:

Das is ja cool! Geht das auch wenn sich der Fritz!Box Monitor (auf dem 
gleichen System) nicht vorher anmeldet? Kann das gerade nicht testen, da 
ich ihn installiert habe.


> 25.02.10 20:11:21;RING;0;0891234567890;089111111111;SIP2;
> 25.02.10 20:11:36;DISCONNECT;0;0;
>
> 25.02.10 20:12:21;RING;0;0891234567890;089111111111;SIP2;
> (DATUM ZEIT;RING;0;Anrufer;MSN oder SIPnummer;Art des Anschlusses..;)
>
> 25.02.10 20:12:28;DISCONNECT;0;0;

Ausgehend wird auch signalisiert:
25.02.10 20:35:23;CALL;0;0;<EIGENE_NR>;<ZIEL_NR>;SIP0;


Diese Nullen sind bestimmt eine Art ID, damit man z.B. einen Disconnect 
zuordnen kann.

Gestestet auf der 7170.


Volker

Volker Schulz schrieb:
>
> Diese Nullen sind bestimmt eine Art ID, damit man z.B. einen Disconnect
> zuordnen kann.
>
> Gestestet auf der 7170.
>

Ich vermute das diese Art ID hochgezählt wird, wenn gleichzeitig mehrere
Anrufe "aktiv" sind. Und dann hast Du recht, dann lassen sich die
unterschiedlichen Stati der Anrufe zuordnen.

Und ja, der Monitor muss nicht auf einem System aktiv sein.
Es geht auch ohne ;-)

Gruß Sven

Sven K. schrieb:
> Volker Schulz schrieb:
>>
>> Diese Nullen sind bestimmt eine Art ID, damit man z.B. einen Disconnect
>> zuordnen kann.
>
> Ich vermute das diese Art ID hochgezählt wird, wenn gleichzeitig mehrere
> Anrufe "aktiv" sind. Und dann hast Du recht, dann lassen sich die
> unterschiedlichen Stati der Anrufe zuordnen.

Da haben wir wohl richtig vermutet. Habe gerade mal von SIP0 auf SIP1 
angerufen, die Ausgabe ist wie folgt:

25.02.10 21:11:58;CALL;0;0;<NR_SIP_0>;<NR_SIP_1>;SIP0;
25.02.10 21:11:59;RING;1;<NR_SIP_1>;<NR_SIP_0>;SIP1;
25.02.10 21:12:14;DISCONNECT;0;0;
25.02.10 21:12:15;DISCONNECT;1;0;

Jetzt stellt sich mir nur noch die Frage, was die zweite 0 bei CALL und 
DISCONNECT macht...


Volker

Volker Schulz schrieb:

> Da haben wir wohl richtig vermutet. Habe gerade mal von SIP0 auf SIP1
> angerufen, die Ausgabe ist wie folgt:
>
> 25.02.10 21:11:58;CALL;0;0;<NR_SIP_0>;<NR_SIP_1>;SIP0;
> 25.02.10 21:11:59;RING;1;<NR_SIP_1>;<NR_SIP_0>;SIP1;
> 25.02.10 21:12:14;DISCONNECT;0;0;
> 25.02.10 21:12:15;DISCONNECT;1;0;
>
> Jetzt stellt sich mir nur noch die Frage, was die zweite 0 bei CALL und
> DISCONNECT macht...
>

Sauber ! Dann steht doch der Implementierung nichts mehr im Wege.
Ankommende Anrufe kann man ja jetzt schon registrieren
und auch den dazugehörigen DISCONNECT.

Persönlich besitze ich kein AVR Board, von daher kann ich nicht testen.

Gruß Sven

Volker Schulz schrieb:
> 25.02.10 21:11:58;CALL;0;0;<NR_SIP_0>;<NR_SIP_1>;SIP0;
> 25.02.10 21:11:59;RING;1;<NR_SIP_1>;<NR_SIP_0>;SIP1;
> 25.02.10 21:12:14;DISCONNECT;0;0;
> 25.02.10 21:12:15;DISCONNECT;1;0;
>
> Jetzt stellt sich mir nur noch die Frage, was die zweite 0 bei CALL und
> DISCONNECT macht...

Die zweite Ziffer nach DISCONNECT zeigt wohl die Verbindungszeit in 
Sekunden.


Dann gibt es noch
25.02.10 21:22:53;CONNECT;0;0;<NR_GEGENSEITE>;

Hier und auch bei CALL bezieht sich die erste Ziffer auf die ID, die 
zweite anscheinend auf die Nebenstelle.


Volker

Hallo Zusammen,

da sieht man mal, das man viel zu kompliziert denken kann, das es einen 
Anrufmonitor gibt, den man per Port1012 belauschen kann wusste ich gar 
nicht...

In dem Source von Ulrich Radig (den ich als Ausgangscode verwende) gibt 
es schon eine funktion für das senden von UDP Daten an ein LCD, ich habe 
das sofrt damit versucht.

Leider klappt das so nicht, geht das mit dem Code überhaupt?

udp_lcd.h

1

#ifndef _UDPLCDCLIENT_H

2

  #define _UDPLCDCLIENT_H

3

4

  #define UDP_LCD_DEBUG usart_write

5

  //#define UDP_LCD_DEBUG(...)

6

7

  #define UDP_LCD_PORT    1012

8

9

  void udp_lcd_init(void);

10

  void udp_lcd_get(unsigned char);

11

12

#endif

udp_lcd.c

1

#include "config.h"

2

#include "udp_lcd.h"

3

#include "stack.h"

4

#include "usart.h"

5

#include "timer.h"

6

#include "lcd.h"

7

8

#include <avr/io.h>

9

#include <avr/pgmspace.h>

10

11

12

//----------------------------------------------------------------------------

13

//Initialisierung des NTP Ports (für Daten empfang)

14

void udp_lcd_init (void)

15

{

16

  //Port in Anwendungstabelle eintragen für eingehende NTP Daten!

17

  add_udp_app (UDP_LCD_PORT, (void(*)(unsigned char))udp_lcd_get);

18

  return;

19

}

20

21

//----------------------------------------------------------------------------

22

//Empfang der Zeitinformationen von einem NTP Server

23

void udp_lcd_get (unsigned char index)

24

{

25

  UDP_LCD_DEBUG("** LCD DATA GET Bytes: %i **\r\n",((UDP_DATA_END_VAR)-(UDP_DATA_START)));

26

#if USE_SER_LCD

27

  lcd_clear();

28

  for (int a = UDP_DATA_START;a < UDP_DATA_END_VAR;a++)

29

  {

30

    lcd_write (eth_buffer[a],1);

31

    WAIT(2000);

32

  }  

33

#endif

34

}

Lg
Kay

Telnet verwendet TCP, nicht UDP.

Lerne den Unterschied zwischen UDP und TCP - dann kannst du dir die 
Frage beantworten.

Außerdem baut der von dir genannte Code keine Verbindung auf sondern 
wartet auf einen Verbindungsaufbau von Extern. Versuche es mal mit dem 
Code für E-Mail senden vom Board aus.

Rufus t. Firefly schrieb:
> Telnet verwendet TCP, nicht UDP.

Sorry, hatte ich falsch verstanden.

Lg

Kay

Rufus t. Firefly schrieb:
> Telnet verwendet TCP, nicht UDP.

und echtes Telnet erwartet auch eine Benutzernamen-Passwort 
Authentifizierung.

Chris M. schrieb:
> Rufus t. Firefly schrieb:
>> Telnet verwendet TCP, nicht UDP.
>
> und echtes Telnet erwartet auch eine Benutzernamen-Passwort
> Authentifizierung.

?

Demnach ist auf dem Port 1012 kein echts telnet Protokoll?

Eine anmeldung ist dort nicht notwendig, nach dem öffnen der Verbindung 
kommen die Daten sofort, ohne Login o.Ä.

lg
Kay

Sven K. schrieb:
> dann lassen sich die
> unterschiedlichen Stati der Anrufe zuordnen.

Plural 'status' bitte.  Status ist U-Deklination.

Das ist ein eher zweitrangiges Problem.

Ulf Rolf schrieb:
> Plural 'status' bitte.  Status ist U-Deklination.

Rufus t. Firefly schrieb:
> Das ist ein eher zweitrangiges Problem.

Zweitrangig ja, aber nicht weniger umfangreich. Stati ist in jedem Fall 
falsch, "Statusse" findet man aber durchaus in Woerterbuchern. Der Duden 
besteht auf "Status", listet aber "Sinusse" als moeglichen Plural von 
Sinus, welcher ebenfalls u-dekliniert wird.

Ueber Telnet hingegen sollte es eigentlich keine zwei Meinungen geben: 
Weder Authentifizierung noch Verschluesselung sind spezifiziert. Der 
Host kann natuerlich ueber Telnet eine Authentifizierung verlangen, 
so wie eine Internetseite auch einen Login fordern kann. Das hat aber 
mit dem Protokoll an sich nichts zu tun.


Kay V. schrieb:
> Demnach ist auf dem Port 1012 kein echts telnet Protokoll?

Doch, spielt aber in diesem Fall ohnehin keine Rolle. ;)


Volker

Volker Schulz schrieb:

> Kay V. schrieb:
>> Demnach ist auf dem Port 1012 kein echts telnet Protokoll?
> Doch, spielt aber in diesem Fall ohnehin keine Rolle. ;)

Volker, du verwirrst mich... :)

Wieso spielt den jetzt Telnet keine Rolle (mehr)?

lg
Kay

Mein Beitrag (der mit dem zweitrangigen Problem) bezog sich auf den von 
Chris M.
Muss wohl ein Software-Glitch gewesen sein, daß ich nicht die beiden 
Beiträge danach zu Gesicht bekommen habe; ich brauche jedenfalls nicht 6 
Minuten, um so einen Beitrag wie o.g. zu verfassen.

Kay V. schrieb:
> Volker Schulz schrieb:
>
>> Kay V. schrieb:
>>> Demnach ist auf dem Port 1012 kein echts telnet Protokoll?
>> Doch, spielt aber in diesem Fall ohnehin keine Rolle. ;)
>
> Volker, du verwirrst mich... :)
> Wieso spielt den jetzt Telnet keine Rolle (mehr)?

Es spielt keine Rolle ob wir es "Telnet", "echtes Telnet" oder "falsches 
Telnet" nennen... Es ist fuer uns einfach eine TCP/IP-Verbindung! ;)


Volker

Hallo,

Peinlicher Fehler.

Ich korrigiere:

> Und dann hast Du recht, dann lassen sich die
> unterschiedlichen Events den einzelnen Anrufen zuordnen.

Klingt einfach besser und vielen Dank für die Korrektur.

Was die Diskussion über telnet soll, verstehe ich jetzt nicht.

In Beitrag Beitrag "Re: Webserver mit Capi over TCP/Anrufmonitor Fritzbox" habe ich 
doch die wichtigsten Infos zum Verbindungsaufbau geschrieben und mit den 
Nachrichten von Volker wurden noch weitere Details aufgezeigt.

Gruß Sven

Sven K. schrieb:

> Was die Diskussion über telnet soll, verstehe ich jetzt nicht.

Das wird wohl daran liegen, das ich in meinem beschriebenen unwissen den 
Unterschied zwischen TCP und UDP wohl nicht verstanden habe und einen 
falschen Denkansatz gepostet habe.

Leider komme ich mit sendmail nicht weiter, trotz der vielen engagierten 
Hilfe.

lg
Kay

Was hat das mit sendmail zu tun?

Rufus t. Firefly schrieb:

Shortie schrieb:
> Außerdem baut der von dir genannte Code keine Verbindung auf sondern
> wartet auf einen Verbindungsaufbau von Extern. Versuche es mal mit dem
> Code für E-Mail senden vom Board aus.

das Modul heißt sendmail und da das bisher der konkreteste Hinweis war, 
mit dem ich etwas anfangen konnte dachte ich, damit es mal versuchen zu 
können.

Bin ich auf dem Holzweg?

Wenn ich das hier alles richtig lese muß doch "nur" eine Verbindung zum 
Fritzbox aufbauen und anschließend ankommende Zeichen zu speichern und 
auszuwerten.

Da sendmail eine Verbindung zu einem Server aufbaut und danach 
Rückmeldungen von diesem auswertet, wäre das ein (in meinen Augen) 
möglicher Ansatz.

Oder liege ich total daneben?

Lg
Kay

ja du wirst sogar einiges rausstreichen können da der Verbindungsaufbau 
bei SMTP ein kleines Ping-Pong Spiel ist

Hallo zusammen, hier ist wieder die "Nervensäge".

ich habe es inzwischen durch trail and error hin bekommen, das ich eine 
Verbindung zur Fritzbox aufbauen kann (testweise über den Telnetserver 
manuell)

Jetzt habe ich (erstmal nur) 2 Fragen/Probleme:

1. wie und was muß ich einbauen, damit die Verbindung offen bleibt?
Derzeit wird nach einem durchlauf die abfrage wieder beendet.

2. ich bekomme nur 25 Zeichen von dem gesendeten String mit.
Vermutlich ist der eth_buffer zu klein, wie kann ich diesen 
zwischenspeichern in einer anderen Variable?

anbei mal der von mir "zurechtgebogene" sendmail Code von Ulich Radig:

fritz.h

1

2

#if USE_FRITZ

3

#ifndef _FRITZ_H

4

  #define _FRITZ_H

5

    unsigned char fritz_enable;

6

    unsigned int fritz_send_counter;

7

    unsigned int my_fritz_cp; //cp = CLIENT_PORT

8

9

    //Port des fritz-SERVERS

10

    #define fritz_PORT 1012

11

12

    //Mit oder ohne Debug-Ausgabe

13

    #define fritz_DEBUG usart_write  //mit Debugausgabe

14

    //#define fritz_DEBUG(...)       //ohne Debugausgabe

15

16

    //IP des fritz-Servers 

17

    #define fritz_SERVER  IP(192,168,1,1) //hier z.B. fritz

18

19

    unsigned char fritz_send (void);

20

    void fritz_init (void);

21

  void fritz_data (unsigned char);

22

#endif //_FRITZ_H

23

#endif //USE_FRITZ

fritz.c

1

#include <config.h>

2

#include <avr/io.h>

3

#include <string.h>

4

#include "usart.h"

5

#include "lcd.h"

6

#include "fritz.h"

7

#include "timer.h"

8

#include "stack.h"

9

#include <avr/pgmspace.h>

10

11

  #include <stdlib.h>

12

  #include <stdarg.h>

13

  #include <ctype.h>

14

  #include <string.h>

15

  #include <avr/io.h>

16

17

#if USE_FRITZ

18

19

unsigned char fritz_enable = 0;

20

unsigned int  my_fritz_cp = 0;

21

unsigned char fritz_get = 0;

22

//----------------------------------------------------------------------------

23

//fritz Client Init

24

void fritz_init (void)

25

{

26

    //Eintragen des fritz Client Ports (1546)

27

    my_fritz_cp = 1546;

28

  add_tcp_app (my_fritz_cp, (void(*)(unsigned char))fritz_data);

29

}

30

31

//----------------------------------------------------------------------------

32

//Daten kommen vom fritz- Server an!! (fritz wird versendet)

33

void fritz_data (unsigned char index)

34

{

35

    //Verbindung wurde abgebaut!

36

    if (tcp_entry[index].status & FIN_FLAG)

37

    {

38

        return;

39

    }

40

41

    if (fritz_get)

42

    {

43

        unsigned int message_code = 0; 

44

45

    message_code = atol((char*)&eth_buffer[TCP_DATA_START_VAR]);

46

47

        //if (message_code != 0)

48

        {

49

            for (int a = TCP_DATA_START_VAR;a < TCP_DATA_END_VAR;a++)

50

            {  

51

                fritz_DEBUG("%c ",eth_buffer[a]);

52

53

        lcd_print (3,1,"%c ",eth_buffer[a]);

54

55

            }

56

57

        }

58

59

          //fritz_get = 0;

60

61

62

        }

63

        tcp_entry[index].time = TCP_TIME_OFF;

64

    }

65

//}

66

67

//----------------------------------------------------------------------------

68

//Versenden einer E-fritz starten

69

unsigned char fritz_send (void)

70

{

71

  if(fritz_get == 0) //Falls nicht derzeit bereits eine fritz gesendet wird

72

  {

73

    //öffnet eine Verbindung zu einem fritz-Server

74

    fritz_DEBUG("Send fritz\n\r");

75

76

    unsigned int my_fritz_cp_new = my_fritz_cp + time;

77

    if (my_fritz_cp_new < 1000) my_fritz_cp_new +=1000;

78

79

    change_port_tcp_app (my_fritz_cp, my_fritz_cp_new);

80

    my_fritz_cp = my_fritz_cp_new;

81

82

83

    //ARP Request senden

84

    if (arp_request (fritz_SERVER))

85

    {

86

      for(unsigned long a=0;a<2000000;a++){asm("nop");};

87

88

      fritz_DEBUG("fritz empfang am Clientport (%i)",my_fritz_cp);

89

      tcp_port_open (fritz_SERVER,HTONS(fritz_PORT),HTONS(my_fritz_cp));

90

      fritz_send_counter = 0;

91

      fritz_get = 1;

92

93

      unsigned long index = MAX_ARP_ENTRY;

94

      unsigned char tmp_counter = 0;

95

      while((index >= MAX_ARP_ENTRY) && (tcp_entry[index].app_status != 1))

96

      {

97

        index = tcp_entry_search (fritz_SERVER,HTONS(fritz_PORT));

98

        if (tmp_counter++ > 30)

99

        {

100

          fritz_DEBUG("TCP Eintrag nicht gefunden (fritzserver)\r\n");

101

          return 0;

102

        }

103

      }

104

      fritz_DEBUG("TCP Eintrag gefunden (fritzserver)!\r\n");

105

    }

106

  }

107

  else

108

  {

109

    return 0;

110

  }

111

  return 1;

112

}

113

#endif //USE_FRITZ

Hallo zusammen.

Ich bin immernoch dabei, die empfangenen Daten aus eth_buffer 
vollständig anzuzeigen.

Ich dachte, folgender Weg sollte gehen, was mir aber anscheinend Daten 
im flash überschreibt....

1

unsigned char fritz_tmp[(MTU_SIZE*2)+1];

2

int xx=0;

3

4

5

for (int a = TCP_DATA_START_VAR;a < TCP_DATA_END_VAR;a++)

6

{  

7

strcpy(fritz_tmp[xx],eth_buffer[a]);

8

fritz_DEBUG("",fritz_tmp[xx]);

9

//lcd_print (3,1,"",eth_buffer[a]);

10

if (xx > (MTU_SIZE*2)) xx=0

11

}

MTU_SIZE wird im Makefile definiert, in meinem fall = 1200.
eth_buffer ist mit unsigned char eth_buffer[MTU_SIZE+1]; deklariert, 
meine Char sollte also doch doppelt so groß sein...
Weiß jemand, wo das Problem liegen könnte?

Lg
Kay

Ist das ganze hier noch aktiv? Bin auch gerade dabei mir sowas zu bauen! 
Wurden die Probleme gelöst?


Grüße