No new IP requests when moving to new subnet w same SSID

[alexgill]

We have many sites, all with the same SSID.

When Apple macOS laptops join this one problematic site, it's failing to obtain an IP unless rebooted. Looking at a packet capture taken from a laptop, it sends an 'DHCP Request' to renew its invalid/previous IP and understandably receives a 'DHCP NAK', but thereafter ceases to issue a 'DHCP Discover' for a new IP. Apple uses an RFC for 'Detecting Network Attachment', and that's where I'm looking to see why they client doesn't realize it's on a new subnet/network.

The problematic site uses Meraki DHCP and a WLC for managing the APs.

Any thoughts appreciated. Thanks.

[pieterh]

"same SSID" does not necessarily mean it is considered the same WLAN/network by the client
that is why roaming between individual/stand-alone access points is  always problematic

do you use centralized configuration  where all access point join the same wireless controller ?
do you use centralized authentication for all sites?
if using different controllers do they share the same mobility group and share the same templates for this WLAN ?

[alexgill]

Thanks. So we have multiple sites, geographically apart, that are Meraki controller based and share the same configuration. Moving from one site to another is fine. Note, this problem isn't moving between APs within the office (aka roaming), but traveling to a site in town A to town B.

The site at town B where issues are occurring is unique in that it uses a WLC for the APs and manually configured with the same company-wide SSID/PSK -- so here, there's no centralization, although, it is using a Meraki security appliance solely as a firewall and DHCP server.

Laptops auto-join the saved SSID, but after attempting the IP renewal and DHCP NAK reply, fails to continue the process of requesting an IP. This could be explained as a client issue, but I'm searching for something in our network that's triggering this failing behavior.

[pieterh]

on the WLC site check if WPA+ TKIP is enabled. if so, then disable and allow only WPA2/AES

[alexgill]

Thanks. Interesting since we currently use "WPA + WPA2", and I understand WPA as utilizing TKIP, but it's not listed, although WPA2/AES is enabled. We are comfortable with changing it to "WPA2 + WPA3" under the Security/Layer2 options.

I am very curious. Could you share the thought behind your suggestion? Would that change perhaps get clients to recognize a site as distinct from the previous site (with identical SSID/PSK) and then properly request an IP? 

[MHM Cisco World]

Can I see the wlc l2 secuirty page?

MHM

[alexgill]

[MHM Cisco World]

since you not use FT + PSK disable the FT (change the FT from adaptive to disable)
do that and  check again. 
MHM

[pieterh]

found a (recent) post with this information:

One common cause of DHCP issues on macOS is a corrupted network cache. This can occur due to outdated or conflicting network configurations, previous network connections that were not properly closed, or a malfunctioning network daemon. To troubleshoot this issue, you can try resetting your network configuration and cache by running the following commands in Terminal:

sudo dscacheutil -flushcache 
sudo killall -HUP mDNSResponder