44net

44net@mailman.ampr.org

3198 discussions

Re: [44net] mailing list security
by Rob Janssen 02 Jun '17

02 Jun '17

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

2 1

Map notification for generic systems.
by Marius Petrescu 02 Jun '17

02 Jun '17

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

5 7

amprgw changeover schedule
by Brian Kantor 02 Jun '17

02 Jun '17

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

1 0

mailing list format
by Brian Kantor 01 Jun '17

01 Jun '17

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

2 1

Re: [44net] mailing list security
by Steve L 01 Jun '17

01 Jun '17

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.

4 3

Re: [44net] ampr-ripd special experimental release 2.2
by Marius Petrescu 01 Jun '17

01 Jun '17

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 >> >> >>

5 11

Re: [44net] Gateways errors at amprgate
by lleachii＠aol.com 31 May '17

31 May '17

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:

1 0

Re: [44net] Gateways errors at amprgate
by Brian Kantor 31 May '17

31 May '17

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

1 0

Re: [44net] Gateways errors at amprgate
by lleachii＠aol.com 31 May '17

31 May '17

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 ----- 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 16:38 Everything is fine here as far as I can see. I don't know why you got traffic for 44.62.1.x when you're not the gateway for it. The route table has the proper route in it. Nor do I know why you're having intermittent connectivity. The cross-country link from Los Angeles to Washington doesn't seem to be dropping packets. And I've been at lunch so I wasn't fiddling with the router. - Brian On Wed, May 31, 2017 at 04:14:37PM -0400, lleachii--- via 44Net wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Brian, > > Is everything OK at AMPRGW, I just received some VERY odd traffic (and I've > been having interment connectivity): > > > 2017-05-31 14:59:57.803 0.000 TCP 104.236.151.76:48212 -> > 44.62.1.10:143 1 40 1 > 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.14:22 1 48 1 > 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.12:22 1 48 1 > 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.10:22 1 48 1 > 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.9:22 1 48 1 > 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.11:22 1 48 1 > 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 -> > 44.62.1.13:22 1 48 1 > 2017-05-31 15:00:36.520 0.000 TCP 213.32.7.73:44191 -> > 44.62.1.10:22 1 40 1 > 2017-05-31 15:02:45.210 0.000 TCP 181.113.163.24:59150 -> > 44.62.1.10:22 1 40 1 > 2017-05-31 15:03:08.697 0.000 TCP 186.134.5.194:51377 -> > 44.62.1.12:22 1 40 1 > 2017-05-31 15:03:26.190 0.000 TCP 104.236.151.76:48281 -> > 44.62.1.12:143 1 40 1 > 2017-05-31 15:03:28.222 0.000 TCP 117.9.45.58:47360 -> > 44.62.1.11:22 1 40 1 > 2017-05-31 15:03:31.438 6.996 TCP 187.199.54.149:43075 -> > 44.62.1.9:81 4 240 1 > > > 73, > > > - Lynwood > KB3VWG > > >44.62.1.8 / 29 Southern Virginia Gateway AB4MW > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

AMPR Gateway error
by R P 31 May '17

31 May '17

Brian May you explain this error line apear in the errors of the gateways ? 169.228.34.84 44.0.0.1 702 [18] dropped: multicast inner destination address

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net