Re: BPQ APRS IGate Issue
- Thank you for your analysis. If I was seeing a commonality of entry points for the IGates having this issue, I would immediately zero in on that server's configuration but I am not seeing that. This appears to be a very rare and specific issue which appears to be happening independent of the server the IGate is connected to. Nonetheless, I will also continue to pursue this from the server side to see if there could be an overrun occurring there.
If it was at the server, I would think I would be seeing this across more IGates/servers and it would be of a more random nature. One of the IGates currently having the issue (an aprsD IGate) is connected to second.aprs.net which has hundreds of connections, supply packets at a very high rate so I would think I would see this on at least one other IGate/server connected to second but I am not. That is why I focused in on the individual clients. Of course, aprsD is on Linux while BPQ32 is on Windows so they are using 2 completely different stacks.
Question: do you disable the Nagle algorithm (set TCPNODELAY) for your feed? You should to prevent buffering in the stack beyond a single packet. APRS-IS servers disable Nagle on their end to help improve near-real-time performance.
I will continue to pursue this from the server angle as well. If you find anything on your end, please let me know so I can see if we can have the aprsD sysops do something to their configurations. Thanks.
--- In BPQ32@yahoogroups.com, "John Wiseman" <john.wiseman@...> wrote:
> Hi Pete.
> Welcome to the group.
> BPQ32 doesn't have to use KISS TNCs (it can work with the UZ7HO soundmodem,
> or a SCS Tracker in host mode), but if configured for a KISS TNC, it will
> ignore any non=KISS packets. Also it doesn't need packets to be terminated
> by CR LF or either.
> From the one example you've quoted, it looks more like the packets are being
> merged after being converted to APRS-IS format - the two qAR's in the packet
> seem to suggest that. Also the first packet has been truncated. My first
> thought that it is the code is not correctly handling an EWOULDBLOCK on the
> send of the first packet. If the stack had accepted part of the packet, and
> the code didn't correctly resend the unsent data we would see that effect.
> While this doesn't seem very likely, as the volume of traffic is pretty low,
> and the microsoft stack can normally take a lot of data without blocking,
> maybe with some network loading conditions it could happen. Anyway, I'll
> have a look at that code, and see what I can find.