[aprssig] A new player (APRS-IS is doing fine, no panic...)

[Heikki Hannikainen]

First, it seems to me that the APRS-IS is doing fine. The spikes are 
currently only doubling the IS stream traffic, which is not a huge 
increase:

https://dl.dropboxusercontent.com/u/37346897/aprsis-spikes.png

That's not an increase in traffic that would hurt the APRS-IS itself today 
in any significant way. No need to panic, the IS appears to be OK.

Luckily, most of the packets in the flood are already getting suppressed 
at the first aprsc server where that client is connected, it's dropping 
some 50-200 duplicate packets per second (according to the normal 
30-second duplicate filtering window):

https://dl.dropboxusercontent.com/u/37346897/aprsis-spikes-dupes.png

You can zoom in to these graphs yourself on some of the core servers for 
example:

1) open up http://sixth.aprs.net:14501/
2) click "Unique packets seen" to plot that as a graph (or some other 
table header which happens to show up in blue)
3) paint area with spikes on graph with the mouse
4) a "Zoom" button appears, click it

At least two of these problematic clients were connected to MYAPRS-1:
http://aprs.myaprs.my:14501/ - there you can see the dropped dupe spikes.

Some clients which read the full feed might get some additional load, for 
sure. aprs.fi is not noticing it much, since its per-srccall rate limiter 
kicks in - effectively that callsign is automatically blacklisted 
temporarily for the duration of the flooding.

It might make sense to implement some sort of automatic per-callsign or 
per-client rate limiter for igate connections in the APRS-IS servers (for 
example, something like, no more than 50 packets/second per srccall), just 
in case some client would accidentally flood the network with unique 
packets at some point. That'd then protect the network automatically 
against this sort of problems (as long as the srccall stays the same). 
Wouldn't need manual intervention or system-wide configuration updates 
when a new problematic client would jump in later.


The fixed version of aprx is already available, Matti fixed it in svn 
revision 566 (4th of March). We'll just now have to kick the problematic 
devices to get them upgraded. There seems to be some language barriers, 
the two stations in question are in Malaysia, and the only reply I got so 
far was very brief ("OH7LZB de YB6HJE 73" - on Facebook...). I'll continue 
on that track.

Seems like the affected devices are mostly D-Link router/wifi-AP soapboxes 
running OpenWRT.

On Mon, 10 Mar 2014, Andrew P.  wrote:

> But do we really have to block _every_ user of the software? Hessu said 
> that there is a fix, so presumably these offending stations haven't 
> upgraded to the fix. Can we block those stations alone until they 
> upgrade? Or block based on a minimum acceptable version number of the 
> software?
>
> In general, does that blocking ability exist in the APRS-IS server code 
> now, or is it a new feature that would have to be added?
>
> Andrew Pavlin, KA2DDO
> author of a client program with blacklisting ability, to wit, YAAC
> ------Original Message------
> From: Jim Duncan
> To: aprssig at tapr.org
> Sent: Mar 10, 2014 10:50 AM
> Subject: Re: [aprssig] A new player
>
>
> Clearly this is a situation which may need the "big hammer" approach. Ban
> all APRX stuff until the programmer responds with a fix and offending
> players have their problem fixed. Plain and simple, you made the contact and
> there was an attitude that it wasn't his problem then that's MORE than ample
> reason to shut down all APRX access. His users will take care of the rest
> when their data isn't going anywhere.
>
> I'd encourage you to do it now, no apologies. Protecting the IS stream has
> to be your first priority for the sake of those who depend upon it.
>
> 73 de Jim, KU0G
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Steve Dimse
> Sent: Monday, March 10, 2014 9:48 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] A new player
>
>> Quite honestly, it seems like the APRS-IS core servers should detect this
> kind of thing and throttle propagation to protect themselves.
>
> It is impossible to predict all the ways programmers could screw up. In the
> 17-odd years of the APRS-IS, no programmer has made a blunder that flooded
> the system the way this one does. The blame does not belong on the APRS-IS,
> it belongs with this programmer, and his attitude after being notified of
> the bug by myself 1.5 months ago. His attitude was essentially the same as
> this same comment. I disagree heartily. This is an aprx bug, and it is up to
> Matti to not just fix the bug, but to contact his users and let them know
> this is a critical update.
>
> But if this continues to be a problem the only answer may be to blacklist
> aprx data. I'd hate to have it come to that, because the losers are the aprx
> users who are innocent in all this.
>
> Steve K4HG
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
>
> Sent from my Verizon Wireless BlackBerry
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>

   - Hessu