¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

TCP-Master/Slave Links


 

Hello all,

I have been gradually converting unreliable TCP-Master/Slave links to UDP.? I still have 3 left that are not reliable:

MAP KD5LPB-7 <address-removed> TCP-Master 10093 B ? ; KD5LPB BPQ
MAP N9LYA-8
<address-removed> TCP-Master 10093 B ? ? ; N9LYA BPQ
MAP NC6J-4 <address-removed> TCP-Master 10093 B ? ? ; NC6J BPQ


As of right now the link with N9LYA-8 is up, but it seems to go down often. It's interesting that all 3 above are using TCP 10093. There doesn't seem to be an issue in general with using the same TCP port on the Master side, though.? There are two cases below that are reliable that both use 10200. Also I used to have two similar AXTCP links with PE1RRR-5 and PE1RRR-7 on TCP 10200 that were reliable.

The following are reliable:
MAP KE0GB-7 <address-removed> TCP-Master 20093 B? ?? ; KE0GB BPQ
MAP N9HWP-7 <address-removed> TCP-Master 10090 B ? ? ; N9HWP BPQ
MAP PI1LAP-7 <address-removed> TCP-Master 10200 B ?? ; Pi1LAP BPQ
MAP W0ARP-7 <address-removed> TCP-Master 10200 B ? ? ; W0ARP BPQ
MAP WA2UET-7 <address-removed> TCP-Master 10093 B ?? ; WA2UET BPQ

The Slave side is the one that does the "heavy lifting". It must port-forward the applicable TCP port to BPQ. If you see your node among the 3 at the top, feel free to contact me about changing back to UDP. When I first moved to the current QTH, I set up quite a few AXTCP links in an attempt to work around Carrier Grade NAT. In the meantime I did set up a means to support UDP again.

73,
Lee K5DAT

Join [email protected] to automatically receive all group messages.