[aprssig] A new player

[Ya'akov Sloman]

Hello. This is my first comment here, please take it as naïve and well-intentioned.  At least naïve concerning the technical and social details of APRS-IS.

It seems to me that the problem is not necessarily the particular software but the behavior.  I would expect the fix to this to be a generalized one: mitigate floods of traffic (where "flood" requires a good specification, to be sure).

My first impulse is to make the fix not at the level of the server, but lower, with something like traffic shaping at the OS level.  It seems that one could characterize a misbehaving node, and simply throttle it.  Under normal circumstances, nodes wouldn't even know that there was such a mechanism in place, but if they produced an unexpected burst of traffic, they would find the pipe contrained for the time they were bursting.

This way (or in a way similar to this) the network would be protected from *any* misbehaving node, whatever the reason.

I realize that this is not a trivial solution but it does have the advantage of no or little change to the APRS software while providing a generalized protective mechanism.

As I said, this is a naïve suggestion and my be obviously wrong or unworkable, but I thought I would put it out there.

73,
Ya'akov
N1EWO

On Mar 10, 2014, at 11:15 AM, Georg Lukas <georg at op-co.de> wrote:

> Hi,
> 
> * Jim Duncan <jdbandman at earthlink.net> [2014-03-10 15:52]:
>> 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.
> 
> This is unfortunately far easier to suggest than to implement in the
> field. Matti has issued a fix a week ago in
> http://repo.ham.fi/websvn/wsvn/aprx?rev=566 - now it is the time for the
> users of the affected platform to get busy and update.
> 
> I have a similar situation with APRSdroid, with people still running a
> buggy version of the app that dates back to 2010(!). I have even
> contacted the people I could get the e-mail addresses of about upgrading
> to the fixed version, with little success.
> 
> In February, there still were over 60 active users of the
> three-years-old APRSdroid 0.x, with almost 5% of the active users
> not running the latest version. Short of implementing a built-in
> auto-update mechanism like done by Microsoft, Mozilla or Google, which
> requires a dedicated corporate group to maintain and test new releases,
> it is impossible to get all users to upgrade - and such a mechanism
> would probably fail on the embedded devices aprx is aimed at.
> 
> Besides, if we ban all old and buggy software (and hardware!)
> implementations from APRS, it will become a very calm place.
> 
> 
> 73 de Georg DO1GL
> -- 
> APRSdroid - Open Source APRS Client for Android | http://aprsdroid.org/m
> https://play.google.com/store/apps/details?id=org.aprsdroid.app | @APRSdroid
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140310/edc8e472/attachment.asc>