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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
Hello All,
I've just got my first allocation and tunneling setup, and now would like to have public traffic routed to my allocation, which I have read requires DNS records to be made for the IPs to be routed.
I'm not seeing any obvious way to contact my coordinator in the portal.
How is this usually accomplished?
Thanks!
Eric, W8ETB
Is anyone else having problems connecting to other stations?
I have about a dozen forwarding partners and until a few minutes
ago none were connecting. I still only have 3 connecting now
and the rest are all unreachable. I have rebooted my JNOS and
it is still occurring.
--
Charles J. Hargrove - N2NOV
NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Nets 449.025/123.0 PL
ARnewsline Broadcast Mon. @ 8:00PM
NYC-ARECS Weekly Net Mon. @ 8:30PM
http://www.nyc-arecs.org…
[View More]NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM
on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32
"Information is the oxygen of the modern age. It seeps through the walls
topped
by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying
(The work praises the man.)
"No matter how big and powerful government gets, and the many services it
provides, it can never take the place of volunteers." - Ronald Reagan
[View Less]
You did what? This is not very nice!
I Really dont like this! Making everyone blind for a pressing security
issue is not the fix! Please undo this, censorship is not right.
Adding to that, i use shodan and its alternatives more than frequently,
and i would like to be ablo to doublecheck my own infra via those web
services.
M.v.g.
Pb0fh Roy van Dongen
On 25 May 2018, at 11:07, Rob Janssen <pe1chl(a)amsat.org> wrote:
>> I'm not at all sure that Shodan is blocked on amprgw. …
[View More]There are
>> more than 2,000 IP addresses that are blocked, with more being added
>> from time to time, plus there are a number of tcp and udp destination
>> ports that are blocked from all IP addresses, but there's no way
>> to be sure that these lists include all Shodan and other scanners.
>
> I have blocked some known Shodan addresses and subnets, and indeed even
> a hoster that is known to be a cesspool and accomodates Shodan and the
> likes:
>
> 66.240.192.138 # census8.shodan.io
> 66.240.205.34 # malware-hunter.census.shodan.io
> 66.240.219.146 # burger.census.shodan.io
> 66.240.236.119 # census6.shodan.io
> 71.6.128.0/17 # cesspool! (including shodan.io, project sonar)
> 80.82.64.0/20 # ECATEL/QUASI (including shodan.io 80.82.77.139)
> 82.221.105.6 # census10.shodan.io
> 82.221.105.7 # census11.shodan.io
> 89.248.160.0/20 # ECATEL/QUASI (incl shodan.io 89.248.167.131
> 89.248.172.16)
> 93.174.88.0/21 # ECATEL/QUASI (incl shodan.io 93.174.95.106)
> 94.102.48.0/20 # ECATEL/QUASI (incl shodan.io 94.102.49.190
> 94.102.49.193)
> 107.6.151.192 # security.census.shodan.io
> 107.6.151.193 # security.census.shodan.io
> 107.6.151.194 # security.census.shodan.io
> 107.6.151.195 # security.census.shodan.io
> 185.163.109.66 # goldfish.census.shodan.io
> 185.181.102.18 # turtle.census.shodan.io
> 198.20.69.72/29 # shodan.io
> 198.20.69.96/29 # shodan.io
> 198.20.70.112/29 # shodan.io
> 198.20.87.96/29 # shodan.io
> 198.20.99.128/29 # shodan.io
>
> (of course many others, these are just the shodan.io entries)
>
> I also have some iptables rules that capture TCP SYN to addresses that
> are not registered in DNS and
> forwards them to an nflog socket to be picked up by some scripts that
> finds those that are repeat
> offenders. Those are logged as candidates for blocking. But I don't
> bother to block everything,
> I run reverse-DNS on them to see if it has some signature patterns like
> "research", "scan" etc or
> one of the known names like shodan.io stretchoid.com etc.
> And irregularly I just sort the entire list and glance over it to see
> if there are clusters of
> addresses and do a whois to see if they belong to some common network.
> Names like DigitalOcean
> pop up quite regularly but of course they are just cloud hosters that
> could also host bonafide
> services.
>
> Rob
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
[View Less]
> especially before Shodan was
> blocked on AMPR...
Has Shodan been blocked on amprgw or have they been convinced to stop scanning AMPRnet?
There are still various agressive scanners active from internet, and I have some scripts
to automatically add them to a blocklist but it still is an ever increasing load on the network.
For example, "stretchoid.com" is an agressive scanner that changes addresses all the time
(but does keep reverse-DNS records on their virtual servers so easy to …
[View More]identify).
They do have an opt-out form but it is a NOP.
(I have completed it 3 times at 1-month intervals but no reply and no effect on the scanning...
maybe Brian should try it as he is listed in the whois as the owner of NET44)
Of course there are others, like security.ipip.net and binaryedge.ninja. Plus the many
many other scanners, "researchers", etc.
Rob
[View Less]
> I'm not at all sure that Shodan is blocked on amprgw. There are
> more than 2,000 IP addresses that are blocked, with more being added
> from time to time, plus there are a number of tcp and udp destination
> ports that are blocked from all IP addresses, but there's no way
> to be sure that these lists include all Shodan and other scanners.
I have blocked some known Shodan addresses and subnets, and indeed even
a hoster that is known to be a cesspool and accomodates Shodan …
[View More]and the likes:
66.240.192.138 # census8.shodan.io
66.240.205.34 # malware-hunter.census.shodan.io
66.240.219.146 # burger.census.shodan.io
66.240.236.119 # census6.shodan.io
71.6.128.0/17 # cesspool! (including shodan.io, project sonar)
80.82.64.0/20 # ECATEL/QUASI (including shodan.io 80.82.77.139)
82.221.105.6 # census10.shodan.io
82.221.105.7 # census11.shodan.io
89.248.160.0/20 # ECATEL/QUASI (incl shodan.io 89.248.167.131 89.248.172.16)
93.174.88.0/21 # ECATEL/QUASI (incl shodan.io 93.174.95.106)
94.102.48.0/20 # ECATEL/QUASI (incl shodan.io 94.102.49.190 94.102.49.193)
107.6.151.192 # security.census.shodan.io
107.6.151.193 # security.census.shodan.io
107.6.151.194 # security.census.shodan.io
107.6.151.195 # security.census.shodan.io
185.163.109.66 # goldfish.census.shodan.io
185.181.102.18 # turtle.census.shodan.io
198.20.69.72/29 # shodan.io
198.20.69.96/29 # shodan.io
198.20.70.112/29 # shodan.io
198.20.87.96/29 # shodan.io
198.20.99.128/29 # shodan.io
(of course many others, these are just the shodan.io entries)
I also have some iptables rules that capture TCP SYN to addresses that are not registered in DNS and
forwards them to an nflog socket to be picked up by some scripts that finds those that are repeat
offenders. Those are logged as candidates for blocking. But I don't bother to block everything,
I run reverse-DNS on them to see if it has some signature patterns like "research", "scan" etc or
one of the known names like shodan.io stretchoid.com etc.
And irregularly I just sort the entire list and glance over it to see if there are clusters of
addresses and do a whois to see if they belong to some common network. Names like DigitalOcean
pop up quite regularly but of course they are just cloud hosters that could also host bonafide
services.
Rob
[View Less]
