@URL 

My suspicion here is that your WAN IP on your gateway is getting DHCP from the mobile networks via the 5g unit in some kind of bridge mode, and its not in the 192.168.254.X range that the 5g unit is set to on its LAN port, which means the WAN port cannot accept data from it because its outside the scope of its subnet mask (or possible your WAN port can see the 5g unit, as evidenced by your ping, but the 5g unit cant respond due to scope mismatch)

WAN IP (from 5g service) = random public ip

LAN IP of 5g unit = 192.168.254.1

scopes wont match, therefore adoption fails.

You may have more success if you can set up the 5g unit in router mode, have it do the ISP<>Private IP natting, add your gateway to it as a DMZ to reduce double NAT issues, and then your wan port will be in the same scope as the 5g unit and adoption should work.

edit: this is just my guess, i havent experimented with the 5g units

One workaround would be to set the controller ip / url setting on the 5g unit (in standalone gui) and point it to the WAN IP you get from the ISP, but this will only work if you have a static IP, or set up a DDNS resolver.

A couple experimental ideas:

Set up a WAN IP Alias on your gateway "internet" connection matching the subnet of the 5g device with some other ip like 192.168.254.222

you could then, maybe, do a One-to-One NAT of your controller IP to the WAN aliased subnet to another IP - this effectively put your controller on an IP upstream of WAN, and if the subnets match, it might be able to adopt properly.  This wont expose your controller to the internet as its on a private IP outside the scope of your ISP connection

Thank you for taking the time to write the detailed reply,

I just tried to point a browser at 192.168.254.1 from the internal LAN and it did not bring up the 5G GUI..,which I am SURE it previously did.....not sure how this worked, as you say, the gateway gets an ISP provided IP address,... so how does it know (with no tweeks) how to route to 192.168.254.1....?

Another thing I had not considered, potentially foolishly....is the controller is on a vlan - on 10.250.1.4....however I have had a play with acl's to ensure the device can route to that network....just ran out of time to test that theory further.

The TP-link guidance here makes it all sound simple... https://support.omadanetworks.com/uk/document/115428/

Will play further and report back.

Just tried to tracert from a LAN PC to 192.168.254.1 and got this... the gateway is sending to a rivate destination...

  @URL 

Hope 2 looks interesting, 172.x - is that the ISP IP you get> if so you are behind some sort of NAT as that is a private not public address.

The failures after that are because the traffic is just going nowehere as no route to that destination IP

Have a try with the two suggestions i added

  @URL 

I'm using the ER701 adopted into an OC200 controller and it works, I haven't had to change the IP on the ER701 (it's still using the default 192.168.254.1).

One thing I've noticed is the ports you've used for the port forwarding are slightly different, i'm using 29810-29817, but I don't think that would cause the issue.

Has the ER701 been previosuly adpoted into the controller you're using? If it has, then retsart everything and it should then connect.

  @nsmith1979