The correct way is to configure a static IP in the controller. Click on the AP's name, select the »Configuration« tab in the popu menu and set a static IP. Settings made in stand-alone mode will always be overwritten if an EAP is adopted in a controller, even the fall-back IP.

BTW: the forum for Omada-/EAP-related questions is the Business WiFi forum here.

puntjuh wrote

The problem is that i cannot pre-provision it... The configuration tab does not become available until after i have adopted the EAP and goes into the provisioning phase, in which state it is already being reset back to it's fallback ip 192.168.0.254/24 since i have no DHCP Server on my management LAN. 

The way I pre-provision EAPs is as follows:

Step 1: Using the web UI of the EAP I set a static IP, e.g. 192.168.12.2 for a target subnet using 192.168.12.0/24.

Step 2: Using EAP Discovery Utility, I bind the EAP with the corresponding controller using any address (a public IP in my case).

Step 3: Customer connects the EAP to its subnet, EAP connects with the controller, controller adopts it and sets fixed IP 192.168.12.2 or whatever is configured.

This way, there is an invisible transition from stand-alone- to controller-provided IP without fall-back to the default IP.

For this scheme to work I just need to know the customer's network IP.

Second scheme if the Discovery Utility isn't available is using DHCP in the lab, bind to controller using DHCP option 138, then set a static IP as outlined above and let the controller adopt it later on final deployment.

Works for me even if the target network doesn't use DHCP.

But it should also be possible to just set the DHCP fall-back IP before deploying the EAP in a DHCP-less network if the controller is running in the same network.

Ah, I see the problem. Omada Controller 3.0.2 not only re-configures the EAP, but resets its software settings in the database for the IP of the EAP to factory defaults as soon as it discovers the EAP again, no matter whether you previously did set a static IP or another DHCP fall-back IP for this EAP in the Configuration menu.

In version 2.7.0 (which I still use in the field) it does not so during discovery - just did setup a fresh install and tried to be sure:

# tcpdump -i en1 -vvv -A 

01:12:28.230226 IP (tos 0x0, ttl 64, id 55549, offset 0, flags [DF], proto TCP (6), length 184)

    192.168.1.250.55343 > 192.168.1.36.29811: Flags [P.], cksum 0x78c7 (correct), seq 1:133, ack 1, win 913, options [nop,nop,TS val 4294952700 ecr 2224485800], length 132
E.....@.@..........$./ts..<N5..4....x......
............{
    "header":    {
        "version":    "TP-LINK ECS ver 1.0.0",
        "mac":    "50:c7:bf:xx:xx:xx",
        "type":    3,
        "error":    0
    },
    "body":    {
    }
}

[...]

01:12:28.398627 IP (tos 0x0, ttl 64, id 55615, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.36.29812 > 192.168.1.250.44960: Flags [.], cksum 0x0dee (correct), seq 506, ack 478, win 243, options [nop,nop,TS val 2224536905 ecr 4294957811], length 0
......@.@......$....tt....... ......
...I....

Controller version 2.7.0 resets the OC's IP setting (if set previously) only if you click on »Forget this AP«, therefore working as described in my previous post even with a fall-back IP or a static IP. If adopting for the first time, you just need to be quick enough to change the IP in OC's Configuration menu for this pending EAP while the OC is still provisioning. With OC 3.0.2 this does not work anymore.

So the only way to pre-provision the EAP in OC 3.0.2 is to assign an alias IP from the 192.168.0.0 subnet to the server running OC in addition to its regular IP. Then you could adopt and change the EAP's IP on the fly.

No idea why TP-Link changed that. Maybe you want to file a bug-report to their support.