it's there the cut didnt get it

/tool fetch mode=http url="http://44.182.21.1:59001/mikrotik?id=wa4zlw@FN20bk" keep-result=no

On 6/1/2017 8:10 AM, Marius Petrescu wrote:

No, it fails because you forgot the '?' between 'mikrotik' and 'id'

On 01.06.2017 15:09, Leon Zetekoff wrote:

...

Hi Marius...fails here I think because AMPRnet is not a default route/interface?

[admin@core100.wa4zlw.homedns.org] > /tool fetch mode=http url="http://44.182.21.1:59001/mikrotikid=wa4zlw@FN20bk" keep-result=no status: failed

failure: closing connection: <404 Not Found> 44.182.21.1:59001 (5) [admin@core100.wa4zlw.homedns.org] >

leon

On 6/1/2017 7:56 AM, Marius Petrescu wrote:

...

/tool fetch mode=http url="http://44.182.21.1:59001/mikrotik?id=yo2loj@kn05os" keep-result=no

---

AVG logo http://www.avg.com/internet-security

This email has been checked for viruses by AVG antivirus software. www.avg.com http://www.avg.com/internet-security

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--- This email has been checked for viruses by AVG. http://www.avg.com

The map itself is standalone (you just need to get the html file and the java scripts that are loaded at startup - see in 'view source').

The JSON event source is a dedicated daemon which I have written for this purpose.

Marius, YO2LOJ

On 01.06.2017 15:17, Kathie Dart wrote:

(Please trim inclusions from previous messages) _______________________________________________ That's so cool. I'd like to use such a map for other things, is this particular one standalone-able? Cheers

Ok, since it seems taht there is already some spoofing going on, I will restrict the senders for mikrotik routers to 44net sources only.

This should have no effect on legitimate users.

Marius, YO2LOJ

On 01.06.2017 16:08, Marius Petrescu wrote:

(Please trim inclusions from previous messages) _______________________________________________ Guys, when adding the script to the routers, please edit the callsign and locator BEFORE running it.

Unless there are valid nodes with non-existing callsigns on invalid QTH locators registernig from the internet, then maybe.

On 01.06.2017 17:29, Brian Kantor wrote:

(Please trim inclusions from previous messages) _______________________________________________ I'm more inclined to think it's misconfigured routers rather than deliberate spoofing, but you may be right.

• Brian

On Thu, Jun 01, 2017 at 04:16:04PM +0300, Marius Petrescu wrote:

...

Ok, since it seems taht there is already some spoofing going on, I will restrict the senders for mikrotik routers to 44net sources only.

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

But how come that this list leak to non ham persons that the know what to do ?

________________________________

You must be right. Too bad, I like to think better of people. - Brian

I assume it's because some number of the subscribers to the mailing list are bots or untrustworthy people. Or maybe they're archive services or remailers that make the list available to the general public.

Consider the fact that every time I post a URL that points at a server whose logs I can watch, there is an immediate attempt to fetch that URL. It happens too quickly to be real people, it's got to be a bot of some sort. And there isn't just one of them, there are typically three or four from different IP addresses in the first few minutes. - Brian

On Thu, Jun 01, 2017 at 06:31:08PM +0300, Marius Petrescu wrote:

Now this is really a good question. On 01.06.2017 18:16, R P wrote:

...

But how come that this list leak to non ham persons that the know what to do ?

Mailman doesn't have CAPTCHA. It does use a challenge; when you request to subscribe, it mails you a key that you have to mail back, but I know that bot subscribers have already automated that. It helps keep some undeliverable addresses from subscribing, but it's not designed as a real security measure.

I've considered using a different mailing list manager, but I haven't found one that was superior enough to make it worth the hassle to transfer the large list of existing subscribers. And I guarantee that if people had to resubscribe, a lot of them wouldn't.

No, I just assume that anything posted to the list becomes public knowledge. The only solution is not to post secrets. - Brian

On Thu, Jun 01, 2017 at 10:55:04AM -0700, David Ranch wrote:

• high impact: delete all users from the email list and make everyone

re-subscribe. I don't know how effect this will be unless the Postman system can enable something like a captcha challenge system to keep out bots. People who don't keep up with their email would loose some of the postings

Thanks, Steve. That looks useful, but will take some effort to adapt it to FreeBSD which is what the mailing list host is running (not Linux). - Brian

On Thu, Jun 01, 2017 at 03:27:13PM -0500, Steve K0STK wrote:

Here's a patch for adding reCaptcha support to Mailman: https://www.dragonsreach.it/2014/05/03/adding-recaptcha-support-to-mailman/

The FreeBSD ports package 'py-recaptcha' says that you need to obtain a key from http://recaptcha.net/api/getkey. Unfortunately, that URL and shorter variations on it just return 404. That domain is served by Google but appears to be empty. There's certainly nothing there anymore. Apparently you now have to sign up with Google and get a private key from the Google developers program.

Why is nothing simple anymore? - Brian

On Thu, Jun 01, 2017 at 03:27:13PM -0500, Steve K0STK wrote:

Here's a patch for adding reCaptcha support to Mailman: https://www.dragonsreach.it/2014/05/03/adding-recaptcha-support-to-mailman/

Hi Michael,

On 02.06.2017 23:13, Michael Fox - N6MEF wrote:

Marius,

A few questions about the dynamic map:

1. How long does it take for an entry to appear on the map? I manually

entered the following URL into a browser (three times) but I don't see it on the map (CA, USA). http://44.182.21.1:59001/generic?id=n6mef@cm97aj

The entry appear immediately on the map (on reception, the daemon sends out a JSON event stream element to all listeners ASAP - less the 1 sec) .

2. How long does an entry remain on the map after the last time you heard

from it? Dynamic is nice, but if a gateway is down for maintenance, it would still be good to know that it exists.

For the moment it stays on the map indefinitely (I still have to figure out how to delete a marker). In the internal buffer of the daemon it will be there for 1 hour and will be available on refresh for that time. But this can be changed anytime since it is just a define in the code.

3. Follow-up to #2: Most similar applications (winlink2K, irlp) use the

colors or status tables to represent status (green=up, red=down, etc.). That would be more useful to me as a sysadmin than how the information was learned (which I realize is useful to you). For example, colors could represent age of information: green="heard from within the last hour", yellow="... within the last day", red="... within the last week". After that, if falls off the map. That would give us a hint as to whether the machine is more likely to be temporarily or permanently down. Would you consider?

This is just a starting point. We can do whatever we want. But again, to change the colors, I need to find out how to modify existing map markers. Still ToDo.

4. Have you given any thought to Brian's suggestion that the input be in

the DNS LOC record format, rather than callsign@maidenhead? It seems like a good way to use your infrastructure while preparing for integration with more "standard" tools later.

As I said, it is our project, we can do whatever we need. I just wanted a quick start, to keep the momentum. Next steps are wide open from my side.