What's new in 1.2:

*) fixed problem - reset configuration & reboot did not work;
*) fixed problem - VLAN header present/not present matcher did not work in ACL;
*) fixed problem - could not match all packets in ACL;
*) fixed problem - deleting one ACL entry did not have immediate effect;
*) fixed problem - could not enable watchdog after it was disabled;
*) added ability to connect to SwOS with VLANs;
*) added save backup & restore backup ability;
*) added support for jumbo frames (up to 9k);

http://www.mikrotik.com/download.html

Looking good.

I'll try it on my 3 in series setup over the weekend and email support if there are any more problems.

Thanks guys!

Soo far so good..

1.2 seems stable (for what I use it for)..

I've got a couple of RB250's sitting in manholes and other places that take some effort to get to.

Am I going to able to restart via software, or am I going to have to lift manhole covers to pull the power plugs?

Now that's an underground network.

Tom

Eben, if you are running v1.1 there should not be any problems upgrading remotely.

Now that's an underground network.

Tom

Don't knock it. It works. STP is amazing stuff

Eben, if you are running v1.1 there should not be any problems upgrading remotely.

Thanks. I'll give it a shot over the weekend.

I've pushed this forward and the problems start...

I logged into the switch that's at the end of the line, clicked on system, browsed for SWOS ver 1.2 and pressed the upgrade button.

After a couple of seconds the SWOS web page came refreshed the system tab and the os version is still 1.1

I then pressed the reboot button but nothing happens.

In fact, I could press the reboot button until I start growing horns out of the side of my head. It still does not work.

Am I right in assuming that I am going to have to power this lot down one switch at a time and then restart them to get the SWOS to upgrade?

Not happy...

Things are not good with this SWOS ver 1.2

First of all, my ongoing issue has not been addressed: Dude still doesn't interpret SMNP properly.

But that's not important now. So I went out and shut power down to the switches and the RB750's next to them.

When I powered the network up, the fun started.

Ping times have gone from less than 3ms to around 31ms. This isn't good. I've done several ping tests and there's no doubt that it's the switches causing the latency. No idea why.

Apart from the latency, there are plenty of ping timeouts. Dude is sending me a long list of ping failures. The units are running - ie traffic is passing through them, but you just can't ping them.

None of these problems were evident in SWOS1.1

The question now is how do I downgrade to the old version?

The switch / RB750 combo in this picture became too much to handle.

I uploaded SWOS 1.1 onto the switch, tried to reboot, failed and used the UPS to cycle the power going to that box.

The unit is now running on 1.1 and it appears happy.

Ping times have dropped to 15/16ms and there are no more ping timeouts being reported by Dude.

Unfortunately my SNMP still doesn't work.

Do you have problems with increased latency and ping timeouts when you ping to or through switch? Are there any transmission errors reported in statistics tab?

Do you have problems with increased latency and ping timeouts when you ping to or through switch? Are there any transmission errors reported in statistics tab?

Both to and through.

Other information here:

Pauses 0 0 0 0 0
Total Errors 0 0 0 0 0
Underruns 0 0 0 0 0
Too Long 0 0 0 0 0
Collisions 0 0 0 0 0
Excessive Collisions 0 0 0 0 0
Multiple Collisions 0 0 0 0 0
Single Collisions 0 0 0 0 0
Excessive Deferred 0 0 0 0 0
Deferred 0 0 0 0 0
Late Collisions 0 0 0 0 0

Hi,
I confirm the issue with the Reboot button. I'm connected over vlan1 from my PC. When I press Reboot the webserver in the switch just dies off silently. The switch itself keeps on forwarding the traffic and not a single packet is lost. If I try to telnet 192.168.88.1 port 80 there is no ARP reply.

Dalimil Gala

I confirm the issue with the Reboot button. I'm connected over vlan1 from my PC. When I press Reboot the webserver in the switch just dies off silently. The switch itself keeps on forwarding the traffic and not a single packet is lost. If I try to telnet 192.168.88.1 port 80 there is no ARP reply.

Make sure you are running v1.2 as there were issues in previous versions.

I confirm the issue with the Reboot button. I'm connected over vlan1 from my PC. When I press Reboot the webserver in the switch just dies off silently. The switch itself keeps on forwarding the traffic and not a single packet is lost. If I try to telnet 192.168.88.1 port 80 there is no ARP reply.

Make sure you are running v1.2 as there were issues in previous versions.

Have any of these problems that I previously brought to your attention been addressed?

Ping times have gone from less than 3ms to around 31ms. This isn't good. I've done several ping tests and there's no doubt that it's the switches causing the latency. No idea why.

Apart from the latency, there are plenty of ping timeouts. Dude is sending me a long list of ping failures. The units are running - ie traffic is passing through them, but you just can't ping them.

None of these problems were evident in SWOS1.1

Please describe your network topology, configuration, how much and what type of traffic is being forwarded through switch when you experience latency issues. We were not able to reproduce any problems with SNMP (tested with Dude v3.6 and v4.0beta2).

Here's something from Dude

I confirm the issue with the Reboot button. I'm connected over vlan1 from my PC. When I press Reboot the webserver in the switch just dies off silently. The switch itself keeps on forwarding the traffic and not a single packet is lost. If I try to telnet 192.168.88.1 port 80 there is no ARP reply.

Make sure you are running v1.2 as there were issues in previous versions.

Hi,
the problem was I accessed the switch via tinyproxy 1.6.3-2 (Debian Etch) where there is a bug in HTTP 1.0 vs. HTTP 1.1:
https://www.banu.com/bugzilla/show_bug.cgi?id=66

The Reboot button worked well via squid 2.6.5-6etch5.

Is there any way to fix the webserver to recover from such a deadlock? This trouble is over for me anyway as I will avoid using tinyproxy in favour of squid.

Dalimil Gala

Ping times have gone from less than 3ms to around 31ms. This isn't good. I've done several ping tests and there's no doubt that it's the switches causing the latency. No idea why.

Apart from the latency, there are plenty of ping timeouts. Dude is sending me a long list of ping failures. The units are running - ie traffic is passing through them, but you just can't ping them.

None of these problems were evident in SWOS1.1

I have been experiencing the same issues as the user above. I did start a trouble ticket, but was wondering if he got this solved. We are really trying to avoid having to downgrade back to SwOS1.1. Please advise if any solution has been found. Thanks.

Concerning the 1.2 release - what are the options to limit access to the device using ACLs?
The point is not to allow unrestricted access to the device and have something apart from username/password to protect the device.

The example applied for MAC filtering without setting port in the "Redirect to" section does not work. I've tried also filtering based on Dst IP, w/ and w/o protocol. Still not working.
BTW the intended usage is to have dedicated management VLAN ID.

I've got a couple of RB250's sitting in manholes and other places that take some effort to get to.

Am I going to able to restart via software, or am I going to have to lift manhole covers to pull the power plugs?

IMG_1626 (Medium).JPG

IMG_1628 (Medium).JPG

Man what some dark fibre will do with $100 media converters...

What is the purpose of this network ?

F.

What is the purpose of this network ?

It connects a number of computers to some servers.

Are there plans to make SWOs access via telnet or ssh?
Because IMHO web UI is the worst it could be in such device :/

Are there plans to make SWOs access via telnet or ssh?

I second this request.

My wish list is:

telnet/ssh
text based config that can be read and edited by field techs
"winbox-like" interface

If it costs $5 more because you have to add some memory, it is worth it. I will spend more than $5 on config time alone.

Because IMHO web UI is the worst it could be in such device :/

No comment. I don't wish to anger the MT Gods.

Are there plans to make SWOs access via telnet or ssh?
Because IMHO web UI is the worst it could be in such device :/

don't all switches have web config ?

I think it's much quicker to apply a few checkboxes than to edit a text file in hex. If you really want, you can make some 10-20 standard configuration backup files and then just upload them. Much quicker than editing.

I think it's much quicker to apply a few checkboxes than to edit a text file in hex. If you really want, you can make some 10-20 standard configuration backup files and then just upload them. Much quicker than editing.

(I don't think anyone wants to edit a hex file, although I have used Hex Workshop for years, ascii is OK)

Here's my long winded problem with the SwOS config files:

I install networks that are usually remote. I am not there, there is no "IT guy" there.
I ship equipment to the site to save shipping costs. I design the networks and re-use configs as much as possible.

I "kit up" the job by emailing or posting to a website all the device configs:

"Bob here's the configs for the Sunshine Ranch project"
MainRouter.rsc
AP21.rsc
AP22.rsc
SW1.cfg
SW2.cfg
APFlash1
APFlash2
etc.

Bob knows how to get the configs into the devices.

My field techs are good, but they are not network engineers. They are installers and very good at it.
They know enough and we have given them the tools to be able to unbox and then winbox/web/console/tftp/etc and install.
Fast, cost effective and excellent results.
I can almost script the install down to when and where each component gets installed and config'd.

As much as I like the idea of a low cost vlan capable switch, it will cost more in the long run if I can't have a field tech quickly paste a config file into it and screw it to the wall.

It's just that simple.

You might think that I could simply make the switch config sitting at my desk, but that is not feasible.
I will spend more in time setting it up (where is the power supply?) than it is worth.

With an [ascii] human readable text based config, I can cut and paste and have a config done in about a minute as I'm sure lots of others on this forum can. Once you work with configs long enough it is like the Matrix, you can read it quickly.
For ROS, I put a handful of variables near the top that I can change quickly: IP/GW/PW/ID
Once the main router is up, I can use it to tweak anything else.

This is a real scenario - for me at least. I'm a lean shop and I need my new install done fast and right the first time.

To sum it up, you gave us ROS that had winbox and rsc files and then took it away in SwOS.
SwOS configs are a step backwards as far as I am concerned. It is almost as useless as the bin config file for a consumer router.

Bad decision by MT for me and I expected something different.
Building a brand is a lot about consistency.

But you can already do the same with the backup files! Give your tech 10 different files, each for it's own scenario. To make the files, you don't need to write them, just click the appropriate checkboxes, SAVE, then change to another configuration - SAVE again. This way you will have your 10 config files that you can give to your personnel.

Normis,
I appreciate you taking the time to read my post, and reply.

This is a philosophical subject now, as it is clear MT has no intent of making changes, despite multiple users asking for it.
My personal feeling is that consistency in ui is important for a brand.
"It looks, feels and smells like a Mikrotik product."

By not keeping the ui of ROS in SwOS, I think MT has made a mistake.

As one frequent user on this forum likes to say, "there are lots of ways to do it...".

As for config files, in practice there are very few standard configs. Nearly everything is custom.
And I don't want my "installer" (!tech) to think about which config file is which. They get paid to pull cable, terminate and plug in.

Besides, how would I name the 10 files so I remember which config is which? I can't put the full config as the filename....and I can't remember where I put my keys.

It is much easier, faster and logical to have a config file that can be edited and then sent to an installer:

RB450G_MPOE.rsc
RB250GS_Building1.cfg
RB250GS_Building2.cfg
RB250GS_Building3_1.cfg
RB250GS_Building3_2.cfg

And if during the install a problem is found with the physical layer, the config can be quickly changed and emailed to the installer or ftp'd to a RB.

I guess I could always write a config converter app.
Is the config file format published?

We can confirm Dude still loosing SMNP connection to RB250GS devices continously.
We can confirm loosing ability to ping TO devices at random times, the devices still reachable via http, only pings stop responding, and after a few minutes they start responding again, bridged plain network, not a NAT or routing problem.
Currently we have 2 RB250GS on our network both behave similar.
Ver. 1.2

Any ideas or updates on this?

We can confirm Dude still loosing SMNP connection to RB250GS devices continously.
We can confirm loosing ability to ping TO devices at random times, the devices still reachable via http, only pings stop responding, and after a few minutes they start responding again, bridged plain network, not a NAT or routing problem.
Currently we have 2 RB250GS on our network both behave similar.
Ver. 1.2

+1

We can confirm Dude still loosing SMNP connection to RB250GS devices continously.
We can confirm loosing ability to ping TO devices at random times, the devices still reachable via http, only pings stop responding, and after a few minutes they start responding again, bridged plain network, not a NAT or routing problem.
Currently we have 2 RB250GS on our network both behave similar.
Ver. 1.2

Any ideas or updates on this?

Update, sometimes (most of the time) HTTP access is also unavailable.

For the ping issue, I added static arp entries for the switches in the RB450G and I have not missed a ping since that time using netwatch.

This may help other access issues as well?

For the ping issue, I added static arp entries for the switches in the RB450G and I have not missed a ping since that time using netwatch.

This may help other access issues as well?

Thanks for the TIP, I'll do that... but that should be fixed by MTIK, I guess... isn't it?

JB

Are there plans to make SWOs access via telnet or ssh?
Because IMHO web UI is the worst it could be in such device :/

don't all switches have web config ?

No they don't.
It's not easy or quick to click, because you need to hawe X interface etc, and this is hard to create such conf by scripts.
If you don't want to create CLI, maybe there is way to make the backup file in some human editable form anf create tftp acces to maintain the conf file on the switch?

No they don't.

Maybe it's easy to click some checbox but with few switches, not with hundreds of ports
And this hard and impractical to make configuration changes drought scripts.

If you are so much against CLI, then maybe you can make the backup file "human editable" so there will by way of creating conf "by hand" or script and uploading it to switch by tftp or sth. similar.

I don't understand your point

What is so hard in making predefined config files and then just forget about the web interface?

1. Find a computer where you do have GUI and a browser
2. "Click-click" to make a generic config variant A
3. Save this as A
4. "Click-click" to make a generic config variant B
5. Save this as B
6. repeat ad nauseum
7. You now have config files for every possible switch configuration
8. Close web config and forget about it forever.

Why edit the files by hand every time, when you can have predefined setting files that need no editing? just pick the config you need.

Although I don't have this problem directly, I will throw in my thoughts (for what it's worth):

RouterOS has a CLI with ways to access it, and a built-in scripting language to configure things. This has helped in standardizing configuration, and in some cases to create "templates" for multiple devices.

When SwOS came, there were much speculation about it having a CLI, or at least a scripting language of some sort. At least Winbox. Since none of this is the case, what is SwOS doing in the well-known Mikrotik "style" of operating systems (aka RouterOS). As a previous poster said, it's all about consistency. I'm going to be blunt here: Cost means a little, but stability and consistency can mean the death of a company as we know it.

Mikrotik, please focus on these issues, instead of price as much. Cheaper isn't better in all cases. After all, we are real network admins/engineers who do real work pushing important data across our devices. It's much more important that we have solid hardware with few bug/few features that work very well.

I truly believe, in this market with lots of manufactures of network OS's and hardware, Mikrotik should be more open in it's design. Things like, "how would you like to improve config management?" You will get lots of suggestions, but at least they will be from the users who have been through the trenches to make this stuff work.

Just my thoughts (getting tired though).

I don't understand your point

What is so hard in making predefined config files and then just forget about the web interface?

Because I would have to create config for every possible situation.
If I would like to connect every customer to different vlan let say with the same id that he has in my database
(lets not consider neither it's good or bad idea for now )How can I predefine the config if I don't know what id would have potential customer etc. etc.
The point is that there are conf. that cannot be predefined(or predefining them makes no sense) but can be easily scripted through templates etc.

Of course you can always create web parser that will "click out" these conf for you but why go around, if?

@Normis.
We agree to disagree? Cool? I hate to upset the hand that feeds my need for mt products.

@dssmiktik
My thoughts exactly. MT should decide what it wants to be when it grows up. ROS was a nice start, now follow it through.
"SwOS", as it is branded, is not an OS.
It is an interface to an asic based router chip, the TF470
http://www.taifatech.com/Files/TF470_Pr ... ief_02.pdf
An interesting device, by the way. 200Mbps WAN-LAN throughput.

The hardware does all the work, not the software.
This may be part of the reason there is no winbox, etc. BUT, the chip does have a serial port!
Perhaps a few more $$ would have given us winbox, ssh and telnet, console......

@gzohop

Ditto.
Besides, what would I name the "variant" files?

Example: "10.10.1.xxx_p1_t_v10:15_p2_v11u_p3v12u_p4_v13u_p5_t_v10,16:20.cfg"

At some point the entire config is in the filename. I can't add comments that I can later search and I can't even read the files to find out what they do.

variant1.cfg, variant2.cfg, variant3.cfg will mean nothing a few days after I create them

Did litle(very litle) research and it seems Mt is limited/ by the chip they've used TF-470-BCL

http://www.cyberwin.com.cn/issuepic/200 ... t2i195.jpg

Haven't found full spec of this chip but if it has hardware Web acceleration so this is why they prefer to use it, or maybe it's not possible too implement other protocols with this chip :/

hmm
seems there is tftp support

"MANAGEMENT
Setup and configuration through web browser
Firmware upgrade via TFTP or Web"

"Click-click"

xD