fixed compile error with overlay_route.c

This commit is contained in:
gardners 2011-08-12 08:15:26 +02:00
parent 2f0307a08d
commit d6ec3f32c1
3 changed files with 18 additions and 6 deletions

View File

@ -8,7 +8,7 @@ OBJS= dna.o server.o client.o peers.o ciphers.o responses.o packetformats.o data
HDRS= Makefile mphlr.h
LDFLAGS= -L/Developer/SDKs/MacOSX10.6.sdk/usr/lib
CFLAGS= -I/Developer/SDKs/MacOSX10.6.sdk/usr/include
DEFS= -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DHAVE_LIBC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDIO_H=1 -DHAVE_ERRNO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRING_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_POLL_H=1 -DHAVE_NETDB_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_IFADDRS_H=1 -DHAVE_NET_IF_H
DEFS= -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DHAVE_LIBC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDIO_H=1 -DHAVE_ERRNO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRINGS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRING_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_POLL_H=1 -DHAVE_NETDB_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_IFADDRS_H=1
all: serval.c dna

View File

@ -561,3 +561,6 @@ int overlay_add_selfannouncement();
int overlay_payload_package_fmt1(overlay_payload *p,overlay_buffer *b);
extern int overlay_interface_count;
/* Userland overlay mesh packet codes */
#define OF_SELFANNOUNCE 0x01

View File

@ -7,20 +7,29 @@ int overlay_add_selfannouncement(overlay_buffer *b)
Notices (SON) because they are just single-hop announcments of presence.
Do we really need to push the whole SID (32 bytes), or will just, say,
8 do so that we use a prefix of the SID which is still very hard to forge.
8 do so that we use a prefix of the SID which is still very hard to forge?
XXX A hearer of a self-announcement who has not previously seen the sender might
A hearer of a self-announcement who has not previously seen the sender might
like to get some authentication to prevent naughty people from spoofing routes.
This should be easy enough to do, but will need some thought.
We can do this by having ourselves, the sender, keep track of the last few frames
we have sent, so that we can be asked to sign them. Actually, we won't sign them,
as that is too slow/energy intensive, but we could use a D-H exchange with the neighbour,
performed once to get a shared secret that can be used to feed a stream cipher to
produce some sort of verification.
XXX - But this functionality really needs to move up a level to whole frame composition.
*/
unsigned char c;
if (ob_append_bytes(b,OF_SELFANNOUNCE,sizeof(OF_SELFANNOUNCE)))
c=OF_SELFANNOUNCE;
if (ob_append_bytes(b,&c,1))
return WHY("ob_append_bytes() could not add self-announcement header");
return WHY("Not implemented");
}