<html><head></head><body><div class="yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div dir="ltr" data-setdir="false">Greetings.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">It appears that I screwed up my APRS program YAAC over a year ago, and no one noticed until last month!</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I happened to review the specifications at <a href="http://www.aprs-is.net/IGateDetails.aspx" rel="nofollow" target="_blank">http://www.aprs-is.net/IGateDetails.aspx</a> and saw something that seemed rather odd.</div><div dir="ltr" data-setdir="false">-----------------------------<br></div><div dir="ltr" data-setdir="false"><div><p>
<i>IGates must use the 3rd-party format on RF of
</i></p><pre><i>IGATECALL>APRS,GATEPATH:}FROMCALL>TOCALL,TCPIP,IGATECALL*:original packet data</i></pre><i>
where GATEPATH is the path that the gated packet is to follow on RF. This format
will allow IGates to prevent gating the packet back to APRS-IS. The format of the 3rd
party path (TCPIP,IGATECALL*) is <strong>mandatory</strong>; APRS-IS paths MUST be removed before gating to RF.
</i></div><div>------------------------------<br></div></div><div dir="ltr" data-setdir="false">It seemed weird to me, but I changed my code so the RF-transmitted packet used my I-gate station's RF callsign-SSID and tocall on the RF AX.25 packet header, and the original station's callsign and tocall only appeared in the 3rd-party header.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Now this is causing duplicate processing of APRS text messages, because an I-gate using my software is one of (but not the only) source to the complaining user's station, and the end-recipient is receiving the message over RF with both the original station's callsign and the Tx I-gate's callsign (in separate RF packets).<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I looked at some other open-source APRS software's Tx I-gate implementations, and they preserve the original sender's source and destination fields in the RF AX.25 frame, but replace the digipeater list with "TCPIP" and the Tx I-gate's RF callsign-SSID (i.e., from where it was relayed back to RF). This makes a whole lot more sense to me. But is it correct?<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">So what _is_ the correct behavior? Related to this, what is the correct contents of the GATEPATH? I'm assuming I should put RFONLY and NOGATE in it (just so stupid receiving I-gates might not send the packet back in again). Do I need to put "TCPIP,myrfcallsign-ssid" in the RF digipeat path as well? If so, I assume I should put them in first and mark them as already-digipeated, so any additional digipeat aliases (to support multi-hop Tx I-gating) would be next. Should RFONLY and NOGATE always be last in the RF digipeat list (assuming we don't have viscous digipeaters)?</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Awaiting advice from the I-gate masters....</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Andrew, KA2DDO</div><div dir="ltr" data-setdir="false">author of YAAC<br></div></div></body></html>