[ethersex-devel] UDP_DIRECT

Discussion:

[ethersex-devel] UDP_DIRECT_SEND type cast

tjareson

2015-03-25 04:20:39 UTC

Hallo,

ich habe ein Problem mit UDP_DIRECT_SEND im control6 scripting,
vermutlich mit type casting.
Wenn ich im control6-Script mit
UDP_DIRECT_SEND(192.168.1.5, 2701, 2701, "Hello world.");
sende, funktioniert es.

Möchte ich allerdings den string durch eine Variable ersetzen, bekomme
ich beim Übersetzen diverse Fehler wahrscheinlich aufgrund des falschen
Variablentypen. Ich habe schon diverse type casts ausprobiert, bin aber
nicht zum Ziel gekommen. Die Variable, welche ich nutzen müsste, ist wie
folgt definiert:
char buf1[24];

Die Fehlermeldungen beim Make stehen unten einkopiert.
Weiss jemand mit entsprechenden c Kenntnissen Bescheid, wie ich den
richtigen type-cast für UDP_DIRECT_SEND machen kann?
Leider lässt sich das für mich im Quellcode nicht wirklich erkennen. Im
Quellcode sieht es so aus, als wenn letztlich mit PSTR auf den Parameter
zugegriffen wird.

Besten Gruß.

Tjareson

avr-gcc -Wall -W -Wno-unused-parameter -Wno-sign-compare
-Wno-char-subscripts -g -Os -std=gnu99 -fdata-sections
-ffunction-sections -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -mcall-prologues -fshort-enums -fno-strict-aliasing
-Iprotocols/usb/usbdrv -Iprotocols/usb -DAVR_BUILD -DF_CPU=16000000UL
-mmcu=atmega1284p -I. -c -o control6/control6.o control6/control6.c
control6/control6.c: In function ‘action_thread_cmdloop’:
control6/control6.c:158:3: warning: variable ‘PT_YIELD_FLAG’ set but not
used [-Wunused-but-set-variable]
control6/control6.c: In function ‘action_thread_sendloop’:
control6/control6.c:222:5: error: invalid initializer
control6/control6.c:222:5: warning: pointer targets in passing argument
1 of ‘strcpy_P’ differ in signedness [-Wpointer-sign]
In file included from control6/control6.c:3:0:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h:1047:14:
note: expected ‘char *’ but argument is of type ‘u8_t *’
control6/control6.c:223:3: warning: pointer targets in passing argument
1 of ‘strlen’ differ in signedness [-Wpointer-sign]
In file included from ./hardware/adc/kty/kty81.h:21:0,
from control6/control6.c:9:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/string.h:133:15: note:
expected ‘const char *’ but argument is of type ‘u8_t *’
control6/control6.c:249:3: warning: pointer targets in passing argument
1 of ‘strcpy_P’ differ in signedness [-Wpointer-sign]
In file included from control6/control6.c:3:0:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h:1047:14:
note: expected ‘char *’ but argument is of type ‘u8_t *’
control6/control6.c:250:3: warning: pointer targets in passing argument
1 of ‘strlen’ differ in signedness [-Wpointer-sign]
In file included from ./hardware/adc/kty/kty81.h:21:0,
from control6/control6.c:9:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/string.h:133:15: note:
expected ‘const char *’ but argument is of type ‘u8_t *’
control6/control6.c:271:3: warning: pointer targets in passing argument
1 of ‘strcpy_P’ differ in signedness [-Wpointer-sign]
In file included from control6/control6.c:3:0:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h:1047:14:
note: expected ‘char *’ but argument is of type ‘u8_t *’
control6/control6.c:272:3: warning: pointer targets in passing argument
1 of ‘strlen’ differ in signedness [-Wpointer-sign]
In file included from ./hardware/adc/kty/kty81.h:21:0,
from control6/control6.c:9:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/string.h:133:15: note:
expected ‘const char *’ but argument is of type ‘u8_t *’
control6/control6.c:293:3: warning: pointer targets in passing argument
1 of ‘strcpy_P’ differ in signedness [-Wpointer-sign]
In file included from control6/control6.c:3:0:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h:1047:14:
note: expected ‘char *’ but argument is of type ‘u8_t *’
control6/control6.c:294:3: warning: pointer targets in passing argument
1 of ‘strlen’ differ in signedness [-Wpointer-sign]
In file included from ./hardware/adc/kty/kty81.h:21:0,
from control6/control6.c:9:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/string.h:133:15: note:
expected ‘const char *’ but argument is of type ‘u8_t *’
control6/control6.c: In function ‘action_thread_keepalive’:
control6/control6.c:324:3: warning: pointer targets in passing argument
1 of ‘strcpy_P’ differ in signedness [-Wpointer-sign]
In file included from control6/control6.c:3:0:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/avr/pgmspace.h:1047:14:
note: expected ‘char *’ but argument is of type ‘u8_t *’
control6/control6.c:325:3: warning: pointer targets in passing argument
1 of ‘strlen’ differ in signedness [-Wpointer-sign]
In file included from ./hardware/adc/kty/kty81.h:21:0,
from control6/control6.c:9:
/usr/lib/gcc/avr/4.7.2/../../../avr/include/string.h:133:15: note:
expected ‘const char *’ but argument is of type ‘u8_t *’
make: *** [control6/control6.o] Fehler 1

e***@users.sourceforge.net

2015-03-25 18:21:12 UTC

Permalink

Hallo,

Post by tjareson
ich habe ein Problem mit UDP_DIRECT_SEND im control6 scripting,
vermutlich mit type casting.
Wenn ich im control6-Script mit
UDP_DIRECT_SEND(192.168.1.5, 2701, 2701, "Hello world.");
sende, funktioniert es.
Möchte ich allerdings den string durch eine Variable ersetzen,
bekomme ich beim Übersetzen diverse Fehler wahrscheinlich aufgrund
des falschen Variablentypen. Ich habe schon diverse type casts
ausprobiert, bin aber nicht zum Ziel gekommen. Die Variable, welche
char buf1[24];

Schau einfach in den Quellcode 45_udp.m4:

Der Aufruf ist
UDP_DIRECT_SEND(ip, lport, rport, text, ...)
wobei Text der Formatierungsstring ist, der an sprintf_P weitergereicht
wird, und die drei Punkte die Variablen/Werte für sprintf_P.

tjareson

2015-03-26 06:54:01 UTC

Permalink

sprintf war der Hinweis, der mir fehlte, Danke.

Mit UDP_DIRECT_SEND(192.168.0.1.5, 2701, 2701, "%s", buf1) funktioniert es.

Noch kurz zur IP-Adresse
In control6.c wird ja die IP Adresse irgendwie mit uip_ipaddr(&ip, 192,
168, 1, 5); zusammengebaut.
Um das auch dynamisch zu machen habe ich mir jetzt im control6 script
folgendes Konstrukt gebaut:

int srvadr1=192;
int srvadr2=168;
int srvadr3=1;
int srvadr4=5;
...
UDP_DIRECT_SEND(srvadr1.srvadr2.srvadr3.srvadr4, 2701, 2701, "%s", buf1)

womit später in der uip_ipaddr Anweisung diese Variablen anstatt einer
festen IP-Adresse auftauchen. Das funktioniert auch. Ist das so gedacht
oder lässt sich das auch irgendwie anders lösen?
srvadr1.srvadr2.... als Parameter sieht irgendwie merkwürdig aus...

Beste Grüße.
Tjareson

Post by tjareson
Hallo,

Der Aufruf ist
UDP_DIRECT_SEND(ip, lport, rport, text, ...)
wobei Text der Formatierungsstring ist, der an sprintf_P weitergereicht
wird, und die drei Punkte die Variablen/Werte für sprintf_P.

e***@users.sourceforge.net

2015-03-26 17:42:07 UTC

Permalink

Hallo,

Post by tjareson
sprintf war der Hinweis, der mir fehlte, Danke.
Mit UDP_DIRECT_SEND(192.168.0.1.5, 2701, 2701, "%s", buf1) funktioniert es.

den Umweg über buf1 braucht es nicht, wenn du UDP_DIRECT_SEND direkt
den String formatieren lässt.

Post by tjareson
Noch kurz zur IP-Adresse
In control6.c wird ja die IP Adresse irgendwie mit uip_ipaddr(&ip,
192, 168, 1, 5); zusammengebaut.
Um das auch dynamisch zu machen habe ich mir jetzt im control6
int srvadr1=192;
int srvadr2=168;
int srvadr3=1;
int srvadr4=5;
...
UDP_DIRECT_SEND(srvadr1.srvadr2.srvadr3.srvadr4, 2701, 2701, "%s", buf1)

Man kann in control6-Skripten auch direkt C-Anweisungen schreiben.
In Deinem Fall halte ich es für sinnvoll, statt UDP_DIRECT_SEND
den C-Code, der dahinter steckt, direkt hinzuschreiben. Erspart
ganz nebenbei auch die Verrenkung mit der IP-Adresse und dem String.
Siehe control6/lang.d/45_udp.m4

Tjareson

2015-03-28 05:41:44 UTC

Permalink

Sind in dem Zusammenhang mit UDP_DIRECT_SEND eigentlich Probleme mit
broadcast bekannt bzw. hat das schon mal jemand genutzt?

Ich steuere mit ethersex eine Kombination aus seriellem Drucker und
RFID-Reader an und wollte, sobald per dhcp eine IP-Adresse zugewiesen
ist, einen broadcast z.B. mit der eigenen IP als Inhalt versenden mit
UDP_DIRECT_SEND an x.y.z.255 , damit die Anwendung (läuft dauerhaft auf
einem Server), die das device steuern soll, ethersex findet.

Das funktioniert auch prinzipiell, allerdings hört ethersex überhaupt
nicht mehr auf mit dem Senden und ich verstehe nicht so ganz warum. (man
sieht an der Netzwerkbuchse, dass beide LED nach broadcast dauerhaft
eingeschaltet sind)

Im control6 sollte nach folgender Mimik sichergestellt sein, dass auch
nur einmal pro Minute der broadcast versendet wird. (die Anwendung die
darauf hört schaltet den broadcast dann mit entsprechendem ecmd c6 set
von populate_on wieder ab, sobald sie einmal die IP adresse von ethersex
per broadcast erhalten hat)

...
THREAD(populate)
if ((populate_do==1) && (populate_on==1))
{
populate_do=0;
uip_gethostaddr(&hostaddr);
clientadr0=hostaddr[0] & 0xFF;
clientadr1=hostaddr[0] >> 8;
clientadr2=hostaddr[1] & 0xFF;
clientadr3=hostaddr[1] >> 8;
UDP_DIRECT_SEND( clientadr0.clientadr1.clientadr2.255 , 2701, 2701,
"Hello world... \n")
}
THREAD_END(populate)
...
ON ONCE CLOCK_SEC == 0 DO populate_do=1; END

In den ersten 2-3 Minuten ist noch eine Sendepause zu erkennen, aber
dann wird irgendwann durchgehend gesendet. Ausserdem dauert das Senden
eines Broadcasts irgendwie viel zu lange.

Irgendeine Idee, was da der Denkfehler ist? Funktioniert broadcast auf
ethersex anders? Prinzipiell könnte in clientadr0..3 am Anfang noch Müll
drinstehen, solange bis per dhcp eine IP da ist. Aber da ja letztlich
schon Daten versendet werden, scheint mir das kein Problem zu sein. (mit
nc -ulp 2701 kann ich die Meldung von ethersex auch empfangen)

Besten Gruß.
Tjareson

Post by tjareson
Hallo,

Post by tjareson
sprintf war der Hinweis, der mir fehlte, Danke.
Mit UDP_DIRECT_SEND(192.168.0.1.5, 2701, 2701, "%s", buf1) funktioniert es.

den Umweg über buf1 braucht es nicht, wenn du UDP_DIRECT_SEND direkt
den String formatieren lässt.