Client Connectivity Quirks in Omada Wireless Network

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

Client Connectivity Quirks in Omada Wireless Network

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Client Connectivity Quirks in Omada Wireless Network
Client Connectivity Quirks in Omada Wireless Network
2024-04-23 16:00:08
Model: ER7206 (TL-ER7206)  
Hardware Version: V1
Firmware Version: 1.4.1 Build 20240117 Rel.57421

Problem Statement:

  • WiFi distribution network over 9 AP's works fine 95% of the time.  The other 5% is intermittent enough that makes it difficult to attribute cause.  
  • Client (smartphone, or TV streaming device) can go into buffering, and streaming stops.  Slow internet browsing.  Speed can drop to modem speeds (56kbps as an example).  
  • Attaching to a different SSID or cycling device power seems to restore full connectivity.  But issue will happen again in the next 20m to 2 hours.  
  • With few clients on this network and light traffic, SL speeds seem to be typical at first connection (80 Mbps+).  Eventually, the DL speed can be artificially slow (5Mbps DL, 13 Mbps UL), that show up as a faster upload.  Issue continues to degrade towards dial-up modem speeds.  Switching to SL directly (phyisically) can yield the 80 Mbps+ speeds, so SL speed is ruled out.    
  • Putting an independent WiFi router on a SL terminal yields maximum SL speeds with no loss of connectivity or buffering issues.  
  • MOOCH is the guest network, open and BW limited.  This issue can affect this too.  
  • Logs show occassional failed authentication for a client device as they roam from AP to AP.   Following two examples are the only type of failure events logged. 
  • [Failed]Joe-s-S22-Ultra failed to connected to Bldg2 2nd Flr with SSID "Bldg2" on channel 11 because WPA Authentication failed.(1 time in a minute)
  • [Failed]joe-s-S22-Ultra failed to connected to Bldg2East with SSID "Bldg2" on channel 6 because the Association times out.(1 time in a minute)
  • No other logs seem to show any useful clues.  Seems I'd have to use a laptop until the issue is experienced and do a Wireshark capture.   
  • Not dependent on signal strength.  Issue can happen with -70 dBm 5 GHz or 2.4 GHz.  
  • Seen "No Internet Connectivity" issues on smartphones.  DHCP successful, but connection stated as "no internet".  Client devices successfully responds to PING.  Older phone, or other compatibility issue not ruled out.  Could be red-herring.  
  • Overall, the clients are happy, and don't seem to notice issues during sporadic use.  Streaming failures are noticed and complaints made.  

 

WDS description:  

Omada 9 AP network covers 3 buildings and surrounding area.  Three Omada switches, GW and OC200 controller.  Internet is sourced from two SL terminals located on different buildings.  While one SL is colocated with GW and Switch, the second is on a different building and brought back to the GW through as VLAN30 over Ethernet, then untagged and fed through an Ethernet SFP into the SFP WAN GW port.  VLAN30 sole purpose is a point-to-point transport to bring the second SL internet feed to the GW.   

 

LAN is default for "Building 2" SSID and is also the management LAN.  This means 192.168.0.0/24 is the management LAN and the client facing distribution LAN.  

Building 3 SSID operates over VLAN33 and is 192.168.33.0/24.  Same issues.  

 

Configuration options: 

Load Balance is enabled.

SSID routing is enabled to send each SSID through it's respective SL terminal.  Easy to turn off and revert to only load balance.  Both methods attempted, with same results.  

I recall that even with only one SSID and one SL terminal, this issue did happen on the default LAN (management and client).  

Have NOT attempted to put both SSID on VLAN and separate management... leaving it on default 192.168.0.0/24.  

Firmware for ALL devices is up-to-date relying on Omada SDN update feature.   

 

This is like some sort of memory leak...or the GW looses track of client traffic switching.  What next?  Where to look?  Any insight or vectors are appreciated.  

 

See diagram.  

  0      
  0      
#1
Options
6 Reply
Re:Client Connectivity Quirks in Omada Wireless Network
2024-04-23 16:22:32

  @RF_Dude 

 

it looks like it should work, I wonder if you can send a screenshot of how you configured vlan30 interface

 

  0  
  0  
#2
Options
Re:Client Connectivity Quirks in Omada Wireless Network
2024-04-23 16:49:46

  @MR.S YES, it should work... and it does most of the time.  Dom3 is basically Bldg3.  Excuse the nomenclature substitution.   

 

VLAN results are below, and how the switch profiles are set up.  Policy Routing when I've tried using it seems to work well.  For consumer level use, this GUI does simplify a lot of the usual port definitions necessary for commercial routers and OS, tag ingress and egress points, etc.  There is a bit of second guessing the built in scripting and limitations how VLAN's get tagged or untagged at each switch port, or what is presented to an AP.  

 

 

 

 

  0  
  0  
#3
Options
Re:Client Connectivity Quirks in Omada Wireless Network
2024-04-23 17:06:29

  @RF_Dude 

I have some suggestions based on what I see here.

 

 

I would not have vlan30 on the switch and router as long as you are going to use the switch against the WAN interface on the router.

so my suggestion is delete vlan30 make it again with switch only, you don't need vlan30 on the router anyway

 

 

 

I wouldn't tag that port either, it should be untagged.

 

 

 

  0  
  0  
#4
Options
Re:Client Connectivity Quirks in Omada Wireless Network
2024-04-23 21:33:55

  @MR.S Thanks for catching that first issue GW and SW for VLAN30.  I'll change to SW only.  

 

Regarding the SL to SW conneciton, it is untagged out of SL, but gets tagged at the ingress point, being Port 8 of that switch.  Just checking with you that we are both clear... that the way I show it, it looks tagged out of the SL.  Don't even know if that is possible.  This is where the consumer Omada interface is confusing... we create the VLAN, and then declare the VLAN active at two or more ports with a PROFILE to magically have a path.  This SL "transport" VLAN30 has no business in any AP, just to be delivered across the same TRUNK to the GW WAN port. 

 

BTW, the switch traffic statistics are almost 10X higher for wired, than for wireless.  All the clients are wireless.  So that trunk passing through all three switches is a traffic multiplier!  

 

Both SL terminals have unique dynamic (private 100.117.75.XXX) IP assigned, but they both appear in the same subnet and SL Gateway (100.64.0.1).   Hoping that doesn't confuse the Omada GW and it's connection/socket tracking for load sharing.  

 

Appreciate your eyes looking at this and insight.  

 

Tony 

  0  
  0  
#5
Options
Re:Client Connectivity Quirks in Omada Wireless Network
2024-04-23 22:17:55

The "Application" GW and SW or SW only is greyed out and is not selectable.  This transport only VLAN should only exist in the switches.  Unless there is another setting elsewhere that would enable it?

 

There also an AP configuration screen that is similarly greyed out and inflexible.  Appears to be for setting up a VLAN association with an SSID.  Dom3 (OK, nomenclature, I tried to called it BLDG3 for this discussion, so ignore) should be associated with VLAN33, but this is only possible if OVERRIDE is ENABLED, then VLAN checkbox becomes enabled.  When I try this, the SSID fails.  It has been a firmware revision or two since I last tried.  

  0  
  0  
#6
Options
Re:Client Connectivity Quirks in Omada Wireless Network
2024-04-24 05:03:25

  @RF_Dude 

 

To answer the last first :-)

 

You have to delete vlan interface and recreate it with switch only..

 

 

about SSID override, what do you want with that? 

I think this function is nice if you want a different SSID on an access point but have nothing to do with the SSID configurations other than chang SSID on spesific Access Point. don't use override if you dont need that,

 

 

  0  
  0  
#7
Options