Page 1 of 2

BETA Testing and Feature Suggestions for next routeros

Posted: Mon Jan 30, 2006 3:04 pm
by cibernet
2.10 :D some ETA? perhaps a year?

Posted: Mon Jan 30, 2006 3:10 pm
by normis
sooner. really sooner. q3 2006 maybe

whats is q3 2006

Posted: Mon Jan 30, 2006 7:12 pm
by kleber
Sorry for bad English, but whats is q3 2006 ?

BETA Testing and Feature Suggestions for 2.10

Posted: Mon Jan 30, 2006 7:28 pm
by dsovereen
OSPF Route/Prefix Filtering (my apologies if this is in routing-test already)

Dave

Posted: Mon Jan 30, 2006 9:02 pm
by rickard
I hope they will include support for Intel motherboard temp readings :-)
that will be nice.

Posted: Mon Jan 30, 2006 9:32 pm
by altaphon
Q3 2006 means the third quarter of 2006 -- hope that's right!

More diagnostic info is always useful. The SNR figures in wireless-test are great, should we expect to see that migrated to 2.10 stable? How about some details on how you measure noise? I can guess, but it would be helpful to know what is actually being measured so we can guess what noise sources it's going to be useful to identify (mainly, is it responsive to noise on channel only, or on adjacent channels too, which would cause some degradation to on-channel performance)?

Posted: Tue Jan 31, 2006 12:21 am
by Beccara
IPV6 - Pure and Dual Stack Options

Posted: Tue Jan 31, 2006 6:14 am
by jp
I'd like to see more commands for filtering a printout on the cli, *nix has grep, cisco has | include, mikrotik has no good cli for this. If you do a /ip route print, you can have pages of routes, and no way to sort or grep them easily.

Posted: Tue Jan 31, 2006 9:53 am
by aviper
"Small nmap port" or simular features ?

Posted: Tue Jan 31, 2006 2:02 pm
by djape
And live radio stations support :D

Little joking wont hurt anyone I hope ;)

Posted: Tue Jan 31, 2006 2:13 pm
by andreacoppini
Antenna diversity!!

Posted: Tue Jan 31, 2006 3:33 pm
by driton
regular expression support for match content at ip filter

Posted: Tue Jan 31, 2006 3:42 pm
by normis
regular expression support for match content at ip filter
why? it is packet content, if you don't know what exactly you are looking for, better not use it. it would be dead slow. this is not for offensive website filtering.

Posted: Tue Jan 31, 2006 3:53 pm
by cmit
Those possible performance problems would be the reason for me to NOT include this - at least in my network setups. RegEx-ing every packets' contents will be a REAL performance killer.
And in my opinion that's something rather not to be done on a router. Ok, RouterOS is evolving more and more into a more generic system and DOES offer content inspection capabilities - but I think that would take it too far.

Just my 2 (Euro) Cent...

Best regards,
Christian Meis

Posted: Tue Jan 31, 2006 8:52 pm
by driton
Well just a fast thought. Other vendors support classifying traffic on application layer based on regular expr eg. classify a specific http url like /html/bin/business and /html/flashgame and give more priority to first than second. Or classify traffice based on MIME types or you can even match a virus/worm etc. with this feature and route it to a blackhole.

Posted: Tue Jan 31, 2006 11:49 pm
by driton
I found something on the net about application level marking:


Router(config)# class-map match-all http_transact

Router(config-cmap)# match protocol http url "/transact/*"

or

Router(config)# class-map match-any audio_video

Router(config-cmap)# match protocol http mime "audio/*"

Router(config-cmap)# match protocol http mime "video/*"


or

Router(config)# class-map match-any web_images

Router(config-cmap)# match protocol http url "*.gif"

Router(config-cmap)# match protocol http url "*.jpg|*.jpeg"

or if you want to block a worm

Router(config)#class-map match-any http-hacks
Router(config-cmap)#match protocol http url "*default.ida*"
Router(config-cmap)#match protocol http url "*cmd.exe*"
Router(config-cmap)#match protocol http url "*root.exe*"



and then you apply policies to these classes. I hope MT will at least look into it.

Posted: Wed Feb 01, 2006 2:31 am
by rickard
I need support for Mobile Telemetry standard EN 300 674 -2-1 on the 5795-5805 Ghz in sweden. with 5 Mhz chanels. then i can use 2 Watt :-) EiRP.

And full support for Hiperlan 2 standard ETS 300 836-1 5.4-5.7 Ghz 1 Watt EiRP, With DFS and TP working :-).

//Rickard

Posted: Wed Feb 01, 2006 5:02 am
by changeip
Let's think about making 2.9.x more stable before getting a wishlist for 2.10 : )

Revision numbering ...
2.10.01
2.10.02
2.10.03
2.10.04
...
2.10.10

Stable BGP
routing-test completion and integration into standard routing

Standard intel mobo fan, temp, power monitoring

Posted: Wed Feb 01, 2006 6:54 am
by [ASM]
My wishlist (it's two years old):
1) SMP support
2) lm_sensors
3) ttl match in /ip firewall
4) l7-filter
5) Script actions OnConnect and OnDisconnect in /ppp profile
6) :include directive in scripts
7) :fetch (to download a new version of some :include file via http :) )
8) add tx-signal-strenght in /interface wireless registration-table print oid
9) Full Changelog :)

there are more things but I cann't remember then now

Posted: Wed Feb 01, 2006 7:33 am
by savage
- Configuration syncnig between routers :) Places where this would be usefull for example, VRRP.
- Configurable ARP Timeouts (Excuse me if I haven't seen it in older versions yet)

Posted: Wed Feb 01, 2006 1:27 pm
by stephenpatrick
Just a few from me: all of these came from real customers or potential customers, so it's more of a "needed" not idle wishes:

- MPLS. One major potential customer asked, they are used to C*sco and we really don't want any of that in the network..
- Proper automatic TPC on wireless , the current "set to -3dB" is only a work-around not really compliance with EU specs
- SNR on atheros radio
- support for MIMO radio cards
- support for WiMax Mini-PCI
- CPU and system temp for regular x86 platforms
- Backup and restore to USB memory stick

Some of those are "easy" and some less so ...

Regards

Posted: Wed Feb 01, 2006 7:51 pm
by expat
- Inbound loadbalancing such as LVS.
- Support for digital certificates for remote access VPN.
- Sync'ing filter rules on VRRP'd devices

EDIT:

- Non-MS winbox app: GTK2 would be nice. :D

Posted: Wed Feb 01, 2006 8:58 pm
by andreacoppini
VRRP MAC address portability (for true failover)

Posted: Wed Feb 01, 2006 10:00 pm
by savage
- Non-MS winbox app: GTK2 would be nice. :D
As a matter of interest. Does it run under WINE?

Posted: Thu Feb 02, 2006 8:50 am
by normis
- Non-MS winbox app: GTK2 would be nice. :D
As a matter of interest. Does it run under WINE?
what `it`, current winbox? yes

Posted: Mon Feb 06, 2006 2:01 pm
by expat
- Non-MS winbox app: GTK2 would be nice. :D
As a matter of interest. Does it run under WINE?
what `it`, current winbox? yes
But it's not very stable and eats the CPU.

Posted: Mon Feb 06, 2006 2:03 pm
by normis
try wine forums maybe?

one tiny suggestion...

Posted: Thu Feb 16, 2006 4:12 am
by dfwair
Maybe a java version of the winbox? It would be great for Apple!

Posted: Thu Feb 16, 2006 8:50 am
by normis
there was a java version a very long time ago - in RouterOS 2.4

But for MacOS - there is now the DarWine and the VirtualPC

Posted: Thu Feb 16, 2006 8:53 am
by changeip
Will winbox communication protocol ever be opened up so we can write apps for specific functions? I would love to have a little window that only showed the traffic graphs - or one that showed a routing table only ... etc.

Sam

Posted: Thu Feb 16, 2006 11:49 am
by stephenpatrick
Less elegant, but you can do this via telnet.

We have a PC app that does that (RadioManager) for installation engineers. It can be customised just to show particular features, including super-friendly signal strength bargraphs, and audio beeper using the PC speaker, for routers that don't have audio.

One of the problems is code maintenance, any changes in the MT CLI command structure means given items don't display. We're on top of that though.
We could get the graphs out for display using FTP, or alternatively generate customised graphs on the PC by logging.

Regards

CableFree Solutions

Posted: Mon Feb 20, 2006 8:34 pm
by rickard
My wish list:

- LM Sensor (Working temp volts on standart Intel MB)
- Dual CPU suport that will be nice (then i can make use of Dual core)
- API for the Winbox :-) so we dont to have make C++ programs all the time. and use Telnet...
-More UPS support like APC, Thrust, Belkin,...

//Rickard

IPv6

Posted: Tue Feb 21, 2006 10:54 pm
by zhall
IPv6, have at least two projects that we can't use MT on due to no IPv6

Posted: Wed Feb 22, 2006 12:49 am
by driton
More robust PPP and features, especially ppp callback.

Re: whats is q3 2006

Posted: Thu Feb 23, 2006 11:13 pm
by boardman
Sorry for bad English, but whats is q3 2006 ?
That means third quarter 2006, third part of the year, july-september.

Bytes....

Re: IPv6

Posted: Fri Feb 24, 2006 9:02 pm
by vegard
IPv6, have at least two projects that we can't use MT on due to no IPv6
I second this. IPv6 would be very useful.

2.10 Feature Request

Posted: Fri Feb 24, 2006 11:09 pm
by dsovereen
Hello,

I sent an e-mail to support quite awhile ago asking for SIP traversal through NAT (we're starting to see newer NAT firewall routers capable of doing this, usually marketed to people doing VoIP) and was told that it would probably be added to 2.9 in a little while. Well, it's been awhile now.

If not in 2.9, can this be added to 2.10?

Thanks,

Dave

Posted: Sat Feb 25, 2006 3:23 am
by BelWave
Let's think about making 2.9.x more stable before getting a wishlist for 2.10 : )

Revision numbering ...
2.10.01
2.10.02
2.10.03
2.10.04
...
2.10.10

Stable BGP
routing-test completion and integration into standard routing

Standard intel mobo fan, temp, power monitoring
Hit it on the head for me, but I don't want to wait until 2.10.10! How about 2.9.15 or 2.9.16 instead?

(1) improve BGP
(2) improve BGP
(3) improve BGP
(4) and lastly improve BGP

Best,

Brad

Re: BETA Testing and Feature Suggestions for 2.10

Posted: Sat Feb 25, 2006 9:26 am
by Hellbound
2.10 :D some ETA? perhaps a year?
add wget or something so we can write script to automatically load or login on web-based application... certain ISP also need web authentication for our router or my APC UPS has only web interface so I need to reboot my modem or server when they're unreachable

secondly, you can add MAC Address binding to certain antenna jack? for instance I have two antennas on my wireless card , JACK-A - Omni antenna covering the area, JACK-B directional grid parabolic antenna aiming to base-station.
by having this option I can skip extra wireless where it is not necessary to have higher bandwidth...
even if you can even step beyond and have conditional binding such as JACK-A is 2.4 and JACK-B is 5.8 (like CM9 a/b/g cards) it will be a super speed as well...

thanks

Posted: Sat Feb 25, 2006 11:48 am
by aviper
1) I'm not quete sure how good is OLSR (i've just start reading the papers) ... but it sound good enough ... :)
2) Antena divercity, soo we can use it for inside Wi-Fi Lans (MIMO should be part of 802.11n, soo we can wait for compatible "end-use" devices :) )

Posted: Sat Feb 25, 2006 5:32 pm
by cmarazzi
How about a reference manual that includes all the features that router Os has.

Re: whats is q3 2006

Posted: Sat Feb 25, 2006 5:35 pm
by Hellbound
Sorry for bad English, but whats is q3 2006 ?
q3 = third quarter (july to september)

Posted: Sat Feb 25, 2006 9:14 pm
by hafiri
An elegant solution to backup configuration is to copy it to a tftp server. You would just make a scheduler to copy config to the tftp server at a certain time interval without having to write scripts to ftp to ther router and copy config or send via email or something which is not so nice. Also it would be nice when you what to apply a template config to a router just to type copy tftp config.

Posted: Sat Feb 25, 2006 10:21 pm
by ghmorris
Let me add another vote for OLSR. Sounds like exactly what we need.

George

Posted: Sat Feb 25, 2006 10:26 pm
by Hellbound
Let me add another vote for OLSR. Sounds like exactly what we need.

George
whats OLSR? is it what I asked?

Posted: Sat Feb 25, 2006 10:34 pm
by ghmorris
OLSR is Otimized Link State Routing protocol. OLSR allows you to design a multi-radio MESH implementation.

Basically it allows you to set costs on any exits from your network, then OLSR figures out the best way to get there. If you get a backhaul link failure, as long as there is another possible route out, OLSR will use it.

Star-OS has it in beta for V3, and it looks like just what we need for micro-cell 900MHz deployments where we will drop in a few ADSL "safety" Internet feeds in addition to our main fibre and let OLSR manage the failover.

http://www.olsr.org/

George

Posted: Sat Feb 25, 2006 10:36 pm
by ghmorris
We'd also REALLY like to see MPLS/VPLS make it to the top of the "must do" list. We're getting chased for MPLS regularly now.

George

Posted: Tue Feb 28, 2006 9:42 am
by rickard
OID (SNMP) support for station mode on the wierless status page .
that will be very nice :-) So i can read out Noice and SNR for my clients.

//Rickard

Posted: Wed Mar 01, 2006 3:33 am
by GJS
Most of these have already been asked for but my 2c:

1. A method of backing up the router configuration so that it can be loaded onto a new router in the event of hardware failure.
2. More UPS support.
3. More OIDs, maybe even SNMP V2? Or 3?
4. A more accurate and comprehensive manual.
5. An accurate and comnprehensive changelog.
6. Support for xDSL PCI cards.

Posted: Wed Mar 01, 2006 2:50 pm
by cmarazzi
A good new feature to have is regarding configuration and WINBOX.

It would be good to be able to work offline in winbox on a Router's configuration and then be able load it back in.

So you will log in to a router with Winbox download a configuration file. And be able to use winBox to configure it. without needing to be connected to the router live. Then be able to upload the configuration to the router.

-Carlo

Posted: Wed Mar 01, 2006 2:52 pm
by normis
what would be the use of this? in what order would your configs be applied? what if these configs conflict?

Posted: Wed Mar 01, 2006 4:08 pm
by GJS
Hmm...yes, I can't see any use for a feature like this. Maybe if you have only dial-up access to your network? But that must be only very rare cases I would think.

Posted: Wed Mar 01, 2006 4:18 pm
by cmit
And I can tell from experiences with different other products that do it that way: This creates some very nasty problem Normunds already mentioned above.
I would strongly suggest to stay away from that ;)

What I could imagine is that you could be able to download a config and only VIEW it offline in WinBox - but even that is very questionable in my opinion...

Best regards,
Christian Meis

Posted: Wed Mar 01, 2006 4:51 pm
by andreacoppini
What I could imagine is that you could be able to download a config and only VIEW it offline in WinBox - but even that is very questionable in my opinion...
How about allowing WinBox to open a SUPOUT file offline? We deal with a lot of Mikrotik boxes which are installed at client sites (and not accessible over the 'net), if we could tell them to send us a SUPOUT file that we can open in WinBox to take a look at their config (and recent log/traffic history) it would be great.

Posted: Wed Mar 01, 2006 4:53 pm
by cmit
Yep - the wish to be able to open/interpret supout files is one of my longest-standing wishes.
But MikroTik has denied this so far... :-(

Best regards,
Christian Meis

Posted: Thu Mar 02, 2006 2:58 am
by Beccara
Ok so i've looked a little more at our network and seen these needs, in order of how much i want them

1. IPV6
2. MultiCast Support
3. MPLS

IMHO this is what will move mikrotik out of the playtime routers and into the realtime networks.


These are all thing supported in basic ISP routers and its logical that if mikrotik wants more market share they will have to put these in at some point

Posted: Thu Mar 02, 2006 7:00 pm
by andreacoppini
A MikroPBX :wink:
- Asterisk is out there and working like a charm, but severly lacking a good, consistent, complete administration tool like WinBox....

Posted: Tue Mar 07, 2006 4:58 pm
by pekr
Guys,

if you want cross platform, small and flexible environment for your Winbox, I am all for REBOL. That is the language created by the person I do regard being kind of genius - Carl Sassenrath - AmigaOS author.

Just expose Winbox protocol API - then you have small GUI or even smaller non-gui version for scripting your configs from outer tools :-)

http://www.rebol.com
http://www.rebol.net

As for what to add to 2.10.x branch - after some talks during MUM with some guys, I think that MT should concentrate upon routing istelf ;-)

Don't also forget to be prepared for Wimax, simply to allow deployment to new areas ...

As for regexp, or scripting in general - well, router is not switch, it probably does not work with packets in-place anyway, so why not to support it for those who would like to have it? I am all for more powerfull scripting hooks, if it makes sense :-)


Cheers,
-pekr-

Posted: Tue Mar 07, 2006 8:46 pm
by eflanery
I would love to see the winbox API opened up, but I don't think it would be a great idea to tie it to a specific language. REBOL is a good language, but personally I would prefer Python, Ruby, or Lisp (no doubt others would prefer VB, Perl or even C).

If MT were to open the winbox protocol, at the socket level, then those of us with an interest could easily implement libraries for whatever language we felt like. It would be easier for them, and more flexable for us.

--Eric

Posted: Tue Mar 07, 2006 8:50 pm
by changeip
Exactly. . .

I am guessing that the remoting that winbox is doing though is built on top of something that is probably not at the socket level, so we'll see.

Sam

Posted: Tue Mar 07, 2006 9:19 pm
by eflanery
Yeah, you are probably right. If I were to guess, mingw seems likely, which would imply a C API.

Still, puting someting together to talk to a C interface is not all that different from talking to sockets, and sure beats scripting up a tty.

Abstraction is good :-)

--Eric

Posted: Sun Mar 19, 2006 12:47 am
by airnet
1) CARP (or similar) Live Firewall state syncronisation and rules syncronisation. CARP was developed for OpenBSD but no doubt there's a linux port somewhere. EG - for VRRP devices or for devices that want to do multiple-edge-bgp-peer-redundancy-balancing. Currently this is not physically possible IF your edge routers have any firewall rules in them.

2) Web-proxy with Client IP spoofing capability - for 100% transparency EG outside world see's clients IP as the originating request instead of the Proxy's address. EG Balabits tproxy is the most efficient way of performing such a task with squid: http://www.balabit.com/products/oss/tproxy/README.txt

3) Human readable SUPOUT.rif + human readable and editable .backup files

4) SMP / HT CPU support

5) R/W SNMP agent

6) A MT 'mirror' website so that people on the other side of the planet can download the latest software without problems. Sometimes we see 2-3 day outages of the MT website. Yes this IS a real pain in the arse when you GOTTA deploy routers to customers and you GOTTA licence it within 24hrs and you CANT.

Posted: Mon Mar 20, 2006 8:46 am
by normis
human readable and editable .backup files
use export files, they contain all configuration, are editable, and can be imported back into newly installed routers
A MT 'mirror' website
we already have a US mirror, look in the download page
SMP / HT CPU support
2.10 should have that at least to some extent
R/W SNMP agent
snmp write is already planned

Posted: Mon Mar 20, 2006 9:59 pm
by eflanery
A MT 'mirror' website
we already have a US mirror, look in the download page
Yea, but how about a _GOOD_ US mirror?

I.e. One that isn't 1/10th the speed of the Latvian server, for those of us in the US (or other places well connected to the US).

--Eric

Posted: Tue Mar 21, 2006 8:59 am
by normis
some people say the opposite about it's speed :) we will check this

Posted: Tue Mar 21, 2006 9:40 am
by changeip
We can provide a mirror possibly ... let me know.

Sam

Posted: Tue Mar 21, 2006 3:20 pm
by bjohns
Along with MPLS, ISIS routing would be nice.

SIP Proxy, more advanced telephony - like allowing hotspot users to use a cordless sip phone and the associated radius support.

NAT-T (another vote)

I guess device drivers will get a revamp, but I would like to see support for VPN accelerators such as the Sokris vpn1401 and the IPSec co-processor on the Intel S series cards etc.

And for something out of left field - network printing. Allow hotspot/campus users to print to a local printer (for a fee of course). So I guess IPP support? This may be better handled by a seperate device. Probably in the same pool as VoD and IPTV.

Posted: Tue Mar 21, 2006 7:42 pm
by csickles
Only one wish...

Here it comes..... Oh no......... I have to say it .......


PCI ADSL


Oh noo.... did I type that out loud ???? :shock: :oops: :shock:


Craig.....

Posted: Tue Mar 21, 2006 10:02 pm
by eflanery
some people say the opposite about it's speed :) we will check this
Well, since 2.9.18 was just released, I downloaded it from both.

From the "Latvian"* link (http://www.mikrotik.com), it took 7sec, at a rate of 1534KBps (big B).

From the USA link (usa2.mikrotik.com), it took 7min 30sec, at a rate of 23.8KBps (also big B).

That is a much greater disparity than even the factor of ten that I gave earlier, more like 64x the speed.

Both of them came in over the same transit link (AT&T's AS7018, which is very well connected), so the problem does not appear to be with us or our providers.

* I put Latvian in quotes, since it now actually seems to resolve (for us at least) to something in or around the Dallas Equinix facility. Actually, both of them appear to be in or around Dallas, but with some significant differances in connectivity.

--Eric

Posted: Tue Mar 21, 2006 10:38 pm
by changeip
I would say there is a definate problem with latency out there.
  6    10 ms    11 ms    10 ms  so-0-1-0-0.gar1.SanDiego1.Level3.net [63.214.191.45]
  7     8 ms    12 ms    11 ms  ge-7-0-0.mp2.SanDiego1.Level3.net [4.68.113.69]
  8    38 ms    42 ms    37 ms  ae-0-0.bbr2.Dallas1.Level3.net [64.159.1.110]
  9    40 ms    40 ms    40 ms  ge-6-2.ipcolo1.Dallas1.Level3.net [4.68.122.140]
 10    40 ms    39 ms    41 ms  4.78.221.158
 11    46 ms    45 ms    42 ms  bgp-shr-fac-gw1-serxx-dal.nationwide.net [216.87.144.178]
 12    43 ms    45 ms    51 ms  cat5509-rsm.core.shreve.net [207.254.193.34]
 13   608 ms   612 ms    45 ms  mikrotik.cust.shreve.net [207.254.214.150]
 14   223 ms   220 ms   217 ms  207.254.214.169
 15   220 ms   233 ms   222 ms  207.254.214.169
 16   363 ms   359 ms   357 ms  207.254.214.169

Trace complete.
Same results here in San Diego ... faster to go to Latvia than to Dallas.

Sam

Posted: Wed Mar 22, 2006 1:36 am
by eflanery
Not to mention 6% packet loss. :roll:
eflanery@wireless:~$ mtr -rc 100 usa2.mikrotik.com
HOST                                    LOSS  RCVD SENT    BEST     AVG   WORST
12.127.79.9                               0%   100  100    9.59   10.91   17.38
gbr1-p70.st6wa.ip.att.net                 0%   100  100   60.54   61.88   63.94
tbr2-cl10.sffca.ip.att.net                0%   100  100   59.57   60.98   64.59
tbr1-cl30.sffca.ip.att.net                0%   100  100   63.36   64.99   67.86
tbr1-cl3.la2ca.ip.att.net                 0%   100  100   63.74   65.73   70.51
tbr1-cl20.dlstx.ip.att.net                0%   100  100   60.71   61.96   64.96
gbr6-p20.dlstx.ip.att.net                 0%   100  100   59.20   78.99   90.67
gar3-p370.dlstx.ip.att.net                0%   100  100   62.75   64.14   74.55
12.119.145.138                            0%   100  100   59.74   67.06   81.72
bgp-shr-fac-gw1-serxx-dal.nationwide.net  0%   100  100   67.33   73.97  271.42
cat5509-rsm.core.shreve.net               0%   100  100   64.22   66.18   99.97
mikrotik.cust.shreve.net                  3%    97  100   63.71   65.52   71.89
207.254.214.169                           6%    94  100  237.27  240.24  246.78

eflanery@wireless:~$ mtr -rc 100 www.mikrotik.com
HOST                                    LOSS  RCVD SENT    BEST     AVG   WORST
12.127.79.9                               0%   100  100    9.30   11.09   16.65
gbr2-p70.st6wa.ip.att.net                 0%   100  100   10.38   13.20   31.66
12.122.84.37                              0%   100  100    9.59   20.06   25.08
192.205.33.98                             0%   100  100    9.52   11.32   16.61
dcr1-so-1-0-0.Denver.savvis.net           0%   100  100   36.38   38.88   66.26
dcr1-so-0-0-0.dallas.savvis.net           0%   100  100   50.65   54.70   59.67
dcr1-as0.dallas.savvis.net                0%   100  100   50.88   53.19   95.86
aer1-ge-5-3.dallasequinix.savvis.net      0%   100  100   51.38   56.35   58.00
ge5-2.fcr01.dal01.softlayer.com           0%   100  100   51.95   58.39   61.25
66.228.113.58-reverse.softlayer.com       0%   100  100   50.85   52.49   58.79
66.228.113.27-reverse.softlayer.com       0%   100  100   51.53   53.35   57.35
It does look like AT&T is giving me some grief in Seattle, between the gar we connect to, and the gbr heading to California, but nothing that would explain the difference.

--Eric

Posted: Wed Mar 22, 2006 3:42 am
by bjohns
Radius AVPair support would be nice too.

Posted: Fri Mar 24, 2006 10:26 pm
by RoddyZ
My wish list:

1) Wildcard soport for the "content" field in filters
2) "persistent" variables. Keep his values after reboot
3) Any kind of facility to write files using input, output, append and random access modes, like old basic language methods
4) A "mac address" list, like the current ip_address list

-Roddy

Feature Suggestions

Posted: Sun Mar 26, 2006 12:22 pm
by bakula

Posted: Mon Mar 27, 2006 2:07 pm
by Alessio Garavano
May be good to don't permit to enable or disable a rule in firewall or an interface which disconnect an external winbox connection :D
Many times need to go back fast to the office or call by phone to enable or disable an erroneous rule or reactivate an interface from a client while it repaired some problem to him in the connection by Winbox. :wink:

Regards and continue looking for the perfect router. This is not very far

Posted: Mon Mar 27, 2006 2:30 pm
by cmit
This can already be achieved by using safe-mode. The hardest thing with safe-mode is to remember to enable it BEFORE doing something on remote routers ;)

It pops to my mind every so often in that second when I did something stupid - but then it's too late...

Best regards,
Christian Meis

Posted: Tue Mar 28, 2006 1:33 am
by hci
1) Wildcard soport for the "content" field in filters
That would be nice. Also, how about QOS inside a PPPoE connection.

Matthew

wget

Posted: Tue Mar 28, 2006 5:07 am
by jdmarti1
How about using something similar to wget on the router. This would make upgrades easier. No longer would I have to download the packages to a PC just so I can upload it to the others.

Posted: Tue Mar 28, 2006 11:44 am
by pedja
A descent scripting language would be nice improvement.

Posted: Tue Mar 28, 2006 11:51 am
by normis
what do you mean by `descent`? is there a lot of stuff that current scripting can't do?

Posted: Tue Mar 28, 2006 8:12 pm
by changeip
what do you mean by `descent`? is there a lot of stuff that current scripting can't do?
The only request for scripting enhancement I would have would be better error handling / reporting. Rather than it simply terminating with nothing give some debug output. Its really hard to troubleshoot a script when you don't even know which line number its terminating on.

Posted: Tue Mar 28, 2006 9:49 pm
by eflanery
In addition to error handling, as changeip suggests, I would like to see support for printed output based upon regex matches ("vendor C"'s | incl, or even ye-olde grep, for example. Things like large routing tables are awkward to deal with using find, :find, :pick, etc...).

Also, more flow control options (subroutines with parameters, for instance) would be nice.

The need for significantly enhanced scripting will largely be oblivated by your new open source API (mentioned somewhere around here), but it would still be nice to have a bit more sophisticated logic available to the units when they are isolated.

I wouldn't complain if you happened to add a Lisp or Python interpreter, though. :)
Perhaps you could even go so far as to give us a busybox and libc (such as "vendor-J" or "vendor-I" does). :twisted:

--Eric

Posted: Wed Mar 29, 2006 1:32 pm
by pedja
what do you mean by `descent`? is there a lot of stuff that current scripting can't do?
In short, something like perl, php or similar language.

Re: BETA Testing and Feature Suggestions for 2.10

Posted: Wed Mar 29, 2006 1:44 pm
by vhatz
Hello,

My wish list:

1) Support for more ISDN interfaces, especially active and higher density cards (multiple BRI or even PRI ports). We desperately need support for ISDN interfaces with analog modems, and higher densities in ports/card, such as Eicon Dive Server cards, or AVM cards, so that we could use MT Router as RAS Servers for dial in. The problem with the current supported interfaces is that we have to separate the analog from the digital incoming dialup calls on different interfaces and there are not enough PCI slots on a motherboard to host many ISDN ports on a signle router. This is very limiting.

2) MPLS is definitely a must.

Posted: Wed Mar 29, 2006 1:52 pm
by normis
ISDN? not going to happen, yesterdays stuff.

MPLS - very complicated thing to make, we are working on it, but it won't be ready anywhere soon.

Posted: Wed Mar 29, 2006 3:04 pm
by vhatz
ISDN? not going to happen, yesterdays stuff.

MPLS - very complicated thing to make, we are working on it, but it won't be ready anywhere soon.
Hello,

Thanks for your reply. Why is ISDN yesterday's stuff? Isn't ISDN boards with analog modems the most efficient way to provide dial-up access to clients?

Best regards,
Vlasis.

Posted: Thu Mar 30, 2006 1:36 am
by RoddyZ
Nice, if we can to have a "save config" command, like cisco routers.

All changes in the configuration, will be erased when the router reboot, but the changes can to be permanent if a "save config" command is executed before.

Is a well know problem, to lost the remote control (winbox or telnet) because a bad command is sended.

-RoddyZ

Posted: Thu Mar 30, 2006 10:02 am
by cmit
You can "simulate" this using RouterOSs' safe-mode. This will make all changes done while in safe-mode only temporarly. If you loose connection to your RouterOS machine, it will revert those changes. Only on leaving safe-mode the changes are stored permanently.

The hardest thing is to think of starting safe-mode before you do something "dangerous". As the mechanism to do changes only temporarily are obviously already there (safe-mode), I think implementing it the other way round shouldn't be too hard. So everything is always done temporarily and HAS to be saved explicitly. Could be easier to work with for several people.

The best thing would be if I could set the "mode" the router is on myself: So either the current way (where you explicitly have to start safe-mode), or a "C***o-like" style, where you always explicitly have to save your config.

Best regards,
Christian Meis

Posted: Thu Mar 30, 2006 1:30 pm
by Beccara
Can we get some comformation from mikrotik about what features taken from these pages will be put in place.

We are looking to do something that will REQUIRE multicast support and i really dont want to put a large amount of time and money into it if mikrotik wont put it in place.

Getting an idea if Multicast and MPLS will make it into 2.10 would be handy for us looking at our options down the line

Posted: Thu Mar 30, 2006 1:32 pm
by normis
as previously said, MPLS is very hard to make, it is a massive system which will take many months to make and test. don't expect it this summer. maybe at end of year.

Posted: Fri Mar 31, 2006 2:59 am
by Beccara
Understandable but how about Multicast? THAT shouldnt be any more diffcult than the rest of the ip subsytems

Posted: Tue Apr 04, 2006 5:29 pm
by dsovereen
Would like RADIUS Accounting from DHCP Server in 2.10

Posted: Wed Apr 05, 2006 5:51 am
by mrchiless
Nice, if we can to have a "save config" command, like cisco routers.

All changes in the configuration, will be erased when the router reboot, but the changes can to be permanent if a "save config" command is executed before.

Is a well know problem, to lost the remote control (winbox or telnet) because a bad command is sended.

-RoddyZ
Another command that goes hand in hand with this one on ciscos, is a reload in xx. So that you can tell the router to reload back to the old config if you break something and cannot access the router

Posted: Wed Apr 05, 2006 6:17 am
by mrchiless
I would like the abilty use more of the TOS bits in the QOS setup.
Using IP Precedence and TOS so that other device can pass information thru to the routeros for us to make QOS decisions on

API for development of drivers

Posted: Tue Apr 11, 2006 8:13 pm
by hkaiser
Hi all,

Out there are a lot of wishes to support a specific kind of hardware, PCI ADSL, WiMax MiniPCI cards, special radio link cards, etc.

I would be a cool feature to create a API, for example in C, to allow customers and developers generate there own drivers for hardware. So a big range of hardware could be supported. And drivers which seem to be well developed and stabil could become part of Mikrotik RouterOS.

with best regards
hkaiser

Posted: Wed Apr 12, 2006 4:08 am
by jp
With regard to ISDN, it's a declining business, and MT is smart to stay out of it. There is already a big surplus of ISDN equipment.

You can get RAS on ebay for pennies on the dollar. Lucent PM3s that cost $10,000 new are $30-500. Pattons which new were $12,000 are $1,000-3,000. Cyclades RAS which were $8,000-12,000 routinely don't sell for any amount of Ebay. Not a good market to be in for MT. Use pm2i's for BRI ISDN, or get a used Adtran atlas ISDN switch to switch BRIs into PRIs or CT1s.

Posted: Wed Apr 12, 2006 8:55 am
by jarosoup
Hotspot feature request

Not sure if this is an unreasonable request...It would be interesting to have a counter that keeps track of the total number of successful logins on the hotspot. For example, a global counter that starts at zero and counts until you manually reset it, and another counter that resets after a predefined (hourly, daily, weekly, monthly, etc) or a defined (reset counter every 00:00:00) period of time and be readable via SNMP. I know you could do this by parsing a logfile with a script, but would be handy to get this statistic via SNMP. Along with that, 3 counters that keep track of the logouts. Maybe another one for failed logins?

Logins:

Total logins: 100
Current Logins: 25

Logouts:

Keepalive Timeout: 5
Idle Timeout: 15
Session Timeout: 0
Lost Lease: 2
User Logout: 3
Other: ? (?)

Two interesting and useful statistics would be helpful here. Wireless clients (laptop users) with weak signal or poor radios often have to login because they lose their lease rather easily. Also, for Hotspots where there is only one user account shared among many users (logging in via a button instead of a user/password) it would be interesting to see how many logins happen every day and overall for busy public hotspots.

Doable? Not Easy? Not worth it?

Also, another plug for adding a counter, readable from SNMP, for current active hotspot users as well as one for active DHCP leases :D

Posted: Fri Apr 14, 2006 3:52 pm
by vhatz
With regard to ISDN, it's a declining business, and MT is smart to stay out of it. There is already a big surplus of ISDN equipment.

You can get RAS on ebay for pennies on the dollar. Lucent PM3s that cost $10,000 new are $30-500. Pattons which new were $12,000 are $1,000-3,000. Cyclades RAS which were $8,000-12,000 routinely don't sell for any amount of Ebay. Not a good market to be in for MT. Use pm2i's for BRI ISDN, or get a used Adtran atlas ISDN switch to switch BRIs into PRIs or CT1s.
Hello JP,

Thanks for your input. First of all I believe that ISDN is not declining. ISDN is replacing most POTS lines for telephone users, and it will not be replaced by another technology for quite some time for this particular application (voice & fax for the end user).

I agree that dialup in general either analog or ISDN is declining in favour of DSL, so, I guess that this was what you meant in your posting in the first place.

However, not everyone has access to broadband, and dialup is still used in the world. Whatsmore, most ISPs that I know give a dialup backup connection to their DSL users in case they have a problem with their DSL connection. I don't understand why there is so much support for analog dialup in MT Router, but so little of it for ISDN.

My point is that no ISP can do without providing dialup service to its users, unless they have a very specific business model.

Also, we are not talking about CONSTRUCTING new ISDN hardware. There is no need for this. As you said, there is a surplus of ISDN equipment being sold, and you are right.

What I'm talking about is ADDING drivers for EXISTING hardware not creating new hardwar. Why not capitalize on this surplus equipment and allow MT users to use all this well-priced equipment in their routers? There are many unused Eicon multiBRI and PRI cards as well as AVM cards out there. There are even low cost ISDN 4port BRI and 8 port BRI from Junghanns.net, or even 1, 2 and 4 span PRI cards from Digium which are used primarily for the Asterisk PBX.

All this equipment could be used for high density RAS on a MT box if their drivers were added in MT. They can even be used as PSTN interfaces for the VoIP capabilites of MT. Given the fact that in most countries ISDN is used more and more as a last mile PSTN connection, it's easy to understand that ISDN interfaces for various uses will be important. Perhaps not so important for the end user for connecting to the Internet, but important for a service provider.

You mentioned some costs of RAS servers like Lucent or Pattons with very low costs. I've been looking for quite some time on ebay and used network equipment web sites, and I couldn't find such prices. Such prices for a fully featured RAS system with RADIUS AAA etc seem too good to be true. I'd be grateful if you could provide me with the URLs where you found those prices.

Best regards,
Vlasis Hatzistavrou.

Posted: Fri Apr 14, 2006 7:33 pm
by Mapik
USB boot will be really good feature :) We now have problems with Intel D945GNT boards that can't boot MikroTik from PATA drives bigger then 8GB (and SATA is not supported by MT, Windows, BSD and others boot fine) and CompactFlash via CF-to-IDE converter is not supported by Intel now :(

Posted: Fri Apr 14, 2006 8:12 pm
by dsovereen
I'd like to see watchdog compatability with the watchdogs built into some of the Mini-ITX boards out there, as well as CPU, temp, fan, voltage, etc status/monitoring support on these same boards. The Commell 671 comes to mind.

Dave

Posted: Fri Apr 14, 2006 9:42 pm
by Wyoming
I would like to see better statistics for the interfaces. Such as Errors on the ethernet interfaces. Maybe Broadcast counters, Collision counters, etc.

Posted: Thu Apr 20, 2006 7:23 am
by butche
Ok, I've seen a LOT of good things mentioned. I will post my short list of wants/needs....

* FTP or RCP client. wget would work for this, too. Some way for the router to initiate a connection to a central server to grab a configuration (such as firewall rules, for example). This would also be useful to SEND exports from the router to a central location (automated backup for example).

* Easier identification of VoIP - This is almost impossible today

* Better identification and control of bit-torrent

* A good API - or better yet, a linux/unix based SCRIPTABLE command line utility that will allow for easier updates initiated on the server side. Would both be asking too much?

* More OIDs exposed (many have mentioned this) to the SNMP interface

* interface stats in the command-line or winbox - errors for example are available via SNMP now, but not in winbox or cli.

* COMPLETE AND ACCURATE CHANGELOG (sorry, but this is probably the biggest issue I have with MT)

* better BGP (this is already improving) and route filtering for OSPF.

* MLPPP - As I understand it, this is already slated for 2.10?

* Policy routing is working, but there are some things that are a pain in the rear to get working right. Perhaps the router should know (for example) that DC routes should always use the "main" table. This is not the case in 2.9.20.

I am sure I will think of more, but this is the quick (off the top of my head) list.

Posted: Thu Apr 20, 2006 9:04 am
by normis
* Better identification and control of bit-torrent
what's wrong with it now? it can already detect and drop any p2p application, including encrypted torrent traffic.
* COMPLETE AND ACCURATE CHANGELOG (sorry, but this is probably the biggest issue I have with MT)
already discussed
* A good API - or better yet, a linux/unix based SCRIPTABLE command line utility that will allow for easier updates initiated on the server side. Would both be asking too much?
API already in the works, this has been posted before

Posted: Thu Apr 20, 2006 9:43 am
by butche
* Better identification and control of bit-torrent
what's wrong with it now? it can already detect and drop any p2p application, including encrypted torrent traffic.
Unless I am missing something, bit-torrent can be dropped, but not easily controlled. I would like to allow the traffic, but control the impact of this devilish p2p app.
* A good API - or better yet, a linux/unix based SCRIPTABLE command line utility that will allow for easier updates initiated on the server side. Would both be asking too much?
API already in the works, this has been posted before
Yes...I am just voicing my vote here, too. This will be very nice to have.

Posted: Thu Apr 20, 2006 9:54 am
by normis
Unless I am missing something, bit-torrent can be dropped, but not easily controlled. I would like to allow the traffic, but control the impact of this devilish p2p app.
true, we will think of something

Posted: Thu Apr 20, 2006 11:54 am
by pedja
In many places MT counts traffic even if it is dropped. That may be very confusing. It would be good if there is option to distinguish traffic which goes al the way, and one which is actually blocked.

Posted: Fri Apr 21, 2006 7:04 am
by Hammy
Let's think about making 2.9.x more stable before getting a wishlist for 2.10 : )

Revision numbering ...
2.10.01
2.10.02
2.10.03
2.10.04
...
2.10.10

Stable BGP
routing-test completion and integration into standard routing

Standard intel mobo fan, temp, power monitoring
Hit it on the head for me, but I don't want to wait until 2.10.10! How about 2.9.15 or 2.9.16 instead?

(1) improve BGP
(2) improve BGP
(3) improve BGP
(4) and lastly improve BGP

Best,

Brad


One more time, Brad. ;-)

oh yeah... IMPROVE BGP!

Posted: Fri Apr 21, 2006 5:09 pm
by jp
One other wishlist suggestions....

Some sort of CPU power management features like newer linux systems have, like powernow.

Fast computers are now dirt cheap, but use LOTS of power compared to old or embedded computers. Some sort of power management would cut our electric bills. (On the mainland, power is about 0.16$ per kwh, and on islands it can be between 0.28-0.50$ per kwh). Power consumption reduction would also reduce the need for cooling. I use rb532 wherever I can at sites to draw less power than a full computer, but sometimes I need the speed or additional interfaces of a full computer.

Posted: Tue Apr 25, 2006 4:19 pm
by pedja
There is an option in script to set LED statuses. It would be good also to be able to read and write some pin statuses on serial and parallel ports.

Posted: Tue Apr 25, 2006 7:46 pm
by eflanery
Parallel would be new, but for serial there is already:
[admin@EricsHome] > :list tool sigwatch
List of console commands under "/" matching "tool" and "sigwatch":

tool sigwatch
tool sigwatch add name= port= pin= on-condition= log= script= copy-from= disabled= 
tool sigwatch disable <numbers> 
tool sigwatch edit <number> <value-name> 
tool sigwatch enable <numbers> 
tool sigwatch export file= from= 
tool sigwatch print without-paging count-only append brief detail value-list terse interval= file= port= on-condition= state
= from= 
tool sigwatch remove <numbers> 
tool sigwatch set <numbers> name= port= pin= on-condition= log= script= disabled= 
--Eric

Posted: Wed Apr 26, 2006 2:57 pm
by pedja
Thanks I did not know about this. But just reads statuses, tehre is no option to set them.

Posted: Wed Apr 26, 2006 4:44 pm
by NetTraptor
Let me add another vote for OLSR. Sounds like exactly what we need.

George
1 more from me....

Posted: Thu Apr 27, 2006 1:28 am
by Mapik
Let me add another vote for OLSR. Sounds like exactly what we need.

George
1 more from me....
Yes. It will be great if you add it.

Posted: Thu Apr 27, 2006 12:09 pm
by Mapik
Any chance for USB boot in the future ???

Show CPU load by process...

Posted: Sat Apr 29, 2006 12:42 am
by Alessio Garavano
May be good to Mikrotik show CPU usage by process to know what is overloading the CPU :wink:

And also it would be good for being able to make run hotspot from an interface bridged but independent to the bridge, for example to have a bridge between ether1 and ether2 but that hotspot single runs on ether2 since it makes version 2.8...

I can´t upgrade my 2.8 to 2.9 because this problem...
I have bridged Ether1 with a Public IP and Ether2 with a Private IP and need to lease to my clients privates and publics IPs, but when i put the hotspot running in other than the bridge interface the server hotspot don´t work and is showed in red, and if i select the bridge interface, in Hosts list appears my clients and all the publics IPs incoming to the router, like MSN, yahoo, etc etc... exist a solution about this?

Regards!
Alessio

Posted: Mon May 01, 2006 4:54 pm
by jp
I've decided it would be a good idea to be able to have multiple versions of router-os to boot. Right now, it will boot the current version, or install the version found on / in flash and boot that. I think it would handy so I could revert or try a version without having to transfer another router-os over the network. Especially handy when there are network problems. Could I make a subdirectory and put the other versions in there? Routeros could automatically copy the prior router-OS into a backup directory space permitting, allowing an easy firmware rollback.

Posted: Mon May 01, 2006 8:49 pm
by stephenpatrick
JP,

some nice ideas, and "roll-back" form a "problematic upgrade" including any config changes would be a really good idea (been there).
Multi-boot, probably a "test network" luxury but nice item IMHO.

Regards

CableFree Solutions

Posted: Mon May 01, 2006 9:53 pm
by GotNet
These come up in the RB forums but has not been mentioned here:

Better control over the RB112 hardware.

LED on / LED off (not just blink)

Speaker frequency outside of alignment mode.

Ability to read the optional user switch

Goal? Customer Friendly Premise Equipment

Mike[/i]

Drivers for current hardware????

Posted: Tue May 02, 2006 6:44 am
by meritel1025
It would be great if MT had drivers for current production hi-cap cards and USB LCDs. We wanted our MT to do our DS3 and OCx support however, the only cards that are supported have been out of circulation for some time. The DS3 cards are too expensive to just hope it will work (knowing it won't).

The serial LCD is nice, but the graphical, USB, units would allow a much more professional looking router to be developed.

This actually seems to be quite common. Much of the hardware MT requires is no longer available or is very hard to find. Picking up COTS hardware usually ends up biting us as it is too new for MT drivers.

I'm not getting bleeding edge on most of this, but when putting in a new system, I do like to have current releases of hardware so I know it will last a few years.

Thanks

Drivers for current hardware????

Posted: Tue May 02, 2006 6:44 am
by meritel1025
It would be great if MT had drivers for current production hi-cap cards and USB LCDs. We wanted our MT to do our DS3 and OCx support however, the only cards that are supported have been out of circulation for some time. The DS3 cards are too expensive to just hope it will work (knowing it won't).

The serial LCD is nice, but the graphical, USB, units would allow a much more professional looking router to be developed.

This actually seems to be quite common. Much of the hardware MT requires is no longer available or is very hard to find. Picking up COTS hardware usually ends up biting us as it is too new for MT drivers.

I'm not getting bleeding edge on most of this, but when putting in a new system, I do like to have current releases of hardware so I know it will last a few years.

Thanks

Re: directional antenna

Posted: Wed May 03, 2006 10:35 am
by pedja
Are you talking about directional antenna or something else?! Umm. There is a good page for directional antenna perhaps!
Also,you can find some other content on it,such as hotel gardasee or brio toys or power boats.
You can search on the homepage try some other keywords,no ads even.these page updated every day.Because of the huge database,it perhaps not very fast,if you don't like it,take it easy.
I cannot believe my eyes. Spam on this forum :)

Posted: Wed May 03, 2006 12:16 pm
by Alessio Garavano
:shock: I suppose that it will be to be neglected because of the MUM in USA :D

Posted: Sat May 06, 2006 2:35 pm
by bsnik
it will be nice if PPPoE can have more QoS control properties

Posted: Mon May 08, 2006 5:24 am
by Hammy
http://wifinetnews.com/archives/005156.html

Faster wireless handoff. This system supposedly is available with Atheros open source drivers.

Posted: Sat May 13, 2006 1:16 am
by pd
one more vote for OLSR

Extended Advertising Features for 2.1

Posted: Thu May 18, 2006 9:12 am
by hotspotsolutions
Hi Guys,

I would like to see the functionality of the Advertsing section for the hotspot increased with extra functionality.

Some ideas I have are:

- The ability to frameset ads instead of popup, to negate popup blockers. The click this link to proceed is fine but it is very obtrusive and when people are paying to use the service I dont think its very professional. So a frameset displays the ad page at the top/bottom and the page they are accessing is in the frame. If the website has a frameset remover which some do then thats fine in my opinion?

- Ability just to bypass if they have a popup blocker. So it tries to popup ad, if it cant, it just continues.

- More control over the popup page. The ability to customize every aspect of this page as per the hotspot pages, so there are variables but how they are worked with is up to us. This would be good so the click here page is "skinned" to look like our sites, or the ad is displayed inline for a second, then continues on. There could be heaps of ways to utilize this page in future.

- Extend popup functionality so when ad is due, the next page is manipulated so that all href tags have a javascript "window.open" command appended to them, this then will override all popup blockers, and again be seemless.

- Allow certain ads to be for specific websites, based on either keywords or partial matches perhaps. So if someone accesses the "Microsoft" website for example, we can display an ad for microsoft products perhaps.

These are all ways we can make the advertise functionality alot more useful to hotspot providers, as at this stage I think its a little limiting in its functionality.

Re: Extended Advertising Features for 2.1

Posted: Thu May 18, 2006 9:33 am
by normis
- The ability to frameset ads instead of popup
this involves manipulation of the website code. first of all it would take a lot of resources and we would have to make some parser. second - it might break a LOT of pages. you can't just force some of your code into some webpages. this is more a `kiosk browser` feature, and must be made in the browser, not the hotspot. i doubt that it's even possible
- Ability just to bypass if they have a popup blocker. So it tries to popup ad, if it cant, it just continues.
sounds fine
- Extend popup functionality so when ad is due, the next page is manipulated so that all href tags have a javascript "window.open" command appended to them, this then will override all popup blockers, and again be seemless.
this too involves manipulation of the pages and is not an easy task. imagine what resources would it take to parse every single page and modify it

Posted: Thu May 18, 2006 9:40 am
by hotspotsolutions
Manipulation of the html was always going to be a long shot, I never thought it was going to be a case of yeah sure, will get right on that :)

But I think opening up the advert page for modification would really help.

We really want to use the advet functionality but we cant justify forcing people with a popup blocker to click a link when they have paid good money to surf the web with our service.

We would like to advertise, I guess we have to find a balance between what MT can do and what is good for the end user.

I dont want to go down the route of breaking web pages as I think that defeats the purpose also.

Posted: Thu May 18, 2006 9:45 am
by normis
but of course, we will improve the AD feature - we just released it, so there is still some improving to do anyway.

Re: Extended Advertising Features for 2.1

Posted: Thu May 18, 2006 10:28 am
by pedja
- The ability to frameset ads instead of popup
this involves manipulation of the website code. first of all it would take a lot of resources and we would have to make some parser. second - it might break a LOT of pages. you can't just force some of your code into some webpages. this is more a `kiosk browser` feature, and must be made in the browser, not the hotspot. i doubt that it's even possible

Using framesets actually does not change external site code. It loads complete external page into a frame without changing it a bit.
<FRAMESET rows="115,*" cols="*"> 
<FRAME name="toolbar" src="http://local.site.url/toolbar.php" scrolling="NO" NORESIZE>
<FRAME name="external" src="http://external.site.url" scrolling=AUTO NORESIZE>
</FRAMESET>
I find this suggestion quite good. Actualy, i would like to see it implemented in proxy so I could, for instance, use framesets to create small toolbar alike addon for each loaded page. i do not run commercial net so i do not need it for adverts, but it could be useful to provide some always needed links or inforamtion related to local network.

Posted: Thu May 18, 2006 10:33 am
by eflanery
one more vote for OLSR
Incase no one had yet noticed, the "other guys" just got OLSR. :(

Patiently waiting. :?

--Eric

Posted: Fri May 26, 2006 10:18 am
by Vigor
1 more vote for OLSR

Posted: Fri May 26, 2006 7:29 pm
by alex23
one more vote for OLSR if it works out fine with no problems :wink:

Client Web Interface

Posted: Sat May 27, 2006 12:37 am
by Hammy
I would like to recommend a client-friendly web interface. That way if a client wants to setup port forwards, wireless keys, etc. they can. Something just like a consumer router.

How hard is this? I'm guessing not hard.

You already have a web interface.
You already have multiple user logins.
You already have varying levels of high level security (web access, telnet, ssh, read, write, etc.).
Just go one step further to say they can write to the NAT section, wireless, etc. but cannot read or write anything that I put there.

This would remove the need for a client to have their own router if they want to have control over their settings (as many users do).

Posted: Sat May 27, 2006 12:54 am
by changeip
Once the API is out we plan on making a client area... dummy proof questions and settings.

Sam

Posted: Sat May 27, 2006 2:34 am
by Hammy
Commercial license?

Posted: Sat May 27, 2006 7:10 pm
by ericsooter
I mentioned this at the MUM conference, and I thought I would post it here. It would be very nice if you could use Virtual AP mode to run NStream and non-NStream together on a single card. I know that John had mentioned that you guys thought about implementing that in the past. Here are the reasons:

1. Tower cost - Some of the towers I'm on are $200-400/mo(or higher) per antenna (depending on height). To simply be able to use virtual AP for NStream support would be a major cost savings; as opposed to hanging another antenna and radio.

2. Nstream migration - Would be a very easy way to migrate non-nstream customers to an nstreame-based tower. From Mikrotik's standpoint, I would see this as something that could sell more licenses/hardware, because of all the non-routeros hardware that would be swapped out or migrated to Mikrotik. I currently don't use Mikrotik CPE's, but if you all had this feature, I would begin to use it.

3. Class of service - For those that use VOIP or other more latency/jitter sensitive applications, we could easily move them to another virtual AP instead of hanging a new AP base up.

I do understand if this is impossible to accomplish due to restrictions of the protocol. But if it is doable, I think it could be a win/win.

Eric

SATA CF Adapter

Posted: Wed May 31, 2006 7:43 pm
by changeip
It would be nice if 2.10 supported some kind of sata so we could start using these type adapters:

http://www.acscontrol.com/Pages/Product ... dapter.htm

Sam

Posted: Wed May 31, 2006 8:46 pm
by Hammy
Once the API is out we plan on making a client area... dummy proof questions and settings.

Sam
Is this going to be available to the public? Cost?

Posted: Thu Jun 01, 2006 3:33 pm
by rockr
I would settle for solid working ospf i rb532 hardware. As of 2.9.24 and routing-test, it is still broken.

Posted: Thu Jun 01, 2006 4:53 pm
by normis
we fixed some ospf issues in 2.9.25, so wait for that

Posted: Thu Jun 01, 2006 9:13 pm
by dsovereen
Any idea on when 2.9.25 will be out?

Thanks,

Dave

Posted: Thu Jun 01, 2006 11:38 pm
by savage
Been said on other posts before, but...

1) Workable VRRP, there's just to many issues currently, and it's flakey at best
2) Certain config replications... Noteably Firewall rules
3) The whole MT configuration taking on a 'redundancy' point of view, master/slave roles, config changes on the master replicated to the slave, master dies, slave works without problems...

A nice example here will be 2 redundant Cisco Pix firewalls for example... Hell, even if a dedicated ethernet port might be required (like the pix does), that's still small change to be able to build good redundancy into a network with MT...

At this stage there's no way to have a reliable redundant (either from a network or hardware point of view) network with MT. OSPF/BGP is not the most stable, VRRP aren't stable at all, etc etc etc. I think redundancy is critical if you want to be considered a serious competitor in the routing field...

Said before in this topic, I'll say it again... I'd VERY much like to see a more stable 2.9 before a 2.10. IMHO, MT moved backwards from 2.8 to 2.9 as far as stability goes... :(

Posted: Fri Jun 02, 2006 10:38 am
by normis
david - today

Posted: Sat Jun 03, 2006 10:50 pm
by nuclearcat
From 2 sources it is leaked, that Atheros have FEC(forward error correction) capabilities.
It can be useful for long-distance, and VERY useful for NLOS.
Already canadian linux based system and BlueBox have capabilities to turn this bits on. Mikrotik must have too.

Posted: Sun Jun 04, 2006 4:52 pm
by grzesjan
david - today
Two days passed after that "today" and no new software.

Gregor

Posted: Sun Jun 04, 2006 11:35 pm
by Alex
it was in Mikrotik lab at friday but not in download page...I think this delay is because new version is under stress-test now...

Posted: Mon Jun 05, 2006 12:30 am
by grzesjan
it was in Mikrotik lab at friday but not in download page...I think this delay is because new version is under stress-test now...
Wow, <irony>the first version stress-tested!</irony>

Yes, I know, I'm cruel :)

Gregor

Posted: Mon Jun 05, 2006 9:20 am
by normis
actually all versions undergo at least a week of stress test

Posted: Mon Jun 05, 2006 11:07 am
by Beccara
david - today

Soooo 72 hours is one looooong day

Posted: Mon Jun 05, 2006 11:39 am
by normis
stress test means that we try to find unapparent issues. if the release is not on the web. apparently we still have to improve it a little. today or tomorrow then

Posted: Mon Jun 05, 2006 12:01 pm
by rpingar
any new nwes about intel driver for 1000pro dual???

the actual one has problems confirmed by MT guys.

Regards

Posted: Wed Jun 07, 2006 1:40 am
by dritoni
- Support for loopback interface would be perfect
- Option to add source interface for radius,telnet etc. sessions
- Supprt for null interface (bit bucket)

Posted: Wed Jun 07, 2006 11:58 am
by Eugene
loopback is available now. Just create an empty bridge.

Posted: Wed Jun 07, 2006 2:25 pm
by dritoni
yes it is true. I just thought it is a hack not a standard way to create it. I think it isn`t in the documentation either.

Posted: Wed Jun 07, 2006 3:27 pm
by nikhil
just get vrrp & bgp (make routing-test a full package) working perfectly in 2.9.x then move to 2.10

Posted: Wed Jun 07, 2006 5:00 pm
by BelWave
just get vrrp & bgp (make routing-test a full package) working perfectly in 2.9.x then move to 2.10
Agreed. I really would like to see a version of 2.9 with a completely tested and stable BGP module supported by WinBox.

What is the red type notice on the download page mean regarding not to configure BGP via the WinBox? What specifically is or are the problems with WinBox and BGP configuration? How long has this notice been posted on the MT site?

Best,

Brad

Posted: Thu Jun 08, 2006 11:59 am
by normis
this is for 2.9.25, there are problems with winbox+bgp test, so use command line.

about VRRP - could any of you please write to support about this problem? we don't have any usable reports about any vrrp problems.

Posted: Thu Jun 08, 2006 3:13 pm
by nikhil
normis there are posts about vrrp and virtual mac address all over. I have tried it quickly but it does not work similar problem to me as well.

Posted: Thu Jun 08, 2006 3:16 pm
by normis
yeah, cool - posts. what about actual problems? we don't have any reports to support

Posted: Thu Jun 08, 2006 3:30 pm
by nikhil
yeah, cool - posts. what about actual problems? we don't have any reports to support
http://forum.mikrotik.com//viewtopic.php?p=39777

No offence Normis
I understand you need supout but when in live environments we have customers to support as well. Please see the thread maybe just maybe it may have a clue , there are a lot of people on this board who have wide experience with MT and can provide clues.

Posted: Thu Jun 08, 2006 3:32 pm
by normis
i understand, but we can't do anything until we can reproduce the problem or see a supout.rif file

Posted: Thu Jun 08, 2006 5:46 pm
by uldis
yeah, cool - posts. what about actual problems? we don't have any reports to support
http://forum.mikrotik.com//viewtopic.php?p=39777

No offence Normis
I understand you need supout but when in live environments we have customers to support as well. Please see the thread maybe just maybe it may have a clue , there are a lot of people on this board who have wide experience with MT and can provide clues.
VRRP currently does not work on VLAN interfaces.

Posted: Sat Jun 10, 2006 7:13 pm
by Mactrekr
Normis,

I would really like to see more T1/E1 synchronous interface PCI/PCIx cards supported. In particular the new line of Sangoma cards, A10x series. Most of the T1 Synch cards currently supported are out of production. I've spoken to Sangoma and they are willing to work with MT to get these cards supported. I've asked about this issue in other forums and never gotten a response. PLEASE address this and let us know what MT intends to do about it.

Mac

Posted: Sat Jun 10, 2006 7:19 pm
by Hammy
True. I don't really use TDM interfaces, but it would be nice to have one as a backup. Anything MT supports is so old and out of production.

Posted: Fri Jun 16, 2006 8:44 am
by dainen

* MLPPP - As I understand it, this is already slated for 2.10?
Can this be confirmed? It would be great to be able to use Mikrotik for MLPPP rather then Debian.

Posted: Thu Jun 22, 2006 10:06 am
by nikhil
WISH :better support for intel nics on pci-x pro 1000mt

http://forum.mikrotik.com//viewtopic.php?p=41321#41321
[Ticket#2006060516000369]

Posted: Tue Jun 27, 2006 3:54 pm
by kalviz
We highly demand IGMP/multicasting. Without supporting these features, RouterOS IS NOT IPTV-ready.

Posted: Wed Jun 28, 2006 8:52 am
by uldis
We highly demand IGMP/multicasting. Without supporting these features, RouterOS IS NOT IPTV-ready.
could you please specify exactly what you want - which routing protocol should we add?

Posted: Wed Jun 28, 2006 8:03 pm
by eflanery
Regarding multicast protocols, IGMP at layer 2 (when MTs are used as bridges) would be a good start.

After that, PIM-DM is probably the most useful for IPTV (fast channel switching, and such). If someone wanted to _try_ delivering IPTV over wireless, they would likely appreciate PIM-SM. For non-IPTV multicast applications, and ease of setup / integration, MOSPF would be great.

--Eric

Ubiquiti Support

Posted: Wed Jun 28, 2006 9:08 pm
by interexus
Will the 2.10 release support the SR3 and SR4 cards that Ubiquiti has? If not what is the time frame for this support if going to support.

Re: Ubiquiti Support

Posted: Fri Jun 30, 2006 5:27 pm
by uldis
Will the 2.10 release support the SR3 and SR4 cards that Ubiquiti has? If not what is the time frame for this support if going to support.
Most likely these cards will work, but I am not sure, since we don't have these cards to test out.

Posted: Sun Jul 02, 2006 2:39 am
by pedja
Is it possible to add option to MT to search for spoecific MAC in all rules and show wherever that MAC is used. Thic would help when we notice strange traffic from strange MAC addresses.

Posted: Tue Jul 04, 2006 9:50 am
by Eugene
it is already possible:
ssh -l admin 10.0.0.1 "/export" | grep "00:0F:33:33:33:33"

Posted: Fri Jul 07, 2006 12:11 am
by Hammy
FCC specified DFS for 5 GHz bands.
Operation in the newly available U-NII spectrum is conditioned upon compliance with
certain technical requirements. Specifically, the new rules require that U-NII devices operating in the
5.25-5.35 GHz and 5.47-5.725 GHz bands employ DFS in order to avoid causing interference to Federal
Government radar systems. DFS is a feature that monitors the spectrum and selects for operation a
frequency that is not already in use. Prior to the start of any transmission, a U-NII device equipped with
DFS capability must continually monitor the radio environment for a radar’s presence. If the U-NII
device determines that a radar is present, it must either select another channel or enter a “sleep mode” if
no channels are available.
TPC as defined by the FCC for all bands, not just the ones they're talking about.
Additionally, the new rules require U-NII devices to employ a TPC mechanism when
operating in the 5.25-5.35 GHz and 5.47-5.725 GHz bands to further protect operations in the Earth
Exploration-Satellite Service (active) (EESS) and the Space Research Service (active) (SRS). TPC is a
feature that adjusts a transmitter’s output power based on the signal level present at the receiver. As the
signal level at the receiver rises or falls, the transmit power will decrease or increase as needed.
Therefore, TPC will cause the transmitter to operate at less than the maximum power when lower signal
levels can provide acceptable service.
U-NII devices operating in the 5.25-5.35 GHz band and the 5.47-5.725 GHz band shall employ a
TPC mechanism. The U-NII device is required to have the capability to operate at least 6 dB
below the mean EIRP value of 30 dBm. A TPC mechanism is not required for systems with an
e.i.r.p. of less than 500 mW.

Posted: Fri Jul 07, 2006 1:13 am
by Hammy
Actually, it would be nice if MT would allow the use of a radio to be dedicated to DFS monitoring. One could add one of these cards and plug it into an inexpensive antenna to be used for the sole purpose of monitoring for DFS so that the card carrying the traffic would not be offline for the duration of the channel scan. Then instead of forcing a channel change and the clients blindly searching for what happened to their AP, the AP could issue a packet that states that it will change to xxxx frequency so the clients know exactly where to go, minimizing the downtime.

While we're on the subject of dedicated cards... GPS sync support like Canopy to allow for higher frequency re-use. You already support a GPS interface, just use that to sync radios.

What? These things break 802.11? That's what N-Streme is for. Can't use N-Streme and WDS slave at the same time because it breaks standards? That's what N-Streme is.

future features

Posted: Tue Jul 11, 2006 4:13 pm
by Ness
Definitely we ALL will need:

0. STABILITY (new bug-fix version NOT every week or 2 and testing BEFORE release). Take a look at linux kernel and Cisco IOS versions.
0. CE certification
0. TPC support (and ability to turn it OFF)
0. Unified Thread Management (hardware antivirus, IDS, spam filter etc)
0. nice 19" rack mount kit
0. optical interface or SFP
1. IPv6 support
2. SBGP support (supporting X.509 certificates) (see RIPE NCC anti-spoofing WG)
3. Ident server (asked for it 5 years ago)
4. PPPoE unauthorized server alerts (a'la DHCP alerts)
5. SwitchBoard (with SSH, VSRP, IGMP, electro-optical convertors on all ports, tantal capacitors, powered by PoE etc)
6. WiMax support (polling is good, but not enough). All wanna NLOS. ATM cells?
7. HSDPA support
8. EV-DO support
9. RoHS
10. USB UPS support
11. DVB/CSA support
12. USB Flash Disk boot (from USB key)
13. Solar power adapter (with PoE)
14. Remote control to reboot routers (and integrated RF sensor in router)
15. Universal Frequency converter
16. Integrated GPS receiver (with SiRF protocol support)

... just kidding ;)

And BTW tell me plz: for what these 2 holes in OUTDOOR package of APs?

Posted: Tue Jul 11, 2006 4:20 pm
by Ness
Oh, forgot one... 8)

What about PoF (Power over Fiber)... can these optical lasers give enough power? All switch to optics... you switch to PoE... strange ;)

Posted: Tue Jul 11, 2006 10:19 pm
by jp
Ness, you forgot IR universal television remote on your list.

Posted: Tue Jul 11, 2006 11:45 pm
by csickles
I for one dont need it...

I have it on me PDA phone... 8)

Posted: Tue Jul 11, 2006 11:47 pm
by csickles
I have only one BIG wish....

Here it comes....
I have to type it....

I cant stop.... Oh NO !!!!

:P A.D.S.L. :P

Oh No!!! did I type that out loud !!! OOPS !!!!

MikroTik ROCKS !!!

Posted: Sat Jul 15, 2006 3:09 pm
by nolis
I would like to see better statistics for the interfaces. Such as Errors on the ethernet interfaces. Maybe Broadcast counters, Collision counters, etc.
I would like that either, especially up/down in interfaces (like cisco gear). I think it would be great if the interfaces could keep such statistics for problem debugging. I have a laser link connected in one side with a cisco and in the other side with a Mikrotik PC box. The cisco reports 1 - 2 times per day link up/down (lasts ms to many secs!) and we cannot understand in which side is the problem because the laser link is a transparent bridge and MT does not report a thing!

Posted: Sun Jul 16, 2006 10:22 am
by nabuk
Only one question:
on 2.10 we will have a really stable dynamic routing support (ospf and bgp), and a very stable router ?
From 2.9 first release there are too much upgrade. Every time I must do an upgrade to a production router I have fear....

export/import. CDP

Posted: Mon Jul 17, 2006 11:38 am
by Ness
One more suggestion: fix export full router configuration to .rsc file to be able latter import it on the other router. It don't working now BTW. Disable MAC address export (will do dublicate MACs), in PPPoE - if you define remote-address=pool import will not work etc.

And why we can't see neighbord Ciscos, if Cisco can see Mikrotik? ;) Add plain old CDP support.

Posted: Mon Jul 17, 2006 11:42 am
by normis
can't be fixed, because router can't know which new card will be which. if you have multiple different hardware devices, it is impossible to 100% restore config

Posted: Mon Jul 17, 2006 12:03 pm
by Ness
A least fix for the SAME hardware. We must every new RIC522 setup manualy. We recall you every time ;)

And plzzzzzzzzzz show string number where error is detected.

UDLD

Posted: Mon Jul 17, 2006 12:15 pm
by Ness
And add UDLD support... we will be able to use your RB as bridges with STP support. Without UDLD STP early or latter will hang all network. http://www.ietf.org/internet-drafts/dra ... dld-01.txt

Please Consider adding these features

Posted: Tue Jul 18, 2006 8:24 pm
by ParisDragon
Please Allow Multiple src or dst address lists when matching

http://forum.mikrotik.com//viewtopic.php?p=43609#43609

Please Add SMTP Authentication and Custom Port Support

http://forum.mikrotik.com//viewtopic.php?t=8616

Ability to have a script FTP to a server and send a file (example your router backup config)

Posted: Wed Jul 19, 2006 10:36 am
by normis
how can the router know which one should be called `incoming` ? the `ether1` could be any interface

Posted: Wed Jul 19, 2006 10:38 am
by Beccara
So you assign interfaces to names?

Ether 1 is Incoming right?

Move router onto new box and tell it that Ether 2 is Incoming.

Need a menu to assign physical interfaces to virtual names

Posted: Wed Jul 19, 2006 10:54 am
by normis
no, the other way around :) the physical interface doesn't have any name. when routeros first starts up, it detects your cards, and assigns names in order of detection. it assigns ether1,2,3,4 etc. router doesn't know about incoming or outgoing, you assign this name later, depending on what you want.

interfaces

Posted: Wed Jul 19, 2006 11:09 am
by Ness
Oh come on. Use MAC addresses of interface to identify which one is ether1 (for manually asigned MACs use mac-alias or something like this) Or use FIFO method (assing randomly). It's much easer to plug cable to other hole, then setup each router manually.

Posted: Wed Jul 19, 2006 11:48 am
by normis
yes, mac address. but how about import to other PC. this doesn't solve anything

Posted: Wed Jul 19, 2006 11:58 am
by Ness
On new hardware we ALREADY have interfaces with names! just enable it and use its name. Don't add new, just change parameters for existing interfaces.

If we rename interfaces, keep interface number (ether1), just add int-alias="outgoing", after import on other router use ether1 on new router, enable it and rename to "outgoing"

Posted: Wed Jul 19, 2006 12:01 pm
by normis
if you already have interfaces with names, export works fine and it is proven. the only problem is on zero-configured routers

Posted: Wed Jul 19, 2006 12:08 pm
by Ness
If we don't have interfaces (how it's possible BTW, after booting of RouterOS, it MUST find all interfaces) use random (we can plug cable to any RJ45 on new router)

Posted: Wed Jul 19, 2006 12:10 pm
by normis
?

please explain differenly, or in latvian

Posted: Wed Jul 19, 2006 12:25 pm
by Ness
Meģinašu latviski

Pēc RouterOS ieladešanas, viņa obligati atrast visus interfeisus (ja draiveris šajam iericem eksiste), tikai pec tam mēs varam importet vecu konfiguraciju.

Mums tikai vajag "enable" interfeisu ar nosaukumu skriptā un uzstadīt interfeisam parametrus no skripta. Un tikai pec tam mainit interfeisam nosaukumu no skripta (piemeram "outgoing")

Principa mēs varam lietot pirmu paņemto interfeisu (jebkuru), tapec ka mes varam iespraust kabeli jebkura briva RJ45.

Mogu esho po-russki ;)

Posted: Wed Jul 19, 2006 12:37 pm
by normis
as far as i know, it already works that way. by default, routeros finds all devices and enables them (after installation). yes, you could assign the names randomly, to any interface, and then just plug the cable in the appropriate port, but some people would not be happy about this random thing.

we will research all possibilities. thank you for suggestions

Posted: Wed Jul 19, 2006 12:49 pm
by grzesjan
we will research all possibilities. thank you for suggestions
Why is it not possible to leave ether1 as ether1 even if this is different physical port?

Imagine such situation - my power supply damaged and burnt whole pc and hard disk. I take firstavailable PC, which has different mother board, different NIC's, but the number of NIC's is the same. Why can't I just import backuped configuration?

Gregor

Posted: Wed Jul 19, 2006 7:30 pm
by ParisDragon
different hardware cant import config, only if Identical in everyway. This is why you do an Export file Full-Config from the main telnet prompt. This file is a script, which can easily be put onto other hardware, long as OS versions match or is newer (in most cases). This even lets you take a config from a RB112,532 and put them on a P4 server system when you need to upgrade the router.

Posted: Wed Jul 19, 2006 7:35 pm
by ParisDragon
as far as i know, it already works that way. by default, routeros finds all devices and enables them (after installation). yes, you could assign the names randomly, to any interface, and then just plug the cable in the appropriate port, but some people would not be happy about this random thing.

we will research all possibilities. thank you for suggestions
It would be very hard for them to do this I think, every MLB you add a card could have the PCI slots assigned differently via BIOS. Now on a Routerboard it should be very easy for them to always assign them statically, even if say WLAN1 has to be skipped. My case and point, I recently added a second Wireless card to a Routerboard 532 and it becamse WLAN1, forcing me to convert everything else (firewall rules, ip addresses, dhcp, etc) to WLAN2 (the old WLAN1). I would have preffered if I put the original card in the WLAN2 slot that is be called WLAN2 (even if WLAN1s slot was empty). On a PC Bases Router OS i cant see how they could ever really know without forcing you to buy only MLBs they want you to and I would rather have MLB flexibility on my bigger Router OS units.

Posted: Wed Jul 19, 2006 8:03 pm
by grzesjan
different hardware cant import config, only if Identical in everyway. This is why you do an Export file Full-Config from the main telnet prompt. This file is a script, which can easily be put onto other hardware, long as OS versions match or is newer (in most cases). This even lets you take a config from a RB112,532 and put them on a P4 server system when you need to upgrade the router.
Have you tried? I have. Importing full export doesn't work.

For example OSPF config has "FIXME" and so on.

Gregor

Posted: Wed Jul 19, 2006 9:01 pm
by ParisDragon
Yes I have, long as I name the interfaces to what they were on the new box, works fine. However I am not using the routing-test package for OSPF.

Posted: Tue Dec 12, 2006 6:38 am
by Jrslick22
How about sorting out the RF leakage (88mhz), that be a real good idea.

Posted: Tue Dec 12, 2006 8:07 pm
by nickb
How about sorting out the RF leakage (88mhz), that be a real good idea.
That doesn't seem like it'd be a problem with RouterOS... ;)

Web COntent Filter

Posted: Wed Dec 20, 2006 6:01 pm
by fcorvalan
Im use webproxy with rules. Please integrate Dansguardian module or similar. Or rules to use blacklist files and/or whitelist files to simplify config web proxy rules. Without use a parentproxy in other CPU.
DNS Server full! Not a DNS Proxy...

Posted: Thu Dec 21, 2006 10:24 am
by gideono
Can we have someway to exclude "local" or certain traffic from the radius accounting with pppoe/vpn sessions ?? There seems to be a lot of people with the same problem as me.

Posted: Fri Dec 22, 2006 10:57 pm
by smacebr
gideono, I've the same problem here. I need to exclude traffic from the accounting to some networks.

=== MY FEATURE SUGGEST ======

== High Priority===

Only using RASPPPOE I can view the LIST OF PPPOE SERVERS available. MK should have this feature. The feature of SCAN PPPOE Servers. They have cloned my PPPOE server!! And I had to take my notebook for scan for this!!! Mikrotik. What do you say? :-)

== others ===

I also agree having MT ROS as DNS server would be great, I want MK the best of all softwares... S2 :-)

Posted: Sat Dec 23, 2006 1:52 am
by changeip
They have cloned my PPPOE server!!
And how did they get your MT to talk to their PPPOE server?

Posted: Sat Dec 23, 2006 7:31 am
by mneumark
Ability to Scan for Non-80211 Noise without having to watch the noise floor. This would be great option instead of trying to use a spectrum analyzer.

Posted: Sat Dec 23, 2006 3:33 pm
by smacebr
My customers were logging in the wrong pppoe server. And NOT my pppoe server. please dont think I am so stupid :-)
It happened before. It will happen again. So the feature of scanning for PPPOE servers in MK would be great!! Raspppoe is opensource and has it implemented already.

Posted: Sun Dec 24, 2006 11:07 am
by pedja
MT should show channel numbers together with frequencies. Channel numbers are native way of dealing with WiFi

Posted: Thu Dec 28, 2006 6:57 pm
by uldis
My customers were logging in the wrong pppoe server. And NOT my pppoe server. please dont think I am so stupid :-)
It happened before. It will happen again. So the feature of scanning for PPPOE servers in MK would be great!! Raspppoe is opensource and has it implemented already.
We will add that to the todo list.

Posted: Thu Dec 28, 2006 8:05 pm
by changeip
1. Please add a mangle action that allows us to clear the Dont Fragment bit... please please please. #1 one request for me right now.

2. Please add a routing-filter selection option that allows us to specify inbound interface. This would allow multiple dhcp clients receiving DHCP addresses to be modified on the way (dynamic-in) in based on their interface.

Thx
Sam

Posted: Sun Dec 31, 2006 1:48 am
by smacebr
uldis, great news from you ... the MK community thanks you :-)

Posted: Sun Dec 31, 2006 1:20 pm
by Art
add pppoe relay agent
this feature will pass pppoe by wlan pseudo bridge

Posted: Tue Jan 02, 2007 12:37 pm
by uldis
add pppoe relay agent
this feature will pass pppoe by wlan pseudo bridge
not planned at the moment.

Posted: Tue Jan 02, 2007 1:58 pm
by normis
2. Please add a routing-filter selection option that allows us to specify inbound interface. This would allow multiple dhcp clients receiving DHCP addresses to be modified on the way (dynamic-in) in based on their interface.

Thx
Sam
please explain a little more, what exactly would this be for and how it would work?

Posted: Thu Jan 04, 2007 10:40 am
by pedja
I had to move MT to new hardware (i changed everything but CF with MT on it). It was i nightmare, MT could not find old ethernet adapters, because they were not there any more and all rules depending on interfaces were messed out.

I know that MT has lists of interfaces which we can see with /interface print and list of ethernet adapters which we can see with /interface ethernet print

As it is now, MT equals inteface with adapters, so if we change ethernet adapter, it creates new interface.

It would be great if these two are separated in manner that we can assign ethernet adapter to the interface, so when we have to change adapters, we just assign new adapter to existing interface. so all the rules that depend on interface would continue working as nothing really changed.

Posted: Thu Jan 04, 2007 6:56 pm
by changeip
I'm working on a script that will help with these migrations (of course if the old is available still). It basically takes all interfaces, wraps them up in a single port bridge, then you insert new adapters, unwrap them and your done. I'm half done - if anyone wants to finish it here it is:

Sam
# --- BEFORE ---
#0.  Make a backup : )
#1.  Find all real interfaces
#2.  Add new bridge interfaces
#3.  Add real interface into corresponding bridge interface
#4.  Reconfigure IP addresses
#5.  Reconfigure Firewall Filters
#6.  Reconfigure NAT Translations
#7.  Reconfigure Mangle Rules
# --- BEFORE ---

# Make a backup
/system backup save name="before-interface-swap"

# Now loop thru each real interface
:foreach realinterface in=[/interface ethernet find] do={

	# Process some vars for speed.
	:local OldName [/interface ethernet get $realinterface name]
	:local NewName ($OldName . "-temp")

	# Add an empty bridge for each real interface we find.
	/interface bridge add name=$NewName comment=[/interface ethernet get $realinterface mac-address]
	
	# Add the interface to its temporary bridge.
	/interface bridge port add interface=$OldName bridge=$NewName

	# Change the IP ADDRESSES from the real interface to the temporary bridge.
	:foreach ipaddr in=[/ip address find interface=$OldName dynamic=no] do={
		/ip address set $ipaddr interface=$NewName
	}

	# -- FIREWALL FILTERS --
	:foreach rule in=[/ip firewall filter find in-interface=$realinterface] do={
		/ip firewall filter set $rule in-interface=$NewName
	}
	:foreach rule in=[/ip firewall filter find out-interface=$realinterface] do={
		/ip firewall filter set $rule out-interface=$NewName
	}

	# -- NAT TRANSLATIONS --
	:foreach rule in=[/ip firewall nat find in-interface=$realinterface] do={
		/ip firewall nat set $rule in-interface=$NewName
	}
	:foreach rule in=[/ip firewall nat find out-interface=$realinterface] do={
		/ip firewall nat set $rule out-interface=$NewName
	}

	# -- MANGLE RULES --
	:foreach rule in=[/ip firewall mangle find in-interface=$realinterface] do={
		/ip firewall mangle set $rule in-interface=$NewName
	}
	:foreach rule in=[/ip firewall mangle find out-interface=$realinterface] do={
		/ip firewall mangle set $rule out-interface=$NewName
	}

	# -- QUEUES --
	:foreach queue in=[/queue tree find parent=$OldName] do={
		/queue tree set $queue parent=$NewName
	}
	:foreach queue in=[/queue simple find interface=$OldName] do={
		/queue simple set $queue interface=$NewName
	}

	# -- DHCP SERVERS --
	:foreach rule in=[/ip dhcp-server find interface=$OldName] do={
		/ip dhcp-server set $rule interface=$NewName
	}

}

# --- AFTER ---
#1.  Find all bridge interfaces

does comment-MAC exist in system now?

if so,
	set name on interface to original
	change interface name to original ?  (strip-temp) ?
	reconfigure rules
	remove bridge ports
	remove bridges


if not, leave in bridge ?




#2.  
#3.  
#4.  Reconfigure IP addresses
#5.  Reconfigure Firewall Filters
#6.  Reconfigure NAT Translations
#7.  Reconfigure Mangle Rules
# --- AFTER ---

Posted: Tue Jan 09, 2007 10:18 am
by pedja
DHCP should be fixed a bit.

Whan lease is set but it does not belong to any defined networks, MT should warn about that issue. Now it acts as nothing is wrong and gives the lease but with incorect parameters. Problem is that it is not obvious why parameters are wrong.

I lost quite a time today to find problem. I mistyped network address innetworks, and lease setup was ok, so I got half correct info on client and could not realize what was going on.

And, one more thing, we should be able to disable network record as we can disable everywhere else. Right now we can set or delete record.

Better SUGESTION of ALL HERE !!!

Posted: Tue Jan 16, 2007 12:56 am
by smacebr
Including OSPF in LEVEL 4 !!!!

Level 5 is TOO expensive just for having OSPF!!!!

OVER TWO TIMES MORE EXPENSIVE THAN LEVEL 4 JUST FOR HAVING OSPF !!! IT IS NOT FAIR !!!!

I cant believe developing OSPF has costed Mikrotik over twice the RouterOS itself. Even larger ISP would not have (or have less) interest in such expensive software (or limited), and a lot of programmers would be encoraged in cracking the software once it would be expensive. Here in Brazil $95 is a lot of money! It is 75% of the national minimum salary.

Maybe one 4.5 version with OSPF would be welcome!!!
I dont have even 50 simultaneos users in most of my MK routers!!!!
But I really need OSPF!!! It makes life easier... please lets not make things worst ...

Maybe a new Level is required.
Level 4.5 for $50 or MAXIMUM $60.
(with the same limitation of L4 just with OSPF)

Posted: Tue Jan 16, 2007 8:48 am
by janisk
license fee is not the software you install it is - new versions, it is support, this is what adds the value. if you buy lvl 5 lic. you get upgrade times to version 4.x with lvl4 lic. currently get only upgrae "time" to version 3.x :roll:

pedlja - many users create many different, wicked configuration. that is wy RouterOS is RouterOS - you can do whatever you want to, but you have to know what exactly you are doing, if you don't read the manual again.

Posted: Tue Jan 16, 2007 9:13 am
by normis
I'm sorry, smacebr, what are you talking about? OSPF is (and will be) included in L4 license. We are talking about BGP which will need L5 for x86 systems.

Posted: Tue Jan 16, 2007 4:55 pm
by jober
I thought the same thing about OSPF because some peoples misunderstanding.
Then I looked at this
http://www.mikrotik.com/software.php
RIP, OSPF, BGP protocols (V3 = no, except RouterBOARD)

The way I read it I would think that you get RIP, OSPF, BGP protocols as long as you are using a RouterBoard with the OS preinstalled.
Is this true?
And is it also true that if one is building PC based APs that you will need V4 to have all the same things we have now in level4 key on a x86/PC based AP router?

Posted: Wed Jan 17, 2007 8:34 am
by normis
I thought the same thing about OSPF because some peoples misunderstanding.
Then I looked at this
http://www.mikrotik.com/software.php
RIP, OSPF, BGP protocols (V3 = no, except RouterBOARD)
that page also says that all v3 information is preliminary and is likely to change.
The way I read it I would think that you get RIP, OSPF, BGP protocols as long as you are using a RouterBoard with the OS preinstalled.
Is this true?
yes, the mentioned limitations apply to other systems only. plus, the limitations are different, go see the same page now, i have updated it.
And is it also true that if one is building PC based APs that you will need V4 to have all the same things we have now in level4 key on a x86/PC based AP router?
v4? please clarify what you mean with this.

Posted: Wed Jan 17, 2007 5:41 pm
by csickles
Clearity...
How Zenn... :D
There is a page to snag and keep close !!!

Posted: Wed Jan 17, 2007 6:59 pm
by jober
Q. v4? please clarify what you mean with this.
A. ROS v4.x vs ROS v3.x

I thought that the old level4 key would get you every thing that level 5 and 6 got you but the level4 was limited to a smalled number of tunnels and such things as connections.
Now a level4 key is a V3 from what it looks like to me. All in respect to the price columns.

Normis, please don't get to annoyed with me for asking these things. I just want a clear understanding of it all and most days I'm kinda thick headed. I also fully understand that you have to keep your products profitable to keep MT moving forward. So don't think I'm bashing your price structure ether.
:lol:

Posted: Thu Jan 18, 2007 8:58 am
by normis
if previously L4 allowed you to upgrade for one year, and L5 - for 3 years, now L4 will allow upgrading up until the latest version of RouterOSv3.

L5 and L6 will allow upgrading up until the latest v4, with no time limitations. This is much better, because you are not forced to stay on a problematic version if upgrade time deadline comes to pass. No more deadline - upgrade is possible forever, just until a certain version.

All answers here:
http://wiki.mikrotik.com/wiki/All_about_licenses

Posted: Thu Jan 18, 2007 5:23 pm
by jober
I see clearly now O-O

Posted: Sun Jan 21, 2007 7:38 pm
by dbostrom
Pardon me if it's already been mentioned or if I've missed some way of doing it that's already in ROS, but the ability to squirt arbitrary strings of characters out of the serial port via the scripting language would be great.

I've seen a hack on the Wiki that allows this (using modem setup string) but it's a bit kludgey for extensive use.

Reason I ask is that we're putting together a little battery powered multi-band survey tool w/LCD display for installers and would like to use RB112 boards for this application. Aside from the difficulty of firing characters out of the serial port it's ideal.

Posted: Mon Jan 22, 2007 1:20 pm
by cmit
Hey - don't call my work-arounds clutchy :D (just kidding) ...

No, seriously - it's not possible right now, but I would renew my request for that possibility to: A command to send out arbitratry text (and binary!) data over a serial port.
And - even better - the ability to have the possibility to trigger a script when a certain regex is matched on incoming data on a serial port...

But if you're doing things yourself, you could also step up to using an own linux distro giving you all abilities you could dream of?!

Best regards,
Christian Meis

Posted: Mon Jan 22, 2007 1:25 pm
by bjohns
To add yet another use for serial port interaction. Many modern charge controllers also have serial interfaces. Having the ability to read this data via the MT would save monitoring equipment at the very least.

Posted: Mon Jan 22, 2007 3:57 pm
by dbostrom
Hey - don't call my work-arounds clutchy :D (just kidding) ...
I mean "hack" in the very best sense of the word!

But if you're doing things yourself, you could also step up to using an own linux distro giving you all abilities you could dream of?!
Yeah, but there are so many places where I have God-like powers of compilation; it's all I can do to maintain hegemony over our legions of Linux boxes. I'm just looking for a break here, heh! That serial port is --so-- close to being useful without me having to tame the entire rest of the RB112...

Posted: Mon Jan 22, 2007 4:35 pm
by cmit
Seldom you get called a "hacker" in the real (good ol') sense these days ;)

Full ACK on the "no need to tame the RB112 with linux" - there's not much left to do for MikroTik to make way for much more sophisticated use of serial ports...

Best regards,
Christian Meis

Posted: Tue Jan 23, 2007 1:29 am
by Hammy
I would a feature that would be similar to existing hotzone products. It would be a feature similar to WDS, but would have the ability to take the data out of the wireless network quickly. It is kinda silly to have a whole town only able to use 25 megabits of throughput because the air is full of everyone else's download.

I believe Butch has a combination of scripts, etc. that make MT very close to what the big $ companies have in their gear. Please work with him to find out what the shortcomings are in his system so we can have a more solid product.

I am looking for this to be used as a giant wifi hotzone supporting mobility for laptops, PDAs, etc. as well as N-Streme mobility for vehicles.

Posted: Tue Jan 23, 2007 2:07 am
by Hammy
I would also like a feature added to the PPPoE client interface specifying an internal interface.

That way I can link a VLAN with a specific PPPoE client interface. This http://forum.mikrotik.com//viewtopic.php?t=11218 thread specifies how to do so currenlty, but it chews up additional IP addresses on the server. I'd prefer to not do that.

Posted: Tue Jan 23, 2007 9:46 am
by pedja
pedlja - many users create many different, wicked configuration. that is wy RouterOS is RouterOS - you can do whatever you want to, but you have to know what exactly you are doing, if you don't read the manual again.
I am perfectly aware of that. I pointed out obvious error condition: lease set but does not belong to any defined network. It is like MT colours red rules that are attached to some ethernet interface which does not exist.

Posted: Thu Jan 25, 2007 9:49 am
by npero
You have Tx/Rx bytes for wireless client in statistic tab but can you add in registration list real Tx/Rx in seconds. Is very usful to check upload, download bandwitch for wireless clients.

Thanks.

Posted: Tue Jan 30, 2007 10:41 pm
by smacebr
normis,

Sorry for the wrong post. I really had read that wrong. But considering the new values that would be really expensive :-)
I am happy to say I WAS WRONG :-)
Beyound me other 3 friends had made the same interpretation of:
http://www.mikrotik.com/software.php

What do you think of using diferent lines for RIP, OSPF and BGP?
(Once it is diferent relating to each level - just a suggestion)

And I am gonna buy some extra MKROS now hehe :-)

Thank you for giving me this news.

Best regards,

sergio marcelo

Posted: Wed Jan 31, 2007 11:30 pm
by pedja
In Winbox, wherewer table view is available, we should be able to set order and size ov the columns and alos choose which columns to see in table.

I find some columns that are forced in simple wiewes and wireless interfaces not importand and some other coluns that are not avialble important.

For instance, in simple queues, target address column isoffered, but what iactualy needed is destination address. In wireless interfaces, i would like to have rx/tx signal strength (in client mode).

Posted: Mon Feb 05, 2007 4:53 pm
by pedja
Winbox: Wireless

Access List, Registration and Connect list should have filter on Interface so we can set filter to display records just for selected interface.

This is similar to how Firewall Fitler Rules are filtered by chains.

It would realy help a lot.

Posted: Tue Feb 06, 2007 2:15 am
by lepiaf
And now you're telling us about ospf in l4 after few l5 bought... homer says "d'oh!" :) keep on with the good work anyway, we're about to test ospf area ranges, hopefully it's the missing ospf route summarization :)

cyah
LePiaf

Posted: Wed Feb 07, 2007 11:24 am
by pedja
It would be good to be able to check CPU temprature and fan speed.

Posted: Wed Feb 07, 2007 3:00 pm
by stephenpatrick
It would be good to be able to check CPU temprature and fan speed.
Ditto, several of our customers have asked for this, specifically on x86 hardware.
We have asked MT directly - AFAIK it's a matter of development priorities, so anyone else who wants this, best to ask now also.

Regards

Posted: Wed Feb 07, 2007 4:27 pm
by npero
I also like to see CPU temperature and speed CPU fan on x86, but is toomany diffrent hardware monitor chips solder on mainboard if Mikrotik can implement some open sorce hardware monitor project and update regulary would have been very nice 8) .


Best regards.

Posted: Thu Feb 08, 2007 9:19 am
by janisk
as you already said - there are many devices for monitoring, and if all of them implement in ROS it will become even bigger. and on a side-note - not all chipsets are supported by linux, and some of them report incorrect values.

Posted: Thu Feb 08, 2007 2:20 pm
by stephenpatrick
Thanks Janisk,

Thanks very much for the response.
IMHO the current size of ROS isn't a problem on x86 - sure it might be when on an embedded routerboard with soldered-down flash - but the larger x86 boxes tend to run from compactflash or DOM where 256MB is not cost-prohibitive - and it's on those where we are more likely to have the issues (CPU/chipset heat, and on indoor boxes, fans) -
How about put it in a special optional package "x86 monitoring" - that way the routerboards won't need it, only load it as an option on x86 builds, where most boxes have plenty of spare flash.

Regarding unsupported boards and wrong values, how about implement the feature **with a strong caveat to check support** and then we (users) post on the WIKI which boards work/are accurate and not. Ones that don't work, well fair enough, we'd all accept that.

Really hope you can do something to implement this feature - would be great.

Regards

Posted: Thu Feb 08, 2007 6:06 pm
by changeip
Yes, a separate package for 'x86 monitoring'.

Posted: Fri Feb 09, 2007 2:58 pm
by pedja
Yes, a separate package for 'x86 monitoring'.
Or even sepaate packages for different chipsets if necessary.


Unrelated to this, here are some more suggestions:

When wireless interface is used in station mode, Wireless / Registration shows info about AP it is connected to. It shows Radio name and MAC Address, but it does not show SSID of the AP it is connected to. It should.

Also, when connection is made based on some rule in Connection list, it would be good that Registration shows which rule exactly matched connection.

Posted: Fri Feb 09, 2007 3:23 pm
by normis
come on! there are more priorities in v3 than this; you are talking like this is the most important thing in a router. separate packages for temperature monitoring? how about new wireless standards, improved speed, mpls, ipv6 and a working bgp?

Posted: Fri Feb 09, 2007 4:01 pm
by pedja
Sorry, I did not understood that this topic is for urgent and important requests. I thought it is started for purpose of various suggestions and ideas.

Posted: Fri Feb 09, 2007 4:15 pm
by normis
it is, but until now, we have not received any important feature requests.

Posted: Fri Feb 09, 2007 4:53 pm
by Diganet
it is, but until now, we have not received any important feature requests.
Okay, here's a feature i could use; some kind of link autotuning. We have some long links running, but in extreme weather SNR can drop a lot and we need to go raise TX power/change channels manually to get those 5-10 dB extra and then change back when weather is fine. Perhaps a thing like whenever SNR drops below a certain value or CCQ gets below a certain limit compared to normal, RouterOS will adjust accordingly within given ratio of course.. I am about to do some scripting to do this, but it's a bit dangerous and also hard to read SNR values from opposite side of link from script. Also the other way around if you have too high SNR it could be great if RouterOS could adjust TXpower to the best.

Regards

/Henrik

Posted: Fri Feb 09, 2007 6:08 pm
by changeip
it is, but until now, we have not received any important feature requests.
Well, "how about new wireless standards, improved speed, mpls, ipv6 and a working bgp?"

I personally don't want to load down the developers and spread them so thin they can't develop solid core functionality. Once those features you mentioned above are solid I will ask for more non-core functionality.

About temp monitoring; I also think temp on x86 is not nearly as important as temp monitoring on the routerboard series. They are outside in remote locations with unstable environmental conditions and being able to monitor your equipment gives you better uptime in the long run. I don't know if the IDT has temp sensor or not, but it should be looked at for future boards.

Posted: Sat Feb 10, 2007 1:32 am
by Mapik
Some load balancing routing protocol, like olsr will be really useful.

Posted: Sat Feb 10, 2007 1:42 am
by stephenpatrick
About temp monitoring; I also think temp on x86 is not nearly as important as temp monitoring on the routerboard series. They are outside in remote locations with unstable environmental conditions and being able to monitor your equipment gives you better uptime in the long run.
Ahem, not to quibble, but many users (and some major customers of ours) have (and plan to have) non-routerboard x86 solutions in sealed outdoor enclosures. Sure, we have implemented excellent passive cooling of 1GHz+ processors - really good - but some of these go into really harsh climates, and mission-critical networks. Not just potentially but a **huge problem** not having temp feedback.
Please do implement this - it's been asked for a lot of times - and appreciate the priorities but this one is bigger than some people think.

Regards

Posted: Sat Feb 10, 2007 1:51 am
by stephenpatrick
it is, but until now, we have not received any important feature requests.
Well, we've contributed a few, and we sure hope they are on the MT roadmap:
-IPV6
-Multicast support especially IPTV style deployments
-SNMP V2, 3
-MPLS
-Temperature and voltage monitoring on all platforms including x86
-Intel IXP52x family chipset/board support
-Atheros SOC support for CPE etc
-Branding for web-box
With those, MT would become an extremely powerful and competitive solution, in today's market.

Regards

CableFree Solutions

Posted: Sat Feb 10, 2007 4:52 am
by ghmorris
Ditto to Stephen.

Particularly:
-Intel IXP52x family chipset/board support
-Atheros SOC support for CPE etc
Need these two just to keep up with the industry direction.

-WiMAX support, preferably in 2.3GHz for Canada.
WiMAX has some powerful advantages using licensed bands.

-MPLS
This is fast becoming a tick-box requirement with many of our bigger customers. End to End Quality of Service is a big deal.

-OLSR or other dedicated, practical link-state sensing layer 3 mesh protocol that actually looks at link quality, not just that the link exists.
We have to have a real multi-radio mesh capability. This is probably our biggest long term network design issue.

-Temp, voltage support for RB series equipment in particular, all platforms in general. Voltage is a bigger deal than temp for me, I want to know what the POE is delivering at the electronics.

-MiMo support - An Orthogon-like design please.
-Diversity support for backhauls.
We had to find other solutions for solid long-range backhauls. We would like to move back to MT, but can't until backhaul implementation is improved.

George

Posted: Sat Feb 10, 2007 1:05 pm
by pedja
it is, but until now, we have not received any important feature requests.
a) That is awesome. If I am developer I would be very happy to see just trivial, cosmetic and usability targeted requests. That would mean that all the mayor stuff is already done, right?

b) I do see some important request here, but usually, developers response to any important request is that it is not important, to complicated, or that it simply would not be done.

c) as developer myself, I always consider each request as important, it is just matter of view who to it is important.

Posted: Sat Feb 10, 2007 1:46 pm
by bjohns
In addition to waiting to hear from the users on what they would like implemented - I would hope MT are looking to the competition on what they are offering.

For example Vyatta may be a young project but it's got a nice wish list that would be worth a look.

I have mentioned various features of Colubris/Nomadix Hotspot access controllers on these forums - I would like to see them in RouterOS.

Posted: Sun Feb 11, 2007 10:57 pm
by grzesjan
come on! there are more priorities in v3 than this; you are talking like this is the most important thing in a router. separate packages for temperature monitoring? how about new wireless standards, improved speed, mpls, ipv6 and a working bgp?
Thanks God!

I have so many problems with BGP and I have even asked Mikrotik on latest MUM in Krakow in Poland about "when can we have working BGP" and Mikrotik guys claimed that BGP is ok and working properly...

Now I see that finally they have understood that BGP is broken :)

Gregor[/u]

Posted: Mon Feb 12, 2007 8:47 am
by normis
pedja - no, we have a ton of cosmetic suggestions and that's great! yes, we are working on some big improvements, and we would like more testing and suggestions.

about temperature monitoring - it is simply impossible to monitor routerboard temp because there are no sensors on it. same for many other devices

Posted: Mon Feb 12, 2007 8:48 am
by normis
grzesjan - have you tested v3 routing-test BGP? that is something new.

Posted: Mon Feb 12, 2007 12:21 pm
by grzesjan
grzesjan - have you tested v3 routing-test BGP? that is something new.
No, but my admins have been told to test v3 beta this month. We will see how it is stable in our usage. Then I will test v3 bgp.

Gregor

Set vlan 802.1p priorities

Posted: Mon Feb 12, 2007 8:26 pm
by dsovereen
I'd like to be able to set 802.1p VLAN priority tags. Currently, you can set ToS bits, but that doesn't help for prioritizing non-IP traffic being bridged over a network.

so what about

Posted: Thu Feb 15, 2007 3:52 pm
by bprasil
multicast routing?

Posted: Thu Feb 15, 2007 3:58 pm
by normis
we already support protocol IGMP for IP Multicast (compliance with RFC 2236)

Support IP Multicast with use Protocol Independent Multicast (PIM) and Sparse and Dense Mode (compliance with RFC 2362, 3973) are being developed.

Posted: Fri Feb 16, 2007 1:13 am
by dainen
MLPPP (rfc1990)

Posted: Fri Feb 16, 2007 8:26 am
by normis
Short for MultiLink PPP, an extension of the PPP that allows the B-channels of ISDN lines to be used in combination as a single transmission line, doubling throughput to 128 Kbps.
from the isdn manual:
bundle-128K (yes | no; default: yes) - use both channels instead of just one

is this it?

Posted: Fri Feb 16, 2007 8:38 am
by dainen
I was referring to mlppp for PPPoE

Posted: Fri Feb 16, 2007 8:54 am
by normis
sorry, no plans for it yet.

Posted: Wed Feb 21, 2007 2:43 pm
by Hammy
I'm not sure if this has been mentioned yet, but solving wireless jitter would be a major bonus to real-time 2-way communications.

How about...

Posted: Wed Feb 21, 2007 8:08 pm
by nbson
A print server?

Re: How about...

Posted: Thu Feb 22, 2007 8:26 am
by normis
A print server?
:D

Posted: Thu Feb 22, 2007 8:31 am
by jober
PtMP Nstreme2 would be cool!
But I guess thats a bit to much.
:lol:

Re: How about...

Posted: Thu Feb 22, 2007 4:31 pm
by janisk
A print server?
this is not universal OS

please stay on routing features at least try

Posted: Fri Feb 23, 2007 12:50 am
by dainen
docket printer :D

Re: How about...

Posted: Fri Feb 23, 2007 4:46 pm
by nbson
A print server?
this is not universal OS

please stay on routing features at least try
I realize that it's not a universal OS. But what do ntp, dns and proxy servers have do with routing? They are all part Mikrotik.

Posted: Fri Feb 23, 2007 5:54 pm
by janisk
as RB500 do not have bios battery than there was needed a way to set correct time after power failure - so NTP client was introduced and since server was not that complicated that was too implemented.

DNS server is simple and is very handy

Re: How about...

Posted: Fri Feb 23, 2007 8:32 pm
by stephenpatrick
A print server?
**if** RouterOS were being used in residential CPE / consumer devices, competing with the likes of Dlink, Netgear, etc then the following would be really desirable compared to products currently on the market:
- Print Server (using USB port)
- NAS (USB or SATA drives presented as network drives on LAN or over wireless)
- Support various media-streaming protocols for streaming MP3s, MPEG2/4 from the NAS drive to remote devices e.g. media extenders
- ADSL2 ports

But it doesn't, and there's no sign Mikrotik plan to be in that market.
So no, don't expect those features any time, or soon.

Regards

Posted: Mon Feb 26, 2007 3:22 am
by ikm3
I think a more versatile DNS server would be nice, e.g. providing DNS names for DHCP clients and the router itself like dnsmasq and also automatically providing reverse DNS for local clients. One really neat feature of dnsmasq is that it will return an IP address on the same network of a client if possible if a host has more than one hostname listed.

EoIP client for Windows

Posted: Mon Feb 26, 2007 7:53 pm
by jober
How about a windows driver/interface for the EoIP tunnel?

Posted: Tue Feb 27, 2007 8:34 am
by janisk
as in other thread - most probably not going to happen

FUTURE REQUEST

Posted: Wed Feb 28, 2007 12:30 pm
by maxfava
FUTURE REQUEST

Hi,
it is usefull if it is possible to implement the MP PPP feature on version 3 (I want it on V2 also :)).
I see on internet that the linux application that support MP multilink is the PPPD.
I tried on my linux adsl with very long trials but it complicated without user interface.

thanks
Massimo

Posted: Thu Mar 01, 2007 11:21 am
by sergis
1. Support for all-generic-ide driver,posibility to start ros with this driver.
2. Option for unloading some kernel modules,services: for example unloading qos module if it not required
3. Ability to tune kernel /proc/net variables
4. Ability to create&using custom kernel for ros :)

802.11s ?

Posted: Fri Mar 02, 2007 3:00 pm
by stephenpatrick
Mesh networking standard -

http://en.wikipedia.org/wiki/IEEE_802.11s

Any comments from MT or various users? i.e. "useful or not" ...

Regards

CableFree Solutions

Re: 802.11s ?

Posted: Sun Mar 04, 2007 2:30 pm
by mag
MPLS would be much better 8)

Posted: Mon Mar 05, 2007 9:38 pm
by sergis
Some new ideas:

1.Some detailed info for wireless - like droped frames,
2.Noise floor scanner
3.Spectrum analyzer..

Posted: Tue Mar 06, 2007 8:19 am
by janisk
Some new ideas:

1.Some detailed info for wireless - like droped frames,
you can see that by frames and hwframes.
frames shows how much you wanted to send
hwframes shoes how much actually frames you have send to send amount of frames
2.Noise floor scanner
it is already there - if you check wireless section
3.Spectrum analyzer..
:roll: thin what you are asking. closes thing is scan feature in RouterOS

please be so kind do not ask features that are not available due to hardware limitations or are already implemented.

here is link to what we already home (lacking some features:
http://www.mikrotik.com/testdocs/ros/2.9

and i suggest you to attend training when possible.

Posted: Tue Mar 06, 2007 4:55 pm
by Campano
a tftp server?

thist ist a simple, secure and light service...

please think in this complement...

Posted: Tue Mar 06, 2007 6:13 pm
by Hammy
A more traditional spectrum analyzer feature would be much appreciated. A graph and textual summary that depicts frequencies and their associated "noises". "Noises" could be composed of both the noise floor parameter and the scan parameter (since one does not include the other). Perhaps the hardware is unable to have a 1 MHz resolution, but a 5 MHz resolution should be available.

Channel reuse on the same site

Posted: Wed Mar 07, 2007 1:56 am
by Frizz
We need to able to reuse the same channel on a single site to support much more subscribers thus improving economics.

I see in this forum many users need this feature but are proposing a solution to channel reuse that many other vendors in the industry (ex Motorola canopy or skypilot) have taken: synchronize the radios with GPS so that they do not interfere with each other.

Transmit GPS synchronization is difficult on a polled protocol like Nstreme while it is trivial on time slotted protocols like canopy use.


However, we have a very simple solution to channel reuse that should be very easy and fast to implement on Nstreme if the atheros driver allows it:

--being able to choose 2 different channels for transmitting and receiving on the same single radio card

for example, on the AP
tx on channel 1 while rx on channel 2
on the subcribers CPEs
tx on channel 2 while rx on channel 1

Using sectorial antennas with good F/B ratio would allow to reuse the same channel many times over the same site, (depending on antennas radio pattern even 3-4 times) since transmitting APs will not interfere with receiving APs on the same site.

Of course I'm talking about PmP Nstreme with a single radio card, since Nstreme2 PtP already has this feature even though using 2 different radio cards.


Furthermore, using different channels for transmitting and receiving is also handy to get around interference on crowded rf environments.


Hope I made myself clear. Any thoughts?

Normis, any comments on feasibility?

Posted: Wed Mar 07, 2007 2:13 am
by Hammy
Some sort of GPS sync would be nice. A few different vendors have GPS sync ability.

Posted: Wed Mar 07, 2007 4:22 am
by jober
Since we are all dreaming! Why not make us a Smart Antenna Array. :lol:

Posted: Wed Mar 07, 2007 8:25 am
by JJCinAZ
Here are some which may have been mentioned before:

1) Reverse DNS lookup's on IP addresses in Winbox when hovering the mouse over an IP address. For example, in torch we often will stop the display and have to manually look up reverse DNS for IP addresses. If the hover did this, it would make things much faster. This also adds a huge cool factor to the UI.

2) Ability to customize and/or brand the web interface. We sell a lot of routers as managed firewalls and allowing the "admins" to do some simple things via the web interface would be great. Maybe be able to build custom web pages and have form submits run scripts (okay, maybe I'm getting carried away here).

3) Add a package to drive one or more common alphanumeric LCD panels w/button support. This would allow us to build some very cool little appliances. The button support could fire off scripts. The current LCD support is way too limited. It's not interesting to see the CPU load.

Posted: Wed Mar 07, 2007 10:21 am
by ste
it is, but until now, we have not received any important feature requests.
Okay, here's a feature i could use; some kind of link autotuning. We have some long links running, but in extreme weather SNR can drop a lot and we need to go raise TX power/change channels manually to get those 5-10 dB extra and then change back when weather is fine. Perhaps a thing like whenever SNR drops below a certain value or CCQ gets below a certain limit compared to normal, RouterOS will adjust accordingly within given ratio of course.. I am about to do some scripting to do this, but it's a bit dangerous and also hard to read SNR values from opposite side of link from script. Also the other way around if you have too high SNR it could be great if RouterOS could adjust TXpower to the best.

Regards

/Henrik
Let me insist in this. This is a very important feature for people building
larger networks with ROSs over wireless links.

We're working in unlicensed spectrum so we're not sure at all to have
a working link from one minute to the other.

So we would like to see ROS-Boxes watch link quality, talk to each other
and take mesures to optimize overall performance and robustness.

Some marketeers call it self healing Network.

I think there are some knobs which should be autoregulated:
- frequency
- power
- (OSPF) Link cost

May be you upgrade the Discovery Protocol for a decentraliced version
or you keep a central link database within Dude to optimize the
network.

Stefan

MIMO Please

Posted: Wed Mar 07, 2007 10:53 pm
by jonbrewer
My #1 request is MIMO - preferably 2x3, but even diversity receive would be an extremely welcome addition.

Posted: Thu Mar 08, 2007 1:48 am
by variable
we already support protocol IGMP for IP Multicast (compliance with RFC 2236)

Support IP Multicast with use Protocol Independent Multicast (PIM) and Sparse and Dense Mode (compliance with RFC 2362, 3973) are being developed.
I am very excited about this!!!
Will it be ready in v3?

How is IGMP currently implemented? in v3 beta you mean?

Will we be able to control IGMP group membership control via radius?