CG Antenna GW-1000 APRS iGate has serious bugs

The CG Antenna GW-1000 APRS iGate gateway appliance contains faulty firmware which causes severe problems to APRS messaging worldwide.  The IS -> RF gateway feature must be disabled on all GW-1000 devices until the bug is fixed by CG Antenna, and firmware is updated on the devices.  Please contact the vendor for further instructions.

CG Antenna has asked me to publish this information so that owners of faulty iGates would more likely learn about the issue. They mentioned a special TTL level serial cable / adapter may be required for the update process.

Description of the issue

When enabled, the APRS-IS to RF (transmit) iGate transmits packets to the RF unmodified.  It does not use the correct 3rd party packet format documented in the iGate specification.  Because of this, other iGates near the faulty iGate assume all of those distant stations are active on the local RF channel, while in fact they may be on the other side of the world.

This causes the other local iGates to transmit APRS text messages destined to all of those remote stations to the local RF channel.  They're operating correctly - the unmodified packets sent by the CG-1000 seem like they would have been transmitted locally on RF.

When a lot of messages are sent, such as during the APRS Thursday event, the local RF channel will be seriously congested.  The CG Antenna GW-1000 device itself will transmit a high rate of packets, packets which are destined to remote stations and which should not be forwarded to RF.  The other iGates confused by the GW-1000 cause additional unnecessary traffic.

Because of the congestion many packets are also delayed long enough to cause the 30-second duplicate packet filtering window to be exceeded.  Packets sent to RF by the GW-1000 will be looped back to APRS-IS and redelivered everywhere in the world.  A single GW-1000 gateway in Switzerland caused delayed duplicate APRS messages to be delivered worldwide.

There are currently GW-1000 gateways operating elsewhere, but it is difficult to track them down and get them disabled.  They are hard to identify, because they send the packets to RF unmodified, without using their own callsign in the 3rd party packet frame like they should.

Timeline

I have notified CG Antenna of the issue by email on January 14th, 2023, and they confirmed receiving the report on January 17th.  On February 4th they confirmed that they have to make a firmware update.  They have not published updated firmware on their downloads page yet as of June 29th, 2023. After 5 months, on June 21st, they updated their web site to note that the feature is faulty and needs to be disabled.

The bug has been present in the firmware since the launch of the product, but only became apparent when the APRS Thursday event got people to send more APRS messages, and some of those messages were originated near GW-1000 iGate.

Learnings

Yes, the APRS messaging feature is brittle and it's easy to cause a bit of a mess.

If you produce and deliver a product like this, make sure it is easy for customers to upgrade the firmware without special tools. Be prepared to ship updated firmware in a timely manner if there is a serious issue.

If you wish to implement an APRS iGate, be sure to fully read the APRS iGate spec, and the details page, and fully understand it. If there's something that you don't understand, please don't do it before obtaining more information or help to understand it.

This is not the only current issue out there - there are other software causing similar issues. I'll make an update in the APRS iGate implementation tips document.

The issue was originally debugged and described in this groups.io APRS group thread.

RX-only igates considered beneficial to the network

As probably most of you know by now, besides running the aprs.fi web site, I'm also one of the two main authors of the aprsc server software. aprsc runs on most of the APRS-IS servers where iGates usually connect.

There have been recent and strong claims saying that receive-only (rx-only) iGates destroy the two-way messaging feature of APRS. This has been claimed in blog posts and facebook threads. Some people ask me if this is true.

No, it is not true. Receive-only iGates do not break messaging if there are transmit-capable igates nearby, and those transmit-capable iGates are connected to an APRS-IS server which has a full APRS feed. All aprs.net and aprs2.net servers, where iGates normally connect, do have a full feed. No problem!

Messaging would work from 1650m / 5400 ft above Vihti, even in the presence of
RX-only iGates, as long as there is at least one TX-capable iGate.

If there are no transmit-capable (TX) iGates around, two-way messaging will not work, of course. Having a transmit-capable iGate would therefore be better, but receive-only iGates are easier to set up technically, they are cheaper (receivers are practically free now), and licensing for automatic transmitters is difficult in many countries. Where transmit-capable (TX) iGates are present, receive-only iGates do not break the TX iGates, they just improve reception coverage. For messages, too.

Just to make it perfectly clear: If there are TX iGates present, additional RX-only iGates improve messaging performance. For the RF-to-IS direction (and ACKs for the IS-to-RF messages).

The common incorrect claim is that the APRS-IS server sends the message only to the latest iGate which heard a station. In fact, the APRS-IS servers (both javaprssrvr and aprsc) send the messages to all iGates which heard the station recently. In aprsc, "recently" means "within 3 hours", and I believe javaprssrvr uses something similar.

The server maintains a list of recently heard callsigns independently for each iGate client. There's a separate list of heard stations for each iGate client. When the server has a packet to pass on, it will look at all connected clients, and for each client, if the recipient of the message is found from the list of recently heard stations, the message will be sent. The scanning will not stop; the message will be given to all clients which heard the station.

I can confirm that we have written the software to do it like this, and since it is open source, you can see the code yourself. The automatic test case also validates that the server keeps working that way, so that there won't be a bug creeping in the future to break it accidentally. I've also tested that javaprssrvr behaves like this – I've run the test cases against it to confirm compatibility.

There may be problems when there is a server with a filtered feed involved (possibly a server software running at the "client" without having a full feed), but those are rare and known to be problematic. All Tier2 servers have a full feed (aprs2.net ones), and so do the core servers.

The real problem is that a user, seeing one-way beaconing to the APRS-IS works, may well expect two-way messaging to work too. And when it doesn't work, there's only a timeout, no immediate feedback saying "sorry, this won't work now", which is what a sensible system would do today.

Even in that case, an rx-only igate is better than nothing! I wouldn't be so harsh against them, since the step from RX-only to TX-capable may be a bit difficult for many.

Bottom line:

In each area, there should be one TX igate, maybe two. More may create QRM as the same messages will be transmitted from APRS-IS to RF many times. RX igates will not break messaging if there are TX igates around – they just improve RX coverage.

This picture may at first seem irrelevant, but it does show me working VHF in AM (122.825 MHz),
and Flarm on 868 MHz to OGN (which runs aprsc). Flarm antenna visible in top left corner.