@StevenB_BE 

 

Just for giggles... have you confirmed these clients have a good signal?  If they're sitting on the edge, dropping an IP and reconnecting can happen.

 

 

  @KimcheeGUN 

Good suggestion but yes, they all had a good signal at the time. With the last two they were literally 3 meters away from the AP with nothing in the line of sight in between. 

  @StevenB_BE 

 

So here is my next question...  Did you confirm the signal within the AP or the Omada controller?  

 

The reason I'm asking is due to the fact if your clients are not roaming properly, they could be pulling from another AP further away.  Even though they're 3M aways from an AP.

 

 

 

 

  @KimcheeGUN 

Valid point, I looked on the device itself. Is there any way I can find the signal strength for a specific device at a specific past moment in time (for which the session is no longer active)? I looked at the different logs in the Omada portal but was unable to find it.

New occurence:

- (different) client device

- visible in the Omada portal as connected client but no activity (0 MB exchanged since beginning of the session)

- Omada portal shows an IP address

- the device itself doesn't get an IP address

- I tried starting an app to check the WiFi signal strength (Wi-Fi Sweetspots) but that doesn't work because the device needs to be connected to the WiFi network to be able to scan

- Wireshark shows continuous requests from the device to the switch to get an IP which is declined every time

What I did after this is download Network Analyzer on my own phone to see if it can be used without connection to the WiFi (only to measure the WiFi signal strength). The app automatically shows your network info (no option to test the signal strength) and offers the option to scan your network - which I did. For some reason this also triggered the switch because the device above all of a sudden did get its IP address (while it had been trying to get one for over 30 minutes). Both devices were in front of me and there was hardly a second between the scan and the first signs of WiFi connection on the other device (numerous messages of social media apps).

The WireShark log shows the switch starting to offer IP addresses again at that exact time (07:06:55 UTC):

 

  @StevenB_BE 

 

Also need to confirm that the clients that are currently having problems are all wired or wireless connections?
What is the overall network topology of your network?
Are only the clients connected to the portal having problems?

 

What is the version of the controller?

  @Virgo 

- Only the wireless clients have this issue

- The network is flat. Single range, no VLANs

- Clients do not use the captive portal at all (not configured)

- Controller: OC200 v1.0 5.4.7 firmware 1.18.3 Build 20220715 Rel.56221

  @StevenB_BE 

 

Based on the first few packet capture images you provided, the Mac address shown in the Decline specific information does not appear to be that of the tplink switch.

Normally, if this is the switch replying to the Decline, the Mac address shown in it should be able to be resolved and show TP-Link, as your last image shows.

Your suspicion is correct, there is another DHCP Server in your network that is messing up.

  @StevenB_BE 

by wireshark handbook, dhcp decline means the dhcp server receive the ACK but due to the conflict of ip, it refuses to assign an ip.

have you checked the dhcp range? is that enough for your devices? does it run out of dhcp ips?

from the reply of 192.168.0.1, assuming that your router is this ip. 

is this device using 192.168.0.5? I don't recall tp-link router assign from 0.2 to 0.254. usually from 0.100-0.199

how about your router? do you reserve anything on that?

@Virgo The first reply comes from one of the client devices (an iPhone). The device in the second screenshot is indeed the router (and the only device to host a DHCP server in the network)