[aprssig] APRS iGate questions

[Matti Aarnio]

On Sun, Sep 05, 2010 at 06:01:39PM +0100, Reuben Wells wrote:
> 
> I have been building a standalone APRS iGate, using an Omnima
> embedded controller with OpenWrt (Linux) and running Aprx 2.0
> (http://wiki.ham.fi/Aprx.en). This has been up and running for about
> a week and everything looked to be working just fine (see M0RXW-B on
> aprs.fi).
> 
> However, yesterday afternoon I had a call from (M0NAS) that he was
> seeing very strange movements on aprs.fi. Now interestingly, when he
> called he was still seeing strange position reports coming through,
> but I had powered off the iGate almost 2 hours earlier at 14:27 UTC
> (15:27 local).

I am inclined to say that there are questionable digipeaters in the area.

 2010-09-03 16:35:24 UTC: M0NAS-9>UQ5VT9,WIDE1-1*,WIDE3-3,qAR,M0NAS:`vC"mHk>/"4L}Neil mobile
 ...
 2010-09-03 18:08:33 UTC: M0NAS-9>UQ5VT9,WIDE1*,WIDE3-2,qAR,M0RXW-B:`vC"mHk>/"4L}Neil mobile [Duplicate position packet]

Something digipeats, and puts out "WIDE1-1" with "has-been-digipeated" flag set.

Something else digipeats and processes WIDE1-1 by New-N rule, and something other
digipeats with New-N rule -- but time spent in those two is about 1h30m.
That 1h30m is mightly lot for APRS-IS to act as a limbo, so I suspect the digipeaters.

Could you get M0NAS-9 to try TRACE1-1,TRACE3-3, and drive similar loop around?
That might supply sufficient clue as to what the buggy thing is.

After all, his packets are generally reaching igate with one digipeat, less
frequently needing two digipeats, and sometimes they need all 4.  It would
be nice to know where they have travelled:

  2010-09-03 12:42:10 UTC: M0NAS-9>UQ5XS4,WIDE1*,WIDE3*,qAR,M0RXW-B:`vCqop1>/"4p}Neil mobile

> And looking at the raw packets from my iGate M0RXW-B on aprs.fi I see:
> 
> 2010-09-04 16:59:28 UTC: *M0RXW-B*>RXTLM-1,TCPIP*,qAC,T2ITALY:T#626,31.3,0.0,127.0,108.0,0.0,00000000
> 2010-09-04 17:00:22 UTC: *M0RXW-B*>APRX20,TCPIP*,qAC,T2ITALY:!5110.89NR00018.64E&Rx-only iGate (aprx2/OpenWrt 10.03 - row at hopgarden.net)
> 2010-09-04 17:01:26 UTC: *M0RXW-B*>RXTLM-1,TCPIP*,qAC,T2ITALY::M0RXW-B :PARM.Avg 10m,Avg 10m,RxPkts,IGateDropRx,TxPkts
> 
> This doesn't make any sense to me as my iGate was physically powered
> off at 14:27 UTC whilst I was reflashing the device. Some how
> packets continued to be retransmitted for about 3 hours after the
> device was powered off. This would explain the strange tracks on
> APRS if the packets were being replayed out of order.

Sorry to contradict you, but your telemetry data seems to be coherent,
it is being sent out every 20 minutes (+ some seconds) until 17:20 UTC,
when it stops.  By "coherent" I mean the sequence numbers are sequential
until then.  (After every 6 telemetry messages there is a skip, because
the telemetry subsystem puts out parms/equations, and unintentionally
consumes one sequence value at it.)

Also aprs.fi seems to have current view of the time. A beacon I sent
8 minutes ago is listed as being sent 8 minutes ago.


> I've since been speaking with the operator of MB7UUE
> (g3rji.alanpaul at gmail.com - http://2e0avq.co.uk/) which is a new
> bidirectional gateway, that is bridging from the Internet to RF and
> he is also not sure what might be causing this.
> 
> Is it possible that MB7UUE could have somehow created a loop in the
> system? i.e. RF->Internet->RF->Internet.

No.  There is too much time spent in limbo.  A TRACE may reveal it.

More like bad firmware on some unmanned digipeater somewhere. I have seen
TNC2s with UIDIGI to loose their marbles after a few months of continuous
operation.  Their own beacons become garbled, and behaviour is overall
erratic.  I can't rule out that KPC3+ units won't have similar problems.

One of the sad omissions in TNC firmwares is that they very often keep
a packet on transmit queue until it goes out without conception of timing
out from the queue.  Now if a site is "busy" so that a digipeater is
constantly receiving something (including packets), but considers channel
to be busy, how long it keeps packets to be digipeated in the queue?
When will the duplicate detection time out?

> Reuben

73 de Matti, OH2MQK