Hi @Birillo 

Thanks for posting in our business forum.

Birillo wrote

Hi @Clive_A 

thanks a lot for your help!

 

The device is in this status since July!

It never reconnected to the controller ....except for the VPN that continue working as usual.

FYI ssh is enabled on the ER605 ..but for what I saw there is no useful command that could help.

I can reach the web interface ..but it says that it is managed by Omada.

In the same network I can reach a small linux device (arm64). I tried to run there the Discovery utility but without any luck. 
I tried different JRE distribution and JavaFX libraries but I have not been able to successfully run the utility. It crashes as soon it starts.

 

 

 

If possible, I'd suggest you use the discovery utility to re-adopt the device. Give it a try.

So far I have been running the connection fine for hours. I'll leave it for a day and see what happens.

We don't provide any troubleshooting or debugging SSH command lines or SSH tech support for the ER605. I know that there are lines may be debunked by people but I stop here.

I recall if the device is under the controller, it cannot modify SSH or the lines are not effective. ER8411 offers the console user guide which you can take a look at yourself.

Hi @Birillo 

Thanks for posting in our business forum.

Birillo wrote

 Thanks @Clive_A 

 

In the meantime, are you please able to point me to the right JRE distribution for arm64?
I am really struggling to run the Discovery tool.
 

Is it normal that running the tool locally I cannot find the local ER605?

You should run the discovery utility on the remote site. In your case. So you should remote to the remote LAN. A computer. Run it there and point the devices in this controller IP. It's LAN IP because you are running it over VPN tunnel.

Sorry that I don't have a Linux environment. You should look at the controller section where people post guides for installation of the Controller (in a Linux environment), I remember.

Hi @Birillo 

Thanks for posting in our business forum.

Been running it for a day and there is no disconnection. Nor the VPN. I suggest you run Wireshark and ping and monitor this for some time.

Just like I asked earlier, how often does it happen? Any pattern?

Use Wireshark on the remote site. Filter should be icmp or ip.addr == x.x.x.x(this should be VPN IP) and tcp.port == 29814.

You should see every few seconds, there is a sync packet between the controller and the remote router(with the VPN IP the client gets).

I'd like to see if it's the remote stopped sending over the sync or it is your VPN stopped stealthily.

Hi @Birillo 

Thanks for posting in our business forum.

Birillo wrote

 Hi @Clive_A,

I have good news.
I used Wireshark as you suggested and I noticed that there was nothing filtered with port 29814.
So just for test I applied the filter on udp 29810 and I could see packets coming from the router.

So I have redirected the packets on the Linux server coming from UDP:29810 and TCP:29814 to the wan ip of the controller.
It has been re-adopted and it is now connected.

 

This is what I did:
socat -T15 udp4-recvfrom:29810,reuseaddr,fork udp:xxxxx:29810

socat tcp-listen:29814,reuseaddr,fork tcp:xxxxx:29814

 

At this point I assume that happened because of the dynamic public IP on the controller site. Also if this was always the case for years.

There is something I am missing in how Omada works, sorry.
Is there a way to use a dynamic IP that the router can use in case it needs to reconnect to the controller?
 

Thanks a lot for your help

But if it is a dynamic IP on your WAN, then it should not be a problem that you cannot connect back. I mean if your WAN IP has been changed, you should at least see a log showing that your WAN disconnects during the DHCP release. You should directly face a VPN issue instead.

But as you reported, there were no logs or any evidence showing the WAN is ever down or the VPN is disconnected.

If your WAN is dynamic, use DDNS to fix the IP problem. That's the way to fix the VPN establishment and then you take port forwarding for adoption into consideration.
Seems to be some order mistake or logic issue.