Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - n6ldj

Pages: [1]
1
This is for information only.

I had a completely reliable connection that would consistently auto-connect following outages, etc. for about four months.  Used public routable IPs on both ends, no firewalls.  Not one connection problem (other than a ISP outage) in 4 months, and we maintain a 24/7 nailed-up connection.**

I dropped the connection for about one hour to rearrange some DC wiring and could not reconnect.  Sip error, and a UDP error.  Rebooted in various sequences many times.   But nothing had changed.  I then noticed that the Radio RRC showed an ip address of 172.83.45.42 (actual) in the "Other Party" field.  That is not one of mine, as it should be from the Control RRC when connected.  I have a managed switch at the site so I disabled the switch port supporting the Radio RRC overnight, then was able to re-connect in the morning. 

I found a message here indicating that this condition might be Carrier Grade NAT (CGN), but the radio end is supplied by a small ISP so that is unlikely.

I then sniffed the traffic coming into the Radio RRC and noted that the IP above was coming in with a destination UDP port that matched the default SIP port, every few seconds.  My guess is that these were possibly SIP connection attempts, but they did not know the password as it never showed connected.  It remains unclear why I could not connect between their attempts as there was not a flood of these.  Maybe the RRC locks out/delays repeated attempts, and the access attempt was regular enough to prevent me from connecting.

I just changed all of the default ports on the devices, including the Web server port, which might resolve this issue for a while.  This is becoming mroe important over the last few years.     

** Unrelated, we had the radio end running through a firewall and nat'ed before this current arrangement.  This arrangement was extremely unreliable from a auto-reconnect perspective.  Maybe I had the ports setup wrong, but sniffing showed that that the Control RRC's auto-reconnection attempts would often use the default destination port numbers to reach the Radio RRC, instead of the ones I set for for it.  As a result, it would get stopped by the firewall and not re-connect.  We had two Radio RRCs on the same site router so one had to use non-default ports.  I believe this problem remains in V2.95.  FYI.   

2
Control unit occasionally uses default port numbers (1300X), not the ones I have set (1500X) under Advanced Settings / Ports.  However, the port numbers *displayed* using the web interface for the Control side remain the ones I have set; these never change.  When this problem occurs, the Control unit hangs and will not reconnect (even if I manually hit the Connect button).  The Control end must be rebooted/restarted.  Proved this yesterday while sniffing IP traffic.   The Control was using 1300X towards the remote site (as the destination port) even though it has always been set for 1500X.

The attached snip was from the control (left side) while the right shows what was coming into the remote router at the radio side.
   
The radio end uses NAT (WAN incoming Port 1500X> NAT > LAN Port 1300X) since we have another Radio RCC there using the 1300X series ports.  Control end is a public IP, no NATTing, firewall, etc.

Not yet sure what creates this condition.  I had cycled power at the Radio end when it occurred.  But I cannot reproduce this.  Yet, this continues to occur every few weeks or months.

Using V2.91.   The Source (173.) and Destination (208.) are from the Control end (208. is the remote site).  Remote site router is only listening for 1500X.   Packets are dropped at the remote Radio site.   

3
Are the ports listed here (see attached) outgoing (destination) ports or incoming (source) ports, from the perspective of the Control Side?

By outgoing, I mean the packets leaving the control side , towards the Radio side.   Incoming would be from the Radio side, towards the control.

I am noticing some strange port assignment issues, once I find the Control Unit in "disconnected" mode, when it has Auto Reconnect set for "Yes".

Greg   






4
I used Dyndns for years; it was free when I started but was astonished to find that they wanted $55 annually now.  Shame on me for using auto-pay and ignoring their price increases.  We are done.         

Microbit might consider adding Google DNS - looks to be a straightforward protocol.     

https://support.google.com/domains/answer/6147083?hl=en#

I already had a domain URL for my email through Google (only $10/yr.) - they allow you to use your own domain instead if having to use one of theirs.  Really simple to setup, and allows you to enter your own static IP for address and associate it with a domain URL.   Simply add and "A record".     


Pages: [1]