Business Community > WiFi > Lost Access to All APs after Merging Omada
< WiFi

Lost Access to All APs after Merging Omada

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Lost Access to All APs after Merging Omada

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Lost Access to All APs after Merging Omada
Lost Access to All APs after Merging Omada
2020-02-04 08:55:21
Model: EAP245  
Hardware Version: V1
Firmware Version: 1.4.0

Hi All,

 

I've exhausted all my current knowladge and can't seem to find a solution on this:

 

I was trying to migrate my current EAPs from one Omada Controller to another as I've upgraded my current "services" server to a new virtualized ESXi host (yay exciting).

 

I'm using a docker image from https://hub.docker.com/r/mbentley/omada-controller (so you can see my configuration) (I'm running a minimal CentOS 7 Installation with the latest version of docker)

 

When I actually initiated the migration... nothing happened. The new Omada controller did not see the APs and just showed them as disconnected, the old Omada controller saw the hosts as migrating. When I went to "unmigrate" the APs they wouldn't reconnect to the original Omada controller. I then reset one of the APs in hopes that I could re-discover them and then re-adopt the AP. No luck. I tried using the discovery toop, I tried the local network of the APs even though they worked before just fine before this.

 

I then shifted to troubleshooting the UDP port 29810 and the TCP ports 29811-3 as these, I've bee told were for discovery. My netstat -l shows that I am listening on these ports

 

 

[root@Omada-Zabbix-Grafana ~]# netstat -l

...
tcp6       0      0 [::]:29811              [::]:*                  LISTEN
tcp6       0      0 [::]:29812              [::]:*                  LISTEN
tcp6       0      0 [::]:29813              [::]:*                  LISTEN
...
udp6       0      0 [::]:29810              [::]:*
...

 

Odd an frustrating... I thought, maybe it's because it's looking for ipv6 and not ipv4... nope, apparently that doesn't matter because every ipv4 is also technically an ipv6. Cool info to know but, no leads.

 

I then shifted to tcpdumps to see if the traffic was actually getting there.

 

I see broadcast traffic from the reset AP on port 29810 but do not see any traffic from the AP on the rest of the ports.

 

I honestly don't know where to go form here but it MUST be a configuration issue with my Omada system but I just really don't know where!

 

Help me TP-Link Community, you're my only hope!

  0      
 
  0      
 
#1
Options
6 Reply
Re:Lost Access to All APs after Merging Omada
2020-02-04 11:37:12

 

sremich wrote

I thought, maybe it's because it's looking for ipv6 and not ipv4... nope, apparently that doesn't matter because every ipv4 is also technically an ipv6.

 

What makes you think so? IPv4 and IPv6 are two completely different protocols, albeit they can co-exist in the same network.

 

Did you disable IPv4 on your new system? Omada EAPs do not (yet) support IPv6 as far as I know.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#2
Options
Re:Lost Access to All APs after Merging Omada
2020-02-05 00:42:08

@R1D2 

 

Thanks for the info, that's totally fare, though I read somewhere that when linux is listening on tcp6 and udp6 it's also listening on tcp and udp for ipv4.

 

However, I went and disable ipv6 in the grub loader and verified that my "netstat -l" output indeed reflected that we were still listening on all the ports:

 

 

[root@Omada-Zabbix-Grafana ~]# netstat -l

....

tcp        0      0 0.0.0.0:29811           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:29812           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:29813           0.0.0.0:*               LISTEN
....
udp        0      0 0.0.0.0:29810           0.0.0.0:*
....

 

Any thoughts?

  0  
  0  
#3
Options
Re:Lost Access to All APs after Merging Omada
2020-02-05 01:13:21 - last edited 2020-02-05 01:38:51

 

sremich wrote

Thanks for the info, that's totally fare, though I read somewhere that when linux is listening on tcp6 and udp6 it's also listening on tcp and udp for ipv4.

 

This is called dual-stack mode and it's platform-specific. Some Linux systems let you enable this mode through net.ipv6.bindv6only kernel setting. But the program must support IPv6 nevertheless. If bindv6only is false, Linux binds to both, IPv4 INADDR_ANY (0.0.0.0) and IPv6 INADDR_ANY (::) when a program binds to the socket using IPv6 address IN_ADDR_ANY. But then you would see that in netstat output anyway.

 

In my opinion, this makes it difficult to write portable software and is something I would immediately disable on my Linix systems (like many other »smart« behaviors from featurists not caring about portability nowadays).

 

However, I went and disable ipv6 in the grub loader and verified that my "netstat -l" output indeed reflected that we were still listening on all the ports:

[root@Omada-Zabbix-Grafana ~]# netstat -l

....

tcp        0      0 0.0.0.0:29811           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:29812           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:29813           0.0.0.0:*               LISTEN
....
udp        0      0 0.0.0.0:29810           0.0.0.0:*
....

 

Any thoughts?

 

That looks good, except that Omada Controller also should listen on ports 8088 and 8043 (remaining ports are version-specific, following is from OC v3.2.6):

 

# netstat -tulpn | fgrep omada
tcp        0      0 0.0.0.0:8088            0.0.0.0:*               LISTEN      16748/omadad    
tcp        0      0 0.0.0.0:8043            0.0.0.0:*               LISTEN      16748/omadad    
tcp        0      0 0.0.0.0:29811           0.0.0.0:*               LISTEN      16748/omadad    
tcp        0      0 0.0.0.0:29812           0.0.0.0:*               LISTEN      16748/omadad    
udp        0      0 0.0.0.0:29810           0.0.0.0:*                           16748/omadad

udp        0      0 0.0.0.0:27001           0.0.0.0:*                           16748/omadad    
#

 

I'm not used to docker, but AFAIK you need port-mapping from the container to the docker host or the other container, right? Is this mapping active? Can you communicate between the two containers?

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#4
Options
Re:Lost Access to All APs after Merging Omada
2020-02-05 01:29:49

@sremich 

 

It is obviously that you fail to migrate the EAP devices. Please reset all the EAPs and adopt them again.

After that, please refer to page 133 of the user guide and try to migrate these devices again.

 

  0  
  0  
#5
Options
Re:Lost Access to All APs after Merging Omada
2020-02-05 04:48:37 - last edited 2020-02-05 04:52:58

 

R1D2 wrote

 

I'm not used to docker, but AFAIK you need port-mapping from the container to the docker host or the other container, right? Is this mapping active? Can you communicate between the two containers?

 

Correct, you need to expose the ports (in both containers) if you use bridged networking (which is the default). The alternative is to use dockers host network

https://docs.docker.com/network/host/

  0  
  0  
#6
Options
Re:Lost Access to All APs after Merging Omada
2020-02-05 04:55:31

 

ASCII wrote

 

R1D2 wrote

 

I'm not used to docker, but AFAIK you need port-mapping from the container to the docker host or the other container, right? Is this mapping active? Can you communicate between the two containers?

 

Correct, you need to expose the ports (in both containers) if you use bridged networking (which is the default). The alternative is to use dockers host network

https://docs.docker.com/network/host/

 

Let me add here that I would recommend to use bridged networking and *not* expose the mongodb server.

Having access to that service hidden is just one thing less to worry about

  0  
  0  
#7
Options

Information

Helpful: 0

Views: 1513

Replies: 6

About Us
Press
Copyright © TP-Link Corporation Limited. All rights reserved.