It would be very handy to be able to write to files in a similar way to how we can currently read a file on the mikrotik.
For example if I wanted to save an address list with comments the append command is currently the only way I can do this, but it outputs a style similar to what you would see when you use the print command, and can't be used as a regular script command.

Also if you wanted to write your on csv file exporting values from the mikrotik you can not.

The current append would be more useful if it wasn't just a print command but allowed you to define the output.

Regards,
Omega-00

I agree.... I just ran in to needing this feature. I have an Access List that I would like to export to my database and I cant find a way to do it. Being able to create csv files for export or import would be great.

Mike

Montana, that's already possible:
download that RSC file and open up in OO Calc or Excel. There use various tools to get the information in a form that you require.

export may work for that, but is very limited in what you can output..

queue simple print stats

will give me a detailed output on each of the queues similar to what I can see in winbox, but can't get the same data to be exported using

queue simple export

(doesn't give any options other than file to export to)

I know, but my reply was to Montana

if you need statistics on usage, you have to use some AAA that is available on routeros, you also might set up hotspot and see all the power of client accounting that it provides, and not using tools for purposes they are not meant to be used.

We're thinking outside the box - exporting details in this form from mikrotik to mikrotik would mean that we have no need for 3rd party componenets in our network.

For a good example of what I've been able to achieve using just the mikrotik see - http://wiki.mikrotik.com/wiki/Using_Fet ... ress_Lists

or
http://wiki.mikrotik.com/wiki/Automate ... sermanager

use mikrotik routeros with hotspot and autenticate against user-manager, that is that "radius" server, just provided by mikrotik and is available on routeros.

that is what i call thinking outside of the box - you have 20 clients on one router, and other 20 on other, at this moment that is not a lot, but if you grow to 1000, to 2000? what then? you will be exporting stats from queues all month long, and then when you finished, you will have to start over again, while using hotspot + usermanager would solve that problems once and for all, for ever.

at least this is how i see it.

edit:
as there are some features that where implemented with some thought in mind, that it is usable while there are not a lot of users, and then you have to fight for user to let this feature go and start using something more powerful that would not make such a problem in the first place.

that is what i call thinking outside of the box - you have 20 clients on one router, and other 20 on other, at this moment that is not a lot, but if you grow to 1000, to 2000? what then? you will be exporting stats from queues all month long, and then when you finished, you will have to start over again, while using hotspot + usermanager would solve that problems once and for all, for ever.

Oh I understand and agree completely in this case, we infact built our own system about half a year before the usermanager came out so have a system that does exactly what we need and is easily scalable (currently supports over 6000~ transient users with an average of 600 new users/vouchers each month)

I don't have any problems with the usermanager and would've probably used it if it weren't for our own system, but the benefits we have of doing it ourselves allows us all the flexibility we could want.

In regards to extra mikrotik features thou, allowing things like the write to file ability gives us the end user an option to do things that aren't originally intended, the IP address lists feature that we've created comes in useful for, blocking servers listed on spamhaus and similar before they hit yes (and updating this list automatically) reducing load on mailservers.

Similarly: other users have found ways of 'adding features' to userman by making their own solutions where having a few more features would've removed the need for anything other than the mikrotik's - http://forum.mikrotik.com/viewtopic.php ... &sk=t&sd=a

Basically, I'm not think you should throw everything down and open up mikrotik to everyone's whims and ways.. but I do believe that 'the more integration that is possible then the more useful the mikrotik system becomes'.. it is still at its core a router, but why not allow the tools to make it an amazingly advanced firewall and hotspot system too?

Hi guys

I too have a great need for writing larger files. I have written a complete accounting system, based on UserManager. It has the ability to send notifications on certain levels of a user's CAP (eg 50%, 75%, 90% and when the user is finally capped). It sends the user an email and SMS. I have a month-end script which resets all users' usage to 0, change their caps (transfer-limit) to what it is supposed to be (ie, if a user had a top-up in the month changing their 2GB account to 3GB, this script will reset the transfer-limit to 2GB for the next month). My script also sends the user an invoice at the same time. Everytime bandwidth is added, my script calculates how much the added bandwidth costs, and adds it to his total cost. Everytime a user makes a cash payment or electronic transfer (a feature the new UM does not have btw), I allocate those funds with another script.

But now my problem is this. My invoices is a simple plain text mail, and lots of users (especially companies) will not accept that as an invoice.

So my solution was to write a script to generate an .html file, which the user can open with their default browser and see a propper invoice. (Many companies nowadays use .html files for invoicing, and it works great). I started writing my script, and it looked like it would be an AWESOME solution, but when I got to the 4th line of the .html file (invoice.html), my script stopped working. After hours of troubleshooting I dicsovered Mikrotik can't write large files. Mikrotik support informed me that it never will.

Now my only solution is to either wait till Mikrotik comes to the party, or to rewrite all my code on FreeRADIUS with some PHP UI (which I would probably have to write myself too).

I really would have liked to move to the latest UM, but I would need to do a considerable amount of coding to get my existing 3.20 scripts to work under v4+, and with the same limitations in V4+, I don't really see the need. I thought of making use of v4+'s billing side, but v4 does not accept manual payments (ie, cash payments, electronic transfers etc). ALL my clients pay either cash or electronically. None of my clients use debit orders or payment gateways.

MIKROTIK, PLEASE GIVE US LARGE FILE SUPPORT!!

There was support introduced for LUA in v4beta versions, but this was subsequently pulled with no followup.

http://wiki.mikrotik.com/wiki/Manual:Lua

Would be good to see it added back again as it would solve a number of current limitations in custom scripts.

Hey Omega

I forgot to mention this, but yes, I'm aware of the LUA situation. If LUA is reintroduced, I'm certainly having a party that night!

user-manager was just an example, since that is simple RADIUS server, any other RAIDUS server can easily fill the spot without any problems on the other hand, if you have router with sufficient storage, you can use user-manager for 1000 users on one of the routers you currently own. My point was - why to try to reinvent something that has already been done.

Hi Janisk

You say we shouldn't reinvent the wheel. In that case, I'll buy you a case of beer if you find ONE RADIUS package which does everything I require it to do without any modifications.

The reason for people like me "reinventing the wheel" is to add functionality to a product. UserManager does not cater for cash or EFT (electronic direct deposit) payments, and those are the only two payment methods I accept. UserManager by default don't have the ability to E-Mail & SMS clients when they reach certain persentages of their cap, so I had to write code for that. UM does not have the ability to top-up a user's cap in the middle of the month, and then autimatically restore the client to their original cap at the end of the month. The list goes on and on. The same also apply for all other RADIUS solutions. The closest alternatives I found was RADIUSManager and DaloRADIUS, but Dalo is still under heavey development, and RADIUSManager also doesn't have half the accounting (money) functionality we need.


The reason I believe in Mikrotik User Manager is its simplicity, ease of installation and restoration from backups and reliability, plus it was possible to overcome almost all limitations by wiked scripts. I make use of address-lists and layer7-address-lists as a database. The layer7-address-list contains the history of all transactions of a client for example. Due to limitations, people like me had to think out-the-box and use other functions in a way it was not intended to get the functionality you really need.

Janisk, I understand you are not allowed to share company secrets, but could you perhaps indicate if there is currently a team dedicated to work on UserManager? If so, would they be interested in looking at requirements people like myself need and perhaps start implementing it? I would be delighted to help with testing and suggestions and also to share my existing scripts.

I believe UserManager has much more potential than ANY other RADIUS product on the market. I am even willing to pay a seperate license fee for it, but then it should meet most of my requirements.

Thanks for your time! G

if user-manager does not meet your expectations you are free to use other solution. original problem in the thread was use of internal /ppp secret database for 1000 users and why it is not working for them. In case you want to replace that with something more powerful - user-manager hits the spot perfectly. While in your case, best course of action is to take some opensource (GLP, BSD) project and contribute to that to get the advanced features you like (and as i red it - you have done just that). This is also the reason why we say - user-manager is a RADIUS server, so if you do not like it, you can always pick another solution so you are not left in the cold if UM does not do what you require.

so the summary of all this - if you have less than 100 users, use /ppp secret it will work ok for you, with more, you can run into problems, but also you can blow it up to 1000 users without noticing any, but eventually you will. so better use something that has been created for that purpose like RADIUS, weather being UM or any other RADIUS implementation if you have server to put it on. and with 300+ users you most probably has a server already.