Is anyone else interested in this facility at all?
We have a lot of tiny embedded widgets scattered around on network segments behind RB133’s in a set of factories. At present we have tux boxes sitting on the segments to provide a distribution point for embedded firmware revisions for the widgets as they can’t cross a router boundary to get to the central firmware server. Being able to use the 133’s as tftp servers would allow us to get rid of more potential failure issues by eliminating the tuxen boxen and relying solely on the << quite reliable >> RB133’s.
The firmware files are only ~64K and we could use the existing FTP facility to easily get to the 133 in the first place. Security on the tftp directory is not an issue & the embedded boxes check the integrity of the download, they have a very limited boot space & so we can’t fit anything else in to use anything more complex than tftp.
The need is strictly TFTP as there are many other boxes from other Industrial suppliers that we have no firmware access to. The lowest common denominator & standard protocol for these widgets for firmware updates is TFTP. On our widgets the whole boot loader & comms system has to fit into 4K It is not a BOOTP system as the TFTP transfer only takes place as required, not at each reboot.
The other direction in which we are looking is an AVR32 NGW100 running linux on each subnet, it would just have been very convenient and cleaner to use the routers instead given that TFTP daemon source is readily available and there is tons of spare space there. Other alternative was to load OpenWRT but we have been happy with progress using ROS and didn’t want to move away from this.
Ive been recommending this feature for about a year now, with the only reply being “its not needed, or is impractical”. And my supposition is that a ntp server is needed or is “more” pracitcal.
As leaf mentioned there are many of us that use an array of stuff beyond the tik routers, such as a cmts, mta units … etc and they are upgraded via tftp. Most of us have tik routers/cpe’s with many mb’s to spare, so I dont see space being the issue and tftp in itself is very trivial in nature.
If the mikrotik guys dont feel comfortable including it in a release, I think it would make MANY happy to just code it as a supplemented package that can be installed at the user’s wish.
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.
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.
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.
The particular client implementation on the majority of devices doesn’t route.
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.
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.
Having said this I wouldn’t like the original request to get lost in the noise. User supported modules or not I would still like to see TFTP functionality available one way or another.
Once again… your not the only one that is in hope of such. Im just hoping maybe one day Mikrotik will realize that many of the routers we use are core and essential routers, and essential routers require essential features.
I would also like to throw in support for a basic TFTP server… We operate a couple of Terayon CMTS’s and have to have a seperate DHCP server / TFTP server to support the cable modem file distribution. I would LOVE the idea of using my existing Mikrotik router to be able to handle these requests. This would just be the end all for my particular application!
10 months and no comment, Doesn’t look particularly promising for what is normally a rather trivial task, given the comparative degree of difficulty in getting a tftp daemon running on the tux boxes
there’s only 11 posts here, half of them yours. doesn’t seem like there is much demand for it … I don’t know about this, maybe it’s on some To-Do list and will be there someday, but I can’t promise anything.
I agree in a need of tftp server. In several cases it is a very good feature, for example when deploying voip systems: avaya telephones needs a tftp serve rfor every boot, they take firmware and config from. And since avaya is a closed system, the phones cnnot use http, ftp or other protocol. tftp only. Any expected release date for this issue?
Personally, I would prefer a TFTP client, so I could use my existing software to login and TFTP a backup of the config to my existing TFTP server where all my Cisco configs are.
>> RB133’s.