It's actually part of an algorithm running on the IS servers that helps
facilitate transmit Igating. In the event that your IGate is beaconing
only on RF, the way that other IGates in your area "know" that your station
is connected to the Internet is via those beacons that look like they are
sent directly to the IS. Without those "fake" beacons, a nearby IGate
would gate a message addressed to your station from IS to RF when it really
didn't need to. So in a nutshell, it's part of a "little scheme" to
prevent gating packets from IS to RF when it's not necessary.
I think in the case of your test below, the IS server didn't know the
difference between a packet generated by your mobile vs. one generated by
your IGate due to using the same SSID.
I'm just the messenger on this one. :-)
Lee - K5DAT
On Sun, Jun 7, 2015 at 2:18 PM, Max Harper via aprssig <aprssig at tapr.org>
wrote:
> Then why does the timestamp on findu match the time the beacon was
> received back and not the time it was actually sent. I have noticed this
> behavior many times over the years using various Igate software programs. I
> can also duplicate the problem anytime.
>> Back years ago when I first discovered the problem I did a test. I
> configured my mobile station to the same ssid as my igate and drove to a
> digi that was about 25 miles away. Using only a few miliwatts of power I
> sent some beacons that my igate couldn't hear direct, only the digi. The
> beacons appeared as if my igate had sent them directly to the aprs-is with
> no sign of the digi.
>> I don't know if it is an igate problem or an aprs-is problem but I see it
> happen all the time. I can understand it being considered a duplicate, but
> why does the path get changed and made to look like it was sent direct to
> the aprs-is when it wasn't? And the example beacon WAS sent out RF only.
>> Max KG4PID
>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20150607/d9823a76/attachment.html>