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

Wed Aug 4 13:31:35 EDT 2021

Thanks Scott - I will forward this info to OE3XWJ-11's operators.

73,
Joerg
DF1JSL

On Wed, Aug 4, 2021 at 7:28 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20210804/edb530ef/attachment.html>