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

Wed Aug 4 16:06:49 EDT 2021

Yes, request a TOCALL from me by telling me about the application
and what TOCALL you think best.  If I agree, then it will be added to
the official list.

http://aprs.org/aprs11/tocalls.txt

"Bob, WB4APR

On Wed, Aug 4, 2021 at 1:27 PM Scott Miller <scott at opentrac.org> wrote:
>
> If they're using the TOCALL of APOTW1 to identify their software, they
> need to pick something else. That's the identifier for the ADS-WS1
> weather station and has been for a dozen years. All of the 'APOTxx'
> TOCALLs should be OpenTracker derivatives.
>
> Scott
> N1VG
>
> On 8/4/2021 3:24 AM, Pete Loveall AE5PL Lists via aprssig 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
> > DF1JSL
> > 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
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org