Hallo zusammen, ich setze mehrere Pollin AVR NET-IO mit einer angepasste Software von Ulrich Radig (ETH_M32_EX_SOFT) ein. Die Webserver hängen ein einem Speedport (W701V, OEM Fritz!box ), der Capi over Tcp unterstützt. Jetzt kam mir der Gedanke, das es doch möglich sein sollte, einen eingehenden Anruf auf dem Webserver im angeschlossenen LCD oder auf der Webseite anzuzeigen. Leider bin ich das, was man in Sachen Mikronkontroller einen kompletten Noob bezeichnen kann, der über C Kenntnisse nahe Null verfügt. Auch die verschiedenen Tutorials haben mir nicht den zündenden Gedanken gebracht. Unser aller Freund G00gle hat leider bei meiner Suche keine Hinweise gefunden, das jemand diese Idee schon einmal umgesetzt hat,. Bei der Suche bin ich jedoch auf http://www.wehavemorefun.de/fritzbox/index.php/CAPI-over-TCP-Protokoll gestossen und dachte, man könne dies als Basis verwenden. Ist hier vielleicht jemand bereit, mir bei der Umsetzung meiner Idee zu helfen? Bei Bedarf kann ich einen Wireshark Trace von dem Verbindungsaufbau und einem angehenden Anruf zur Verfügung stellen. Lg Kay
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
ich fände einen monitor cool der einfach snmp traps empfängt und diese anzeigt ...
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
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.
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
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*)ð_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
Mallo Matthias, ich hab das Projekt aufgegeben und eine andere Lösung gewählt. Grundidee war www.ip-phone-forum.de/showthread.php?t=206194 was ich allerdings für meine Zwecke umstrukturiert habe.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.