Running a self hosted Omada Controller (v6.2.10.17), Enterprise SSID with RADIUS dynamic VLAN (FreeRADIUS + daloRADIUS). Clients authenticate via EAP-TLS with a client certificate, VLAN comes from the cert's Subject OU field, falling back to a MAC based lookup table for devices without a cert yet (those use PEAP). This particular client was on EAP-TLS during both incidents below, but we've seen the same wrong VLAN pattern on PEAP clients too, so it doesn't look tied to one specific EAP method. AP model is EAP772(US) v2.0, fw 1.5.3. Correct VLAN for this client should be 53, the SSID default/unauthenticated VLAN is 100.

Here's what's happening: a wireless client stays connected to the same AP the whole time, no roaming, no reassociation in the logs, and mid session it suddenly gets a DHCP lease from VLAN 100 instead of its usual VLAN 53. About a minute later it corrects itself back to VLAN 53. Happened twice in a week, both times on the same day:

2026-08-30 14:27:15 - DHCP Server rejected the request of the client 16-XX-XX-XX-XX-D0 (IP: 192.168.53.52)
2026-08-30 14:27:16 - DHCP Server allocated IP address 192.168.100.102 for the client 16-XX-XX-XX-XX-D0
2026-08-30 14:28:35 - DHCP Server allocated IP address 192.168.53.52 for the client 16-XX-XX-XX-XX-D0

2026-08-30 18:09:07 - DHCP Server allocated IP address 192.168.100.103 for the client 16-XX-XX-XX-XX-D0
2026-08-30 18:10:11 - DHCP Server allocated IP address 192.168.53.52 for the client 16-XX-XX-XX-XX-D0

The main thing worth flagging: there's no RADIUS query reaching the server at all when this happens, checked FreeRADIUS's own radius.log for both timestamps and found nothing there, whether the client is on PEAP or EAP-TLS doesn't seem to matter. No AP roam or reassociation logged either, and no session change record for this client in the controller's Mongo DB around either timestamp. So this doesn't look like a RADIUS problem, it looks like something happening purely on the gateway/DHCP side.

What I did notice in the controller's own server.log is a bunch of repeated entries where it can't resolve the log type for gateway DHCP events, something like this:

INFO [...] Failed to replace device name in log content, log omadaLogEnum:null, log key: OSG_DHCP_S

This shows up constantly, not just around the two incidents, so there might just be a bug in how the gateway's DHCP events get logged and tagged. Not sure if it's actually related to the VLAN issue though since those log lines don't carry a client identifier.

Anyone run into a client's DHCP lease briefly landing on the wrong VLAN like this with a dynamic VLAN setup, with no RADIUS request involved at all? Would appreciate any pointers on what else to check.