Warning! Illegal callsigns on aprs.fi

[UR4URD]

Hello!

I would like to draw your attention to the fact that the call signs with the prefix D1 have appeared on the site map, which are illegal because they are issued by the occupying power of the unrecognized "Donetsk People's Republic".
The use of these call signs in amateur radio is a violation of both Ukrainian legislation (administrative work under the illegal call sign) and criminal law (calls for violation of the territorial integrity of Ukraine).
On behalf of Ukrainian radio amateurs, I ask you to block the use of illegal call signs on the aprs.fi website.

Thanks for understanding!

Aleksander Krolikovski (UR4URD)

[Heikki Hannikainen]

On Tue, 20 Jul 2021, UR4URD wrote:

> I would like to draw your attention to the fact that the call signs with the prefix D1 have appeared on the site map, which are
> illegal because they are issued by the occupying power of the unrecognized "Donetsk People's Republic".
> The use of these call signs in amateur radio is a violation of both Ukrainian legislation (administrative work under the illegal call
> sign) and criminal law (calls for violation of the territorial integrity of Ukraine).
> On behalf of Ukrainian radio amateurs, I ask you to block the use of illegal call signs on the aprs.fi website.

Hello,

This is a difficult question. I fully understand and recognize that the
area, along with some other parts of your country, have been invaded and
the annexations and proto-states have not been recognized by other
countries or the UN or ITU.

On the other hand I would like to view this from the point of the
individual amateur radio operator who might happen to live in this area,
unable or unwilling to flee their home when the war came.

Let's say that Finland, where I live, would be invaded by a larger
neighbouring country, such as Sweden. :) Finland might not be able to
resist the mighty Swedes, and I would find myself improving my lousy
Swedish language skills again. The new administration would say I shall
use an SM callsign, SM7LZB, or cease operations. I might not be able to
obtain a new OH callsign if I were to get a new license. My only
practical option might be to use that callsign, or not do ham radio at
all. It'd probably not be accepted as DXCC credit, which I could live
with, but I would be annoyed if I'd be punished by aprs.fi for the fact
that we failed to resist the invasion and surströmming.

I don't know if the actual users of these D0/D1 callsigns are the
invaders, or merely people who happen to live there in somewhat difficult
conditions. It might be difficult to find out for sure, at least from over
here.

Club Log's take on this has been to mark the contacts as "INVALID", but
that merely means they're not valid for DXCC contact points. One can still
log the contacts.
https://clublog.freshdesk.com/support/solutions/articles/3000037653-d0-d1-donetsk-people-s-republic

I'd be interested to hear how other organisations and services have
handled this.

Please note that I do not, in any way, support the annexations or
invasions. I'd just prefer to consider the issue from the angle of
individual people being enabled to practice amateur radio, even if they
happen to end up living in such an area.

- Hessu

[Nosey Nick VA3NNW]

On Thursday, 22 July 2021 at 06:37:38 UTC-4 Heikki Hannikainen wrote:

I'd be interested to hear how other organisations and services have
handled this.
Please note that I do not, in any way, support the annexations or
invasions. I'd just prefer to consider the issue from the angle of
individual people being enabled to practice amateur radio, even if they
happen to end up living in such an area.

How do you handle any other pirates or other "Illegal callsigns"? I thought you usually attempted to be a fairly complete and accurate record of every APRS packet heard on the air (and reported to the APRS backbone) and quite a few packets that were never on the air and may or may not ever be gated on to the air (CWOP etc but also packets injected direct into the backbone by various other services like ISS trackers and ham smartphone apps)

I think I see some value in highlighting / marking in red / doing strike-though (which google groups won't let me do) of any callsigns that appear to be NOT valid "of a form recognised by the ITU" perhaps, but I don't think you should make it D1-specific / Ukraine-specific, keep it neutral, you'd want to mark those unlicensed truck trackers and things as well. Maybe then allow a filter "show me only valid calls", vs "show only invalid-looking calls" vs "show all calls", up to you which is enabled by default, but I can certainly imagine license-enforcement teams appreciating a view of ONLY the invalid-looking calls? You'd obviously have to keep up-to-date pretty quickly as ITU introduces new prefixes reasonably often.

There's the awkward issue of objects / items vs callsigns. If I recall, the spec says they share the same namespace even though objects/items do NOT have to be valid ITU callsigns, and are often deliberately and by design tactical things like HAMFEST07, club names, "Runner001" or "Water001" in the marathon, "Car001" in the rally, hospitals, storm names, nets, meetings, FREQUENCIES even, http://www.aprs.org/localinfo.html

To be clear, D1FOO would be COMPLETELY valid as an object/item, there's almost no rules and certainly no licensing requirements there at all... but source callsigns almost certainly SHOULD be valid? How about digipeating paths - presumably NOT, because q-constructs, WIDEn-n, ARISS, RELAY, etc? It's reasonably obvious which is which on the backbone based on where in the packet they fall, but how does/should APRS.fi (and OTHER display programs/apps/sites, for there are many) handle it on the display side?

I guess ideal would be for different display formats for each of:

• Valid-looking ITU-compatible callsign appearing as an object/item (NOT required to be a call but might be nice to show if it looks like one?)
  
• Non-callsign appearing as an object/item (PERFECTLY valid but could be displayed differently?)
• Valid-looking ITU-compatible callsign appearing as the actual SOURCE callsign or in the digipeating path
• DESTINATIONS definitely aren't required to be valid calls, and are usually APRS or software name/ver - APLWS2, APMI06, APRX29...
  
• Other valid things appearing in the digipeating path, like q-constructs, WIDEn-n, WIRES? DSTAR? ARISS? RELAY? ECHO? Backbone node names - hang on, can't these be ANY desired digipeat selector hops in almost freeform text, D1234 would be valid here, no?
  
• Other things, that don't look like valid ITU-compatible callsigns, appearing in the source callsign - perhaps display these with a strikethrough and a hover-text explaining why?

I'm wondering if the only thing that is "required" to look like an ITU callsign is the SOURCE? Even there, not for WX on CWOP or... Well, let's look at real-world data on the actual APRS backbone, before APRS.fi gets its hands on it: I don't see a huge number of these AS SOURCES. In yesterday's data for example:

    294 D18015318>APRARX,SONDEGATE,... - a "403.810 MHz Type=DFMx7 Radiosonde auto_rx v1.3.2 !wXX!" - what's a Radiosonde? Is this in Ukraine/ "DPR"?
     69 D1APRS>APRS - an "APRS iGateway", this might be what you are complaining about?
      1 D1K6S-10>AK12q-9 - an invalid position "393.0N082.50t7" (wrong number of decimal places and no E/W) from a D1 callsign.  Given the corruption in the rest of the packet, I'm inclined to believe the source call might have been corrupted as well, and gated by an igate that doesn't verify checksums?

Is 1 packet every 20min worth ANYONE's time? Is this ACTUALLY a problem, or just anticipating a problem in advance?

And questions for UR4URD, have you made similar requests to other APRS display sites / programs / apps, or only aprs.fi? Will you be asking APRS-IS backbone providers to block them on ingress, egress, or transit, or only (perhaps a subset of) sites / programs / apps on the display side? I assume you appreciate that APRS.fi IS NOT APRS, it's only one of many ways to display the contents of the APRS-IS backbone (and in this case CWOPS and a few other APRS-IS alternatives)?

73, Nick VA3NNW

 

[Heikki Hannikainen]

On Thu, 22 Jul 2021, Nosey Nick VA3NNW wrote:

> How do you handle any other pirates or other "Illegal callsigns"?

For the most of the time, except for bad packets generated by buggy
software or technical glitches or DDOS attacks, I've just been archiving
them. It'd be generally silly for a pirate to transmit accurate APRS
positions, as it makes it very easy to track them down, but it's happened
quite a few times. It's useful if aprs.fi keeps them in archive: it shows
that the wrongful thing did happen, when and where.

> There's the awkward issue of objects / items vs callsigns. If I recall,
> the spec says they share the same namespace even though objects/items do
> NOT have to be valid ITU callsigns, and are often deliberately and by
> design tactical things like HAMFEST07, club names, "Runner001" or
> "Water001" in the marathon, "Car001" in the rally, hospitals, storm
> names, nets, meetings, FREQUENCIES even,
> http://www.aprs.org/localinfo.html

The spec doesn't go as far as saying they're in the same namespace, but it
is my interpretation that they are.

> To be clear, D1FOO would be COMPLETELY valid as an object/item, there's
> almost no rules and certainly no licensing requirements there at all...
> but source callsigns almost certainly SHOULD be valid? How about
> digipeating paths - presumably NOT, because q-constructs, WIDEn-n,
> ARISS, RELAY, etc?

It's also quite common to use "tactical call signs", at least in the US,
there are a lot of digipeaters and other similar things which are regular
APRS stations (not objects or items) but with the source callsign being
the name or location of the digipeater, and the actual callsign being in
the comment string (or somewhere else).

So weird non-ITU-prefix source callsigns happen, and they happen quite a
lot.

>     294 D18015318>APRARX,SONDEGATE,... - a "403.810 MHz Type=DFMx7 Radiosonde auto_rx v1.3.2 !wXX!" - what's a Radiosonde? Is this in
> Ukraine/ "DPR"?

Radiosondes are radiosondes. Weather sonde balloons with radio
transmitters. It has become a popular sport to receive those and gate the
data to APRS. I don't think they belong to the APRS-IS since they're not
amateur radio traffic, but that's what they're doing (and quite a lot).
They're D<number>.

https://aprs.fi/#!call=D1%2A
https://aprs.fi/#!call=D2%2A

There's a different service to track sonde balloons, which would be
preferred over APRS: https://sondehub.org/

- Hessu

[Nosey Nick VA3NNW]

I pointed out:

> http://www.aprs.org/aprs11/aprs-names-and-spaces.txt

> 1) NAMES: Station, ITEM and OBJECT names were all meant to be in the same NAME space. (2016: and also APRS message addees)

Reading further into the same thing-that-might-count-as-"spec":

ITEMS dropped the spaces by definition for brevity. STATION names are from the AX.25 header and have callsign-type restrictions (WHEN ENTERED into the sending TNC) debate continues about what is allowed in 3rd party packets. Object names can contain any printable ASCII character (I will concede, this includes embedded spaces)(not trailing spaces). (2016: and can be mixed case)

2) PACKET TYPES: STATION, OBJECT and ITEMS were all supposed to be just different ways of enteirng a "thing" into the distributed APRS virtual display. THeir SOURCE was always to be retained as long as the information was valid. ANd their TYPE was supposed to be retained on the display for immediate recognition. (2016: but other- wise are interchangeable as long as the name matched).

[ Typos and CApitalisation oddities from the original ]

... but again, I would posit that you're welcome, perhaps encouraged, to have neat formatting / display mechanisms to show whether a given "thing" came from an OBJECT, and ITEM, or a STATION, and for the latter maybe even display things that look like valid ITU calls vs invalid ITU calls differently "for immediate recognition", but it sounds like you would still be in no way obliged to filter invalid calls even in  STATION fields (from the AX.25 headers)

Thanks, as always

Nick VA3NNW

[Nosey Nick VA3NNW]

Heikki Hannikainen wrote:

> There's the awkward issue of objects / items vs callsigns. If I recall,
> the spec says they share the same namespace even though objects/items do

> NOT have to be valid ITU callsigns, and are often deliberately [... NOT ...]

The spec doesn't go as far as saying they're in the same namespace, but it
is my interpretation that they are.

Trying to remember where I recalled this from. Found http://www.aprs.org/aprs11/aprs-names-and-spaces.txt which may or may not count as "the spec" but says:

1) NAMES: Station, ITEM and OBJECT names were all meant to be in the
same NAME space.  (2016: and also APRS message addees)

So weird non-ITU-prefix source callsigns happen, and they happen quite a
lot.

Wow, so... D1XYZ.. would appear to be... perfectly valid in ALL relevant APRS fields even if it's NOT a valid ITU callsign then?

If Dayton chose to rename itself D1FEST they would have a perfectly valid reason to beacon D1FEST onto APRS(-IS) from Ohio, or any location in the world they chose.

Radiosondes are radiosondes. Weather sonde balloons with radio

transmitters. [...] They're D<number>
https://aprs.fi/#!call=D1%2A    https://aprs.fi/#!call=D2%2A

It seems to be pretty easy to conclude that it would be wrong to unconditionally block anything beginning D1, regardless of whether it's a valid ITU callsign or not. At igates, or on the APRS-IS backbone, or on APRS.fi or any other site/app that chooses to render APRS(-IS) data. If you wish to display them differently, and/or offer ability for users to selectively search for them and/or filter them out, that's obviously up to you as the author(s) of this one particular interface to the shared data set, but there would appear to be no legal, technical, or other good reason to treat D1 particularly specially.

If someone else wishes to locate pirate activity and enforce regional radio regulations, that's obviously a completely different matter, and a very noble goal. Hopefully APRS.fi and other APRS front-end apps/sites will help you in your quest to locate the pirates!   :-)

Thanks Heikki, for the services you offer!