Page 1 of 1

Vote for new RouterOS features!

Posted: Tue Mar 13, 2007 3:01 pm
by normis
http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Please add your votes to the list, or add new features. The list is moderated, so no cheating - only add +1

Example: MPLS (votes: 1) - if you would like to see this feature, hit EDIT and change to "votes: 2".

Posted: Tue Mar 13, 2007 10:47 pm
by The Grog
You do MPLS and I will personally buy at least 30 licenses..

I can then deploy Mikrotik instead of expensive Cisco routers!

You have my vote for MPLS.. adding it now!

Posted: Wed Mar 14, 2007 9:44 am
by janisk
nice idea

maybe users will get more used to existence of wiki as a good source of information

Posted: Wed Mar 14, 2007 12:51 pm
by normis
nice voting, keep 'em coming!

Posted: Mon Mar 19, 2007 12:33 pm
by normis
cheating is not tolerated, I have temporarly blocked Rpingar's account for messing with the votes

Posted: Mon Mar 19, 2007 3:04 pm
by stephenpatrick
cheating is not tolerated
Can we have another Wiki to "name and shame" the cheats ...

Posted: Mon Mar 19, 2007 3:39 pm
by pedja
why you do not use voting feature of this forum?
It is better, more practical and easier to use.

Posted: Mon Mar 19, 2007 3:41 pm
by normis
users can't add features in forum polls

Posted: Mon Mar 19, 2007 5:43 pm
by ofca
besides, in poll you can vote on only one position.
BTW:
"Your IP address is 10.1.7.53. Please include this address in any queries you make."

Posted: Tue Mar 20, 2007 8:44 am
by normis
yes that's another problem, forum visitors have one ip

Posted: Tue Mar 20, 2007 9:15 am
by rpingar
you are right i just added two o three vote to Wireless QoS on 12 and plus vote.....(i added the feature)

Nice to see you cancelling completely the feature, this means only that you don't have great interest to implement it.

Sorry about it, I have never read that one user can only exprime one vote.

Regards

Posted: Tue Mar 20, 2007 9:25 am
by normis
well what did you think? you thought you can add 999 votes to one feature?

Posted: Tue Mar 20, 2007 9:28 am
by rpingar
:D

Posted: Tue Mar 20, 2007 3:53 pm
by BrianHiggins
what happened to the wireless QOS? when I voted for it I was the 13th vote... and now I don't see it listed anymore :cry:

Posted: Tue Mar 20, 2007 4:14 pm
by rpingar
ask normis!!! :)

Posted: Tue Mar 20, 2007 4:37 pm
by normis
it's there

Posted: Wed Mar 21, 2007 3:03 am
by BrianHiggins
not that I can see... there's Wireless QoS WMM with 3 votes, but when I voted there was a Wireless QOS with 12 votes, plus my vote to make 13...

the wireless GPS sync was there with 11 or 12 votes when I voted, so it couldn't have been renamed...

someone has completly removed the wireless qos from the list...

Posted: Wed Mar 21, 2007 8:46 am
by normis
it's because mister Rpingar here added his 10 votes, i removed those

Posted: Wed Mar 21, 2007 10:40 am
by Alex
if I have only 1 vote can i remove my vote from list and add it to other position or create new?

Posted: Wed Mar 21, 2007 10:43 am
by cmit
Hmmm?
If I don't really understand something basic very wrong, it should be obvious how you can vote:
You only have ONE vote for EACH feature that's on the list, and of course you may also add one or more features to the list and add 1 vote for each feature.

You may NOT add more than one vote for any single feature, because that would distort the picture.

Normunds: Right?

Best regards,
Christian Meis

Posted: Wed Mar 21, 2007 10:51 am
by normis
of course ...

Posted: Wed Mar 21, 2007 10:58 am
by normis
here come some early replies to your requests:
GPS Wireless Sync


not possible at all, special professional grade hardware is needed. the GPSes that attach to serial port have precision of ~1 sec. The special hardware device will have ~40uSec.
IPv6


although IPv6 is a wery wide subject, we are already testing it.
Wireless Routing Protocols


working on it
Winbox Graphical QOS Flow for easy setup up of Bandwidth limiting and
Shaping
can someone clarify this ???
"SNMP V2, V3"
v3 already has this

Posted: Wed Mar 21, 2007 11:12 am
by Alex
Normis, can you add in next routeros virtual ethernet interface, witch can be connected to real ethernet card? When you change hardware of your router, routeros usualy lose ip address and arp table settings(they becomes invalid). If this feature will be avalaible, i think this "bug" will be fixed :)
for example: ip address is set up on virtual interface. Name of interface is changed(not ether1, for example fibertomoscow).You change hardware.After change virtual interface connects to ethernet card and all settings will be ok.

Posted: Wed Mar 21, 2007 11:18 am
by janisk
the problem is - your virtual interface should be somehow linked to real interface - only thing to do that, that i know, is mac address, so if you cahnge your NIC MAC will change too, so you will loose config either way, but you can set name of that interface to a previous value and at least some rules are preserved.

but then we end up in the same spot we began with.

use VLAN

Posted: Wed Mar 21, 2007 11:23 am
by Alex
all of soho routers can clone mac address.i dont think that it is hard to do this in soft.if you have 1 ethernet card, virtual interface can be linked without problem.if more, then may be by irq

Posted: Wed Mar 21, 2007 11:58 am
by ofca
janisk - what he meant is some "config" object, on which you can do most things, and which would work as alias for any rules and stuff defined. Then you could attach this "config" object to some interface, and it would immediately "redirect" all connected rules/queues/stuff, and also reconfigure settings, like mac-address, link-speed etc.

You could go one step further:
/interface config
add type=wireless name="wireless-uplink" ssid="..." mode=station
add type=ethernet name="lan" mac-address=00:00:00:00:00:00
/interface config relations
set wireless-uplink real-interface=wlan1 auto-relate-pattern-on-missing="wlan#"
set lan real-interface=ether1 auto-relate-pattern-on-missing="ether#"
As long as you keep your router wlan1,2,3 and ether1,2,3 free, you can swap damaged cards and every new would pick-up configuration object from removed one.

That's for theory, but how easy/possible it is to code is on you :)

Posted: Wed Mar 21, 2007 1:05 pm
by Frizz
here come some early replies to your requests:
GPS Wireless Sync


not possible at all, special professional grade hardware is needed. the GPSes that attach to serial port have precision of ~1 sec. The special hardware device will have ~40uSec.

The gps hardware that works with Motorola canopy or Skypilot gear does not look that special at all....

I do understand gps sync is quite hard to implement with a polling protocol instead of a time slotted one.

But what about implementing the capability of receiving on a channel and trasmitting on another that would achive the same result of gps sync but is a lot easier to implement?



What I'm talking about here it is not receiving and trasmitting on a channel at the same time (that of course is not possible with only one card); It is about quickly changing the channel before trasmitting while listening all the time on the receiving channel.

Depending on the atheros driver this could be quite easy to implement and would have the same benefits of gps sync that is:
eliminating colocation interference and allowing channel reuse
this is something wisps very badly need to scale and support hundreds of subscribers on a single site.

check out this post for further explanation:
http://forum.mikrotik.com//viewtopic.php?t=14337

Posted: Wed Mar 21, 2007 2:51 pm
by normis
the problem is that the internal timings of the GPS device are around 40uSec, but the data over serial is transfered once in 1-2 seconds, plus the `latency` of the serial port itself ...

Posted: Wed Mar 21, 2007 6:50 pm
by stephenpatrick
I think there are some solutions for this. Certainly it can be done, there are solutions out there commercially available, i.e. accurate sync of serial-attached GPS.
I had a quick (30 sec) websearch:
http://lists.ntp.isc.org/pipermail/ques ... 08797.html

http://www.brigsoft.com/atomic-clock-sync/

http://www.galsys.co.uk/gps-network-server-time.htm

http://www.atomic-clock.galleon.eu.com/ ... oducts.htm

http://www.spectracomcorp.com/

http://www.beaglesoft.com/stsyinstall.htm

There seem to be ways to solve this problem - how about some more research on that angle?
Do the MT developers want us/me to have a more detailed look - happy to help.

Regards

CableFree Solutions

Posted: Thu Mar 22, 2007 9:28 am
by normis
I think there are some solutions for this. Certainly it can be done, there are solutions out there commercially available, i.e. accurate sync of serial-attached GPS.
I had a quick (30 sec) websearch:
http://lists.ntp.isc.org/pipermail/ques ... 08797.html

http://www.brigsoft.com/atomic-clock-sync/

http://www.galsys.co.uk/gps-network-server-time.htm

http://www.atomic-clock.galleon.eu.com/ ... oducts.htm

http://www.spectracomcorp.com/

http://www.beaglesoft.com/stsyinstall.htm

There seem to be ways to solve this problem - how about some more research on that angle?
Do the MT developers want us/me to have a more detailed look - happy to help.

Regards

CableFree Solutions
most of these links don't talk about precision, one mentioned 40ms, that's not enough to be useful.

Posted: Thu Mar 22, 2007 12:42 pm
by stephenpatrick
Thanks for pointing that out Normis, clearly 30 secs wasn't enough - I will have to do some more homework :oops:
I am sure there is a solution out there - just need to find it -

Posted: Thu Mar 22, 2007 8:44 pm
by stephenpatrick
OK, I did 5 minutes more homework:

http://www.embeddedstar.com/press/conte ... d2741.html
http://www.embeddedstar.com/press/conte ... d5918.html
and the vendor is ...
http://www.trimble.com/tmg_acutime2k.shtml
and a product/starter kit
http://trl.trimble.com/docushare/dsweb/ ... nt-186464/
protocol that you it uses
http://www.navgeocom.ru/oem/download/genf/tsip.pdf

It does seem to meet the timing needs, as well as using RS232 interface. Guess it's calibrating itself, measuring the time taken across the RS232 interface to get it to the quoted 50 nanoseconds.

So a bit more digging should get the exact solution for GPS sync ...
Hope the MT guys can build it in -

Regards

CableFree Solutions

Posted: Fri Mar 23, 2007 7:38 am
by bjohns
Are there any miniPCI based GPS devices?

Commell make one although there aren't any specifications detailing accuracy/speed.

Posted: Fri Mar 23, 2007 7:11 pm
by stephenpatrick
Nice one -
Interestingly, according to the manual
ftp://ftp.commell.com.tw/COMMELL/suppor ... 954GPS.pdf
it appears as UARTs (read: COM ports) i.e. the miniPCI contains PCI<>UART then UART<>GPS. So the situation is similar to a serial GPS module regarding timing I guess.

No Linux drivers mentioned - Windows only :-(

Regards

CableFree Solutions

Posted: Thu Mar 29, 2007 7:29 pm
by Hammy
the problem is that the internal timings of the GPS device are around 40uSec, but the data over serial is transfered once in 1-2 seconds, plus the `latency` of the serial port itself ...
Mikrotik has developed quite a bit of hardware. Couldn't you just develop a GPS receiver that does what you want?

Posted: Fri Mar 30, 2007 5:15 am
by ubb
I added arping to the list. It's been removed with a note saying that it's already there. As far as I'm aware, there's a MAC ping but not arping. They're opposites. Am I mistaken? Maybe I just haven't seen the arping.

Posted: Fri Mar 30, 2007 8:34 am
by normis
[normis@demo.mt.lv] > ping 
Send ICMP Echo packets. Repeat after given time interval.

<address> -- IP address
interval -- Delay between messages
size -- Packet size
ttl -- Time to live
do-not-fragment -- Do not fragment ping packets
src-address -- Source IP address to use when pinging
arp-interface -- Ping using ARP requests on this interface instead of ICMP
count -- 
^^^^ not this one ? this is v2.9

Posted: Wed Apr 04, 2007 11:50 pm
by tgrand
It would be nice to have a system logging action to allow a script to run.

Posted: Thu Apr 05, 2007 10:07 pm
by freethought
I've added DHCP failover as seen in ISC DHCPD (i.e. with the ability to synchronize leases so that all servers can serve the entire subnet) and support for Sangoma S518 ADSL PCI Cards including the ability to do ML-PPP to the wiki page.

Posted: Mon Apr 09, 2007 7:26 pm
by ginovilla
Since the GPS Sync option is difficult to implement, are you guys are already working for the MPLS feature?

Gino

GPS Sync

Posted: Sat Apr 14, 2007 11:31 am
by geskorup
I think the only reason people are looking for GPS sync with MT is so that they do not have to buy expensive Motorola equipment. You do have to realize that even if they did implement GPS sync, it most likely wouldn't be compatible with Motorola or any other GPS sync'd product. So what's the point?

Well, forget the GPS part, what about just a standard sync? Two or three radios in the same board transmitting at the same time shouldn't be too tough to do.

And I think you may be incorrect about the whole timing/latency issue. The GPS RECEIVER may be accurate to 40-50uS. But the timing mechanism with Motorola Canopy is one pulse per second. You can make a fake sync at..... one pulse per second (useful in the event of a GPS failure). You can take two APs, run a sync cable between them, have one radio set to generate the sync and the other receive... no GPS, just sync.

The whole GPS idea is to avoid site-to-site interference AND co-location interference.

With all the votes for GPS sync, it's a good idea, but it just isn't going to happen. It could, but I think MT would have roll out entire new hardware to get it done. It would be expensive, so again, what's the point? If you want GPS sync just buy Motorola.

Posted: Sat Apr 14, 2007 12:21 pm
by Frizz
Normis,
Please try to understand how important channel reuse is for wireless isp that have many subscribers.
This is not something the casual user that set up a link or two will request, that's for sure.

However, being able to reuse channels on the same site is a must for a carrier grade platform that enables wisp to reach economy of scale connecting hundreads of subscribers on a site.

I'm personally working for a wisp with thousands subcribers, we use mainly mikrotik/nstreme with very good results and we are very satisfied with it.
Unfortunalty, on many sites we are now hitting a wall, we cannot squeezee more subscribers on the AP and there are only a few channels..... We cannot even get more sites since they would interfere with each other, not being in synchronized transmission.

Please have a serious look into the feasibility of GPS sync or some other simpler alternative solutions like:
-simple sync: two or three radios in the same board transmitting at the same time. (this could be very easy to do)
-or single radio that transmitts on a channel and receive on another.
-or any other simple solution that avoiding co-location and site-to-site interference enables channel reuse.

Posted: Sun Apr 15, 2007 5:42 am
by TomKolb
I posted this the other day in another thread. I think it is a must have feature.

We use a lot of Canopy gear that we GPS sync with 3rg party GPS receiver hardware. It comes from a great company called PacketFlux at http://www.packetflux.com/ that costs 139.95. I bet these guys could provide the hardware design if Mikrotik can find a way to utilize it.

Posted: Mon Apr 23, 2007 1:16 pm
by complete2006
Better debug information like cisco's "show".
In the past we used cisco before we through the out and migrated to ROS. After having trouble with the OSPF (also routing test) in ROS we removed the both core routers an put Cisco 7301 in. After some hours I felt comfortable again with IOS and I saw what I miss in ROS (debug). In cisco I miss Winbox :lol:

I know we are talking about different price-worlds but much more debugging will be fine.

Re: Vote for new RouterOS features!

Posted: Wed May 30, 2007 11:30 am
by pedja
I voted for few items. now I see list is longer and I would liek to vote for some more, but I cannot tell which one I already voted for. :(

Re: Vote for new RouterOS features!

Posted: Thu May 31, 2007 3:59 pm
by janisk
see history of that document and you will see what have you changed when you entered your vote the first time

Re: Vote for new RouterOS features!

Posted: Fri Jun 22, 2007 10:20 am
by changeip
not worth wasting a vote on, but it would be nice to be able to also specify a band in a connect-list entry.

Sam

Re: Vote for new RouterOS features!

Posted: Tue Jun 26, 2007 11:01 am
by uldis
not worth wasting a vote on, but it would be nice to be able to also specify a band in a connect-list entry.

Sam
currently you can only specify one interface in the connect list. And you are setting in the interface settings the band. The wireless card. So I think this additional setting is not required.

Re: Vote for new RouterOS features!

Posted: Fri Jun 29, 2007 1:37 am
by bokili
Again, Can you add VPDN Functions on voting:

1. L2TP Tunnel Authentication
2. LAC and LNS Functions
3. Multiple (id) sessions through one l2tp tunnel
4. Accepting multiple connections through one LAC (To make possible multiple (without limit) l2tp connections from the same LAC)
5. Include multilink possible with l2tp connections from LAC (so you can use ISDN 2 channels without a problem)

I see that there is a lot of interested companies and individuals in this functions.