search

hessu / aprsc

aprsc, a core APRS-IS server
119 stars 38 forks source link

Denied Packets (Issue #48) #82

Closed na7q closed 7 months ago

na7q commented 8 months ago

I couldn't re-open the original issue. So doing this one for the time being.

There is a clear issue with stations being on the same server and using RF. Making traffic literally impossible at times. I think there needs to be something done about this. I'm not sure what at this time.

Recently I noticed if my Messenger APRS client is logged into the same APRS server as another client. If I send a message via RF from the Messenger client, to another IS only client on the same server, the server simply says "delete", and it's gone.

Example: NA7Q-1 is an RF and IGATE station. SMS is a BOT on the same server as NA7Q-1. Sending a message via RF to SMS, denies the packet because it was over RF while it is simultaneously logged in to the server. If a message from NA7Q-1 to SMS is sent ONLY on the server, everything works fine.

While I do understand this a complex problem, and actually happens a lot more than people realize from what I'm now seeing.

hessu commented 7 months ago

Hi,

https://github.com/hessu/aprsc/issues/48#issuecomment-720755242 still describes the problem and the solution.

The Messenger APRS client needs to send the message to both RF, and to the APRS-IS, at the same time. This is the solution to the problem.

If it sends the packet only to RF, and is at the same time connected to the APRS-IS, the APRS-IS server it is connected to will drop the packets as looped-back packets, as it is expecting that they would be entering the APRS-IS from the client socket using that callsign-SSID to log in.

na7q commented 7 months ago

That seems to be the opposite of a solution. Thus defeating the purpose of APRS as a whole. There has to be a real answer to this real problem.

You also state "at the same time". Based on exact timestamps, or within a timeframe? Why do I ask this? Because APRS with VARA HF is at MINIMUM going to take about 12 seconds between IS and RF to IS. We're looking for functional, not dysfunctional operation.

hessu commented 7 months ago

This functionality is not specific to aprsc; aprsc is just doing what javaprssrvr was doing, according to the original specification.

Please take the discussion to APRSSIG for example, maybe we can get comments from Pete Loveall who probably made the original choice of dropping these packets, 20-30 years ago when there were serious loop issues breaking the APRS-IS.