Does anyone know if there is on the web place that i can give address and a protocol / port and it will send data according to the protocol / port i want ?
Or has anyone the capability to do so ?
I want to tests some firewall rules that i made ...
Thanks Forward
Ronen - 4Z4ZQ
I think an adequate explanation for the URL-fetch mystery is that some
people
run a virus scanner or have their e-mail delivered to a mailservice that
does
scanning, and this scanner fetches all URLs in the message to check if
they
point to malware...
No amount of validation of the subscribers will solve that problem.
The only thing you can do is obfuscate the links, but that is
incovenient for
the reader.
Similar problem: whenever you download a program, a second fetch is done
by
Microsoft/Google/Apple/whatever your favorite vendor to check what it
is.
I have seen this several times on a download server we run at work.
Rob
I also added a notification method for generic systems (they will appear
as grey dots).
Schedule a 5 min cron job (or whatever is needed to get it done) with
the following instruction:
wget -O /dev/null http://44.182.21.1:59001/generic?id=test@AA00AA
Replace test@AA00AA with your gateway_call@qth_locator
This also will only work from 44net sources only.
Have fun,
Marius, YO2LOJ
On Monday, around 0930 Pacific (1630 UTC), we'll be moving the inbound
route for 44.0.0.0/8 from old amprgw to new.
Shortly after, as soon as it's confirmed working, I'll turn off the RIP
sender on old amprgw and you should stop seeing any more traffic from
169.228.66.251 (although the machine will stay up so we can archive it
before turning it off). You'll continue to get RIP from 169.228.34.84,
and that's where encap traffic will come from for the foreseeable future.
This changeover will have the effect of moving the gw.ampr.org web site
from old amprgw to new amprgw, so the graphs, charts, and tables will
change to content as seen from new amprgw's view, thus we'll lose a few
days history.
Encap packets sent to old amprgw after the changeover will not be
forwarded, as the machine will have no further routing to network 44.
Gateways which have not updated their outgoing encap path will be
unreachable.
Everything else should just work.
Wish us all good luck!
- Brian
I got tired of seeing the 'please trim inclusions' header line
on each message, and I don't think it was doing any good being
there, and there were some negative comments about it, so I
deleted it. If I did it right, this message won't have it.
- Brian
Someone could create an email list only available on 44net, however I
doubt there would be much activity on such a list.
The biggest thing I wish this list had was a way to search the
archives. I almost sometimes wish it was crawled by google etc. But
at the same time that just welcomes more of the unwanted.
David,
For the purpose of placing devices on a world map a 6-position
gridsquare should be minimal and enough.
People wanting to send a more exact position can do it, but a 4-position
grid square is IMHO not sufficient. So for the moment, the receiving
side truncates the locator to 6 positions and converts that one to a
lon/lat value (the center of the subsquare).
Let me get this map running first and we will see where we go from there.
On 31.05.2017 03:58, David Ranch wrote:
> Hey Marius,
>
> If you are going to use grid squares instead of Lat/Long or GPS
> coordinates, could you maybe support addition resolution on the Grid
> square? For example, my high resolution grid square is CM97ai02ak
> <http://www.dxmaps.com/callbook/gmap.php> . Most people might only
> like to give say CM97, most people will give CM97ai, maybe others
> might give CM97ai02 .
>
> --David
>
>
> On 05/30/2017 01:43 PM, Marius Petrescu wrote:
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>> Hello everyone,
>>
>> For the proposed experiment on creating a interactive dynamic map of
>> the ampr-ripd systems, I created a special version (2.2).
>>
>> The daemon accepts a new parameter -L <string>. If this string is
>> defined, it will be sent every 5 minutes to my gateway 44.182.21.1
>> via UDP to port 59001.
>>
>> The format I will use is plain and simple gwcallsign@locator, case
>> insensitive e.g. -L yo2loj@kn05or.
>>
>> If we will ned somehow more data, the string can be replaced wit
>> anything, it is just sent as it is and will be parsed by the backend.
>>
>> For the moment there is only a simple listener monitoring that port,
>> and I am working on the server and interactive map which will be
>> available at
>>
>> http://yo2tm.ampr.org/ampr-map/
>>
>>
>> For those that do not want to participate, there is no need to upgrade.
>>
>> And even if you do, not setting the -L parameter will not send any
>> data, the result being the same behavior like 2.1.1.
>>
>>
>> Download:
>>
>> http://www.yo2loj.ro/hamprojects/ampr-ripd-2.2.tgz
>>
>> http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.2.tgz
>>
>>
>> Have fun,
>>
>> Marius, YO2LOJ
>>
>>
>>
Brian,
That seems to have fixed it!
Thanks and 73,
-KB3VWG
----- Reply message -----
From: "Brian Kantor" <Brian(a)UCSD.Edu>
To: "lleachii--- via 44Net" <44net(a)hamradio.ucsd.edu>
Cc: <lleachii(a)aol.com>
Subject: [44net] Gateways errors at amprgate
Date: Wed, May 31, 2017 17:31
Well, damn. I restarted the ipip daemon and they went away.
Looks like it's time to debug the routing table maintenance routing.
The log shows a new route being added but it appears to have been
loaded on top of your route, thus misdirecting traffic. I'll work
on it. Sorry for the bug.
- Brian
On Wed, May 31, 2017 at 05:14:13PM -0400, lleachii--- via 44Net wrote:
> Odd...they're still being received (Eastern Daylight Time). Just a few
> moments ago:
Amprgw ignores the TOS field. I don't see how that would affect
anything here.
- Brian
On Wed, May 31, 2017 at 04:47:44PM -0400, lleachii(a)aol.com wrote:
> Brian,
> Since I noticed the connection issue, I switched back to ToS 0x00 (Default)...just to be sure.
>
> I can still reach other gateways directly... I'll check to make sure I'm receiving routes.
>
> - KB3VWG
