Discussion:
Simple Network Paging Protocol to APRS Gateway
Kenneth Finnegan
2014-09-17 16:21:41 UTC
Permalink
Let me preface this with a word of warning: this software is still
very fragile and unfinished, so what you're looking at is mostly held
together with duct tape.

A month ago, I was looking something up in /etc/services when I
noticed that port 444 is allocated for a protocol I had never heard
of: SNPP. http://en.wikipedia.org/wiki/Simple_Network_Paging_Protocol

A relatively simple protocol lost to history, but one that could
possibly be useful for talking to APRS clients. Having nothing better
to do this month (except work on my thesis), I decided it'd be a nice
way to brush up on my C daemon programming...

I present to you... the KWFSNPP gateway daemon!

Code can be found here: https://github.com/PhirePhly/kwfsnpp

You can play with it by connecting via "telnet
snpp.thelifeofkenneth.com 444" as long as I'm able to keep this kludge
running.

The use case here is for when you want to send a one-way APRS message
to someone, and you don't happen to have anything like APRSdroid or
Xastir running. Telnet into a KWFSNPP server and issue the following
commands:

PAGER W6KWF-5
MESSAGE Call Sean on W6BHZ/R
SEND
QUIT

My daemon then handles the retries and parsing the ack to make sure
the message is delivered to the target. The message does appear to be
coming from "KWFSNPP," so you need to appreciate that your message
won't include a useful From: field, just like in the good old pager
days.

Another possible use-case is sending APRS messages from short-lived
shell scripts such as scheduled cronjobs...
echo -e "PAGE W6KWF-5\nMESS Nightly backup of file server
failed!\nSEND\nQUIT" | nc snpp.thelifeofkenneth.com 444

If you try and connect and the server is down, it likely means I
thought better of exposing such an alpha piece of software to the
Internet at large, or it just died somehow...

Is this useful? Maybe...

Is this a silly project to be working on in 2014 when I should be
finishing my thesis? Absolutely!

Is this robust? Not at all, yet...

This is nowhere near finished or bomb proof. The following issues are
on the top of my list:
* Doesn't properly handle the APRS-IS server disconnecting
* Doesn't do any rate-limiting to prevent SNPP client abuse
* Doesn't try hard enough to verify valid destination addresses
* Doesn't daemonize yet. I currently have it running in a screen session
* There's no kwfsnppd.conf support yet, so the command line gets a little long
* A bunch of the options are hard-coded with no option flag support yet.
* I use the N*30 retry backoff algorithm that the OpenTracker uses,
having not yet put any thought into the ideal retry behavior for
APRS-IS connected stations.

Thoughts?

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/
Max Harper
2014-09-17 22:25:41 UTC
Permalink
I may not have been holding my mouth right, but it kept disconnecting on me. Is 444 the port? I tried it using putty in telnet mode.

Max KG4PID
Kenneth Finnegan
2014-09-18 00:58:25 UTC
Permalink
Turns out there was two bugs that Max managed to trip.

* Putty seems to send new lines in separate TCP packets than the line
before them, which broke my socket driver.

* There was an off-by-one error in the argument parser for the PAGEr
command.

I've got quick hacks for both on the live server, but fixes to git are
still in the works.

Putty is a little tricky because it defaults to active telnet mode, so I
think the best mode for putty is raw.

Kenneth Finnegan
On Sep 17, 2014 3:31 PM, "Max Harper" <kg4pid-/***@public.gmane.org> wrote:

> I may not have been holding my mouth right, but it kept disconnecting on
> me. Is 444 the port? I tried it using putty in telnet mode.
>
> Max KG4PID
>
>
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
>
Andrew P.
2014-09-18 01:12:31 UTC
Permalink
One concern about this, is that it doesn't do any excuse at authentication to confirm the person sending a message is a licensed amateur radio operator, so it could allow unlicensed users to transmit to RF. The APRS-IS backbone's passcode mechanism may not be the strongest, but at least it slows down attackers a little bit and requires them to at least claim to be licensed. As this SNPP daemon is implemented now, it leaves the licensee of every transmitter this daemon can get to at risk.

Andrew, KA2DDO

Date: Wed, 17 Sep 2014 17:58:25 -0700
From: kennethfinnegan2007-***@public.gmane.org
To: aprssig-***@public.gmane.org; kg4pid-/***@public.gmane.org
Subject: Re: [aprssig] Simple Network Paging Protocol to APRS Gateway

Turns out there was two bugs that Max managed to trip.
* Putty seems to send new lines in separate TCP packets than the line before them, which broke my socket driver.
* There was an off-by-one error in the argument parser for the PAGEr command.
I've got quick hacks for both on the live server, but fixes to git are still in the works.
Putty is a little tricky because it defaults to active telnet mode, so I think the best mode for putty is raw.
Kenneth Finnegan
On Sep 17, 2014 3:31 PM, "Max Harper" <kg4pid-/***@public.gmane.org> wrote:
I may not have been holding my mouth right, but it kept disconnecting on me. Is 444 the port? I tried it using putty in telnet mode.
Max KG4PID


_______________________________________________

aprssig mailing list

aprssig-***@public.gmane.org

http://www.tapr.org/mailman/listinfo/aprssig
Steve Dimse
2014-09-18 01:29:28 UTC
Permalink
On Sep 17, 2014, at 8:12 PM, Andrew P. <andrewemt-***@public.gmane.org> wrote:

> One concern about this, is that it doesn't do any excuse at authentication to confirm the person sending a message is a licensed amateur radio operator, so it could allow unlicensed users to transmit to RF. The APRS-IS backbone's passcode mechanism may not be the strongest, but at least it slows down attackers a little bit and requires them to at least claim to be licensed. As this SNPP daemon is implemented now, it leaves the licensee of every transmitter this daemon can get to at risk.

I figured this would take less than 12 hours to get brought up. I'll spare everyone my usual review of the passcode history since it has been less than a year since it last came up.

But no, this daemon does nothing to increase risk to IGate operators. The passcode doesn't require 'attackers' to claim to be licensed. No one has any claim to any ham callsign on the internet, they are assigned for use on RF. If someone transmits as K4HG on the airwaves they are violating US law. If they do so on the internet they are violating nothing. Security through obscurity is no security at all. Do not stick your head in the sand - the APRS IS has been wide open for a decade. Accept it. Deal with it.

Steve
Kenneth Finnegan
2014-09-18 01:41:36 UTC
Permalink
On Wed, Sep 17, 2014 at 6:12 PM, Andrew P. <andrewemt-***@public.gmane.org> wrote:
> One concern about this, is that it doesn't do any excuse at authentication
> to confirm the person sending a message is a licensed amateur radio
> operator, so it could allow unlicensed users to transmit to RF.

I thought about implementing SNPP's authentication extension, but
decided that it hamstrung the simple elegance of the protocol.

I'm not willing to require users to provide their APRS-IS passwords
every time they log in, since even I have found calculating those
passwords seriously inconvenient. I move between systems so much that
the easiest way to get passwords is through the web generators, but
they keep catching flak and getting shut down so I keep needing to
find new password hashers.

In the end, I don't plan on leaving this one exposed to the Internet
indefinitely, so the daemon's implicit trust can be limited to each
deployment's LAN by the gateway firewall.

So yes, this daemon doesn't use the APRS authentication mechanism du
jour. I'm more interested in people's first impressions on the daemon
itself.

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/
Charles Bland
2014-09-18 03:30:29 UTC
Permalink
As usual, you come up with interesting stuff.

However,.....

Since I know you a *little* better than most on this list......

GET BACK TO WORK ON YOUR THESIS!!!!!!!!!!!!!!

Chucky


On Wed, Sep 17, 2014 at 6:41 PM, Kenneth Finnegan <
kennethfinnegan2007-***@public.gmane.org> wrote:

> On Wed, Sep 17, 2014 at 6:12 PM, Andrew P. <andrewemt-***@public.gmane.org> wrote:
> > One concern about this, is that it doesn't do any excuse at
> authentication
> > to confirm the person sending a message is a licensed amateur radio
> > operator, so it could allow unlicensed users to transmit to RF.
>
> I thought about implementing SNPP's authentication extension, but
> decided that it hamstrung the simple elegance of the protocol.
>
> I'm not willing to require users to provide their APRS-IS passwords
> every time they log in, since even I have found calculating those
> passwords seriously inconvenient. I move between systems so much that
> the easiest way to get passwords is through the web generators, but
> they keep catching flak and getting shut down so I keep needing to
> find new password hashers.
>
> In the end, I don't plan on leaving this one exposed to the Internet
> indefinitely, so the daemon's implicit trust can be limited to each
> deployment's LAN by the gateway firewall.
>
> So yes, this daemon doesn't use the APRS authentication mechanism du
> jour. I'm more interested in people's first impressions on the daemon
> itself.
>
> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/
> _______________________________________________
> aprssig mailing list
> aprssig-***@public.gmane.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
Tom Hayward
2014-09-18 16:51:11 UTC
Permalink
On Wed, Sep 17, 2014 at 6:41 PM, Kenneth Finnegan
<kennethfinnegan2007-***@public.gmane.org> wrote:
> On Wed, Sep 17, 2014 at 6:12 PM, Andrew P. <andrewemt-***@public.gmane.org> wrote:
>> One concern about this, is that it doesn't do any excuse at authentication
>> to confirm the person sending a message is a licensed amateur radio
>> operator, so it could allow unlicensed users to transmit to RF.
>
> I thought about implementing SNPP's authentication extension, but
> decided that it hamstrung the simple elegance of the protocol.

Just throw stunnel in front of it with LotW certificates.

Tom KD7LXL
Loading...