[aprssig] APRS-IS q construct / (server?) reject messages "qAO" related to foreign call sign

Jörg Schultze-Lutter joerg.schultze.lutter at gmail.com
Wed Aug 4 12:48:17 EDT 2021

Pete, thanks (as always!) for taking care of this. I was able to get in
touch with OE3XWJ-11's operators and provided them with your feedback. They
are now aware of the issue and started to work on fixing it.


On Wed, Aug 4, 2021 at 12:26 PM Pete Loveall AE5PL Lists via aprssig <
aprssig at lists.tapr.org> wrote:

> It is not the q construct but a bad IGate implementation.  The qAO
> construct indicates that the IGate is receive-only (does not transmit to
> RF).  However, it appears that OE3XWJ-11>APOTW1 (I include the TOCALL to
> identify the IGate software) is apparently improperly responding with a rej
> to messages it thinks are to stations it sees on RF.  This is bad behavior
> for 2 reasons: first, the IGate is falsely identifying itself as the
> station on RF and second, the IGate is falsely assuming it is the only path
> to APRS-IS for the station on RF.  As you have shown, the second assumption
> is wrong (an ack does get through) and generating packets falsely
> identified as being from a different station is NEVER proper operation.
> The second assumption is always a bad assumption because of the necessary
> dupe checking that occurs at the servers on APRS-IS.
> Hope this helps.
> 73,
> Pete Loveall AE5PL
> pete at ae5pl dot net
> -----Original Message-----
> From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Jörg
> Schultze-Lutter
> Sent: Wednesday, August 4, 2021 2:36 AM
> To: aprssig at lists.tapr.org
> Subject: [aprssig] APRS-IS q construct / (server?) reject messages "qAO"
> related to foreign call sign
> tl;dr: I think that an Austrian call sign causes unintended message
> interferences with APRS-IS and several APRS bots - including mine. I
> haven't seen this behavior in the past and I don't believe that there is a
> general design flaw with my program. Please advise.
> --
> I am the author of an APRS bot which started its life in January as a
> functional clone of KI6WJP's WXBOT (my program was written from scratch,
> though). The bot uses its own TOCALL identifier (
> http://aprs.org/aprs11/tocalls.txt). Raw APRS messages can be accessed
> here:  https://aprs.fi/?c=raw&call=MPAD&limit=1000&view=normal
> Over the past few days, I noticed that there was a decline in the number
> of messages that I was able to receive from my bot via *radio*
> transmission. Based on the analysis of the message flow, it looks to me as
> if my bot and others are affected by an Austrian call sign (OE3XWJ-11)
> which results in the intermittent generation of qAO reject messages that
> are broadcasted in response to the user's original requests to our bots.
> This issue only affects messages with message ID's - unconfirmed messages
> are not affected. I would like to get some clarification on how to remedy
> this issue on my end (if possible).
> Message exchange examples follow. Note that all reject messages use the
> generic "APRS" ToCall identifier which makes me assume that they were all
> generated by the APRS-IS server itself.
> 1 - message exchange:  APRS-IS to APRS-IS (via an IOS app)
> --
> 2021-08-03 07:29:54 CEST: DF1JSL-10>APSK21,TCPIP*,qAC,T2GYOR::MPAD
>  :cwop{2
> 2021-08-03 07:29:55 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-10:ack2
> 2021-08-03 07:29:55 CEST: MPAD>APRS,qAO,OE3XWJ-11::DF1JSL-10:rej2
> 2021-08-03 07:30:02 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-10:CWOP
> DW6761 03-Aug-21 11C 136deg Spd 0.0km/h Gust 0.0km/h Hum 94%{OO
> 2021-08-03 07:30:08 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-10:Pres
> 1014.3mb Rain(cm) 1h=0.0, 24h=0.0, mn=0.0{OP
> 2021-08-03 07:30:02 CEST: DF1JSL-10>APSK21,TCPIP*,qAC,T2GYOR::MPAD
>  :ackOO
> 2021-08-03 07:30:02 CEST: DF1JSL-10>APRS,qAO,OE3XWJ-11::OE3BCB-1 :rejOO
> 2021-08-03 07:30:08 CEST: DF1JSL-10>APRS,qAO,OE3XWJ-11::MPAD     :rejOP
> 2021-08-03 07:30:08 CEST: DF1JSL-10>APSK21,TCPIP*,qAC,T2GYOR::MPAD
>  :ackOP
> 2 - message exchange: radio to APRS-IS (via FTM-400XDE)
> --
> 2021-08-03 08:20:08 CEST:
> DF1JSL-1>APY400,WIDE1-1,WIDE2-1,qAR,DB0BI-10::MPAD     :cwop{41
> 2021-08-03 08:20:08 CEST: MPAD>APRS,qAO,OE3XWJ-11::DF1JSL-1 :rej41
> 2021-08-03 08:20:09 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-1 :ack41
> 2021-08-03 08:20:16 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-1 :CWOP
> EW6958 03-Aug-21 11C 23deg Spd 0.0km/h Gust 3.2km/h Hum 95%{OT
> 2021-08-03 08:20:22 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-1 :Pres
> 1014.0mb Rain(cm) 1h=0.0, 24h=0.10, mn=0.0{OU
> 2021-08-03 08:20:16 CEST: DF1JSL-1>APRS,qAO,OE3XWJ-11::MPAD     :rejOT
> 2021-08-03 08:20:22 CEST: DF1JSL-1>APRS,qAO,OE3XWJ-11::MPAD     :rejOU
> 2021-08-03 08:20:35 CEST:
> DF1JSL-1>APY400,WIDE1-1,WIDE2-1,qAR,DB0BI-10::MPAD     :ackOU
> Additional example traffic from the other affected bots' logs can be found
> at the end of this email.
> Based on http://www.aprs-is.net/q.aspx, my conclusion is as follows:
> 1) My call sign  (DF1JSL) sends a message to my MPAD APRS bot.
> 2) The APRS-IS server network generates a reject message (qAO, FROMCALL
> does not match login) that is associated with call sign OE3XWJ-11 and sends
> that reject back to my call sign DF1JSL-xx.
> 3) The original request to my bot still traverses through the APRS-IS
> network and therefore gets picked up by my bot.  Similar to WXBOT and its
> clones, my bot does not take ack/req requests into consideration.
> 4) Additionally: As the reject msg from the APRS-IS server was sent to the
> sender's call sign (DF1JSL..), my bot would never have seen it anyway. So
> it will honor the user's request and process it.
> 5) The bot generates an ack message, processes the user's initial query
> and sends the response messages back to the user via APRS-IS.
> What I don't understand is the constant association of each reject message
> with that Austrian call sign. Regardless of the content that I send to my
> bot - it aways triggers a reject which is always associated with the same
> Austrian call sign. As several other bots also seem to be affected, I doubt
> that this is a general design flaw with all of our bots.
> It also looks to me that from time to time, any bot response received via
> *radio* can sometimes experience long/very long delays between sending the
> request and receiving the response. This might be related to the "reject"
> responses which _may_ prevent the response message to be broadcasted via
> radio - or the radio itselfs rejects the message after receiving the 'rej'.
> Everything I SEND to my bot via radio or APRS-IS is usually received by the
> bot without any delay, though.
> Is there any way for my bot to detect and remedy this situation? As
> mentioned earlier, the reject message gets returned to the original sender
> (and *not* to my bot) so that message will not pass my bot's APRS-IS
> message filter (g/MPAD). Disabling the APRS-IS filters, having a look at
> the whole traffic and detecting the reject message cannot be the answer.
> What is the best cause of action for such a case?
> .... or did I just misinterpret the whole thing and this is normal
> behavior? :-)
> Thanks for taking the time to read this.
> 73's from Germany
> Joerg
> https://github.com/joergschultzelutter/mpad
> Additional examples which make the "Austrian reject pattern" obvious.
> Every reject message is associated with OE3XWJ-11.
> from WXBOT
> 2021-08-02 19:03:40 CEST: N0ISU-9>APY400,WIDE1-1,WIDE2-1,qAR,W0RAY::WXBOT
>   :friday {01
> 2021-08-02 19:03:40 CEST: WXBOT>APRS,qAS,KI6WJP::N0ISU-9  :ack01
> 2021-08-02 19:03:40 CEST: WXBOT>APRS,qAO,OE3XWJ-11::N0ISU-9  :rej01
> 2021-08-02 19:03:46 CEST: WXBOT>APRS,qAS,KI6WJP::N0ISU-9  :Waukee IA.
> Friday,Sunny High 87{UX
> from WXYO (WXBOT clone)
> 2021-08-01 23:18:29 CEST: WXYO>APRS,qAO,OE3XWJ-11::YO9JAZ-9 :rej3
> 2021-08-01 23:18:29 CEST: WXYO>APRS,qAS,YO8SDE-1::YO9JAZ-9 :ack3
> 2021-08-01 23:18:36 CEST: WXYO>APRS,qAS,YO8SDE-1::YO9JAZ-9 :Targoviste in
> h clear sky T:23.83C,W28 at 3.18,H44,P1009hPa,rain 0mm,c{GQ
> from WA1GOV-10 (not even a WXBOT clone)
> 2021-08-01 23:42:38 CEST: WA1GOV-10>APRS,qAO,OE3XWJ-11::YO9JAZ-9 :rej1
> 2021-08-01 23:42:38 CEST: WA1GOV-10>APX217,TCPIP*,qAC,T2USANE::YO9JAZ-9
> :ack1
> 2021-08-01 23:43:05 CEST: WA1GOV-10>APX217,TCPIP*,qAC,T2QUEBEC::YO9JAZ-9
> :ISS over KN43GS AOS 02Aug21 10:01 UTC AZ 169 MaxEL/AZ 6/128
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20210804/279f79e8/attachment.html>

More information about the aprssig mailing list