Page 1 of 1

v4.0 Feature Request(s)

Posted: Fri Jan 25, 2008 8:24 pm
by BrianHiggins
100% new version of NStream (NOT backwards compatable) to include advanced polling, full QOS, reduced latency, dynamic frequency selection WITHOUT disconnecting active clients, automaticly adjusting framing policy (that does not affect QOS)

New version of NStream Dual with automatic fall back to half duplex if one link fails

full antenna diversity support for regular 802.11a/b/g mode

full support for 802.11n and WiMax

ability to read every value displayed in winbox via SNMP, plus create custom snmp OIDs for values calculated through scripts

Re: v4.0 Feature Request(s)

Posted: Fri Jan 25, 2008 9:24 pm
by roadrunner
Isn't the next version number going to be 3.2.x or 3.1.x instead of 4.0? They had the 2.9.x, 2.8.x, 2.7.x, etc. series before 3.0.
full support for 802.11n and WiMax
I think Mikrotik have stated they will both be supported when they are supported in Linux with stable drivers.


A feature I would like to request is a 'PPP IP pool' that works like the DHCP lease table that is stored periodically. I would like my PPPoE users to get the same IP address, if available, even after rebooting my Mikrotik PPPoE server/router.

Re: v4.0 Feature Request(s)

Posted: Fri Jan 25, 2008 10:45 pm
by BrianHiggins
Isn't the next version number going to be 3.2.x or 3.1.x instead of 4.0? They had the 2.9.x, 2.8.x, 2.7.x, etc. series before 3.0.
If you read the new description of this board, it states "BETA Testing and Feature Suggestions for the next RouterOS release (ROS v4)".
A feature I would like to request is a 'PPP IP pool' that works like the DHCP lease table that is stored periodically. I would like my PPPoE users to get the same IP address, if available, even after rebooting my Mikrotik PPPoE server/router.
you can already make PPPoE assign IPs out of a pool, if you want them to be static, assign them that way (most ISPs charge the customer a small monthly fee for a static IP).

Re: v4.0 Feature Request(s)

Posted: Fri Jan 25, 2008 11:20 pm
by roadrunner
it states "BETA Testing and Feature Suggestions for the next RouterOS release (ROS v4)".
Thanks, I found that info after posting. I haven't been in the forums much since 3.0 final was released.
you can already make PPPoE assign IPs out of a pool, if you want them to be static, assign them that way (most ISPs charge the customer a small monthly fee for a static IP).
I was just wanting semi-static pool like DHCP does. DHCP tries to assign the same IP address to a machine/mac address when a DHCP client re-connects. I have setup some customer with static IP's from my RADIUS server(s). We no longer allow dial-up users to request static IP's, only DSL & Wireless customers can get Static IP addresses.
I think Mikrotik have stated they will both be supported when they are supported in Linux with stable drivers.

This post by normis sums up their position on new hardware and drivers
http://forum.mikrotik.com/viewtopic.php?p=67179#p67179
we only support chipsets that are supported by the linux kernel. we don't add custom or hacked drivers.

I saw them testing 802.11n cards at the 2007 MUM in Orlando. I also want them to support WiMax/802.16 for my network. Some of the advantages of 802.11n might not be so useful for outdoor multipoint wireless networks, but I hope support for both 802.11n & WiMax will be added when available.

Re: v4.0 Feature Request(s)

Posted: Sun Jan 27, 2008 1:17 pm
by bokili
100% new version of NStream (NOT backwards compatable) to include advanced polling, full QOS, reduced latency, dynamic frequency selection WITHOUT disconnecting active clients, automaticly adjusting framing policy (that does not affect QOS)

New version of NStream Dual with automatic fall back to half duplex if one link fails

full antenna diversity support for regular 802.11a/b/g mode

full support for 802.11n and WiMax

ability to read every value displayed in winbox via SNMP, plus create custom snmp OIDs for values calculated through scripts
This will be excellent features. Is it possible that mikrotik make new dual nstreme from source, to achieve more bandwidth ?

Re: v4.0 Feature Request(s)

Posted: Sun Jan 27, 2008 4:29 pm
by rpingar
in a PtMP system we are looking to lower the latency and to have a full wireless qos with nstream. We are not looking to more bandwidth.

So my vote is to a new feature in nstream that take into account the priority, it should be selected on the AP and not on the clients. We could not use it in a ptp link but it should be useful in a ptmp.

Regards
Ros

Re: v4.0 Feature Request(s)

Posted: Tue Jan 29, 2008 11:07 pm
by BrianHiggins
This will be excellent features. Is it possible that mikrotik make new dual nstreme from source, to achieve more bandwidth ?
full QOS and reduced latency will provide better bandwidth where needed through more efficient use of the airtime.

Re: v4.0 Feature Request(s)

Posted: Wed Feb 13, 2008 6:51 pm
by NickW
I'd really like to assign dynamic public IP addresses from a single pool, from my FreeRadius server.

Re: v4.0 Feature Request(s)

Posted: Thu Feb 14, 2008 7:21 am
by hqvnet
01
-----
The possibility of the mark packet ttl, in the firewall to allow such ttl 128 and ttl 64, blocking the rest, avoiding the sharing of the connection linux and windows xp
-----

02
-----

In Winbox

A menu where I can write all of my ip Mikrotik

After Winbox connected, I can, switch to another ip automatically, simply just, click on the option.
Example
| 192.168.10.1 Base |
| 192.168.10.2 AP |
| 192.168.10.3 Hotspot |

When I click on the option chosen in Winbox, he now automatically connects at ip or Mac desired, without having to open another window winbox it going easy, clicked, connected.
---

03
-----

Then add more options. I have to leave now.

Re: v4.0 Feature Request(s)

Posted: Fri Feb 15, 2008 5:31 am
by nz_monkey
I would like to request 802.1f / IAPP support so that devices such as Wifi VoIP phones can roam from AP to AP without dropping out.

This would also allow devices to roam on outdoor AP's e.g. a 4 wheel motorbike with a 900mhz radio mounted could roam from AP to AP without drop outs.

Re: v4.0 Feature Request(s)

Posted: Tue Mar 11, 2008 3:33 pm
by uebi
A small but (at least to me) useful feature would be a tiny upgrade to Tools -> Graphing.
The graphing for queues works really great, but..... in Winbox you can also see the traffic transmitted for every queue. Would it be possible to include this value on the queue graph website where "Max-limit:" etc is listed?
I guess this would be pretty easy to implement. The graphs keep untouched but one more value (next to Max-limit, Limit-at, ...) would be included.

This would be nice, because if the amount of transmitted traffic would be shown on the website, a customer could use the graphing facility as a "cheap" accounting tool (apart from the router reboot issue) with "allow target" enabled.
Every user could browse to the Mikrotik router and see how much traffic he/she already transmitted. A script like
:local date
:local day
:set date [/system clock get date]
:set day [:pick $date 5 6]
/queue simple
:if (day = 01) do={ 
reset-counters-all 
}
could reset the counters on the 1st day of every month the the show starts again.

Anyone sharing my idea? :)


Greets,
uebi

Re: v4.0 Feature Request(s)

Posted: Fri Mar 14, 2008 4:25 pm
by Ibersystems
Hi,

we need support for LACP. Now LACP packets can't pass over RouterOS.

This makes very simple to make redundant links without scripts.


Thanks,
Martín

Re: v4.0 Feature Request(s)

Posted: Fri Mar 14, 2008 11:28 pm
by nz_monkey
To support LACP over Bridged link's Mikrotik will need to change to using a commercial network stack such as the one from ZebOS. The linux bridge will not support this functionality. Hell they only just added support for RSTP which has been a standard for as long as I can remember, do you think the linux dev's will ever add LACP and MSTP support to it ?

ZebOS has it right now however, so is a good option.

Re: v4.0 Feature Request(s)

Posted: Tue Mar 18, 2008 1:11 pm
by vlada1
Add this to v3 first .... then v4 lol

LDP features:

* downstream on demand label advertisement
* ordered label distribution control
* conservative label retention

MP-BGP based MPLS IP VPN
MPLS TE support using RSVP

Re: v4.0 Feature Request(s)

Posted: Wed Mar 19, 2008 5:38 am
by nz_monkey
Agreed on the MPLS features, if these were available we could sell Mikrotik kit instead of Juniper M series.

Re: v4.0 Feature Request(s)

Posted: Wed Mar 19, 2008 9:09 am
by normis
Add this to v3 first .... then v4 lol
do you want v3 to ever be stable? ;)

Re: v4.0 Feature Request(s)

Posted: Wed Mar 19, 2008 1:17 pm
by bokili
do you want v3 to ever be stable? ;)
I want this desperately!!!! :shock:

Re: v4.0 Feature Request(s)

Posted: Wed Mar 19, 2008 2:27 pm
by normis
do you want v3 to ever be stable? ;)
I want this desperately!!!! :shock:
good! then let's concentrate on fixing and optimising, and let's leave BIG new features for v4

Re: v4.0 Feature Request(s)

Posted: Wed Mar 26, 2008 7:47 pm
by Ibersystems
Hi,

this is a little new feature to put systems on date/time.

A button in /system/clock that when you click on it winbox take system time/data (of our computers) and actualize routerOS time/data with this system time. It's to avoid putting date/time manually when no NTP service available. One click instead of put manually all data/time parameters.

Thanks,
Martín.

Re: v4.0 Feature Request(s)

Posted: Thu Mar 27, 2008 4:23 am
by ngds
I'd really like to see support for native vlans, so I can properly connect to my Cisco gear via trunks.

Re: v4.0 Feature Request(s)

Posted: Fri Mar 28, 2008 6:19 pm
by jp
I connect to HP gear using what you'd call Native VLAN. The native one would be the untagged VLAN that switch port is on and the main interface in the MT. The VLAN interface in MT would go to tagged VLANs on the same port in the switch. Not sure how the Ciscos differ, but HP tries to be fairly Cisco compatible in their switches.

Regarding NTP, unless you are on a brand new unconnected network, there is no reason why you might not be able to get NTP. Every MT can be a NTP server, so it should be trivial to have a single NTP server on your network for all your private devices. I would suggest this, especially if you need to be calea compliant, as it might be important to note the times of the data capturing.

Re: v4.0 Feature Request(s)

Posted: Mon Mar 31, 2008 10:08 am
by gacopl
What I would really like to see is SNMP-write support please :)

Re: v4.0 Feature Request(s)

Posted: Wed Apr 16, 2008 7:29 am
by netrat
SCTP support

Re: v4.0 Feature Request(s)

Posted: Wed Apr 16, 2008 10:46 am
by pedja
Allow option to see what actual connections are handled by specific queue rule. Torch is unusable for this, as what gets into queue depends on many factor which are not possible to handle with torch.

Allow option that shows how connections are routed within router. If there are several routes to the same destination it is very hard to find out which one is used for specific connection.

Re: v4.0 Feature Request(s)

Posted: Wed May 07, 2008 11:27 am
by Wmillo
New access metod for PtMP system:
New scheduling for polling-nstream (not only round robin algorithm) with advanced QoS like 802.16(d-e).
Thanks

Re: v4.0 Feature Request(s)

Posted: Wed May 07, 2008 7:38 pm
by BrianHiggins
New access metod for PtMP system:
New scheduling for polling-nstream (not only round robin algorithm) with advanced QoS like 802.16(d-e).
Thanks
don't forget the DFS part...
100% new version of NStream (NOT backwards compatable) to include advanced polling, full QOS, reduced latency, dynamic frequency selection WITHOUT disconnecting active clients, automaticly adjusting framing policy (that does not affect QOS)

Re: v4.0 Feature Request(s)

Posted: Thu May 08, 2008 1:07 pm
by Wmillo
I'd like the alarm signal (or flag) if the received signal level is too high (saturation).

Re: v4.0 Feature Request(s)

Posted: Tue May 20, 2008 3:13 am
by nz_monkey
I would like to see the IPSEC implementation improved, in particular:

- Use generic names, e.g. Phase1 instead of "Peers", and Phase2 instead of "Policy", DH Group 2 instead of "modp 1024", or maybe extend the names e.g. "Peers - Phase1", "Policies - Phase2"

- Allow the use of IPSEC Tunnel Interfaces aka Route based VPN's, this will allow inter operable Dynamic routing over IPSEC with other vendors. It will also allow the use of simple firewall policies to/from the VPN interface.

- Add support for "Autokey Keep Alive"

- Change lifetimes to be measured in seconds (like every other IPSEC device in existence)

Adding these features will make it easier to understand the IPSEC process, make it easier to inter-operate with other vendors products, make it simpler to control inter-site traffic through the use of firewall policies, and make RouterOS more enterprise ready.

Re: v4.0 Feature Request(s)

Posted: Tue May 20, 2008 11:35 am
by hippo
I second the request for tunnel based route based vpn:s (see nz_monkeys post).

I would also like to see support for virtual routers (vrouters,vrf...)

Re: v4.0 Feature Request(s)

Posted: Tue May 20, 2008 11:45 am
by nz_monkey
Virtual Routers/Virtual Domains is a great idea, but I would not want to be the programmers at Mikrotik trying to implement it!

Re: v4.0 Feature Request(s)

Posted: Tue May 20, 2008 4:40 pm
by hippo
Actually most of the functionality for virtual routers are already in the routeros in the form of routing-tables. What needs to be added is some form of front end so that you are able to place interfaces in certain virtual-routers and make sure that traffic only hits the corresponding routing table. There also needs to be added some sort of functionality so that you can route traffic between virtual-routers (or routing tables), but I don't think it would be that hard.

Re: v4.0 Feature Request(s)

Posted: Wed May 21, 2008 9:30 am
by pedja
Long time ago it was promised that we will get triggers - option that MT executes script when some condition occurs. That would help a lot preserving resources now spent on scheduled scripting.

Re: v4.0 Feature Request(s)

Posted: Thu Jun 26, 2008 8:51 pm
by vsaldarriaga
I also second the request for tunnel based route based vpn:s (see nz_monkeys post).
Having to flush all installed-sa 's when only one problematic tunnel is the culprit of an
incomplete negotiation is also a hassle.

Re: v4.0 Feature Request(s)

Posted: Sat Jul 05, 2008 8:25 pm
by roneyeduardo
Please, make a RouterOS version instalable in Ubiquity's NanoStation hardware. In it's forum, Ubiquity already stated that they would make any modification needed in their hardware to supporte RouterOS.

Re: v4.0 Feature Request(s)

Posted: Tue Aug 05, 2008 11:13 pm
by Falconix
XMPP(Jabber) functionality in in Router OS, send notice with scripts over XMPP.

Re: v4.0 Feature Request(s)

Posted: Wed Aug 06, 2008 2:08 am
by QpoX
Maybe some OEM support... a webserver that run's via files that the OEM corp has uploaded, files that exec commands to the RouterOS...
So that the enduser can not see that it runs RouterOS...

I think that more company's will use RouterOS that way...
It's will still be RouterOS under it all but with the resellers user-interface and Mikrotik still makes money...

Re: v4.0 Feature Request(s)

Posted: Wed Aug 06, 2008 8:32 am
by normis
Maybe some OEM support... a webserver that run's via files that the OEM corp has uploaded, files that exec commands to the RouterOS...
So that the enduser can not see that it runs RouterOS...

I think that more company's will use RouterOS that way...
It's will still be RouterOS under it all but with the resellers user-interface and Mikrotik still makes money...
if you are an OEM, then you would know that this is already possible

Re: v4.0 Feature Request(s)

Posted: Wed Aug 06, 2008 5:04 pm
by QpoX
Maybe some OEM support... a webserver that run's via files that the OEM corp has uploaded, files that exec commands to the RouterOS...
So that the enduser can not see that it runs RouterOS...

I think that more company's will use RouterOS that way...
It's will still be RouterOS under it all but with the resellers user-interface and Mikrotik still makes money...
if you are an OEM, then you would know that this is already possible
I only thought a OEM chould change the logo ind the console...

Re: v4.0 Feature Request(s)

Posted: Thu Aug 07, 2008 9:12 am
by normis
Maybe some OEM support... a webserver that run's via files that the OEM corp has uploaded, files that exec commands to the RouterOS...
So that the enduser can not see that it runs RouterOS...

I think that more company's will use RouterOS that way...
It's will still be RouterOS under it all but with the resellers user-interface and Mikrotik still makes money...
if you are an OEM, then you would know that this is already possible
I only thought a OEM chould change the logo ind the console...
also the webpage. isn't that enough?

Re: v4.0 Feature Request(s)

Posted: Thu Aug 07, 2008 1:16 pm
by Muqatil
I would like to have a full configurable webbox selecting what i want to show on webbox (maybe only NAT rules and some few more features)
Something like the HotSpot Interface.

Re: v4.0 Feature Request(s)

Posted: Thu Aug 07, 2008 1:19 pm
by normis
router OS has no built in webserver that could do these things.

Re: v4.0 Feature Request(s)

Posted: Thu Aug 07, 2008 5:30 pm
by ottife
MESH,MESH,mature MESH protocols!!!

Re: v4.0 Feature Request(s)

Posted: Wed Aug 13, 2008 2:37 am
by nathany
I second the improved IPSEC implementation as mentioned by nz_monkeys

Re: v4.0 Feature Request(s)

Posted: Wed Aug 13, 2008 2:42 am
by nz_monkey
To the Mikrotik team. If you need access to other vendors hardware for compatibility testing with an improved IPSEC implementation please let me know.

We have hundreds of Juniper/Netscreen, Cisco, Fortinet routers/firewalls in production and can give you full access for testing.


Regards,



Andrew

Re: v4.0 Feature Request(s)

Posted: Thu Feb 05, 2009 5:31 am
by omega-00
MSTP support would be good to have for our larger implementations.

Re: v4.0 Feature Request(s)

Posted: Mon Feb 09, 2009 6:28 am
by jahirg
I would like MKT add in routeros a special field for put one powerfull DPI engine in firewall.

MKT must be stablish a alliance with IPOQUE, They have a good software for detection in L7.

ipoque's Protocol and Application Classification Engine (PACE) helps network equipment and software vendors to enhance their products with a powerful and proven layer-7 protocol detection. PACE uses a combination of deep packet inspection (DPI) and behavioral analysis to reliably detect protocols even if they use advanced obfuscation and encryption techniques. PACE has been optimized for performance and classification reliability. It is highly flexible and can be integrated in any existing system such as firewalls, UTM appliances and WAN optimization controllers.

Re: v4.0 Feature Request(s)

Posted: Mon Feb 09, 2009 9:49 am
by normis
so and RouterOS doesn't have this ?
http://wiki.mikrotik.com/wiki/L7

Re: v4.0 Feature Request(s)

Posted: Tue Feb 10, 2009 1:17 am
by cigamit
My feature request.

Inclusion of the ARP Cache into the SNMP ouput, just like my Cisco devices do.
RFC1213-MIB::atPhysAddress.2.1.192.168.0.150 = Hex-STRING: 00 23 5F 6E 56 76

Re: v4.0 Feature Request(s)

Posted: Wed Feb 18, 2009 3:23 am
by scold
Is it possible to have tftp, snmpget (for graphs), snmptrap, machine(s) class (for usermanager), optional usermanager backend compatibility (radius, ldap), in RouterOS, please?

Re: v4.0 Feature Request(s)

Posted: Wed Feb 18, 2009 10:31 am
by msundman
Here's my list:

* Route/interface based IPsec (0/0 - 0/0) (nz_monkey)

* vrouters (Metarouter on RB1000 might do the trick)

* Ethernet interface error statistics via CLI/Winbox

* Improved sniffer that allows to easily from cmdline filter and print sniffed packets in realtime. Just like running tcpdump from a shell on a Linux firewall.

* Improved OpenVPN features: UDP, CCD-files, Multiple instances

* The torch on interface feature in winbox is awsome! I'd like to be able to do that on individual firewall filter rules as well! You can already see the counters on how much traffic is matched by each rule, so if I could just right click on a rule and select torch (or sniff) to see what accual traffic is matched by the rule it would be really even cooler :)

Re: v4.0 Feature Request(s)

Posted: Sun Feb 22, 2009 4:02 pm
by omega-00
Can we get another option on the user accounts for the router that allows us to disable the 'show password' option?

Currently you can use the 'password' option to disable access to user account editing, but I don't know how I can give someone guest access without giving them all my pppoe and pptp client passwords at the moment.

Re: v4.0 Feature Request(s)

Posted: Sun Feb 22, 2009 4:56 pm
by roc-noc.com
I would like MT to cooperate with other vendors such as Ubiquiti for things like NSTREAM, or loading RouterOS onto their platform. (Ubnt needs to have some form of a polling protocol that is able to work with RouterOS) Many people here use MT as access points and Ubnt as the client CPE devices, but at the moment there is no option for polling. Ubnt has asked for your cooperation before (From what I was told) and you did not give them any.

I find Ubnt goes out of their way to cooperate with YOU and to work with MT hardware and even MT BUGS sometimes.

I think it would be fair to have MT cooperate with a company that tries its hardest to make it's gear compatible with yours, even though yours is not compatible with many other vendors.

(This is not a "feature" but it is something that MT should start to consider)
kewikeed you don't know what you are talking about. Mikrotik has spent many many years developing and improving their ROS which is the foundation of their success. You are asking them to give away the heart of the company to any competitor that makes cheap compatible hardware.

It is not going to happen. UBNT can spend their own money (including prize money) to develop their own OS. And don't believe that UBNT are just a bunch of nice guys who only want to make the world a better place to live. They are competitors who would love to take away Mikrotik's market.

Tom

PS I sell both Mikrotik and UBNT and I know what I am talking about.

Re: v4.0 Feature Request(s)

Posted: Sun Feb 22, 2009 5:10 pm
by QpoX
I would like MT to cooperate with other vendors such as Ubiquiti for things like NSTREAM, or loading RouterOS onto their platform. (Ubnt needs to have some form of a polling protocol that is able to work with RouterOS) Many people here use MT as access points and Ubnt as the client CPE devices, but at the moment there is no option for polling. Ubnt has asked for your cooperation before (From what I was told) and you did not give them any.

I find Ubnt goes out of their way to cooperate with YOU and to work with MT hardware and even MT BUGS sometimes.

I think it would be fair to have MT cooperate with a company that tries its hardest to make it's gear compatible with yours, even though yours is not compatible with many other vendors.

(This is not a "feature" but it is something that MT should start to consider)
kewikeed you don't know what you are talking about. Mikrotik has spent many many years developing and improving their ROS which is the foundation of their success. You are asking them to give away the heart of the company to any competitor that makes cheap compatible hardware.

It is not going to happen. UBNT can spend their own money (including prize money) to develop their own OS. And don't believe that UBNT are just a bunch of nice guys who only want to make the world a better place to live. They are competitors who would love to take away Mikrotik's market.

Tom

PS I sell both Mikrotik and UBNT and I know what I am talking about.

RouterOS does run on custom x86 hardware...
In my eyes getting RouterOS on more hardware = more sold licenses.
But getting RouterOS on UNBT hardware does cost some $$$ to make it work a 100%.

Re: v4.0 Feature Request(s)

Posted: Sun Feb 22, 2009 5:26 pm
by roc-noc.com
Ethernet interface error statistics via CLI/Winbox and snmp.

You have already done a great job on wireless interfaces. Please pay similar attention to ethernet interfaces.

This is especially important now that you have RouterBoards like the new RB450G. We will be selling this as a low cost layer 3 switch. I can get loads of ethernet stats on the other layer 3 switches that I work with.

Tom

Re: v4.0 Feature Request(s)

Posted: Tue Feb 24, 2009 11:29 pm
by hedele
Hello :)

Is there any chance of getting server-side MLPPPoE implemented?
We had to use a Cisco 7200 Router for PPPoE termination because RouterOS does not support MLPPP on the server side :(

Since it is already working pretty well client-side, I suppose it might only be a small step towards a MLPPPoE server?

Re: v4.0 Feature Request(s)

Posted: Thu Feb 26, 2009 4:17 am
by taylorc
100% new version of NStream (NOT backwards compatable) to include advanced polling, full QOS, reduced latency, dynamic frequency selection WITHOUT disconnecting active clients, automaticly adjusting framing policy (that does not affect QOS)

New version of NStream Dual with automatic fall back to half duplex if one link fails
Perhaps enhance Nstreme throughput even more by providing the option of a sync-based mechanism. Example with 5 clients:

Polling-based
-----
AP Poll -> Client1
Client1 transmit
AP Poll -> Client2
Client2 transmit
AP Poll -> Client3
Client3 transmit
AP Poll -> Client4
Client4 transmit
AP Poll -> Client5
Client5 transmit

Sync-based
-----
AP -> Broadcast Sync and Timeslot assignments
Client1 transmit
Client2 transmit
Client3 transmit
Client4 transmit
Client5 transmit

Wouldn't that be sweet?!?!?

Re: v4.0 Feature Request(s)

Posted: Wed Mar 11, 2009 6:29 pm
by Akangage
Profile feature @ UserManager

Re: v4.0 Feature Request(s)

Posted: Thu Mar 12, 2009 7:21 pm
by bofh666ie
interface error stats and SNMP traps. And logging for mpls/vpls/ldp

Re: v4.0 Feature Request(s)

Posted: Sat Mar 14, 2009 4:48 pm
by sioannou
A torch option for the Firewall filter rules would be great.
e :D

Re: v4.0 Feature Request(s)

Posted: Sun Mar 15, 2009 3:15 pm
by sioannou
what about an MTR tool included on the MT. That will really help on troubleshouting network issues.

For MTR info visit this site http://www.bitwizard.nl/mtr/

Re: v4.0 Feature Request(s)

Posted: Mon Mar 16, 2009 11:23 am
by pedja
It would be great to see at least in and out interfaces for Connections. Some tool to investigate where actually travvic goeas according to Packet Flow Diagarm would be ultimate.

Re: v4.0 Feature Request(s)

Posted: Mon Mar 16, 2009 11:23 am
by normis
in and out interfaces for Connections
torch is no good?

Re: v4.0 Feature Request(s)

Posted: Mon Mar 16, 2009 5:01 pm
by omega-00
Ethernet interface error statistics via CLI/Winbox and snmp.

You have already done a great job on wireless interfaces. Please pay similar attention to ethernet interfaces.

This is especially important now that you have RouterBoards like the new RB450G. We will be selling this as a low cost layer 3 switch. I can get loads of ethernet stats on the other layer 3 switches that I work with.

Tom
Error statistics are already available via snmp, I was looking at these myself on an RB1000 just the other night, however it would be good to have them under an advanced section (similar to the wireless) when we want to check from winbox itself.

Re: v4.0 Feature Request(s)

Posted: Mon Mar 16, 2009 6:50 pm
by andreacoppini
It would be great to see at least in and out interfaces for Connections. Some tool to investigate where actually travvic goeas according to Packet Flow Diagarm would be ultimate.
Add me to this one! Bridges are hell to diagnose!

Re: v4.0 Feature Request(s)

Posted: Tue Mar 17, 2009 10:53 pm
by xezen
add some way to right data to sql server

as i would like to make a gui of my system
with gps information
and snmp data

Re: v4.0 Feature Request(s)

Posted: Wed Mar 18, 2009 1:13 am
by andreacoppini
add some way to right data to sql server

as i would like to make a gui of my system
with gps information
and snmp data
Isn't that what monitoring tools are for? The Dude can do that, only not in SQL (yet).


I vote for wireless diversity support.

Re: v4.0 Feature Request(s)

Posted: Fri Mar 20, 2009 12:41 pm
by chvdr
...
full antenna diversity support for regular 802.11a/b/g mode

full support for 802.11n and WiMax

...

is there some list of supported hardware

Re: v4.0 Feature Request(s)

Posted: Fri Mar 20, 2009 12:44 pm
by normis
http://wiki.mikrotik.com/wiki/Supported_Hardware

user maintained list, anyone can update it

Re: v4.0 Feature Request(s)

Posted: Fri Mar 20, 2009 1:05 pm
by chvdr
i just wonder what about 802.11n
is there any hope...

Re: v4.0 Feature Request(s)

Posted: Fri Mar 20, 2009 1:26 pm
by normis
i just wonder what about 802.11n
is there any hope...
search the forum, this question is answered too many times already

Re: v4.0 Feature Request(s)

Posted: Sat Mar 21, 2009 7:53 pm
by pedja
in and out interfaces for Connections
torch is no good?
Of course it is not. First it works only with one interface, and it shows traffic only on that interface.

What I asked for is that firewall connections show in and out interfaces in connection list. If the same list shows what exact routing table rule affected that connection that would be supreme help.

And, tool to investigate where through traffic actually goes according to Packet Flow Diagram would be ultimate.

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 6:16 am
by masked
ability to create hotspot options for users to select from bandwidth speeds and quota's not just time. please let me know if this is already available and i have overlooked it.

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 9:53 am
by xezen
i wanted to know in the firewall address list if thay can in to it
so that we can have
name and
ip address

or select a dns

name and
dns name

and the same thing with firewall insted of an ip address an dns name

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 9:56 am
by normis
what do you mean by "name" if it's not DNS name?

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 10:16 am
by xezen
for example

we have

name :goolge
ip address :196.100.30.1

now id like it to be

name :google
ip address :grayed out(as i have selected the option for dns name )
dns name :www.google.co.za

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 10:19 am
by normis
what is the use of this? you want to make an alternative for DNS :) ?

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 11:43 am
by xezen
yes it more for local dns
like one big network with 20 mailserver voip servers and hosting sevrer

so i dont have to keep track of the ip addres i just use the dns names for each of the hosting servers

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 2:33 pm
by Chupaka
Normis, he just wants to use domain names instead of IP addresses in firewall rules =)

xezen, no, it's not possible directly. you should use scripting

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 5:27 pm
by andreacoppini
Normis, he just wants to use domain names instead of IP addresses in firewall rules =)
Isn't that the use of firewall Address Lists?

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 5:36 pm
by Chupaka
Isn't that the use of firewall Address Lists?
what's general between Address-Lists and Domain Names?..

Re: v4.0 Feature Request(s)

Posted: Tue Mar 24, 2009 7:36 pm
by andreacoppini
Isn't that the use of firewall Address Lists?
what's general between Address-Lists and Domain Names?..
DNS names are for resolution by any TCP/IP device (computers, routers, servers, etc). Address Lists are only internal to the router they are specified on. Sort of like a 'Group' of IP addresses. A single address list name can contain multiple IP addresses, then when you set up firewall rules, you can use that address list 'name' instead of each device's IP address.

If you want to specify rules using names instead of IPs, and you want to address each device individually (instead of as a whole group), you could create a new address list for each device. So each address list name contains only 1 IP address. Very inefficient way of doing it in my opinion, but it can be done.

If you want to keep track of which rule is affecting which device, it's easier to just use comments!

Address Lists: http://www.mikrotik.com/testdocs/ros/3. ... s_list.php

Re: v4.0 Feature Request(s)

Posted: Wed Mar 25, 2009 2:43 am
by Chupaka
xezen wants to use names because IPs can change without notification =) so, as I said, he should use scripting. yes, quite efficient way is to add address-list, add entries for needed servers, write domain names in comments of those entries, and periodically via script update addresses of those entries by resolving their comments

Re: v4.0 Feature Request(s)

Posted: Wed Mar 25, 2009 11:11 pm
by xezen
im not good at scripting!!!!!!!!!!!
At all

so can you maybe show me an example to get this right
as it might be simple for others but im no good at it

so if you can give me an example i would be glad as it will help me a lot!

Re: v4.0 Feature Request(s)

Posted: Thu Mar 26, 2009 1:45 am
by omega-00
Heres an example of a command I use to change the IP for a VPN link between 2 dynamic IP addresses.
:global "vpn-interface-name" "Server_PPTP"
:global "new-vpn-ip" [:resolve "vpn.some.domain.tld"]
:global "current-vpn-ip" [/interface pptp-client get $"vpn-interface-name" connect-to]
:if ($"current-vpn-ip" != $"new-vpn-ip") do={ /interface pptp-client set [find name=$"vpn-interface-name"] connect-to=$"new-vpn-ip"}
It checks to see if the name resolution has changed since last time it looked (I'm using a dynamic DNS address on the vpn server router) and if so, changes the vpn connect-to ip to match.

Re: v4.0 Feature Request(s)

Posted: Thu Mar 26, 2009 1:50 am
by Chupaka
add the following script
:local addresslist "mylist"
/ip firewall address-list
:foreach i in=[find list=$addresslist] do={set $i address=[:resolve [get $i comment]]}
change "mylist" to your desired address-list name, then
/ip firewall address-list
add list=mylist comment="google.com"
add list=mylist comment="myserver1.local"
add list=mylist comment="myserver2.local"
and run script

Re: v4.0 Feature Request(s)

Posted: Thu Mar 26, 2009 3:41 pm
by xezen
thnaks for all the help with the scripting part it helped me solve the problem

there should be a topic i opend with examples of scipts to help people

as i know the people in this forum will have somthing to say as this topic we are talking in is for v4.0
and not for scrpits
thanks for the help

Re: v4.0 Feature Request(s)

Posted: Thu Mar 26, 2009 3:55 pm
by normis
thnaks for all the help with the scripting part it helped me solve the problem

there should be a topic i opend with examples of scipts to help people

as i know the people in this forum will have somthing to say as this topic we are talking in is for v4.0
and not for scrpits
thanks for the help
there is such place: http://forum.mikrotik.com/viewforum.php?f=9

Re: v4.0 Feature Request(s)

Posted: Fri Apr 24, 2009 4:37 pm
by xezen
can use add a connection be able right logs straight into a access,sql or oracle database? even if it must be done by script

so routerboard will be able to understand SELECT * FROM WHERE
connect
address
username
password

as i like to have one thing that does everything?

or to allow some kind of file transfer to be able to take place between routerboards and a pc?

Re: v4.0 Feature Request(s)

Posted: Fri Apr 24, 2009 10:28 pm
by trm3
I have a very specific need for real unencrypted GRE tunnels rather than IPIP tunnels. Some of the hardware that my customers' satellite traffic traverses can apply various spoofing / window adjustment acceleration procedures to both native traffic and GRE tunnels, but not IPIP or any other form of tunnel. Could there be a tunnel-type pull down defaulting to the existing IPIP, but allowing selection of GRE, in the IP Tunnel creation window?

Re: v4.0 Feature Request(s)

Posted: Fri Apr 24, 2009 11:16 pm
by trm3
The ability to specify different redistribution rules for each VRF (for BGP/OSPF/RIP/Static/Connected) is a must in our environment. We have a global Cisco MPLS network with each VRF having a /27 or /28 presence in every major node with interconnected customer/satellite routers. We need either individual controls or individual in/out route-maps for each VRF.

Sorry if I've overlooked something, but I can't find this.

Re: v4.0 Feature Request(s)

Posted: Tue Apr 28, 2009 9:37 am
by titius
USB ethernet and wireless support? Is it hard?

I know some USB ethernet work, but very very small number of devices work :(

Re: v4.0 Feature Request(s)

Posted: Tue Apr 28, 2009 9:49 pm
by xezen
when i run this
:local addresslist "mylist"
/ip firewall address-list
:foreach i in=[find list=$addresslist] do={set $i address=[:resolve [get $i comment]]}
most of themstay 0.0.0.0 can anyone tell me why

Re: v4.0 Feature Request(s)

Posted: Wed Apr 29, 2009 12:19 am
by Chupaka
xezen, it seems like error in :resolve of unknown host in your comment. maybe some coments are absent, or they are inexistant names? try running this script in terminal window:
{
:local addresslist "mylist"
/ip firewall address-list
:foreach i in=[find list=$addresslist] do={set $i address=[:resolve [get $i comment]]}
:put "All done, keeper!"
}

Re: v4.0 Feature Request(s)

Posted: Wed Apr 29, 2009 2:51 pm
by normis
wrong thread! make a new post in Scripting forum

Re: v4.0 Feature Request(s)

Posted: Wed Apr 29, 2009 11:02 pm
by HaQs
Native support in ROS to automaticaly backup CFG to FTP server
Set Time: day / week / month ...
file name: RB_IDENT_TIME ...

Re: v4.0 Feature Request(s)

Posted: Thu Apr 30, 2009 12:46 am
by ayufan
You can send a mail with backup.

Re: v4.0 Feature Request(s)

Posted: Thu Apr 30, 2009 1:35 am
by noam_chom
Decent per user QOS would be nice to have in the ROS 4.0 .
If I am not wrong we all concluded that still there is no way to make "per user QOS" in MT.

Ilija

Re: v4.0 Feature Request(s)

Posted: Thu Apr 30, 2009 12:02 pm
by xezen
{
:local addresslist "mylist"
/ip firewall address-list
:foreach i in=[find list=$addresslist] do={set $i address=[:resolve [get $i comment]]}
:put "All done, keeper!"
}
i ran this and it sed
failure

i took all the comment and ran a ping on all of then and all come back with a reply

her is my examples

im having problems with

home.disney.go.com
youtube.com
facebook.com

Re: v4.0 Feature Request(s)

Posted: Thu Apr 30, 2009 12:52 pm
by Chupaka
open terminal and try ":put [:resolve home.disney.go.com]" - what will you see? maybe you have a space before or after comment?

Re: v4.0 Feature Request(s)

Posted: Thu Apr 30, 2009 2:49 pm
by omega-00
when i run this
:local addresslist "mylist"
/ip firewall address-list
:foreach i in=[find list=$addresslist] do={set $i address=[:resolve [get $i comment]]}
most of themstay 0.0.0.0 can anyone tell me why
Side note that IS relevant to v4 feature requests: the resolve command is currently broken and has been for the last couple of versions.
using :resolve in any script where the domain doesn't resolve will simply cause the script to terminate. Can this be fixed for v4? :-P

Re: v4.0 Feature Request(s)

Posted: Thu Apr 30, 2009 11:21 pm
by xezen
thanks for all the help thay should start a live chat that we can try solve this live as i tryed #mikrotik on the irc be not many people are on there

Re: v4.0 Feature Request(s)

Posted: Thu Apr 30, 2009 11:24 pm
by xezen
that was broken as one one my names on my list were not working and when i deleted them the rest worked so if this problem can be fixed it will be help full thanks
mikrotik and all the users forthe help

Re: v4.0 Feature Request(s)

Posted: Fri May 01, 2009 4:30 pm
by titius
and you again posting scripting issues in wrong area?

Re: v4.0 Feature Request(s)

Posted: Thu May 07, 2009 5:37 pm
by iwikus
Improved cluster (HA) support - to have two rb450G as active/standby cluster:
- nat table (conntrack) synchronization between two boxes.
- some kind of automatic configuration replication to standby box.

Re: v4.0 Feature Request(s)

Posted: Thu May 07, 2009 6:01 pm
by Chupaka
- nat table (conntrack) synchronization between two boxes.
could you please describe it in more detail?..

Re: v4.0 Feature Request(s)

Posted: Thu May 07, 2009 6:09 pm
by QpoX
Improved cluster (HA) support - to have two rb450G as active/standby cluster:
- nat table (conntrack) synchronization between two boxes.
- some kind of automatic configuration replication to standby box.
i agree, redundancy on all functions.

Re: v4.0 Feature Request(s)

Posted: Thu May 07, 2009 7:46 pm
by iwikus
If you use VRRP and NAT (and/or statefull firewall) you need to transfer connection states when IP is transfered to other box (failover happends). If not, established connections will be dropped.

http://conntrack-tools.netfilter.org/ma ... ml#sync-pb
- nat table (conntrack) synchronization between two boxes.
could you please describe it in more detail?..

Re: v4.0 Feature Request(s)

Posted: Fri May 08, 2009 2:41 am
by omega-00
Improved cluster (HA) support - to have two rb450G as active/standby cluster:
- nat table (conntrack) synchronization between two boxes.
- some kind of automatic configuration replication to standby box.
Add to that, active hotspot user synchronization between devices.

Re: v4.0 Feature Request(s)

Posted: Mon May 18, 2009 2:52 pm
by jsanyi
Hi!
Would it be possible to...
- use the dynamic address lists in webproxy access lists too? (adding and removing or disabling a lot of rules from access lists would be much problematic than using lists already defined for firewalling for the same, very different networked addresses)
- create some kind of rule groups in webproxy access lists? (eg. a group for chat sites could be assigned to an address or a subnet, or maybe to a list of ips with only one rule, this would minimalize the access list items needed and improve easy configuration, eg. 10+3 rules would be enough to enable/disable access to 10 sites for 3 subnets, while this now needs 10*3 rules)
Thanks!

Re: v4.0 Feature Request(s)

Posted: Thu May 28, 2009 2:30 am
by astib
Hi!
I would love to have in new version:
- GRE support (no EOIP, IPIP, PPTP ... just GRE please :-) This can make my life much easier!
- source address for EOIP tunnel, like IPIP has
- ability of telnet/ssh from MK to non-default ports
- keys support for WinBox
- synchronization of connections between routers
- synchronization of particular filter tables would be lovely, even very basic!
- better firewall logging (session creation,teardown, bytes sent, etc)

Just my ideas -- thanks for reading them :)

Astib

Re: v4.0 Feature Request(s)

Posted: Thu May 28, 2009 12:23 pm
by Chupaka
- ability of telnet/ssh from MK to non-default ports
[admin@vpn1] > /system telnet 192.168.0.1 ?
Port ::= 1..65535    (integer number)

Re: v4.0 Feature Request(s)

Posted: Thu May 28, 2009 1:20 pm
by astib
:-D
ok, feeling ashamed, forget that line :)

Re: v4.0 Feature Request(s)

Posted: Sun May 31, 2009 5:03 pm
by Martell
I seriously second the improved IPSEC implementation as mentioned by nz_monkeys! Yes, yes and yes, please!

If possible, even in the 3.x version. I aslo work a lot of Junipers/Netscreens, Ciscos, Checkpoints and others, and the tunnel inerfaces are the most needed lack in the MT.

I know they are very serious guys there in the MT and they can easily make the changes! I respect them a lot.

Re: v4.0 Feature Request(s)

Posted: Mon Jun 01, 2009 10:07 am
by nz_monkey
Hi Martell,

Please vote on this feature at http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

A lot of people want the tunnel/route based IPSEC support, but it's no good posting all over the forums as it can be easily forgotten.

Also, if Normis or any of the other MT guys are paying attention I can provide access to:

- Juniper J Series, SRX, SSG(Netscreen)
- Fortinet FortiGate's
- Cisco 8xx, 18xx

For testing during the development of this feature.

Re: v4.0 Feature Request(s)

Posted: Mon Jun 01, 2009 11:19 am
by xezen
what about raid for x86 os?
so licanse key can be saved or backed up in somekind of whay

Re: v4.0 Feature Request(s)

Posted: Mon Jun 01, 2009 11:24 am
by normis
raid makes problems with license key, it can't work. but this is not the only reason RAID is not supported.

Re: v4.0 Feature Request(s)

Posted: Mon Jun 01, 2009 11:46 am
by xezen
so what the best way i can set up a x86 system to prevent hardwer fail and be able so have storade

i thougt load os on sd card

put thats not best for proxy

Re: v4.0 Feature Request(s)

Posted: Mon Jun 01, 2009 12:03 pm
by Chupaka
you may use another drive for proxy cache

Re: v4.0 Feature Request(s)

Posted: Mon Jun 01, 2009 9:25 pm
by xezen
so on sd card and another drive for proxy?


whats be safest way for less hardware problems

Re: v4.0 Feature Request(s)

Posted: Wed Jun 03, 2009 8:58 pm
by infowest
Nstreme improvement ideas:

- Can Nstreme in PTMP environment be more intelligent about polling, such that "less busy" CPE's get fewer polls, thus reducing the resource usage and hopefully allowing us to get more cpe's per AP before we start hitting the nstreme limits?
- Can Nstreme be built into hardware on a routerboard to make it more efficient, handle more cpe's, etc?
- GPS sync for nstreme - what a winner that would be!

Re: v4.0 Feature Request(s)

Posted: Thu Jun 04, 2009 2:35 am
by nz_monkey
Put your requests on the Wiki so people can vote on them: http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Re: v4.0 Feature Request(s)

Posted: Thu Jul 09, 2009 8:47 pm
by ochyst
Please, we need stable sshd and https on RouterOS or something to restart deamons without reboot router.

Watchdog for deamons?

Seting /ip services from more than one network (available from)?
Users - more than one allowed address?

Support for 3.5GHz?

More testing before relase new version of RouterOS!!!

Re: v4.0 Feature Request(s)

Posted: Sun Jul 12, 2009 12:14 am
by Verlen
Please in add sorting by enabled/disabled account in PPP - Secrets (via Winbox)

Re: v4.0 Feature Request(s)

Posted: Sun Jul 12, 2009 11:04 am
by xezen
cant mikrotik add VideoCache to mikrotik x86 proxy service?


as it would be nice to have one system working

we know squid is an option

Re: v4.0 Feature Request(s)

Posted: Mon Jul 20, 2009 10:30 am
by xezen
question has mikrotik thought aboat adding an digital in/output to one on the new release boards


uses for it could be for alarm output for tamper if some one trys to open mikrotik box so it can email and sms network administrator

can be used for a relay output if needed to trigger something

and can be used in industrial use for reading inputs and relaying outputs at the mikrotik is the best board used for many diffrent industrial useses just with comm to ip no relay input trigger and output trigger will make it very usefull in industrial use

TDMA and GPS on a routerboard?

Posted: Sat Aug 22, 2009 5:15 am
by infowest
I'd much rather see polling done in hardware (fpga) so we can scale like crazy, but would TDMA be of any use in software? Someone apparently is doing that...

Examples:

FreeBSD (looks like it could even use GPS - why not add GPS to a routerboard?):

http://siomail.ucsd.edu/pipermail/swap/ ... 00683.html

Linux:

http://www.cs.ucdavis.edu/~prasant/pubs ... -tdmac.pdf

Re: v4.0 Feature Request(s)

Posted: Sat Aug 22, 2009 5:45 am
by fewi
If you use VRRP and NAT (and/or statefull firewall) you need to transfer connection states when IP is transfered to other box (failover happends). If not, established connections will be dropped.

http://conntrack-tools.netfilter.org/ma ... ml#sync-pb
- nat table (conntrack) synchronization between two boxes.
could you please describe it in more detail?..
I very much second that. This would put the firewalling capabilities somewhere up there with ASAs and competing products.

A related though somewhat different request: ideally, this could even be extended into a load sharing scenario - if all machines in the 'cluster' know about all clients, the DHCP server can pass out the different gateway IPs (possibly with a manually configurable weight? That way you can mix different hardware platforms) and you can scale with the number of customers simply by adding more routers. This would be extremely useful for Hotspot scenarios. I've dealt with Hotspot areas that had to temporarily support over 6,000 concurrent clients - nearly impossible to do on a single box.
In that case you may not be able to have full connection state table sharing so that connections are reset, but it could reasonably work just by all slaves sharing authentication state of clients so clients don't have to re-authenticate.

Felix

Re: v4.0 Feature Request(s)

Posted: Tue Aug 25, 2009 12:55 am
by fewi
Very minor: when running "/system backup save", the default filename is in format Hostname-DDMMYYYY-HHMM. That doesn't sort very well, maybe it would be nice if this could be in ISO format Hostname-YYYYMMDD-HH:MM instead.

Felix

Re: v4.0 Feature Request(s)

Posted: Tue Aug 25, 2009 6:43 am
by dssmiktik
do you want v3 to ever be stable? ;)
Yes I do, very much so!

Re: v4.0 Feature Request(s)

Posted: Tue Aug 25, 2009 6:46 am
by dssmiktik
Virtual Routers/Virtual Domains is a great idea, but I would not want to be the programmers at Mikrotik trying to implement it!
Using more standard, mature packages from open source would be nice. They've been around a long time and have a huge user base hacking and perfecting the software.

Re: v4.0 Feature Request(s)

Posted: Tue Aug 25, 2009 6:51 am
by dssmiktik
I would like to have a full configurable webbox selecting what i want to show on webbox (maybe only NAT rules and some few more features)
Something like the HotSpot Interface.
*bump
Along with this a configuration option to enable/disable simple/advanced web interface (default being simple interface). This way many users are happy with simple webbox but advanced users can get advanced interface if desired.

Re: v4.0 Feature Request(s)

Posted: Mon Sep 21, 2009 6:04 pm
by stephenpatrick
Intel 82574L Gigabit Ethernet controller

Is this supported, or going to be supported?

Regards

Re: v4.0 Feature Request(s)

Posted: Mon Sep 21, 2009 8:12 pm
by dssmiktik
Intel 82574L Gigabit Ethernet controller

Is this supported, or going to be supported?

Regards
Support for all Intel 825xxx gigabit ethernet controller. (This should be one driver to cover any card with that chipset.)

Hardware assisted TDMA

Posted: Sat Jan 09, 2010 1:25 pm
by nz_monkey
There are a few updated papers on Sam Leffler's Atheros hardware assisted TDMA implementation. They are a very interesting read, and something I hope we will see on RouterOS at some point in the future.

http://people.freebsd.org/~sam/FreeBSD_ ... 090921.pdf
http://people.freebsd.org/~sam/TDMAPres ... 090921.pdf

Re: v4.0 Feature Request(s)

Posted: Sun Jan 17, 2010 8:17 am
by fbaffoni
There are a few updated papers on Sam Leffler's Atheros hardware assisted TDMA implementation. They are a very interesting read, and something I hope we will see on RouterOS at some point in the future.

http://people.freebsd.org/~sam/FreeBSD_ ... 090921.pdf
http://people.freebsd.org/~sam/TDMAPres ... 090921.pdf
Totally Agree with nz_monkey, Ubiquiti has added the Sam Leffler's implementation on his new AirMax, could be greate if Mikrotik be compatible with Ubiquiti AirMax. I'd prefer to use a MK AP than a Ubiquiti AP (MK hardware has better rosourses)

I know that MK has his own polling algorithm using NSTREME and is possble to disable CSMA, but NSTREME is a propietary protocol, I can't use Ubiquiti. Could be greate if MK support TDM.


What do the MK people says about this?

Re: v4.0 Feature Request(s)

Posted: Sun Jan 17, 2010 10:10 am
by nz_monkey
I am not concerned with Ubiquiti AirMax compatibility at all.

It would just be good to see a hardware based TDMA protocol on Mikrotik.

Re: v4.0 Feature Request(s)

Posted: Thu Feb 11, 2010 10:31 am
by ElectricCat
My feature request: sometimes the symbolic name of the PPTP-server is needed to connect to ISP, but the RouterOS asks the IP address only. If MikroTik were make it possible to use symbolic names as the PPTP-server address, there would be a great leap for them in Russia.

Re: v4.0 Feature Request(s)

Posted: Thu Feb 11, 2010 9:43 pm
by pedja
That was asked long time ago and declined. Mikrotik stuff does not have understanding for our needs to be able to use mnemonic addresses instead of IP.

Re: v4.0 Feature Request(s)

Posted: Fri Feb 12, 2010 7:43 am
by ElectricCat
That was asked long time ago and declined. Mikrotik stuff does not have understanding for our needs to be able to use mnemonic addresses instead of IP.

Pity... Well, we should use our scripting solutions then...

Re: v4.0 Feature Request(s)

Posted: Fri Feb 12, 2010 5:14 pm
by pedja
Yes, and do not ask why you have to hack something that should and can be so simple....

Good side is that we now have Routerboards with TWO power connectors. That is a huge gain.