I have a very basic AP configuration and it works if I assign a static IP to match the host network. I have the ethernet connected on lan port eth0.1 to the host network.
If I change from static to dhcp client it fails to aquire an ip address from the host network. However it will aquire dhcp from the wan port eth.02.
Am I missing something obvious here?
Make sure you turn off the DHCP server for the LAN (if not already disabled). If you are using the LuCI web interface when you change the protocol from static to DHCP client, you must click save and apply and then quickly open a web browser at the new DHCP supplied address (which you will have to either have set in advance on your upstream router DHCP reservations, or quickly check that router to see what it has assigned to the OpenWrt device). If you don't act quickly enough, the configuration will get rolled back. The alternative way of doing this is to use UCI commands and/or edit the config file directly.
Dnsmasq is removed from my build and the behaviour is the same if it is installed. Dchp client "save and apply" obviously goes to rollback but I so I choose "keep settings" which then loses connection because still there is no client lease from the upstream dhcp server. Also after reboot.
Just to verify -- are you absolutely certain of this? Have you done a full network scan and/or verified that it is not showing up in your DHCP server's client list? It is entirely possible that it is working but simply not getting the IP address that you're expecting it to be given by the upstream DHCP server (hint: it may not be the same IP as it would get when connecting to the WAN port).
Aside from that, I'm out of ideas without seeing the /etc/config/network file. Could you post that?
How much else did you cut out of the build? In particular udhcpc is the IPv4 client daemon, it needs to be running.
@mk24 - that's a good point. But I suspect that udpcpc is likely still there since the OP stated that the router will get a DHCP supplied address on the WAN port. But, @brenton - can you verify that udhcpc is indeed still part of your image?
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdc8:bcbd:402c::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.1.9'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
config device 'wan_eth0_2_dev'
option name 'eth0.2'
option macaddr 'b0:4e:26:78:12:81'
config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '0 6t'
I don't see it. It hasn't been explicitly excluded from the build?
base-files busybox cgi-io dropbear firewall fstools fwtool getrandom hostapd-common iptables iw-full jshn jsonfilter kmod-cfg80211 kmod-gpio-button-hotplug kmod-ipt-conntrack kmod-ipt-core kmod-ipt-nat kmod-leds-gpio kmod-mac80211 kmod-mt7603 kmod-mt76-core kmod-nf-conntrack kmod-nf-conntrack6 kmod-nf-ipt kmod-nf-nat kmod-nf-reject libblobmsg-json libip4tc2 libip6tc2 libiwinfo20200105 libiwinfo-lua libjson-c4 libjson-script liblua515 liblucihttp0 liblucihttp-lua libnl-tiny libubox20191228 libubus20191227 libubus-lua libuci20130104 libuclient20160123 libxtables12 logd lua luci-app-firewall luci-base luci-lib-ip luci-lib-jsonc luci-lib-nixio luci-mod-admin-full luci-mod-network luci-mod-status luci-mod-system luci-theme-bootstrap mtd netifd openwrt-keyring procd rpcd rpcd-mod-file rpcd-mod-iwinfo rpcd-mod-luci swconfig ubox ubus ubusd uci uclient-fetch uhttpd uhttpd-mod-ubus urandom-seed urngd usign wireless-regdb wpad-basic
Collected errors:
*** opkg_install_cmd: Cannot install package udhcp.
Makefile:153: recipe for target 'package_install' failed
make[2]: *** [package_install] Error 255
Makefile:112: recipe for target '_call_image' failed
make[1]: *** [_call_image] Error 2
Makefile:196: recipe for target 'image' failed
make: *** [image] Error 2
Ok then.... hmmm
The config you posted is obviously the one with a static IP assigned on the LAN.
In theory, you should be able to make this work as a DHCP client by modifying the file to look like this:
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'dhcp'
Is this how you had performed the change, previously?
Could you ssh into the router and post the output of the following:
opkg list-installed | grep dhcp
On my router (19.07.1 official stable release build), I see the following:
odhcp6c - 2019-01-11-e199804b-16
odhcpd-ipv6only - 2019-12-16-e53fec89-3
This makes me wonder what package has the DHCPv4 client that runs on the system by default... it's obviously there, but not as a standalone package.
Wan port log:
Sun Feb 23 16:26:13 2020 kern.info kernel: [ 1749.477263] rt3050-esw 10110000.esw: link changed 0x01
Sun Feb 23 16:26:17 2020 daemon.notice netifd: wan (1175): udhcpc: sending select for 192.168.1.104
Sun Feb 23 16:26:17 2020 daemon.notice netifd: wan (1175): udhcpc: lease of 192.168.1.104 obtained, lease time 86400
Sun Feb 23 16:26:18 2020 daemon.notice netifd: Interface 'wan' is now up
So it looks like udhcpc is up 
Meanwhile, have you had an opportunity to change your LAN definition as I described earlier and then perform a full network scan to see if the router does indeed get an IP (even if not the one that is expected)?
There are a handful of strategies that you can consider that might help... one that might help would be to create a new VLAN and assign it to one ethernet port. Make that new VLAN a member of the lan firewall zone so that it has the same privileges, and assign it a static IP address in a different subnet than your current network. Turn on the DHCP server, too. This will give you a 'management' port to work with so you have easy access to the router config. Once that is established, you can change your LAN to DHCP client and you should be able to see what happens (does it get an address -- if so, what is it; if it doesn't get an address, does the log reveal anything).
Thanks I'm now getting somewhere. It seems dhcp is working only it's just not accessible or visible on the dhcp host when assigned a static lease however client's can connect to it fine. When not static it shows a dhcp lease on the host but again is not accessible from the host side. I can connect to it's wireless ap and manage it from the assigned address. Some good progress...
what do you see in the logs? What's the latest status of the /etc/config/network file?
Sorry I'll post back again later. Just a bit lost atm with it all. Thanks for helping. Could you please post a config for vlan management port that sounds like a good idea. I've no clue how to set that up 
I hate to state the obvious here, but I presume you are aware that the protocol for WAN and LAN interfaces are set independently. So if you want the WAN interface to be a DHCP client you set it as such, and if you want the LAN interface to be a DHCP client you also set it so. That being said, I think it's usually best to have the LAN IP as static.
/etc/config/network
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fdc8:bcbd:402c::/48' config interface 'lan' option type 'bridge' option ifname 'eth0.1' option proto 'dhcp' config interface 'wan' option ifname 'eth0.2' option proto 'dhcp' config device 'wan_eth0_2_dev' option name 'eth0.2' option macaddr 'b0:4e:26:78:12:81' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '1 2 3 4 6t' config switch_vlan option device 'switch0' option vlan '2' option ports '0 6t'
Some good news 
Sun Feb 23 18:05:37 2020 daemon.notice netifd: Interface 'lan' is setting up now Sun Feb 23 18:05:37 2020 daemon.notice netifd: lan (1516): udhcpc: started, v1.31.1 Sun Feb 23 18:05:38 2020 daemon.notice netifd: lan (1516): udhcpc: sending discover Sun Feb 23 18:05:38 2020 daemon.notice netifd: lan (1516): udhcpc: performing DHCP renew Sun Feb 23 18:05:38 2020 daemon.notice netifd: lan (1516): udhcpc: sending discover Sun Feb 23 18:05:41 2020 daemon.notice netifd: lan (1516): udhcpc: sending discover Sun Feb 23 18:05:42 2020 kern.info kernel: [ 233.870050] rt3050-esw 10110000.esw: link changed 0x02 Sun Feb 23 18:05:44 2020 daemon.notice netifd: lan (1516): udhcpc: sending select for 192.168.1.100 Sun Feb 23 18:05:44 2020 daemon.notice netifd: lan (1516): udhcpc: lease of 192.168.1.100 obtained, lease time 86400 Sun Feb 23 18:05:44 2020 daemon.notice netifd: Interface 'lan' is now up
I don't want to use the wan port I believe that would create double nat I was just using it for troubleshooting. I do want to use udhcpc client because the device will be used on a different network and I don't want to have to reconfigure the device if they make changes to their network. I do however like the idea of a management port. Could you please provide a configuration for it.
Thankyou
Everything is behaving well now, even static lease:
Sun Feb 23 19:29:52 2020 daemon.notice netifd: Network device 'wlan0' link is up Sun Feb 23 19:29:52 2020 daemon.notice netifd: lan (2756): udhcpc: performing DHCP renew Sun Feb 23 19:29:52 2020 daemon.notice netifd: lan (2756): udhcpc: sending renew to 192.168.1.1 Sun Feb 23 19:29:52 2020 daemon.notice netifd: lan (2756): udhcpc: lease of 192.168.1.9 obtained, lease time 4294967295
I'm not sure what was going wrong before maybe I was missing something in my build. I was also connecting from a relay-bridged router but I've now connected directly to the host router. Anyway I'm still not trusting this device in the wild without a management port. Can I just assign a second ip to the lan?