<div dir="ltr">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.<br><br>--<br><br>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 (<a href="http://aprs.org/aprs11/tocalls.txt" target="_blank">http://aprs.org/aprs11/tocalls.txt</a>). Raw APRS messages can be accessed here:  <a href="https://aprs.fi/?c=raw&call=MPAD&limit=1000&view=normal" target="_blank">https://aprs.fi/?c=raw&call=MPAD&limit=1000&view=normal</a><br><br>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).<br><br>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.<br><br>1 - message exchange:  APRS-IS to APRS-IS (via an IOS app)<br>--<br>2021-08-03 07:29:54 CEST: DF1JSL-10>APSK21,TCPIP*,qAC,T2GYOR::MPAD     :cwop{2<br>2021-08-03 07:29:55 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-10:ack2<br>2021-08-03 07:29:55 CEST: MPAD>APRS,qAO,OE3XWJ-11::DF1JSL-10:rej2<br>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<br>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<br>2021-08-03 07:30:02 CEST: DF1JSL-10>APSK21,TCPIP*,qAC,T2GYOR::MPAD     :ackOO<br>2021-08-03 07:30:02 CEST: DF1JSL-10>APRS,qAO,OE3XWJ-11::OE3BCB-1 :rejOO<br>2021-08-03 07:30:08 CEST: DF1JSL-10>APRS,qAO,OE3XWJ-11::MPAD     :rejOP<br>2021-08-03 07:30:08 CEST: DF1JSL-10>APSK21,TCPIP*,qAC,T2GYOR::MPAD     :ackOP<br><br>2 - message exchange: radio to APRS-IS (via FTM-400XDE)<br>--<br>2021-08-03 08:20:08 CEST: DF1JSL-1>APY400,WIDE1-1,WIDE2-1,qAR,DB0BI-10::MPAD     :cwop{41<br>2021-08-03 08:20:08 CEST: MPAD>APRS,qAO,OE3XWJ-11::DF1JSL-1 :rej41<br>2021-08-03 08:20:09 CEST: MPAD>APMPAD,TCPIP*,qAC,T2UKRAINE::DF1JSL-1 :ack41<br>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<br>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<br>2021-08-03 08:20:16 CEST: DF1JSL-1>APRS,qAO,OE3XWJ-11::MPAD     :rejOT<br>2021-08-03 08:20:22 CEST: DF1JSL-1>APRS,qAO,OE3XWJ-11::MPAD     :rejOU<br>2021-08-03 08:20:35 CEST: DF1JSL-1>APY400,WIDE1-1,WIDE2-1,qAR,DB0BI-10::MPAD     :ackOU<br><br>Additional example traffic from the other affected bots' logs can be found at the end of this email.<br><br>Based on <a href="http://www.aprs-is.net/q.aspx" target="_blank">http://www.aprs-is.net/q.aspx</a>, my conclusion is as follows:<br><br>1) My call sign  (DF1JSL) sends a message to my MPAD APRS bot.<br>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. <br>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. <br>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. <br>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.<br><br>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.<br><br>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.<div><br></div><div>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?<br><br>.... or did I just misinterpret the whole thing and this is normal behavior? :-) </div><div><br></div><div>Thanks for taking the time to read this.<br><br>73's from Germany<br>Joerg<br>DF1JSL<br><a href="https://github.com/joergschultzelutter/mpad" target="_blank">https://github.com/joergschultzelutter/mpad</a><br><br>Additional examples which make the "Austrian reject pattern" obvious. Every reject message is associated with OE3XWJ-11.<br><br>from WXBOT<br><br>2021-08-02 19:03:40 CEST: N0ISU-9>APY400,WIDE1-1,WIDE2-1,qAR,W0RAY::WXBOT    :friday {01<br>2021-08-02 19:03:40 CEST: WXBOT>APRS,qAS,KI6WJP::N0ISU-9  :ack01<br>2021-08-02 19:03:40 CEST: WXBOT>APRS,qAO,OE3XWJ-11::N0ISU-9  :rej01<br>2021-08-02 19:03:46 CEST: WXBOT>APRS,qAS,KI6WJP::N0ISU-9  :Waukee IA. Friday,Sunny High 87{UX<br><br>from WXYO (WXBOT clone)<br><br>2021-08-01 23:18:29 CEST: WXYO>APRS,qAO,OE3XWJ-11::YO9JAZ-9 :rej3<br>2021-08-01 23:18:29 CEST: WXYO>APRS,qAS,YO8SDE-1::YO9JAZ-9 :ack3<br>2021-08-01 23:18:36 CEST: WXYO>APRS,qAS,YO8SDE-1::YO9JAZ-9 :Targoviste in h clear sky T:23.83C,W28@3.18,H44,P1009hPa,rain 0mm,c{GQ<br><br>from WA1GOV-10 (not even a WXBOT clone)<br><br>2021-08-01 23:42:38 CEST: WA1GOV-10>APRS,qAO,OE3XWJ-11::YO9JAZ-9 :rej1<br>2021-08-01 23:42:38 CEST: WA1GOV-10>APX217,TCPIP*,qAC,T2USANE::YO9JAZ-9 :ack1<br>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<br><br><div><div></div></div></div></div>