Hello,
I've put my Freebox in bridge mode and I begin to configure my microtik
router.
In bridge mode the option "multiposte TV" dosen't seem to work.
I think, I must "forward" some ports but which ?
Any idea ?
--
F1sxo
I have updated the elproxy.tar.gz file on my webserver: http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz
There was a race condition in the code that ultimately resulted in some proxies being stuck in the authentication
phase. It can be recognized by the debug info in square brackets appearing in the QSO column
of the /dev/shm/elproxy status file, like [st4 fd20 t0]
It is normal when such info briefly appears, but when it remains for a few seconds that proxy is stuck
into a BUSY state without an actual user. This can be checked using:
fgrep [st /dev/shm/elproxy
and when output appears, repeat it 30 seconds or so later and see if it is still there.
On our PI9NOZ proxies, after running 230 proxies for over two months, 6 proxies were stuck.
Hard-to-locate problem...
Finally, Jann Traschewski has found this bug! Thanks for debugging it and mailing me the patch!
The bookkeeping of the usage of filedescriptors was somehow getting out of sync (that I already knew...)
and he found it happened in the error handling of TCP connections to the directory server.
I had been looking in this area for quite some time, but somehow forgot about the fd used for that
purpose and only traced all the paths of open/close of the fd used for the actual user connection...
To update, re-fetch the elproxy.tar.gz and unpack (only elproxy.c is changed), re-run make and re-start
the program (I run it from its /home/elproxy home directory, when you put it in /usr/local/bin or similar
of course remember to move it there again)
This is the patchfile of the change, you can apply that using "patch --ignore-whitespace elproxy.c" instead of
downloading it again.
--- elproxy.c.orig 2016-11-24 10:02:22.000000000 +0100
+++ elproxy.c 2018-06-26 23:43:22.908000000 +0200
@@ -1428,6 +1428,7 @@
buf[0] = 1;
close(fd);
+ pr->tcp_fd = 0;
} else {
ds->proxy = pr;
ds->timeout = now + ADDR_SOCKET_TIMEOUT;
@@ -1638,6 +1639,7 @@
close(fd);
unregisterfd(fd);
+ pr->tcp_fd = 0;
if (pr->state == BUSY)
proxy_message(pr,PROXY_MSG_TCP_CLOSE,0,NULL,0);
Again thanks to Jann for finding this!
Rob
Hi,
I submitted a request for a netblock under 44.131.0.0/16 (United Kingdom)
over a month ago. I've not heard anything back from the coordinator
despite following up with emails.
Is there a way we can look to proceed with this request at all?
Thanks,
Alistair
Just an update to let everyone know how things are progressing.
Of the allocation of 44.190.8.0/24 that I was allocated a while back, I
have allocated a block of 150 IPs for Echolink proxies, which have been
operational for around a month. The server that the proxies run on had
some pre-existing Echolink proxies and conference servers. I migrated
the existing (private) proxies to the new binary, which was seamless.
I wasn't sure whether the proxy binary could coexist with the existing
conferences, because the proxy binds UDP ports 0.0.0.0:5198 and
0.0.0.0:5199, but in practice, this works fine.
On the weekend, I added a new Echolink conference to the server. This
conference is the first to use one of the new 44net IP addresses
(outside the range the proxies use). Again, everything is working
well. The new allocation is getting a bit of use here. And I can
confirm that running proxies with the binary alongside conference
servers works well. You just have to ensure you use different IP
addresses for each in their configs. :) I have allocated a block of 10
IPs for the integrated IRLP/Echolink conferences. Any new conferences
will be using these IPs, while legacy ones will remain where they are,
unless I need to renumber for some reason, in which case, they will
simply be moved to their reserved 44net address. There's a couple of
extra items that will be allocated new IPs in this instance. Also, the
IRLP side may end up on 44net, in the instance of a renumber. I may
simply drop the /28 altogether.
And I'm now very happy, the old juggling to find IPs (I was fully
utilising a /28 and starting to bump proxies that weren't getting used)
is no longer necessary. :)
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
