TFTP should be able to work outside the layer2 lan. We have a central TFTP server we use to provide firmware files to switches and configuration to and from ciscos on various parts of our routed network.
The particular client implementation on the majority of devices doesn't route.
If your application requires it to be on the LAN, perhaps you could use port forwarding to make it appear there is a tftp server on the MT when it is actually centralized. Your dhcp server options might be able to tell the device to get the tftp file from a remote server as well.
No dhcp on these little guys during boot. In some areas the port forwarding may be a possibility & I will give it a run. The current problem prompting the initial post would not be suited to this as the link to the LAN segment is via PPP over radio. I really don't want a timeout midway through a re-flash. Having the TFTP server local to the site eliminates this issue. As some sites are solar powered it is advantageous to minimise the no. of CPU's present, the primary embedded gear is solar savy and controls everything else anyway but ultimately simpler is better.
That said, I think a tftp server would be handy to have on an MT. Perhaps MT could make a /3p menu section where third party contributors could upload compiled software to run on the mikrotiks. Since all commands would be preceeded by /3p, everyone would know they are using non-mikrotik supported commands.
JP that is a VERY VERY good idea. I accept Mikrotiks need to keep the control over ROS & it's reliability once deployed out in the field however there are occasions where I could drop another box offline by being able to run a simple task on the Routerboard.
I would also clearly be prepared to accept any resultant issues. A library of 3rd party modules would be great as this would also expose any code to a wider range of testing issues.