i installed your patch .. here some feedback/problems a had
with OpenWRT and gluon i succeeded ... actually testet it on a tplink841n-v9
runs with or without -m (master) for a while (30 min++)
/usr/sbin/alfred -i br-client -b bat0 -m
[my big wonder is , why do these router always only output their own
entry for alfred -r 158 , while there are master .. on debian based
master this is filled up to 290]
on debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3
(2016-01-17) x86_64 GNU/Linux
i got some build errors .. and than after a short while in alfred master
mode ... segmentation fault
(1 or 2 minutes, sometimes only seconds)
this after master announcements and already collecting some 90+ alfred
####### patch stuff
####### wget https://patchwork.open-mesh.org/patch/15944/raw/
patch < tcp.patch
patching file alfred.h
Hunk #1 succeeded at 90 (offset 1 line).
Hunk #2 succeeded at 103 (offset 1 line).
Hunk #3 succeeded at 131 (offset 1 line).
Hunk #4 succeeded at 147 (offset 1 line).
Hunk #5 succeeded at 170 (offset 1 line).
Hunk #6 succeeded at 187 (offset 1 line).
Hunk #7 succeeded at 200 (offset 1 line).
Hunk #8 succeeded at 227 (offset 1 line).
patching file main.c
patching file netsock.c
patching file recv.c
patching file send.c
patching file server.c
patching file unix_sock.c
Hunk #1 succeeded at 229 (offset 7 lines).
Hunk #2 succeeded at 259 (offset 7 lines).
####### build errors
recv.c: In function 'recv_alfred_packet':
recv.c:436:48: warning: passing argument 5 of 'process_alfred_request'
makes pointer from integer without a cast
(struct alfred_request_v0 *)packet, -1);
recv.c:302:12: note: expected 'struct tcp_connection *' but argument is
of type 'int'
static int process_alfred_request(struct globals *globals,
make -C vis all
make: Entering directory '/home/freifunk/alfred/vis'
make: Leaving directory '/home/freifunk/alfred/vis'
make -C gpsd all
make: Entering directory '/home/freifunk/alfred/gpsd'
make: Leaving directory '/home/freifunk/alfred/gpsd'
Apr 22 20:01:06 fffr-spielwiese kernel: [4398895.515177] alfred:
segfault at 2f ip 0000000000406034 sp 00007fff9dc39580 error 6 in
Apr 22 20:02:05 fffr-spielwiese kernel: [4398954.569665] alfred:
segfault at 2f ip 0000000000406034 sp 00007ffc45b97d50 error 6 in
On 27.03.2016 20:37, Hans-Werner Hilse wrote:
Am 2016-03-27 20:26, schrieb Hans-Werner Hilse:
> Changes in v2:
> - non-blocking sending over TCP sockets
This uses non-blocking IO also for sending via TCP.
TCP is chosen when the message size exceeds MAX_UDP_ANSWER (from
alfred.h), which is for now conservatively chosen to fit in bad-case
MTU settings - or if the data request came via TCP (as the same
connection is then used for the reply).
I've run this for a few hours in a test setup with 3x alfred as master
and 30 slaves, with some errors, dups and latency thrown in for good
measure (yay for VDE, virtual distributed ethernet).
The current implementation has a downside: non-blocking TCP sending
for now assembles the full data that is to be sent in a memory buffer,
which will then get sent bit by bit (depending on buffers, network and
the remote side). This is a consequence of the lack of a good way to
guarantee a consistent state of the data store over the time it takes
until the full message stream is completely transmitted to the remote
end (the data store might get modified between beginning and finishing
An alternative approach - and a major redesign of data storage - would
be some kind of log-based approach. I'm not so sure if that really is
warranted for, and in any case, that's quite a different undertaking.
The flag "-t" is still present and will toggle whether alfred will try
to request using TCP at all. This will allow to use a TCP-enabled
alfred in an environment that is not yet fully TCP enabled (this
matters only for the master servers AFAICS).
make the world nicer, please use PGP encryption