Wifi Connection but randomly no internet

maxna · April 29

Using 6 Zyxel Cloud WiFi6 AX1800 Wireless Access Point [NWA50AX] with one Zyxel 8-Port Gigabit PoE Switch [GS1900-10HP]
clients are connected to the wifi network but randomly cannot connect to the internet

plase advise what the issue for this could be

Zyxel_Nami · April 30

Hello @maxna

Please check if the end devices have received an IP address after connecting to the WiFi network. If the devices haven't received an IP address, please verify that the Switch and Router/Gateway/DHCP server are configured correctly for VLAN and DHCP.

Could you also specify if this issue is affecting all end devices or only specific ones? Please share the MAC addresses of the affected devices via private message by clicking on my name and selecting 'Message'.

Alternatively, you may enable Zyxel Support Access to facilitate our assistance.

maxna · May 2

hi

dhcp is enabled
this randomly affects all kind of devices windows/mac + adroid/ios

i will enable Zyxel Support Access now

Zyxel_Nami · May 3

Hi @maxna

clients are connected to the wifi network but randomly cannot connect to the internet

⇒ When you mention this, are you referring to clients that show as connected to an SSID but somehow can't reach the Internet, or are the clients completely disconnected from an SSID altogether?

If it is the first issue, please help us with the following ping checks. This test can help identify which parts are experiencing failures:

Ping the connected NWA50AX (identify the AP using the Clients tab)
Ping the GS1900-10HP switch
Ping your gateway
Ping 8.8.8.8

Let us know at which device the ping fails. Ensure that your PC allows incoming ICMP packets.

Additionally, your Nebula site shows 5 of 6 APs running at 100M link speed. Please refer to the this FAQ to understand and potentially resolve this status.

In the meantime, considering the presence of numerous IoT devices on your site, most of which are likely connected to the 2.4GHz band, optimizing wireless configuration is crucial. Here are some tips:

Configure the dedicated SSID for your IoT devices, enabling only 2.4GHz band only. Please refer to this FAQ
Adjust Maximum output power with Deployment selection, following the below screenshot and this FAQ

maxna · May 6

thank you

yes - clients that show as connected to an SSID but somehow can't reach the Internet

following the ping results, no ping failed
i was not abel to find out the IP of the switch

APs seem ok
8.8.8.8 seems slow to me

i am aware of the issue of the APs running at 100M link speed - also this seems random - it has worked and then suddenly it changed to orange without any phisical changes

now i changed the cable on one AP and this is also green now - but the other one was orange for a while now green again
could this be related to the ports of the switch?

anyhow also with orange APs we always had connectivity - now some devices connect to SsID but not reach internet

i also changed all APs that are connected to IoTs to 2,4 only…

please advise

foyer
PING 192.168.0.1 (192.168.0.1): 56 data bytes

64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=4.234 ms

64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=3.740 ms

64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=6.692 ms

64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=3.494 ms

64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=8.025 ms

64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=3.199 ms

64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=3.366 ms

64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=7.893 ms

eventraum

64 bytes from 192.168.0.141: icmp_seq=0 ttl=64 time=6.909 ms

64 bytes from 192.168.0.141: icmp_seq=1 ttl=64 time=3.308 ms

64 bytes from 192.168.0.141: icmp_seq=2 ttl=64 time=3.745 ms

64 bytes from 192.168.0.141: icmp_seq=3 ttl=64 time=7.302 ms

64 bytes from 192.168.0.141: icmp_seq=4 ttl=64 time=4.436 ms

64 bytes from 192.168.0.141: icmp_seq=5 ttl=64 time=7.126 ms

64 bytes from 192.168.0.141: icmp_seq=6 ttl=64 time=3.612 ms

64 bytes from 192.168.0.141: icmp_seq=7 ttl=64 time=3.582 ms

buero

PING 192.168.0.234 (192.168.0.234): 56 data bytes

64 bytes from 192.168.0.234: icmp_seq=0 ttl=64 time=7.051 ms

64 bytes from 192.168.0.234: icmp_seq=1 ttl=64 time=3.581 ms

64 bytes from 192.168.0.234: icmp_seq=2 ttl=64 time=3.619 ms

64 bytes from 192.168.0.234: icmp_seq=3 ttl=64 time=3.613 ms

64 bytes from 192.168.0.234: icmp_seq=4 ttl=64 time=3.790 ms

64 bytes from 192.168.0.234: icmp_seq=5 ttl=64 time=3.524 ms

64 bytes from 192.168.0.234: icmp_seq=6 ttl=64 time=3.584 ms

64 bytes from 192.168.0.234: icmp_seq=7 ttl=64 time=3.562 ms

64 bytes from 192.168.0.234: icmp_seq=8 ttl=64 time=3.558 ms

64 bytes from 192.168.0.234: icmp_seq=9 ttl=64 time=3.526 ms

64 bytes from 192.168.0.234: icmp_seq=10 ttl=64 time=3.538 ms

64 bytes from 192.168.0.234: icmp_seq=11 ttl=64 time=7.295 ms

64 bytes from 192.168.0.234: icmp_seq=12 ttl=64 time=3.300 ms

64 bytes from 192.168.0.234: icmp_seq=13 ttl=64 time=3.235 ms

64 bytes from 192.168.0.234: icmp_seq=14 ttl=64 time=3.707 ms

coworking

PING 192.168.0.252 (192.168.0.252): 56 data bytes

64 bytes from 192.168.0.252: icmp_seq=0 ttl=64 time=3.962 ms

64 bytes from 192.168.0.252: icmp_seq=1 ttl=64 time=3.068 ms

64 bytes from 192.168.0.252: icmp_seq=2 ttl=64 time=3.436 ms

64 bytes from 192.168.0.252: icmp_seq=3 ttl=64 time=3.487 ms

64 bytes from 192.168.0.252: icmp_seq=4 ttl=64 time=3.377 ms

64 bytes from 192.168.0.252: icmp_seq=5 ttl=64 time=4.223 ms

64 bytes from 192.168.0.252: icmp_seq=6 ttl=64 time=5.887 ms

foyer

PING 192.168.0.87 (192.168.0.87): 56 data bytes

64 bytes from 192.168.0.87: icmp_seq=0 ttl=64 time=5.918 ms

64 bytes from 192.168.0.87: icmp_seq=1 ttl=64 time=2.389 ms

64 bytes from 192.168.0.87: icmp_seq=2 ttl=64 time=3.021 ms

64 bytes from 192.168.0.87: icmp_seq=3 ttl=64 time=2.823 ms

64 bytes from 192.168.0.87: icmp_seq=4 ttl=64 time=3.011 ms

64 bytes from 192.168.0.87: icmp_seq=5 ttl=64 time=2.106 ms

64 bytes from 192.168.0.87: icmp_seq=6 ttl=64 time=4.860 ms

64 bytes from 192.168.0.87: icmp_seq=7 ttl=64 time=6.185 ms

64 bytes from 192.168.0.87: icmp_seq=8 ttl=64 time=2.809 ms

64 bytes from 192.168.0.87: icmp_seq=9 ttl=64 time=3.002 ms

64 bytes from 192.168.0.87: icmp_seq=10 ttl=64 time=2.909 ms

stadtakademie

PING 192.168.0.144 (192.168.0.144): 56 data bytes

64 bytes from 192.168.0.144: icmp_seq=0 ttl=64 time=7.326 ms

64 bytes from 192.168.0.144: icmp_seq=1 ttl=64 time=7.280 ms

64 bytes from 192.168.0.144: icmp_seq=2 ttl=64 time=3.867 ms

64 bytes from 192.168.0.144: icmp_seq=3 ttl=64 time=3.838 ms

64 bytes from 192.168.0.144: icmp_seq=4 ttl=64 time=3.324 ms

64 bytes from 192.168.0.144: icmp_seq=5 ttl=64 time=7.181 ms

64 bytes from 192.168.0.144: icmp_seq=6 ttl=64 time=3.533 ms

64 bytes from 192.168.0.144: icmp_seq=7 ttl=64 time=7.343 ms

64 bytes from 192.168.0.144: icmp_seq=8 ttl=64 time=7.373 ms

64 bytes from 192.168.0.144: icmp_seq=9 ttl=64 time=3.443 ms

64 bytes from 192.168.0.144: icmp_seq=10 ttl=64 time=3.493 ms

64 bytes from 192.168.0.144: icmp_seq=11 ttl=64 time=3.475 ms

64 bytes from 192.168.0.144: icmp_seq=12 ttl=64 time=3.599 ms

kaiserssal

PING 192.168.0.17 (192.168.0.17): 56 data bytes

64 bytes from 192.168.0.17: icmp_seq=0 ttl=64 time=7.085 ms

64 bytes from 192.168.0.17: icmp_seq=1 ttl=64 time=3.417 ms

64 bytes from 192.168.0.17: icmp_seq=2 ttl=64 time=7.016 ms

64 bytes from 192.168.0.17: icmp_seq=3 ttl=64 time=3.330 ms

64 bytes from 192.168.0.17: icmp_seq=4 ttl=64 time=3.435 ms

64 bytes from 192.168.0.17: icmp_seq=5 ttl=64 time=3.624 ms

64 bytes from 192.168.0.17: icmp_seq=6 ttl=64 time=7.720 ms

64 bytes from 192.168.0.17: icmp_seq=7 ttl=64 time=8.469 ms

64 bytes from 192.168.0.17: icmp_seq=8 ttl=64 time=8.003 ms

64 bytes from 192.168.0.17: icmp_seq=9 ttl=64 time=7.946 ms

64 bytes from 192.168.0.17: icmp_seq=10 ttl=64 time=3.406 ms

64 bytes from 192.168.0.17: icmp_seq=11 ttl=64 time=4.271 ms

64 bytes from 192.168.0.17: icmp_seq=12 ttl=64 time=3.588 ms

64 bytes from 192.168.0.17: icmp_seq=13 ttl=64 time=7.308 ms

64 bytes from 192.168.0.17: icmp_seq=14 ttl=64 time=3.995 ms

64 bytes from 192.168.0.17: icmp_seq=15 ttl=64 time=3.416 ms

64 bytes from 192.168.0.17: icmp_seq=16 ttl=64 time=3.467 ms

64 bytes from 192.168.0.17: icmp_seq=17 ttl=64 time=3.506 ms

64 bytes from 192.168.0.17: icmp_seq=18 ttl=64 time=3.297 ms

64 bytes from 192.168.0.17: icmp_seq=19 ttl=64 time=4.044 ms

PING 8.8.8.8 (8.8.8.8): 56 data bytes

64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=17.181 ms

64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=17.772 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=19.226 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=20.135 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=19.743 ms

64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=17.389 ms

64 bytes from 8.8.8.8: icmp_seq=6 ttl=118 time=21.009 ms

64 bytes from 8.8.8.8: icmp_seq=7 ttl=118 time=22.061 ms

64 bytes from 8.8.8.8: icmp_seq=8 ttl=118 time=21.927 ms

64 bytes from 8.8.8.8: icmp_seq=9 ttl=118 time=21.579 ms

64 bytes from 8.8.8.8: icmp_seq=10 ttl=118 time=21.166 ms

64 bytes from 8.8.8.8: icmp_seq=11 ttl=118 time=20.836 ms

64 bytes from 8.8.8.8: icmp_seq=12 ttl=118 time=21.662 ms

64 bytes from 8.8.8.8: icmp_seq=13 ttl=118 time=17.122 ms

64 bytes from 8.8.8.8: icmp_seq=14 ttl=118 time=25.239 ms

64 bytes from 8.8.8.8: icmp_seq=15 ttl=118 time=18.298 ms

64 bytes from 8.8.8.8: icmp_seq=16 ttl=118 time=21.048 ms

gateway

PING 192.168.0.1 (192.168.0.1): 56 data bytes

64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=3.681 ms

64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=3.653 ms

64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=6.839 ms

64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=4.335 ms

64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=3.304 ms

64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=4.635 ms

64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=3.428 ms

64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=7.044 ms

64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=7.525 ms

64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=3.415 ms

64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=4.839 ms

64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=4.328 ms

64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=3.787 ms

maxna · May 6

hi
can you please check this

Zyxel_Nami · May 6

Hi @maxna

following the ping results, no ping failed
i was not abel to find out the IP of the switch

⇒ To locate the IP of the switch, you can use the ZON Utility. You can download it from here. However, there's no need to ping the switch now, as all connections to the gateway and 8.8.8.8 are fine.

i also changed all APs that are connected to IoTs to 2,4 only…

⇒ I noticed that you have configured both SSIDs to use the 2.4GHz band. This means there is no 5GHz band available, limiting devices with 5GHz capabilities from connecting to the faster band, which is suitable for mobile devices, laptops, etc.

I recommend the following setup:

Choose one SSID exclusively for the 5GHz band.
Choose another SSID exclusively for the 2.4GHz band.
Allow IoT devices to connect to the 2.4GHz SSID.
Allow 5GHz capability devices to connect to the 5GHz SSID.

The APs themselves will broadcast both SSIDs unless otherwise specified.

You can check their capability at Clients > Access point clients > 'Capability' tab. Devices that support 802.11ax/ac are dual-band devices, while devices that support 802.11b/g are limited to the 2.4GHz band.

Regarding the end device you messaged, did you perform the ping test for it when the issue was occurring?

The below logs showed that it disconnected itself from the SSID at a signal strength of -61dBm. Initially, its signal strength fluctuated from -78dBm to -68dBm, suggesting that the device may have been searching for a better signal but couldn't find a suitable one.

To allow the end devices to connect and roam smoothly between each AP, the deployment should be checked and adjusted, especially in a multiple AP setup. Some points to consider:

Ensure APs are not placed too close or too far from each other. The overlapping signal should be around15-20% to optimize coverage. Please refer to the FAQ below for more details:
https://community.zyxel.com/en/discussion/22401/how-to-measure-signal-overlap-for-effective-client-roaming
Adjust the output power setting as recommended for multiple APs by referring to the FAQ below.
https://community.zyxel.com/en/discussion/14422/nebula-how-to-optimize-wireless-performance-with-deployment-selection-and-maximum-output-power

maxna · May 6

thank you
if i set u the IoT devices in a seperate SSID will they still be able to communicate with a client in another SSID?
eg printer, speaker etc

will check for the other points?
but how can this be related to the connectivity issues?

why did the AP "coworking" go back to orange status since friday? noting changed in the setup

Zyxel_Nami · May 7

Hi @maxna

if i set u the IoT devices in a separate SSID will they still be able to communicate with a client in another SSID?
eg printer, speaker etc

⇒ They can communicate with clients on another SSID as long as both SSIDs are configured in the same VLAN and subnet, as in your case.

will check for the other points?
but how can this be related to the connectivity issues?

⇒ Are you referring to the separate SSIDs, signal overlap, or output power?

why did the AP "coworking" go back to orange status since friday? noting changed in the setup

⇒ The orange status could be due to various reasons such as cable quality or the uplink device. We checked the AP via SSH remote, and it now shows the AP running at 100M.

You may check the Switch ports' status at Monitor > Port > Port > Status as the screenshot below to verify the speed.

maxna · May 13

hi
changed to power output of the APs also created a new 5ghz only ssid - issues still happening

just messaged you the mac adress that just had problems (now randomly connected and working)

issue seems to appear to devices that have not been connected to the network previously…

Zyxel_Nami · May 14

Hello @maxna

I received your message. It looks like the end device was attempting to connect to the SSID "Coworking" (dedicated 5GHz) on AP "Kaisersaal" but failed, as shown in the below screenshot. This indicates that the authentication process was not completed. Please double-confirm that the password was entered correctly.

If the password has been already correct, we should consider the channel utilization of the AP "Kaisersaal". Please see the below screenshot of AP Kaisersaal's Channel Utilization on May 13, 18:30 (UTC+2) (= 16:30, UTC+0) in the "Access point usage and connectivity" section. The data shows that the 2.4G channel utilization is at 82%, which is quite crowded. Also, you can see that the usage of 2.4GHz is consistently within 60-80% at all times, and higher compared to 5GHz, which may result in poor connections.

It is suggested to try configuring these settings in[Configure > Access points > Radio settings] and observe if it helps:

Disable Avoid 5G DFS channel to prevent channel interference.
Increase your WLAN rate control for 2.4GHz to 5.5Mbps, while 5Ghz to 12Mbps:
https://community.zyxel.com/en/discussion/14348/nebula-how-to-optimize-wireless-performance-with-wlan-rate-control

After these adjustments, if the issue still persists, please collecting the diagnostic info of the AP that the device is connecting and share with us via the private message. Below is the FAQ on how to collect it.

And also please provide us with the affected client information includes MAC address, connected time and SSID, client's screen record showing disconnection (if possible).

https://community.zyxel.com/en/discussion/17314/how-to-collect-the-nebula-ap-diagnostic-info-by-gui

Best regards,

Wifi Connection but randomly no internet

All Replies

Categories

Nebula Tips & Tricks

Nebula Help Center